Welcome to another edition of Talsco Weekly

IBM i Briefs: 💰 What a P05 IBM i box costs now. ⚛️ IBM’s quantum foundry lands $1 billion.
AI: 🗝️ Give your AI agents an authority map.
Career: 🔮 What does an IBM i developer do in 2028? 🗂️ Four boxes for a developer’s day.
Database: 🐝 The database guardrail IBM i has always had.
Learning: 📚 The IBM i study guide one developer built for everyone. 🧪 IBM Bob took an IBM i exam. The grade isn’t the story.
Modernization: 🗺️ Don’t modernize the oldest code first.
Open Source: 🐧 The operating system you shape by describing it. 🐘 PHP 8.6 reaches Beta 3.
Trends: 🔀 The partition line is becoming a career line.
Did You Know: 💡 Where does the AI actually run on IBM i?

IBM i Briefs

First real pricing on the Power S1112.

The Power S1112, the only Power11 machine in the P05 IBM i software tier, has shipped for six weeks without published IBM pricing. Reseller quotes fill the gap.

A four-core rack with 64 GB and 1.6 TB of flash runs $41,950. With 128 GB, 12.8 TB, and a tape adapter, it’s $88,000. The same build with ten cores, in the P10 tier, is $98,000.

There’s no one-core option. IBM i subscriptions are extra, and Power11 has no perpetual licenses.

⚛️ IBM’s quantum foundry lands $1 billion

A chip fab built only for qubits.

The U.S. Department of Commerce finalized a $1 billion CHIPS Act award with Anderon, IBM’s quantum foundry company, first announced in May as a letter of intent. IBM is adding $1 billion of its own.

Anderon runs a 300-millimeter pure-play quantum wafer fab in Albany, New York, open to the wider quantum industry rather than IBM alone. Its wafers support superconducting qubit arrays and the signaling and readout chain around them.

First wafers are already running through the facility.

AI

🗝️ Give your AI agents an authority map

Know what each agent can reach.

An investigation into a recent incident found roughly 700 AI agents coordinating an attack on a major company, organizing through a message board nobody sanctioned.

The lesson for IBM i shops: give agents an authority map before you give them more tools.

For every agent in production, know which systems it reaches, which data it reads, which actions it executes, which agents it can hand work to, and who can revoke it instantly.

Then test the group, not just each agent. Narrow the permissions.

Career

🔮 What does an IBM i developer do in 2028?

The answer gets blurrier the further out you look.

Developers keep asking me the same question. What do I need to do next?

The better question is what the role will actually look like. And the honest answer comes with a confidence level that drops the further out you look, because AI is moving faster than anyone’s roadmap.

IBM i is a special case. The scarce asset was never RPG syntax. It’s the business logic.

Why that 1998 patch exists. Which nightly job quietly feeds the GL. What breaks if you touch order entry at month-end.

AI can already read a 4,000-line fixed-format program and explain what it does. What it can’t explain is the part that was never written down. Why that rule exists, who asked for it, and what broke last time. And it can’t sign off when the change hits production and the auditor comes calling.

Right now. AI is a strong assistant on the reading side. Explaining legacy RPG, converting fixed to free, writing SQL, drafting documentation.

Experienced developers get much faster, because they know when the answer is wrong. Newer developers get faster too, and that’s the risk. Fluent output reads like correct output when you don’t yet know the difference.

Here’s the split nobody names. Writing new code and changing a thirty-year-old program are not the same job.

On a greenfield app, the AI writes it, the tests prove it, and a bad guess costs an afternoon. On IBM i, the program is the spec, and too often the only test harness is production.

That’s why legacy trails, and it isn’t the model’s fault. It’s verification.

One year. Agents take scoped tasks end to end. Refactor a program, wrap logic in an API, write the test cases. Some shops are already there.

Two years (low confidence). The valuable person is a system owner. Someone who translates between the business and the agents, knows the stack from Db2 to the job scheduler, and owns the outcome.

A three-developer shop may need fewer people. Rarely zero. One person covers more ground, and that hire matters more.

Past two years? It’s anyone’s guess.

Our Take: AI doesn’t eliminate the IBM i developer. It eliminates the IBM i developer who only codes.

The gap between shops won’t be who has AI. It’ll be who can prove a change is safe.

So don’t wait for the map to finish drawing. Build the skills that hold up on every version of it.

Learn the business, not just the program. Get serious about testing, because AI is only as safe as your ability to verify its work. Practice explaining the system to people who have never logged into IBM i.

