How AI Ends the Legacy Modernization Cycle in Healthcare Software

Every legacy system in healthcare was once a modernization.

Somebody scoped it, defended it in front of a board, funded it, built it, and shipped it. It worked. Then over the next ten or fifteen years the people who built it moved on, the reasoning behind it left the building with them, and what stayed was code nobody could fully explain. Now it sits on your risk register, and somebody has quoted you a number to replace it.

That number is mostly the price of recovering knowledge your organization already paid for once and then lost.

We have been running this cycle for forty years. Build, forget, rediscover, rebuild. Every turn costs close to full price because every turn starts from almost nothing. The rules live in the code. The reasons live in people. The code survives and the people leave.

I believe that cycle is ending, and I do not think the industry has caught up to what that means.

The cost story is the smaller half

My partner Shawn Crowley published a piece worth your time: Getting the Green Light on Your Rewrite. His argument is that agentic engineering changed the economics enough that shelved modernizations deserve another look, and he puts numbers on it. Discovery work compresses by roughly half, because agents read the old codebase directly instead of analysts reconstructing it over months. Replicate work compresses by about 60%. Net-new work by about 30%. One platform modernization in his model goes from 100 weeks to 44.
He is right, and I would go further. Cheaper is the smaller half of this. The larger half is that we finally have a way to stop paying the same bill twice.

What changes when the work happens in writing

To direct an agent, you have to say what you mean.

You state the intent before anything gets built. You state the rules the system has to follow and the constraints that cannot be violated. When the agent proposes something wrong, you say why it is wrong. When you reject an approach, the rejection and the reasoning both get written down, because writing them down is how the work moves forward.

None of that is discipline anyone has to impose. It is the mechanism. The record accumulates as a byproduct of building rather than as a document somebody has to go produce afterward, which is why it actually gets produced. Every team in this industry has a policy requiring design rationale. Almost none of them have design rationale, because the policy asks people to stop working and write. This does not ask.

So you come out the other side holding two things. The new system, and the reasoning behind every decision in it. Why the eligibility rule carries that exception. Why the field is nullable. Why a workaround somebody added in 2014 turned out to be load-bearing. Not a rule living in a developer's head. Not a constraint only your longest-tenured subject matter expert can explain. Written down, in sequence, in a form the next team can read.

Why this record does not rot

The fair objection lands right here. Documentation always rots. Every organization has a wiki full of pages that were true in 2019.

Those pages rot because nothing breaks when they do. They get written for an audit or a policy, read by almost nobody, and there is no moment when being wrong costs anyone anything.

This record behaves differently, because it is the input to the next change rather than a description of the last one. When an agent modifies the system, it works from the accumulated rules, constraints, and prior decisions. If that context is missing, the change gets made without any knowledge of why the rule existed. If it is stale, the change gets made against a rule that stopped being true. Either way it shows up fast, in the output, on an ordinary working day.

That turns maintenance into self-interest. Keeping the record current is how you keep the system changeable. It stays current for the same reason your test suite stays green, which is that letting it break makes tomorrow harder in a way you feel immediately. The record is load-bearing now, and load-bearing things get maintained. Documentation nobody reads is the only kind that decays.

One requirement comes with that, and I would write it into a contract. The record has to live with the code, in plain text, in a repository you own. A record that lives inside a vendor's platform is rented rather than durable. Portability is what carries it across the next team, the next tool, and the next decade.

Which means the next modernization does not start from archaeology. It starts from documentation. The cycle that made this expensive stops running.
That is what I mean by the last expensive modernization. Not that software stops needing to be replaced, because it will keep needing that. The full price you are being quoted right now, the one that includes rediscovering everything your own organization once knew, is a bill you should only have to pay one more time.

Why this lands hardest in health

Everything above is true in any industry. It is worth more in yours, for three reasons.

Your knowledge decays faster than anyone's, because it is not only technical. It is a coverage rule, a consent requirement, a clinical workflow that exists because of an incident in 2016. That kind of knowledge is exactly what never makes it into a comment in the code.

You are the one industry legally required to explain yourself. Everywhere else, design rationale is good practice. In your world, an auditor can ask why a decision was made and expect an answer years later. You have been trying to produce that record by hand, at real cost, with real gaps. Now it falls out of the work.

And you are better positioned to use it than anyone. What makes agentic engineering dangerous is generating more work than anyone can meaningfully check. What makes it safe is a definition-and-review discipline strong enough to keep up. Teams outside regulated industries are building that discipline from nothing right now, mid-project. You already have it, and you have been carrying it as a tax while others moved faster without it. That tax is the asset now.

Two cautions before anyone gets carried away.

Raw agent transcripts are raw material and not an audit trail. Somebody has to decide at the start which parts get promoted into controlled documentation and which stay as project history. Do that on purpose and you have something genuinely new. Skip it and you have a very large folder nobody opens.

And do not apply Shawn's percentages evenly to a regulated project. Replicate is a loaded word when a regulator sits downstream of you. Demonstrating that behavior a patient or an auditor depends on did not change is a deliverable, and it gets produced whether the code took four weeks or forty. My working assumption is that verification compresses more slowly than the build does. Ask for that line separately and hold it closer to flat.

The trap

The obvious move after reading Shawn's piece is to buy your engineers AI licenses, wait two quarters, and re-run the estimate. Adoption looks fine, a couple of your stronger developers get genuinely faster, and the modernization has not moved.

My partner Mike Marsiglia explained why with a factory floor. You are limited by your slowest work center, so speeding up one station relocates the bottleneck instead of raising output. McKinsey found teams pairing AI with structured process saw 16 to 30% productivity gains and 31 to 45% quality improvements. Faros AI tracked 1,255 teams that adopted tools without changing process and found no measurable improvement at all.

For everything above it is worse than a wash. A developer working faster on their own produces no durable record, so you buy the speed, skip the part that compounds, and set the next generation up to pay full price again. Our process is published in Agentic Engineering for Teams if you want the mechanics.

What to ask for

If an estimate is sitting in a drawer, do not go argue about AI. Do two things.

Split the number into discovery, build, and verification, then get a fresh estimate on each line separately. Expect discovery to move the way Shawn describes, build to move with it, and verification to hold.

Then ask the question almost nobody is asking yet. When this project is finished, what will the written record look like, where will it live, and which parts of it land in our controlled documentation? Ask it before the work starts, because it changes how the work gets run. A team with a real answer has done this before. A team that treats it as an afterthought is about to hand you another system nobody can explain in 2038.

The part I care about more than the money

I was talking recently with a leader at a health plan who lives inside one of these systems. Somewhere in the conversation something shifted. The complexity had always been a weight she carried, too large to ever really see into, and the idea that a machine could finally read the mess and explain it back gave her something I do not hear often in those rooms. Relief.

Our team saw the same thing on a state agency codebase of about a million lines, roughly 84% COBOL, single programs past 18,000 lines, almost none of the original authors still around. Work that used to take subject matter experts weeks came back in days, as a draft they corrected rather than a blank page they filled.

That system was somebody's modernization once. Somebody stood in front of a board and defended it. Everything they knew is gone, and we spent real money learning it again.

We do not have to do that to the people who come after us. That is the part I would take to your board.

‍