“Why then, can one desire too much of a good thing?”
– William Shakespeare, As You Like It

‍

In our Orchard Retreat earlier this month outside Nashville, we talked about how enterprises can adapt to an era of “software abundance,” when discernment and judgment, etc., etc., become the bottleneck. That’s a VERY popular topic right now, but curiously few relate to modernization.

Why? Well, modernization is... different. It’s not greenfield development (although I suppose it sort of is if you API the heck out of everything, but that creates its own complications). So we talked about the difference between getting the project “done” versus getting everything working together, the bits you’ve changed, and the bits you haven’t yet (or never will).

But first, the basic theory. A February 2026 economics paper from MIT, Washington University, and UCLA — Some Simple Economics of AGI — models these as two racing cost curves. The cost to automate is falling exponentially, driven by compute and accumulated knowledge. But alas, the cost to verify is biologically bounded: meaning, it runs on human time, human judgment, and human expertise, none of which scales like software.
‍
Put another way, you can’t automate what one of our participants aptly called “taste”. In the universe of modernization, that means the long pole in the tent is human-curated verification, that long, sticky morass at the end of an effort, somewhere between debugging and user acceptance testing.

But what if you could automate verification?

Because, unlike greenfield efforts, rewriting legacy systems has an exemplary model of behavior that represents what’s working already (drum roll, please): the existing system.
‍
To accept this, however, is to upend decades of “standard” modernization approaches. Three implications:

• It reframes the modernization goal from “reimagine” to “move, then improve.” Classic approaches treat the legacy system as a liability to be escaped. But if the existing system is the specification, the project logic inverts: you’re not racing to replace something broken, you’re exactly reproducing something that works, then selectively improving it.
• It makes automation useful precisely where it has failed. Automated tools have always handled the mechanical parts of modernization (e.g. translating COBOL) reasonably well. What they’ve never been able to do is know whether the result is right. Behavioral replication solves this by giving AI a ground truth to check against, not a test that it wrote for itself.
• It changes the risk profile in a way that organizations can actually stomach. Traditional modernization asks leaders to accept a long period of faith, one that might be longer than their career span at a particular organization. Incremental behavioral replication, by its nature, creates a continuously verified parallel system for the duration of the effort, where real results accrete rather than arriving all at once at go-live. Good stuff to report to the board.

None of this, of course, automates taste. But you can capture it. It makes previous judgment calls (for better or worse) portable. And once captured, it becomes something more valuable than mere documentation: it’s a complete inventory of every decision, workaround, and assumption ever made now visible, named — and sitting in a comprehensive test suite.

That means you’re not starting over (or creating tomorrow’s legacy/technical debt). You’ve just built a system for continuous modernization; you’re always able to capture the behavior, so you’re always able to change what you need to change. All the new stuff you want? Those are finally just engineering problems. And, as it turns out, we’re getting pretty good at automating that.

‍

‍

News and Views

Stephanie Walter at HyperFRAME wrote a clear and accurate brief about how the Mechanical Approach is structurally different from code-first modernization.

Maryna Klo at HackerNoon explains that while extracting business rules tells you what the system is supposed to do, it’s not that great at telling you what it *actually does* across the full range of conditions it’s encountered over decades. Perhaps system behavior, then, is a better source of truth?

Some academic validation: a comprehensive test suite built against the existing system is, in the language of a recent University of Victoria paper, one of the few reliable tools for paying down intent debt — making explicit, in a form both humans and AI agents can consult, what the system was actually built to do.

‍

‍

From the Orchard

Here’s to another Google Cloud Next! A major highlight this year was when SulAmérica, one of South America’s largest insurers, took the stage to talk about how Imogen was powering (and accelerating) their modernization success with Imogen. We also sponsored our first booth and co-hosted a fabulous networking party at the 1923 Prohibition Bar with Thoughtworks.

It’s been a year since we launched Imogen — and the platform is now replicating upwards of 10,000 lines of COBOL per week, per engineer, fully-verified and production-ready. Edward Hieatt reflects on some other noteworthy achievements.

AI can give you faster, but can it also give you confidence of success? We’re hosting a webinar with our partner Thoughtworks on why most modernization attempts fail — and how a test-driven, behavior-first approach flips the equation. Register here.

Thought experiment: at current migration rates, we’d need 844 years to clear the estimated inventory of 800 million lines of COBOL. Rachit Awasthi ran the numbers using our approach — and the comparison is stark. Ask us about how you can increase the surface area of where AI is actually helpful.


Curious to learn more? Say hello@mechanical-orchard.com.‍

‍

—

View all newsletters here

‍