And a question for shops. If AI takes the junior work, where do your future seniors come from?

The apprenticeship ladder ran on maintenance tickets. That makes a deliberate Hire, Train and Mentor model more important, not less.

Wondering where your IBM i career goes next? Let’s talk.

Building the team your shop needs in 2028? Book a call.

🗂️ Four boxes for a developer’s day

Urgent and important aren’t the same thing.

An IBM i developer’s day fills up fast. The user who calls, the job that failed overnight, the ticket someone marked urgent.

James Clear’s take on the Eisenhower Matrix sorts every task into four boxes: do it now, schedule it, delegate it, delete it.

Urgent is what reacts to you. Important is what moves the work forward. Most days, urgent wins by default.

The box developers skip is delete. Clear borrows a programmer’s line for it: “There is no code faster than no code.”

Our Take: Look at what sits in your important-but-not-urgent box. That’s usually where the career work lives.

Documenting the business logic nobody wrote down. Learning SQL properly. Testing what the AI wrote. Training the junior.

None of it will ever be urgent. All of it is what makes you hard to replace.

Database

🐝 The database guardrail IBM i has always had

AI agents can now change a database under supervision.

A database DevOps vendor has built a governed path between IBM Bob and the database.

An AI agent proposes a schema or data change. Instead of touching the database directly, the request routes through a control plane.

Policies get enforced, risky changes get blocked, rollback readiness gets checked, and every action is audited before it reaches production.

The vendor pitches it as the guardrail for agents working at machine speed. Speed without losing control. Good pitch, and a real gap filled for most database shops.

Our Take: Read that list again. Policy enforcement, a rollback point, a full audit trail on every change.

Db2 for i has shipped most of it for decades, in journaling, commitment control, and object-level security.

This article isn’t about IBM i. But the governance model everyone is now bolting on is close to native on your platform. The edge is knowing how to use it.

Learning

📚 The IBM i study guide one developer built for everyone

A free IBM i learning site, fixed to free.

I just spoke with an RPG developer who has been on the platform since 2017. Fixed and free format first, then deep into JavaScript, AI, and MCP. Full-stack IBM i.

He built a learning site, partly to capture what he knows. Now he wants the whole community to have it.

It’s substantial. 32 chapters, 9 learning paths, 200 explained questions, 44 RPGLE and CL coding labs, and a symptom-first guide to common issues. Every chapter links back to IBM documentation and Redbooks. Free, no login.

New to IBM i: start with the foundations path. Objects, libraries, and name resolution, in plain English, with fixed and free format side by side.

For the veteran: go straight to the common issues and interview drills. A sharp way to check a candidate, or your own blind spots.

One honest note. The code examples haven’t been compiled on an IBM i host, so run them on your dev partition before trusting them.

Our Take: For years, the IBM i story has been the retirement cliff. That story is missing a character.

The developers who came in around 2017 now have close to a decade on the platform. And with AI in hand, they are building things like this. Not just code. Ways for the next person to learn.

That doesn’t make 30 or 40 years of experience less valuable. It makes it more valuable.

The veteran who knows why the system works, paired with a developer who can turn that knowledge into something teachable, is a real succession plan.

That pairing is the superpower.

Building your IBM i skills, or sharing what you know? Let’s talk.

🧪 IBM Bob took an IBM i exam. The grade isn’t the story.

Where the AI knew IBM i, and where it guessed.

An IBM i solution architect built a six-test benchmark for IBM Bob. Synthetic code, planted defects, and a hidden answer key Bob never saw.

Bob averaged 8.2 out of 10. The average isn’t the story.

Bob was strong at understanding intent. It explained mixed fixed and free RPG, caught buried logic bugs, replaced a row-by-row cursor with one set-based UPDATE, and scored highest on Db2 index reasoning.

It slipped on platform specifics. Activation groups. Parameter semantics. An HTTP function called with response columns it doesn’t have, and a library command that doesn’t exist as written. Answers that looked right and wouldn’t run.

New to IBM i: treat the misses as your study list. Where Bob guessed is where the platform fundamentals live.

For the veteran: that’s your edge in one line. Bob drafts. You know which detail breaks in production.

Our Take: Two IBM i learning resources crossed my desk this week, both from developers publishing what they know for anyone to use.

That’s the shift. Knowledge that used to live in one head is getting written down and shared.

This benchmark shows why that matters. AI sounds just as confident when it’s wrong. The more solid IBM i knowledge the community puts out in the open, the easier it gets to tell the difference.

Modernization

