The rewrite taboo did not die of old age. It died of a price change.
I made that argument in July: for systems whose intent lives in an executable oracle, the cost of a full rewrite collapsed. One engineer porting roughly half a million lines of Bun from Zig to Rust in eleven days was the receipt. Thousands of tests and a hard compatibility target meant every generated change faced an examiner that never got tired and never got polite.
That argument stopped where the evidence stopped, at one codebase with a conformance suite standing behind it.
An enterprise backlog lives at a different scale. It is forty systems, or four hundred, many of them older than the teams operating them. Their intent lives in exception queues, hardcoded business rules, regulatory interpretations, production workarounds, and the memory of people who retired. When the repricing reaches that portfolio, the question is no longer simply whether rewriting has become cheaper. It is which systems have become economically eligible for a rewrite, and which have not. The sort key surprised me.
A system's rewrite price is set by its answer key, not by its code.
Everything in this post follows from that sentence, so the term deserves a real definition before it does any more work.
What Bun had that your policy administration system does not
The July argument used a term from software testing: the executable oracle. An oracle is anything that lets a machine grade the question that decides a cutover: does the new system behave like the old one everywhere that matters?
Conformance suites qualify. So do test suites with real behavioral coverage, reconciliations that must balance to the penny, and recorded production traffic that can be replayed against both systems and diffed. Bun was unusually rewritable because that question had a mechanical answer.
Most enterprise systems face no such examiner. Their correctness lives in behavior: the override a team added in 2011, the batch job that runs twice at quarter-end for reasons nobody documented, the field that means one thing to claims and another to finance. The system is often its own only specification.
The first person who reviewed this draft read "oracle" and asked what the database company had to do with any of it. It was a fair question about the wrong company, and it convinced me that the testing term does not travel well outside its discipline. From here on, I will use a plainer name for the same idea: the answer key.
An answer key can establish equivalence. It can show that the replacement behaves like the system it is replacing. It cannot, by itself, prove that the old behavior is still desirable.
That distinction matters. A characterization test can faithfully preserve a defect that downstream systems now depend on. A replay harness can prove that a thirty-year-old exception still fires without telling anyone whether the exception should survive. The answer key tells us whether the new system is the same. A specification tells us whether the old system was right. Modernization needs both.
The answer key inventory
Here is the sorting exercise I would run against any modernization backlog this year. Score every candidate system into one of three rewrite-readiness tiers, and be stingy about the first one.
The stinginess matters because every incentive in a large organization pushes toward overclaiming. A team that reports 80 percent test coverage is reporting a number about lines, not necessarily a number about behaviors. The paths that sink cutovers hide in a different kind of gap: the quarter-end path, the leap-day path, the retry storm nobody has rehearsed since the incident that created it. Tier placement is a bet on a cutover weekend, so score it like one.
Tier 1: the answer key exists. This tier holds calculation engines with golden datasets, protocol integrations with conformance suites, and systems whose outputs already reconcile daily against a trusted external record, such as the general ledger. Teams claim this tier freely because "we have tests" always feels true. The membership test is blunt: would you bet a cutover weekend on green? Systems that pass just became some of the cheapest rewrite candidates in the portfolio, and there are fewer of them than most architecture reviews suggest.
Tier 2: the answer key is constructible. The system's behavior is stable and observable even though nothing checks it comprehensively today. These systems reward a specific move: build the answer key before touching the replacement. The toolkit is familiar, just rarely funded as the first deliverable: characterization tests that record what the system actually does, bugs included; capture and replay of production traffic; and shadow runs in which old and new process the same day while a reconciliation compares their outputs. The modernization project starts life as a verification project, and that inversion is the strategy.
For many systems in this tier, the answer key will cost far less than the rewrite it de-risks. It can be built while the old system remains in production, and it retains value even if the rewrite is delayed. A characterization suite can improve ordinary maintenance, incident diagnosis, vendor changes, and future migration work. It is not automatically cheap, especially when the legacy system is poorly observable, but it is one of the few modernization investments that can still pay off when the larger program pauses.
Tier 3: the answer key is absent or contested. Nobody agrees on what correct means. Two business units interpret the same field differently, a known defect has become load-bearing, or the behavior itself is the subject of an unresolved policy dispute. The repricing has not reached this tier because the organization cannot yet state what a replacement must preserve, what it should intentionally change, or who gets to decide.
These systems need intent recovery first. Someone has to write the specification the system never had, resolve the disagreements hidden inside current behavior, and identify which accidents deserve to survive. That work is human, political, and slow. I made the case for the durability of that artifact in The Spec Is the Product. Tier 3 is where that argument gets expensive.
These tiers do not replace portfolio prioritization. A Tier 1 system with little business value may still wait, and a Tier 3 system with an unacceptable security or operational exposure may demand immediate investment. The tiers answer a narrower but newly important question: can a replacement be proven well enough to make the rewrite economically credible? The roadmap still has to combine that readiness with value, urgency, and risk, and the combination changes the conversation from "what should we modernize?" to two better questions: "what must we modernize?" and "what can we now modernize with evidence?"
The smallest answer key I own
I ran a miniature version of this exercise in July on my own laptop, on a project with no enterprise stakes.
MacHeadroom is a Mac menu bar app I am building that shows the top CPU and memory consumers, with one twist: it consolidates helper processes into a single row per application, so a dozen Chrome processes appear as Chrome. Every number it displays is a claim about the machine, and a monitoring app that shows plausible wrong numbers is worse than no app at all.
The answer key came with the operating system. macOS already exposes process accounting through tools such as ps and Activity Monitor. Before polishing the interface, I built the reconciliation: sample the system, consolidate the processes my way, and compare the result against the platform's own accounting every five seconds, with two percent as the permitted drift. The comparison lives where the mistakes live, in the consolidation itself, because a dozen Chrome helpers have to sum to what the platform says Chrome is using, every cycle, or the row is wrong.
MacHeadroom is greenfield, so I will not dress it up as a rewrite story. It is the answer-key discipline at its smallest useful scale. The checkable truth was sitting there the whole time. The only meaningful decision was to compare my output against it before trusting what I had built.
Tier 2 work on a forty-year-old system follows the same principle with more zeros, more stakeholders, and much less forgiveness.
The budget line moves
Put the tiers against a project plan and the old cost model starts to look incomplete. Construction dominated the traditional rewrite estimate, which is why planning centered on lines of code, modules, integration points, and developer-years. Generation is getting cheaper, so the relative weight of the remaining work increases. The expensive questions become: can we recover the intent, build the answer key, reconcile the data, prove the integration behavior, and execute the cutover safely? The dominant cost moved rather than disappeared.
The second edition of my book gives this discipline a name: evaluation capacity as a separately funded constraint. Treat the answer key as a capital asset with its own budget line, not as a testing task buried inside the construction plan.
The asset case is straightforward. A project's replacement code ships once. Its answer key can gate every future regeneration of the system, every model upgrade, every vendor substitution, and every material change after the cutover. It can also improve maintenance and change confidence in the existing system before the rewrite begins.
I made the broader case in Trust the Gate, Not the Actor and The AI Operating Ledger. The modernization backlog is where that accounting becomes operational. A business case that prices the port but hides verification inside it is still using the old curve.
Score three, pilot one, scale on evidence
The first move fits inside a quarter. Pick three candidate systems and score their answer keys against four questions:
- Does a failing test exist for every behavior that matters?
- Can a representative period of production activity be replayed against both systems?
- When old and new disagree, who arbitrates, and against what record?
- What evidence will risk, audit, and any relevant regulator accept as proof?
Write the answers down. The scores will probably disagree with the current roadmap, and that disagreement is useful.
The system everyone wants to modernize, the one with the executive sponsor and the conference-slide architecture, may score Tier 3 because its correctness is politically contested. The unglamorous batch process that reconciles to the general ledger every night may score Tier 1, even though nobody has proposed touching it in a decade.
That does not automatically send the batch process first; it tells the organization which candidate can produce credible evidence quickly, and which one is still disguising an intent problem as a technology problem.
Then run Platform Pilot Zero on one valuable Tier 2 system. Build the answer key first. Use reconciliation as the gate. Cut over only when the difference between old and new is understood, accepted, and quiet enough for the system's risk profile.
The book's term for that discipline is evidence-gated scaling: the program earns its next tranche of systems from the pilot's reconciliation record, and that record should be auditable by a skeptic. Enthusiasm scales faster than evidence in every large transformation I have watched, which is precisely why the gate belongs on evidence.
The honest objection
The strongest objection deserves the floor: code volume was never the hardest part.
Data migration, integration topology, organizational change, operational readiness, and regulatory validation dominate the cost of many enterprise modernizations. Cheap code generation touches none of them directly. That is correct, and I will not argue otherwise.
What the repricing changes is the feasibility threshold. It shrinks one term in the equation enough to reorder which systems can clear the total cost. Projects that failed the old construction math may now pass, provided their verification story holds. The other terms still cost what they cost.
The answer key does not make data migration cheap. It turns migration from a subjective project into a measurable convergence problem. It does not untangle integrations. It lets the team observe whether the new topology preserves the outcomes that matter. It does not perform organizational change. It gives operators and business owners concrete evidence to accept or reject the new behavior. Verification leaves the hard parts hard and makes more of them measurable.
A second caveat comes with regulated industries, including mine. Green tests rarely satisfy independent validation requirements on their own, and risk teams, auditors, and regulators may require separate controls, traceability, review, and evidence based on the system's materiality. The answer key makes validation faster and stronger without replacing the validator, and anyone selling an agentic rewrite that skips that step is selling you an incident.
Two findings would send me back to revise this post. If constructing answer keys consistently costs as much as the rewrites they enable, rising on the same curve, Tier 2 collapses into Tier 3 and the sorting loses much of its economic value. If enterprise ports show cutover failure rates unmoved by serious verification investment, then the gate is theater and the skeptics were right about more than the hard parts.
I do not expect either result, but the approach fails safely. Even if the rewrite never proceeds, the organization retains a clearer specification, stronger observability, and a reusable record of how the current system behaves. The program produces answer keys either way, and answer keys keep.
So the Monday morning answer is small and concrete. Pick three systems, score their answer keys against the four questions, and combine that readiness with business value, urgency, and risk. Fund the strongest Tier 2 candidate's answer key as its own line, run the pilot, and let the reconciliation record decide what earns the next tranche.
The repricing already happened. The sorting is how it reaches your ledger.
Related reading
