Mainframe and AI: legacy is missing logs and owners, not age

CIO Dive reports AI agents helped sustain confidence in the mainframe. Three checks that tell you whether your system is legacy, and what to do about each one.

The platform everyone called obsolete can still tell you what it did yesterday

The year a system was born tells you almost nothing about the risk it carries. What does tell you fits into three checks you can run this afternoon: can you reconstruct what that system did yesterday without someone opening the database by hand, is there a human name that answers for it when it breaks at 2am, and does it come up from scratch on a clean machine without a step that lives only in someone's head. Pass all three and you have an old system. Fail two and you have legacy, even if the first commit is from 2019.

CIO Dive published today a story titled "AI adoption helps sustain confidence in the mainframe", backed by BMC's annual survey. The short read: companies brought agents in to help manage the platform, and confidence in it held up while modernization runs alongside. A machine the market has called obsolete since before smartphones existed got a new tool bolted on top and became more trustworthy. Hold on to that image, because it dismantles the most common excuse we hear on sales calls.

Age is a registration field, not a diagnosis

Rebuilding yesterday's order from the logs is the first of the three checks

"That system is from 2019, it's already legacy." I hear that almost weekly, and it almost never arrives with a measurement attached. It arrives as a feeling: the new team cannot read the code, the previous vendor walked away, nobody wants to put their name on what is running. That feeling is real and expensive. It just has nothing to do with the calendar.

The mainframe is the most stubborn proof of that. These are platforms with decades of service in banking, insurance and payroll, running transactions that cannot be off by a cent. They stay up for boring reasons: a record of everything that happens, people trained to operate the thing, written procedures, change windows with a named owner. The AI agent came in on top of that base. It works because there is something to read. No agent improves a system that never says what it did.

And the reverse case is funnier than it should be: a company with a two year old stack, containers, a clean pipeline and a green dashboard on the wall that cannot answer which change altered the shipping fee last week. The mainframe answers.

The three checks that decide whether you have legacy

These are the questions I ask before looking at a single line of code, when someone shows up asking for a rewrite:

• Instrumentation: if an order went out with the wrong discount yesterday, can you rebuild its path from logs, with timestamps and the value at each step, without asking a developer to query production by hand. Anyone who depends on a manual query does not have monitoring, they have an on call rotation.
• Ownership: write down the name of the person who can explain the commission rule without opening the code. If the same name shows up on four lines of your system list, that name is the most expensive asset you own, and the risk lives in their vacation calendar, not in the repository.
• Reproducibility: someone clones the repo on a machine that has never seen the project and brings the environment up using only what is written down. If the missing step lives in one person's memory, the system is already legacy, whether it is three or thirty years old.

Founders panic about the first one. The second is the one that drains the budget. I am not sure that ordering holds for a three person team where everyone wrote everything. It holds hard the moment the team turns over.

The `/health` endpoint that returns 200 and checks nothing

When the same name shows up on four lines of the list, the legacy is their calendar

My favorite piece of rotten shell is the health endpoint that returns 200 without verifying anything. It does not touch the database, does not test the queue, does not ping the integration. It returns 200 because the process is alive. On top of it sits a colorful dashboard showing uptime at ninety nine point something, and the board sleeps well. Its twin is the test with no assertion: coverage reports 80%, the test runs the function, claims nothing about the result, and the pipeline stays green.

The metric exists, the guarantee does not. That is how a 2019 service ends up more legacy than a 1994 platform: the 1994 one keeps accounts of what happened, the 2019 one keeps decoration. If you are weighing whether to rent a senior team for that kind of cleanup, our take on squad as a service covers when the model earns its keep and when it does not.

"My case is different, only one person here can touch it"

That objection shows up in every conversation, and it deserves a blunt answer: your case is not different, it is the standard one. Concentrated knowledge is the form of legacy that shows up least in a technical audit and most in the invoice.

The practical effect is dull. The person who knows becomes the bottleneck for every decision, planning starts waiting on them, and their market rate rises before you notice. If you want to size that bill, start with the current developer rates in Brazil and multiply by the weeks your roadmap sat still waiting for one person to come back from leave. Nobody puts that line in the budget, and it is bigger than the SaaS licence you cancelled last quarter.

The mainframe got a maintenance budget. Your system got a fixed price.

Here is the part nobody enjoys. The mainframe arrived in 2026 instrumented because someone paid for maintenance for thirty years, with contracts, procedures and named owners. It was never cheap, which is precisely why it still runs.

Most systems that reach us were born under the opposite model: fixed price, scope frozen on paper, no provision for what happens after go live. That model rewards a vendor for shipping whatever survives the demo and then walking away. Structured logging does not show up in a demo. Runbooks do not show up. Tests that actually assert something do not show up. Add up everything that never shows up in a demo and you get the exact list of what is missing from your 2019 system.

So our default answer to "nobody understands this code anymore" is rarely a rewrite. A rewrite freezes revenue for months and hands back, at best, the same product with no instrumentation. The order we use instead, described in how we work, is simpler: stop the visible bleeding, instrument enough to find where it starts, then argue about which part is worth replacing. Stopping the bleed is fast. Finding the source takes longer. Treating the disease is months of medicine, and anyone promising otherwise is selling a demo.

The AI agent fits exactly at that point in the order, not before. It reads logs, correlates alerts, suggests the small change, proposes the test. On top of a system that records nothing, it produces confident guesses, which is the last thing you want near code that moves money.

What you can do before Friday

Pick the system that comes up most often in your meetings about money. Answer the three questions in writing, with a name and a date next to each: who reconstructs what it did yesterday, who explains the rules without opening the code, who has brought that environment up from scratch this half. It takes about forty minutes and needs no vendor.

If all three answers carry the same name, you have found your legacy, and it has nothing to do with the date of the first commit. Some company out there kept a decades old platform reliable enough to put an AI agent in charge of maintaining it. Which of the three questions can your five year old system answer today without texting one specific person?