🗺️ Don’t modernize the oldest code first

Age is a weak modernization metric.

Most modernization plans start with the oldest, ugliest code. This piece says that’s the wrong filter.

A thirty-year-old program that rarely changes may not be worth touching. A newer one inside pricing or billing may be urgent.

Better filters: business value, change pressure, operational risk, architectural leverage, knowledge risk, and delivery risk.

Change pressure is the sharpest. Don’t ask how old the code is. Ask how much future work passes through it.

And one of the six isn’t code at all. Knowledge risk is a staffing question.

Open Source

🐧 The operating system you shape by describing it

Mouse optional. The keyboard runs everything.

Omarchy, an opinionated Linux build from DHH, is having a moment. Over a million downloads in its first year, and $18.5 million pledged to its foundation.

The pitch: someone makes the hard setup choices, and AI agents handle the rest. Diagnosing crashes, fixing problems, even building plugins from a plain description.

Then there’s the part that will make an IBM i person smile. Everything happens by keyboard. The manual says it plainly: when the system first starts, you can’t do a thing with the mouse alone.

Config files, terminals, logs, hotkeys. Things a person and an agent can both read and drive.

Our Take: None of that is new to you. Command entry, function keys, hands never leaving the keyboard.

The industry called that obsolete and spent twenty years bolting mice and browsers onto everything. Now the most talked-about Linux desktop of the year ships mouse-optional, and the argument is speed. Fewer clicks, no hunting through menus, and plain text an agent can read.

The 5250 got mocked for the wrong reason. Green screens aged badly on looks, not on ergonomics.

IBM i was chef’s choice long before omakase was a tech word. Operating system, database, and security, decided for you and built as one.

And Power already runs Linux in partitions right beside IBM i, on the same box. That Linux side is where much of Power’s AI tooling lives.

The question for most shops isn’t whether they can experiment there. It’s whether anyone is.

Got an old computer lying around? Then test out Omarchy this weekend!!

🐘 PHP 8.6 reaches Beta 3

A release cycle worth watching, not installing.

PHP 8.6.0 Beta 3 arrived September 10, the third beta of the 8.6 cycle. Release candidate 1 is planned for September 24.

The team is blunt about it: this is an early test build, not for production. The NEWS and UPGRADING files list what’s new and what breaks.

If PHP is part of your IBM i toolkit, this is the window to test on a dev partition, well before 8.6 goes final.

Trends

🔀 The partition line is becoming a career line

IBM i roles are starting to cross over.

On a Power server, a partition line separates IBM i from Linux. For years, a similar line separated IBM i roles. Admins ran the box. Developers wrote the RPG.

It wasn’t always that way. In many shops, the RPG developer ran the box too, back when applications were simpler. As the stack grew more complex, the roles split.

Now AI is pulling them back together, this time from the admin side.

I recently spoke with an IBM i architect who has spent his career on the hardware and OS side. When his company’s RPG developer retired, he used AI to step into the development work and fill the gap.

It didn’t erase the need for RPG expertise. It changed who could supply it.

The same shift is happening on the platform. Much of the AI work on Power runs in Linux partitions next to IBM i. The people who move comfortably across those lines, admin to RPG or open source developer, IBM i to Linux, are the ones shops will lean on.

From the Field: This isn’t the generalist replacing the specialist. The architect pulled it off because he already knew the system. AI gave him a new way in. It didn’t give him the knowledge.

That’s the hiring signal. Deep platform knowledge, plus the curiosity to cross a line you used to stay behind. Job titles will lag behind the work.

Smaller shops should watch this closely. Many outsourced the admin role because it wasn’t a full-time job. Someone who runs the box and writes the RPG might be.

And for shops facing a retirement, look at who’s already in the building. Your next developer may be running the box right now.

Crossing a line in your IBM i career? Let’s talk.

Planning around a retirement? Book a call.

Did You Know?

💡 Where does the AI actually run on IBM i?

Not inside IBM i. On Power11, the model runs in a Linux partition on the same physical machine, using the chip’s on-chip matrix engines or a Spyre accelerator, a 75-watt PCIe card holding 32 cores.

Your RPG program calls it like any other API.

Same box. Same data. Nothing leaves the building.

Join

Contact us

If you are an RPG programmer looking to explore opportunities or a client who is looking for a talented IBM i professional, please contact us. We look forward to assisting you.

Do you know of someone who could benefit from Talsco Weekly? If so, please use the social media buttons to spread the word. Thank you!

Talsco Weekly: Who writes the RPG when the developer retires?