Standing Still Was Never Free

Standing still feels like the safe choice. It almost never is. It is usually the expensive choice that has learned to look harmless.

Start with the thing most large organizations are quietly dreading. Somewhere in the company there is a mountain of old code that needs to be modernized. It runs something that matters. It was written by people who have moved on. It has grown for a decade or two, and it is not getting smaller.

There are two honest ways to think about what to do with it, and one dishonest way that almost everyone uses.

The dishonest way is this. We examine the risks of using AI on that code in enormous detail. Can the agent hallucinate? Can it introduce a subtle bug? Can it misread the legacy? All real questions. And then, without noticing, we write down the risk of doing nothing as zero.

That is the cheat. Doing nothing is not the absence of risk. It is a different risk, and we simply refuse to put it on the page. The mountain keeps growing. The people who still understand the code keep retiring. The competitor who was willing to move keeps pulling ahead. Every one of those is a cost. They are just invisible, because nobody books them.

And there is a hard limit underneath all of this. You cannot hire your way through a large legacy mountain at the pace reality demands. The people do not exist in the numbers the plans assume. The ones you do find need years to learn a system whose original authors have already retired, and the understanding that retired with them cannot be hired back at any salary. This is not theory. I hear it directly from organizations sitting on exactly this problem. Some of them have started making a choice that would have sounded reckless two years ago: consciously taking the AI risk over what I have come to think of as the recruitment risk. The risk that your entire modernization plan rests on a staffing forecast.

And this calculation is not confined to software. A senior executive in a research-heavy industry recently walked me through his version of it. His company has a forecast for what it needs to deliver over the coming years, and behind that forecast sits a number: how many skilled people they would need to recruit to get there. He does not believe in that number. So they are betting on AI instead. Not because the AI is ready. It isn't, and he knows it. But when he weighs the two probabilities against each other, an unproven technology against a hiring plan he considers unrealistic, the technology wins. He did not call it a transformation. He called it a hedge.

That is the recruitment risk, priced by someone whose job is to price risk. Both paths are uncertain. He put both on the same page, and the staffing plan lost. Coding agents are, for many legacy systems, the same bet in a different building. The industry already has a name for this at scale: the software factory. Rows of AI agents reading, rewriting and testing code around the clock, at a pace no human team can match.

So the answer is just to turn the factory loose on the mountain and go?

No. And this is where I have to be careful, because "standing still is also a risk" is exactly what every salesman of every immature technology has ever said. It is how people get talked into reckless things. If I stop there, I have written you a blank check.

So here is the part that separates the two. Speed hides its own risk too. Faster code that is subtly wrong ships that error downstream, with confidence, at scale, and you find out much later. The point is not that the AI path is safe. The point is that you have to stop comparing a visible risk to an invisible zero. Put both on the page. Count them honestly. And when you do, standing still usually turns out to be the more expensive one.

Usually, but not always. And that qualifier is what separates an honest argument from a sales pitch. The salesman always tells you to move. I am telling you to count, and to accept that sometimes the count will say wait.

Now the hardest problem, because it cuts against everything I just said.

Legacy is the single most dangerous place to point a coding agent. It is code nobody fully understands anymore. It often has no tests. When it breaks, it breaks in production three weeks later, in a way nobody predicted. That is the most expensive kind of truth to verify. So pointing a software factory at undocumented legacy and pressing start is not bold. It is the most dangerous thing you can do, only now faster and at scale.

Both things are true at once. You cannot afford to stand still, and you cannot afford to move recklessly. That tension is not a flaw in the plan. It is the plan, if you resolve it correctly.

So go back to what makes legacy so dangerous in the first place. Nobody fully understands it. Nothing documents it. There is no specification to hold the new code against, and there is nobody left who could write one.

Except the system already did.

It runs. Every day, in production, it does exactly what it does. Every input it accepts, every output it produces, every strange edge case nobody remembers is a line in a specification that nobody wrote but everybody trusts, because the business has been standing on it for twenty years. The old system is an oracle. Ask it what correct looks like, and it answers. The most dangerous property of legacy, that it exists only as behavior, turns out to be the way through. Capture that behavior, and you can turn what the system does into the specification it never had on paper.

Once you have that, modernization becomes verifiable. The question stops being "is the new code correct?" which is impossible to answer for a system nobody understands. It becomes "does the new code behave like the old one?" which is measurable, and automatable, and something an agent can be held to.

The expensive truth just became cheap. Not because the model got smarter, but because the old machine can answer.

This flips the whole job. The real work in modernizing legacy with agents is not letting the agent rewrite the code. That is the easy part. The real work is building the harness that turns the old system into a spec. Whoever does that can industrialize modernization at the pace the business actually needs. Whoever skips it is just playing with fire more efficiently.

And this is where the factory metaphor quietly falls apart. A factory multiplies the identical. This work is the opposite. It is about characterizing the unique, one strange behavior at a time, before anything gets multiplied at all. The software factory's real product is not code. It is verifiability. The code was never the scarce thing.

I want to be honest about two more objections, because a serious reader will raise them if I do not.

The first. Is the bottleneck really developers? In many legacy projects it is not writing code that is slow. It is understanding what the system is supposed to do. Why a specific odd exception exists. Which business rule is buried in line four thousand. That knowledge often retired years ago, and an agent does not write it back into existence faster. It can replicate a bug faithfully and call it modernization. The oracle helps here, because it lets you preserve behavior without first understanding it. But preserving behavior and modernizing correctly are not the same thing, and you have to say that out loud. Carrying subtly wrong behavior forward, with total confidence, at scale, is its own kind of failure.

The second. A competent risk officer will tell you that known risks weigh more than hypothetical ones, and that caution with immature technology is rational. That is not a foolish position. It deserves a real answer, not a dismissal. The answer is that the risk of standing still is not hypothetical. It is just deferred, and deferred risk is the most dangerous kind, because it accrues quietly while everyone congratulates themselves on being careful. The executive with the hedge has not become less careful. He has become a better accountant.

So the choice was never move fast or play it safe. Both paths carry risk. The only honest move is to make both visible and count them properly, especially in the systems where getting it wrong costs you more than a bug report. Where it costs you in exposure, in trust, in the kind of thing that does not roll back. In those systems, the cost of standing still is almost always the number you underbooked.

You will pay to cross that mountain either way. The only real choice is whether you pay now, deliberately, on your own terms, or later, under pressure, after the last person who understood the system has already gone.

Standing still was never free. It was just an invoice you had not opened yet.