AI Legacy Takeover

The "RPG guy" announces he's leaving.

He's the one person who truly understands how the AS400 application works—the arcane business rules buried in code written before most of the current staff were hired, the undocumented workarounds that keep month-end processing from collapsing, the mental model of a system that has no architecture diagram because he is the architecture diagram.

Maybe he's retiring. Maybe he's moving to a competitor who offered him a retention bonus your HR team didn't think to match. Maybe he's simply aging out—because the average RPG programmer is now approaching 70 years old.

Suddenly, the $2 million per year maintenance bill isn't the scary number. The scary number is the knowledge walking out the door.

This chapter maps the trap. Not to depress you—to make the economics of escape undeniable.

The Maintenance Death Spiral

The headline numbers are damning enough. Nearly two-thirds of companies spend over $2 million annually maintaining legacy systems¹. Banks and insurance companies dedicate up to 75% of their IT budgets to preserving systems that were built in a different era². Across the board, organisations pour 60–80% of their IT budgets into maintaining existing infrastructure rather than driving innovation³.

But the headline numbers hide the real danger: compounding.

The true cost of legacy maintenance compounds at roughly 20% annually. A mid-sized financial services firm spending $250,000 on maintenance and hardware in Year 1 accumulates over $1.5 million in five years through escalating costs, compliance upgrades, and hardware failures⁴. This isn't a budget line item. It's a compounding tax on your ability to compete.

The Downtime Tax

Legacy systems don't fail gracefully. They fail expensively and unpredictably. Unplanned downtime costs $9,000 per minute—$540,000 per hour—with legacy system failures accounting for 40% of major outages⁵.

A single significant outage can cost more than a year of maintenance fees. And unlike modern cloud infrastructure with automated failover and redundancy, legacy systems typically have limited or no disaster recovery—when they go down, they stay down until someone with tribal knowledge can diagnose the problem.

Innovation Starvation

The maintenance death spiral doesn't just drain money. It drains possibility. Legacy-dependent organisations take 2–3x longer to implement changes⁶, and 90% of IT leaders report that legacy systems hinder innovation²¹. The U.S. Government Accountability Office reports that 80% of federal IT budgets go toward maintaining legacy systems, creating what they describe as "a vicious cycle that starves innovation while feeding outdated technology"⁷.

This is the vicious cycle at work: high maintenance costs starve the innovation budget, making transformation harder, making maintenance more critical, which drives costs higher, which leaves even less budget for innovation. Each year, the trap tightens.

"If hidden costs exceed $300,000 annually, modernisation typically pays for itself within 18–24 months."

The Workforce Crisis

If the maintenance economics don't force your hand, the demographics will.

The average COBOL programmer is now 55 years old, with 10% of the workforce retiring annually. Fewer than 2,000 COBOL programmers graduated worldwide in 2024⁸. Sixty percent of mainframe professionals are over 50. And some estimates put the typical RPG programmer at around 70 years old⁹.

The blunt version, from Planet Mainframe: "Mainframe developers are not just retiring, they are expiring—and young developers have little interest in mainframe careers."¹⁰

You Can't Hire Your Way Out

This isn't a problem you can solve with a recruiter. Gartner predicts that 60% of modernisation efforts will be delayed due to lack of legacy skills, and 70% will stall—not because of outdated technology, but because no one's left who understands it¹¹.

The knowledge gap isn't like learning a new JavaScript framework. As one analysis put it: "Teaching someone to keep a complicated mainframe application running is not the same as teaching them JavaScript—it requires 30 to 40 years of experience with business logic."¹²

The cumulative impact is staggering. By 2026, more than 90% of organisations will be adversely affected by IT skills shortages, resulting in approximately $5.5 trillion in cumulative losses due to delayed products, diminished competitiveness, and lost business¹³.

"The average COBOL programmer is about the same age as the language itself."

The Traditional Modernisation Trap

So the maintenance is killing you, the workforce is vanishing, and you know you need to move. You call in the consultants. They commission a 6-month discovery phase. They produce a 200-page requirements document. They get vendor quotes. The number comes back: $5–10 million, 12–18 months, and a history of failure rates that would ground any airline.

And the project gets shelved. Again.

Sixty-five percent of modernisation projects exceed budget and timeline, with average cost overruns reaching 62%¹⁴. In catastrophic failures—which are not as rare as you'd hope—overruns reach 447%¹⁵. The Cutter Consortium's assessment is characteristically blunt: "Conventional redesign and rewrite approaches for legacy modernisation will have failure and overrun rates no better than for other conventional projects, and may well be worse."¹⁶

Why Traditional Discovery Fails

The root cause is buried in the discovery process itself. Traditional legacy modernisation begins with meetings. Lots of meetings. Stakeholders describe what the system does, business analysts document it, and architects sketch a replacement.

The problem? Meeting-based discovery captures what people say the system does, not what it actually does. Requirements documents are stale the day they're finished. The 12–18 month delivery timeline means the business has moved on by the time the replacement arrives. And the finale—a big-bang cutover—is the highest-risk deployment pattern in software engineering.

Even government auditors see the trap. The U.S. GAO warns: "Until agencies fully document modernisation plans for critical legacy IT systems, their modernisation initiatives will have an increased likelihood of cost overruns, schedule delays, and overall project failure."¹⁷ But the documentation itself becomes a bureaucratic industry—consuming months of effort to produce artefacts that describe yesterday's reality.

The Decision That Isn't a Decision

Most organisations end up in the same place: maintain by default.

This isn't a decision. It's avoidance. And the economics of avoidance get worse every year as maintenance compounds, the workforce shrinks, and competitors who escaped the trap pull further ahead.

"Nobody got fired for commissioning a requirements phase."

But perhaps they should have been.

The Real Cost of Waiting

The paradox is stark: 95% of ATM swipes run on legacy systems, 70% of Fortune 500 transaction processing depends on COBOL, but the workforce to maintain these systems is vanishing¹⁸.

Every year you wait:

• Maintenance costs compound another 20%
• Another 10% of your legacy workforce retires
• Security and compliance requirements tighten
• Competitors who escaped the trap pull further ahead
• More tribal knowledge walks out the door—permanently

The direction of travel is clear. The U.S. Social Security Administration has committed to a $1 billion AI-assisted upgrade of its legacy COBOL codebase¹⁹. Amazon used AI agents to modernise thousands of legacy Java applications "in a fraction of the expected time"²⁰. Even government—historically the slowest-moving sector—is committing to AI-driven legacy replacement.

McKinsey reports that a transaction processing system that would have cost $100 million to modernise now costs less than half when using generative AI³³. That's the headline. But the headline buries the real story.

The real story isn't that replacement got cheaper. It's that maintenance is now the risky bet. Replacement has flipped from "expensive gamble" to "measurable convergence." This chapter makes the economic case that the flip has already happened—and waiting costs more than acting.

AI Coding Has Crossed the Threshold

The single best thing AI is good at right now is coding. It's astronomically capable. It keeps up with the best elite programmers on the planet—and then you can parallelise it and meta-manage it. It's off the charts.

That's not aspiration. It's measurement. Claude Opus 4.5 achieves 80.9% on SWE-bench Verified—the first AI model to exceed 80% on this real-world coding benchmark³⁴. GPT-5.2 Codex sits at 80.0%³⁵. These aren't toy benchmarks. SWE-bench Verified tests issue-resolution on real open-source repositories—the kind of practical engineering work that matters for system replacement.

The Agentic Multiplier

But raw model capability isn't even the most important number. Architecture is.

Andrew Ng's research demonstrates that GPT-3.5, used in single-shot mode, achieves just 48.1% on HumanEval coding tasks. Wrap that same model in an agentic workflow—a loop that generates, evaluates, critiques, and refines—and it jumps to 95.1%³⁶.

Read that again: a weaker model in an iterative agent loop outperforms a stronger model used in single-shot mode. The orchestration IS the capability.

This validates the entire nightly build approach to legacy replacement. The question isn't "can one AI write perfect code?" It's "can a loop of AI agents converge on correct code through iteration?" The answer is demonstrably yes.

Anthropic's own custom harness improves Opus 4.5 performance by 10 percentage points compared to standard frameworks³⁷—further evidence that orchestration architecture is as important as the underlying model.

Real-World Evidence

Elite developers are already working at this level. One documented case: 11,900 lines of production code generated without opening an IDE³⁸. OpenAI's internal Agent Builder was developed in under six weeks, with Codex writing 80% of the pull requests³⁹. GitHub Copilot users complete tasks 56% faster⁴⁰.

The question has shifted from "can AI write code?" to "how do we orchestrate AI coding at scale?"

The Cost Collapse

AI capability alone doesn't flip the economics. The cost collapse does.

LLM inference prices have fallen between 9x and 900x per year depending on the benchmark, with a median decline of 50x per year across all benchmarks. After January 2024, this accelerated—the median decline increased to 200x per year⁴¹.

What this means for legacy replacement: the compute cost of running parallel coding agents overnight is falling faster than anyone predicted. The same nightly build workflow that might cost $500 today in API calls could cost $2.50 next year at the same scale.

The Parallel Agent Multiplier

Individual AI coding is impressive. Parallelised AI coding is transformational.

Multi-agent coding systems now handle 50,000+ line codebases that choke single agents⁴². Tens of instances of AI running in parallel—being orchestrated to work on specifications, documentation, the full CI/CD lifecycle—condensing a month of teamwork into a single hour⁴³.

One case study accelerated development by 48x, reducing time from months to days and producing over 100 AI models per year compared to a previous capacity of 2–5 models annually with traditional methods⁴⁴.

And this isn't niche. Gartner reports a 1,445% surge in multi-agent system inquiries from Q1 2024 to Q2 2025. By the end of 2026, 40% of enterprise applications will include task-specific AI agents, up from less than 5% in 2025⁴⁵.

The Economics Flip: Old vs New

Five Factors Behind the Flip

The fifth factor deserves emphasis. The governance problem that kills chatbot projects—"how do you trust real-time AI with customers?"—doesn't exist here. Code goes through the same review, testing, and deployment pipeline you already use. We don't really trust developers either. We test their code and review their PRs. We check in PRs. We don't just let them do whatever they want. A good AI is quite analogous to a developer that you don't trust.

Why This Is Safer Than the Chatbot

Here's the counter-intuitive truth that most executives get backwards: the legacy replacement—the project that looks enormous and scary—is actually safer than the "simple" chatbot that looks like a quick win.

The chatbot looks simple because the interface is simple. One text box. But underneath, it's a public-facing stochastic actor with infinite input space, real-time expectations, compliance exposure, and adversarial users. That's the boss fight.

Legacy replacement, by contrast, sits squarely in AI's lane:

This maps directly onto what we call the Cognition Ladder⁴⁶. Rung 1—competing with humans in real-time—has a 70–85% failure rate. That's the chatbot. Rung 2 and 3—augmenting in batch and transcending what was previously impossible—are where AI wins. Legacy takeover is squarely Rung 2–3: batch observation, overnight code generation, human review in the morning. Every characteristic that makes AI strong is present.

The Honest Caveat

Integrity demands a caveat before moving on.

Experienced open-source developers using AI tools actually took 19% longer to complete tasks on their own repositories—while believing they were 20% faster. A perception gap of nearly 40 percentage points⁴⁷.

Industry analysis confirms the pattern: "The 'average' speedup reported in broad market surveys is likely driven by the massive volume of low-complexity, boilerplate tasks where AI is a force multiplier. The slowdowns are concentrated in the 'critical path' engineering—the deep logic that defines the system's reliability."⁴⁸

What this means for legacy replacement: AI excels at new code generation and boilerplate—exactly what nightly builds produce. It's less effective at surgical edits to complex existing systems—exactly what you're not doing. The approach described in this book sidesteps the productivity paradox entirely: you're not asking AI to understand and modify legacy code. You're asking it to generate fresh code from clean specifications.

Regeneration Economics

The deepest advantage of AI-driven replacement isn't speed or cost. It's that specifications appreciate while code depreciates.

When a nightly build reveals a gap—a missing business rule, an edge case the test suite didn't cover—you don't patch the code. You fix the specification, add a characterisation test, and let the next nightly build regenerate everything. Each improvement to the spec produces better output. Each model improvement produces better output from the same spec. The specification is an appreciating asset⁴⁹.

Contrast this with traditional development. A $5M codebase written by humans in 2024 doesn't get better in 2025. It gets more expensive to maintain. A specification that generates code through AI agents gets better every time the models improve—automatically, at no additional cost.

"Specifications remain durable while code regenerates with model improvements. Today's specs get better code tomorrow—for free."

Your auditor asks three questions about your legacy system:

1. "Show me the access control matrix."
2. "Show me the disaster recovery test results from last quarter."
3. "Show me which staff members can approve a transaction AND process the payment."

If your answers are "it's complicated," "we haven't tested it," and "probably the same person"—you don't have a legacy system. You have a compliance breach waiting to be discovered.

Chapter 1 made the economic case. Chapter 2 made the capability case. This chapter makes the governance case—because in regulated industries like insurance, finance, and healthcare, governance risk is the one that can shut you down entirely.

The Black Box Problem

Most legacy systems were built in an era when "observability" wasn't a concept. They were built to work, not to be visible.

"The original architects focused on making things work, not on making them visible. They built functional systems that operate like black boxes."

This creates three distinct blind spots that compound into a governance nightmare:

What "Black Box" Means in Practice

• No audit trail: Who changed what, when, and why? In many legacy systems, the answer is "nobody knows." Transaction logs may exist but they're incomplete, unstructured, or stored in formats that modern tools can't read.
• No real-time monitoring: The system is either "running" or "down." There's no gradient—no early warnings, no performance trends, no anomaly detection.
• No dependency mapping: Which components depend on which? What happens if this batch job fails? Which downstream systems break? Often, the only person who knows is the one approaching retirement.
• No access logging: Who accessed what data? In 2026, this isn't a nice-to-have—it's a regulatory requirement in virtually every regulated industry.

The financial reality of blindness is staggering. In 2025, one in eight enterprises loses over $10 million per month to undetected disruptions linked to observability gaps²¹. You can't manage what you can't see. And you can't govern what you can't audit.

Security: The Expanding Attack Surface

Legacy systems run on end-of-life software that no longer receives security patches. This isn't a theoretical risk—it's an actively exploited attack vector.

An average end-of-life software image accumulates 218 new vulnerabilities every six months after support ends²². Nearly 46% of CISA's Known Exploited Vulnerabilities catalogue are linked to end-of-service software²³. Unpatched vulnerabilities are linked to 60% of data breaches, with 44% of exploits targeting vulnerabilities that are 2–4 years old²⁴. In 2026, 54% of ransomware incidents were traced back to outdated or poorly patched systems²⁵.

The U.S. Government Accountability Office flagged 10 "critical" legacy IT systems years ago. Most still haven't been modernised. These systems "used outdated languages, had unsupported hardware and software, and operated with known cybersecurity vulnerabilities."²⁶ If the U.S. federal government can't secure its legacy systems with effectively unlimited resources, mid-market companies with $2M budgets certainly can't.

Separation of Duties: The Audit Nightmare

Separation of duties (SoD) is fundamental: no single person should be able to initiate, approve, and complete a sensitive transaction. It's required by SOX, APRA, GDPR, and virtually every compliance framework²⁷.

Modern systems enforce SoD through role-based access control, workflow approvals, and audit logging. When roles are well-defined and duties are separated, audit trails become clearer—auditors can trace actions back to specific individuals.

Legacy systems? Not so much.

The regulatory landscape is tightening. GDPR fines reached €5.65 billion cumulatively by March 2025, with 80% of 2024 fines linked to security lapses²⁸. California's Insurance Consumer Privacy Protection Act (2025) specifically targets the insurance industry with privacy protections exceeding general privacy laws²⁹. The EU AI Act becomes fully applicable August 2026, establishing risk-based obligations for high-impact systems—legacy systems processing insurance claims or medical data will be squarely in scope³⁰.

"Your legacy system's security model was designed in 1998—before SOX, before GDPR, before APRA CPS 234. It predates the compliance framework it's supposed to satisfy."

Disaster Recovery: Hideously Complex and Expensive

Modern cloud-native applications can be replicated, containerised, and failed over in minutes. Legacy systems on proprietary hardware? That's a different story entirely.

AS400/iSeries disaster recovery requires specialised infrastructure, specialised skills, and specialised vendors—all of which are scarce and expensive³¹. Most businesses don't regularly test their DR plans—many skip backups, delay failover testing, or lack specialised staff to act when disaster strikes³².

The honest question for the board: "If this system fails catastrophically on a Friday afternoon, when does it come back? Who does the recovery? Have we tested this?"

The Knowledge Moat Around One Person

Chapter 1 covered the workforce demographics. This chapter covers the governance risk of that concentration.

The scenario in regulated industries: one person understands the batch job that generates regulatory reports. One person knows how to recover the system from backup. One person can interpret the error codes. One person holds the admin credentials. That's not a staffing issue. That's a governance failure.

In any compliance framework, concentrating critical operational knowledge in a single individual—with no documented procedures, no tested succession plan, and no separation of duties—is a material risk.

How the Pipeline Fixes This

The 5-phase pipeline described in Part II doesn't just replace the system—it replaces the knowledge concentration:

• Phase 1 (Observe): Captures what the legacy whisperer does, not just what they describe. Behaviour is recorded empirically.
• Phase 2 (Hypothesise): Encodes their knowledge as executable tests—permanently. The knowledge is in the test suite, not in one person's head.
• Phase 4 (Verify): The test harness IS the documentation. It proves the system works not because one person says so, but because automated tests verify it nightly.
• After replacement: Knowledge lives in the spec and test harness. Multiple people can maintain the modern system. Standard skills, not specialised legacy skills.

The Governance Case for Replacement

Replacement solves what maintenance never can:

The traditional framing asks "can we afford to replace this system?" The governance framing asks the harder question: "Can we afford to keep running a system that can't be audited, can't be secured, can't be recovered, and depends on one person who's approaching retirement?"

In regulated industries, the second question outweighs the first. The system isn't just expensive—it's non-compliant. And the gap between what regulators require and what legacy systems provide is widening every year as compliance frameworks evolve.

The Hidden Cost of "Passing" Audits

Many organisations "pass" audits on legacy systems through compensating controls: manual procedures, additional sign-offs, paper-based approvals layered on top of systems that can't enforce them. These compensating controls are expensive (labour-intensive), fragile (depend on people following procedures), and fundamentally dishonest—they satisfy the letter of compliance without the spirit.

The AI-driven pipeline replaces compensating controls with architectural controls: access is enforced by the system, not by policy. Audit trails are automatic, not manual. Separation of duties is enforced by workflow, not by trust.

"One person holding all the knowledge, all the access, and all the recovery capability isn't a staffing issue. It's a governance failure."

"Do you think you'd know everything about the legacy system?"

Nearly everything that matters day-to-day, surprisingly fast, with evidence. And you'd have more honest requirements than any meeting could produce.

The answer to the full question—"would you know everything?"—is no. But you'd know nearly everything that matters. And more importantly, you'd know exactly what you don't know. That's the difference between fog-of-war discovery and measurable gap analysis.

Requirements as Empirical Artefacts

Most legacy modernisation fails because it treats requirements as a meeting outcome. This approach treats requirements as an empirical artefact.

Meeting-based discovery captures what people say they do. Observation captures what they actually do. These are not the same thing. Workarounds, shortcuts, tribal knowledge, undocumented processes—all visible in behaviour, invisible in meetings.

Why Observation Beats Interviews

The Layered Evidence Stack

Observation isn't just screen recording. It's a multi-layer evidence collection that, combined, produces a more complete specification than any requirements document could.

The combination is more complete than any requirements document because it captures reality, not intention.

The Overnight Decomposition

This is where AI's superpowers—batch processing, patience, parallelism—transform raw recordings into structured specifications.

Overnight, vision AI decomposes recordings frame by frame. For each frame or transition, it extracts:

• What screen is the user on?
• What fields are visible?
• What data did they enter?
• What action did they take?
• What was the result?
• What state did the system transition to?

This builds slowly into user flows, field mappings, screen states, business rules, and edge cases—all derived from empirical observation.

AI-Augmented Exploration

Beyond passive recording, AI agents can actively explore. Using tools like Playwright, agents navigate applications programmatically—clicking through the UI, discovering user journeys, and taking screenshots⁵⁰. This creates an additional discovery layer: the AI itself finds paths that users might not have demonstrated during recording.

As Thoughtworks frames it: "Looking at systems purely from a behavioural standpoint is a useful way of thinking about reverse engineering the existing behaviour of an application."⁵¹

And the tools already exist at scale. Celonis Task Mining collects data by recording user activities through a workforce productivity app, automatically creating a dataset with screen records⁵². Skan.ai combines human task data with system-driven activities to create a complete picture of operational flow⁵³.

Multiple Staff, Multiple Weeks

Don't rely on one person's usage. Record across multiple staff members to capture different roles and permission levels, different workflows for the same task (individual workarounds), edge cases encountered naturally, and frequency data—which workflows happen daily versus weekly versus monthly.

A week of capture across 5–10 staff gives substantial workflow coverage. A month adds the monthly processes: month-end reconciliation, reporting cycles, and the seasonal flows that only surface under specific conditions.

The 80/20 Reality—and the Long Tail

Honesty demands acknowledging the limits. UI recordings will nail 80% of day-to-day workflows fast. Most users repeat the same patterns daily. The coverage comes quickly and with high confidence.

The long tail is where the legacy monster lives:

• Month-end jobs and batch processing
• Exception handling and error recovery
• Odd permission states and role-specific workflows
• Integrations nobody remembers building
• "We only do that once a quarter when the regulator asks" paths
• Seasonal processes (end of financial year, tax time)

But here's why this is still dramatically better than meetings: with meetings, you miss the same long-tail items plus you get inaccurate descriptions of the 80% you could have captured directly. Observation gives you evidence-backed coverage of the common paths plus a measurable gap list for the uncommon ones.

The key advantage: you know what you don't know. The gap is measurable, not a fog of war. And the nightly build machinery described in Chapters 5 and 6 is exactly how you hunt the long tail—through diffs, gap detection, and active exploration in subsequent iterations.

"Observed behaviour is more honest than meeting requirements—the system confesses its actual rules through use."

The Observation Phase in Practice

What a Month Adds

A month of capture adds the monthly processes (reconciliation, reporting, exception handling), deeper statistical pattern recognition (frequency, average time per task, exception rates), edge cases that only surface under specific conditions, and integration behaviour over a full business cycle.

The Phase 1 Deliverable

• Workflow inventory with frequency data
• Screen catalogue with field mappings
• User flow diagrams (auto-generated from recordings)
• Business rule candidates (extracted from behaviour patterns)
• Data model sketch (from exports and observed data relationships)
• Gap list: what's NOT yet captured (known unknowns)
• Coverage estimate: "We've observed X% of logged transactions"—this number is what makes uncertainty measurable

Written specs are useful. But tests are the part you can't argue with at 2am.

When a nightly build fails at 3am, nobody pulls up the requirements document. They pull up the test suite. The test suite IS the specification—it's the only specification that's executable, falsifiable, and unambiguous.

This chapter covers Phase 2 of the pipeline: converting raw observations into executable specifications. The output isn't a 200-page document. It's a test harness that captures how the legacy system actually behaves.

From Observations to Executable Specifications

Phase 1 delivered raw material: workflow inventories, field mappings, business rule candidates, a data model sketch, and a gap list. Phase 2 converts this into a layered specification—not a document, but a hierarchy of increasingly precise, testable assertions.

This hierarchy maps cleanly to the Progressive Resolution approach⁵⁷: intent before architecture, architecture before components, components before detail. Don't advance until the current layer passes its stabilisation gate. Stabilise the domain model before specifying field-level rules. Stabilise business rules before generating code.

Characterisation Testing: The True Specification

Characterisation testing—also known as Golden Master testing—is a means to describe the actual behaviour of an existing piece of software and protect existing behaviour against unintended changes via automated testing⁵⁸.

How it works: observe what the legacy system does for a given set of inputs. Write a test asserting that the replacement system produces the same output. That's it. The legacy system IS the oracle⁵⁹.

When these disagree—and they will—the characterisation test wins. Because users have been relying on actual behaviour, not documented intention.

Building the Test Suite

For each observed workflow:

1. Capture inputs: Data entered, buttons clicked, conditions met
2. Capture outputs: Screen state, data changes, reports, exports, API responses
3. Create test: "Given [these inputs], the system produces [this output]"
4. Categorise: Happy path (80% common), edge case (20% uncommon), integration, validation

The Golden Master Progression

After establishing a Golden Master suite, you can modernise with confidence. As understanding deepens, you add finer-grained tests further down the pyramid—from coarse "does the output match?" comparisons to precise unit tests⁶⁰.

This approach is relatively easy to implement for complex legacy systems and works for complex outputs like PDFs, XML, and images⁶¹.

The Spec Is the Asset—Not the Code

The code is ephemeral. You steer at a higher level⁶³.

The specification plus test suite is the durable asset. Code is generated from it nightly. When the spec improves, all code improves automatically. This is the opposite of traditional development, where code IS the asset and specs are stale documents gathering dust.

The delete test makes this concrete: "If I deleted all the generated code, could I regenerate it at will from my spec and test suite?" For this pipeline, the answer should always be yes. The test harness captures legacy behaviour. The spec captures what to build. The code is regenerated nightly.

Advanced Specification Techniques

When source code is available, deeper analysis is possible. Abstract Syntax Tree (AST) techniques allow AI to infer and formally document critical business rules and map all data dependencies⁶⁴. Execution traces captured via symbolic execution engines provide runtime behaviour data—data flows, state transitions, and decision paths at a deeper level than screen recording alone⁶⁵.

But human validation remains critical throughout.

"AI accelerates the heavy lifting—analysis, translation suggestions, doc generation—but experienced developers and architects must validate, interpret, and guide the transformation."⁶⁶

The balance: AI does the exhaustive capture and initial spec generation. Humans review, correct, and validate. Domain experts—the remaining legacy knowledge holders—review specs each morning and correct misinterpretations. Their knowledge gets encoded in the spec permanently. Not lost when they retire.

The Phase 2 Deliverable

The Quality Gate

Before proceeding to Phase 3 (Build), verify:

• ☑ Major workflows have characterisation tests
• ☑ Domain model is stable (not changing daily)
• ☑ Business rule catalogue reviewed by a domain expert
• ☑ Coverage metrics documented and acceptable
• ☑ Gap register maintained and prioritised

"The real specification isn't a document—it's a test suite. Written specs are useful, but tests are the part you can't argue with at 2am."

“An army of coding bots in parallel, coding up the specification changes from last night. Every day, a beta cut of the legacy system replacement.”

This is Phase 3 of the pipeline—and it’s where the economics become visceral. One night of parallel AI coding agents produces what would take a human team weeks. And because the code is regenerated from spec, every night’s build incorporates every improvement to date.

You have an executable specification from Phase 2. You have a test harness that captures legacy behaviour. Now you need to convert those into a working system—not once, but every night, each build converging closer to production-ready.

The Coding Swarm Architecture

Multiple AI coding agents working simultaneously on different modules⁶⁷. Each agent gets an independent copy of the code—a separate worktree providing true isolation⁶⁸. One agent generates code while another writes tests, a third handles documentation, and a fourth reviews for security issues. All happening simultaneously⁴³.

Tens of instances of AI running in parallel—being orchestrated to work on specifications, documentation, the full CI/CD DevOps lifecycle—condensing a month of teamwork into a single hour⁴³.

This isn’t theoretical. Optimists report building complete projects in three days with swarms handling 50,000+ line codebases that choke single agents⁴². The parallel architecture removes the bottleneck of sequential processing and turns the 10-hour overnight window into a massive throughput multiplier.

Why Parallel Matters

A single AI agent working serially is still fast, but bounded. Ten parallel agents working on ten modules simultaneously deliver roughly 10x throughput, minus coordination overhead. The nightly window—say 8pm to 6am, a solid ten hours—gives enough time for multiple parallel passes, each building on the previous.

But speed alone isn’t the point. Parallel agents enable specialisation. Instead of one agent doing everything, you can assign:

• • Code generators — implementing module logic from spec
• • Test generators — writing additional unit and integration tests
• • Security reviewers — scanning for vulnerabilities and access issues
• • Documentation agents — keeping API docs and comments in sync
• • Integration agents — verifying cross-module contracts

The Orchestration Layer

The orchestrator is the boss, not any individual agent. It assigns modules to agents based on the spec, manages dependencies between modules, collects results and runs integration tests, detects conflicts and resolves them, and triggers re-generation when tests fail.

You can parallelise it, and then you can meta-manage it. It’s just off the charts capable. The meta-management—the orchestration—is what makes the swarm coherent rather than chaotic⁶⁹. Without an orchestrator, you get 10 agents producing 10 different interpretations of the same system. With an orchestrator enforcing shared contracts, you get a unified system built at 10x speed⁷⁰.

Progressive Resolution: Structure Before Detail

Without progressive resolution, the coding army produces spaghetti. With it, structure stabilises before detail, and structural problems get caught before code investment⁵⁷.

Applied to code generation, the resolution layers look like this:

The rule that prevents spaghetti: “Don’t advance until the current layer passes its stabilisation gate.”

How This Maps to Nightly Builds

Humans review gate decisions each morning. The AI proposes, humans approve advancement. Nobody moves to L5 code generation until L1 architecture is stable and validated.

The Nightly Build Cycle

Here’s what one night looks like, end to end⁷¹.

Repeat nightly. Each cycle converges closer to production-ready.

What Happens at Each Stage

5pm — Spec Freeze. Today’s spec changes are finalised: new characterisation tests from morning review, corrected business rules, resolved gaps. The spec is the “source of truth” for tonight’s build.

6pm — Build Starts. The orchestrator assigns work to parallel coding agents. Each agent receives its module spec, characterisation tests, and integration contracts. Agents work independently in isolated worktrees—they can’t interfere with each other.

6pm–2am — Coding. Agents generate or regenerate code from spec. Each agent runs its own unit and module tests as it works. Self-critique loops let the agent evaluate its own output, detect issues, and iterate. Agents that finish early take on additional modules or perform cross-module review.

2am–5am — Integration and Testing. The orchestrator merges all modules. The full characterisation test suite runs against the integrated build. Integration tests verify cross-module behaviour. Data migration scripts run against a snapshot of live data. A diff report is generated: what changed from last night’s build and why.

6am — Build Complete. New beta cut available. Test results summary ready for human review. Diff report highlighting changes, new passes, new failures. Gap report showing which characterisation tests still fail—the convergence metric.

9am — Human Review. The team reviews the beta cut, test results, and diff report. Test failures are analysed: is this a spec gap, a generation error, or a genuine edge case? Spec updates are queued for today’s spec freeze, feeding tomorrow’s build. Decision: is this build an improvement? Keep or roll back to yesterday’s?

“Once you call it a ‘nightly build,’ you suddenly inherit 20 years of software hygiene for free.”

Code Is Ephemeral — The Spec Is the Asset

This is the concept that changes everything about how you think about legacy replacement: the code is not the asset. The specification and test harness are.⁷²

When a nightly build reveals a gap—a missing business rule, an edge case the test suite didn’t cover—you don’t fix the code. You fix the specification, add a characterisation test, and let the next nightly build regenerate everything. The regenerated code is clean. No accumulated patches. No spaghetti. No technical debt.

This is the “Nuke and Regenerate” principle in practice: specifications remain durable while code regenerates with model improvements⁴⁹. If the spec is right, the code will be right—verified by the characterisation tests. And when AI models improve, the same spec automatically produces better code. No additional investment required.

The Vocabulary Shift

Language matters because it activates the right mental models. When you say “legacy modernisation project,” people hear “18 months, $5 million, coin flip.” When you say “nightly convergence loop,” they hear “CI/CD, measurable, iterative.”

“AI recommendations” sounds like magic that should just work. “Nightly decision builds” sounds like engineering that needs discipline. The same reframe applies here: calling it a “nightly build” immediately activates 20 years of CI/CD muscle memory in any engineering organisation.

Regeneration Economics

The deepest advantage of the nightly build pipeline isn’t speed or cost. It’s that specifications appreciate while code depreciates.

Today: Your spec generates working code via current AI models.

Six months from now: The same spec generates better code via improved models—for free. No changes to the spec required. The code quality improves automatically because the models improve.

Compare to traditional development: A $5M codebase written by humans in 2024 doesn’t get better in 2025. It requires ongoing maintenance just to stay the same quality. The economics run in opposite directions.

With LLM inference costs falling 200x per year post-January 2024⁴¹, the economics improve on both axes simultaneously: the code gets better AND cheaper to generate. A nightly build that costs $500 today in API calls might cost $2.50 next year at the same scale.

This is the “delete test” for your pipeline: if you deleted all the generated code, could you regenerate it at will from your spec and test suite? For this pipeline, the answer should always be yes.

CI/CD Mapping: What You Already Know

By framing legacy replacement as a CI/CD pipeline, you inherit decades of software engineering discipline for free.

What this mapping buys you:

• • Version control: Every night’s build is tagged and recoverable
• • Diff-based review: Humans focus on what changed, not the entire codebase
• • Automated quality gates: Builds that fail tests don’t get promoted
• • Rollback capability: Bad build? Go back to yesterday’s—it still works
• • Observability: Test pass rates, convergence metrics, gap tracking

Each nightly increment follows a mini-waterfall: spec → generate → test → review⁷³. Agile iteration happens at the day level—each day is a full cycle. But within each day, the process is spec-driven and deterministic. When generation is cheap and surgery is expensive, you optimise for spec clarity and ruthless evaluation harnesses.

Practical Considerations

“Remembering the code is ephemeral, you steer at a higher level using progressive resolution.”

The traditional modernisation mindset demands: “It must be complete and perfect before we switch.” This mindset is why projects take 18 months and still fail.

The alternative: measurable convergence through nightly builds, where each day’s build is closer to production-ready than yesterday’s—and you can prove it with numbers. Not hope. Not a project manager’s Gantt chart. Numbers.

You Don’t Trust AI — You Trust the Tests

You don’t have to trust AI to build code because you’ve built a test harness⁷⁶. You’ve built SDLC and you can inspect the code. You don’t need to trust AI.

This removes the trust problem that kills other AI deployments—chatbots, autonomous agents, customer-facing systems. The governance model is identical to what you already use for human developers: code goes through PR review, automated tests must pass, human review before promotion, rollback if something goes wrong.

The Untrusted Developer Analogy

We don’t really trust developers either. We test their code and review their PRs. We check in PRs. We don’t just let them do whatever they want. A good AI is quite analogous to a developer that you don’t trust.

The AI coding agent IS an untrusted developer—one that works overnight, never gets tired, and produces reviewable artefacts. Existing SDLC governance applies without modification. No new governance frameworks needed. This is governance arbitrage: routing AI value through existing engineering controls rather than inventing new governance theatre.

The Convergence Loop

Convergence is what separates this approach from traditional modernisation. Instead of “we’re in requirements” or “we’re in testing”—vague phases with no quantified progress—you have a single number that tells you exactly how close you are to production-ready⁸⁰.

The convergence metric is the scoreboard. It’s visible, unambiguous, and tells you exactly how close you are to production-ready. Traditional modernisation has no equivalent metric. You’re either “in requirements” or “in development” or “in testing”—with no quantified progress indicator.

How Gaps Get Closed

Each morning, the human review identifies why tests fail:

Each morning’s findings become tonight’s spec improvements. Tomorrow’s build is closer to done. The loop is self-correcting: gaps don’t accumulate, they shrink. The unknown surface area decreases measurably each cycle.

Hunting the Long Tail

After the first 80% converges quickly, the remaining 20% requires active hunting. Techniques for finding it:

• • Data diffs: Compare legacy system outputs with new system outputs for the same inputs. Differences reveal gaps.
• • Exception logging: Instrument the new system to flag any input it can’t handle. These exceptions become new characterisation tests.
• • Shadow comparison: Run both systems in parallel on live data. Compare outputs nightly. Divergences are the gap list.
• • Targeted SME interviews: Now that you have 80% captured, specific questions to domain experts fill precise gaps rather than broad discovery.
• • Historical data replay: Feed 12 months of actual transactions through both systems. Compare results.

“You don’t need perfection—you need convergence. And convergence is something machines are annoyingly good at, provided you give them a scoreboard.”

The Morning Review Process

Not coding. Reviewing, validating, directing.

The Review Rhythm

Decision Points

Humans provide what AI can’t: business judgment, domain knowledge, the “that doesn’t feel right” instinct⁸¹. Humans are NOT reviewing every line of code (that’s the test harness’s job). Humans ARE making strategic decisions: which gaps matter most, when to change approach, when to declare “good enough.”

The Strangler Fig — Safe Cutover

Even if you can rebuild fast, production cutover is where blood pressure spikes. Big-bang cutovers—“turn off old system Friday, turn on new system Monday”—are the highest-risk deployment pattern in software engineering. 12–18 months of development leading to a single high-stakes moment. This is how 447% overruns happen⁷⁷.

The sane pattern is the Strangler Fig approach, coined by Martin Fowler: put a façade (proxy) in front of the legacy system, route some traffic to the new system, and expand gradually⁷⁴.

The key principle: at every stage, you can reverse⁷⁹. The proxy routes traffic. If the new system stumbles, route back to legacy. No data loss, no downtime, no panic.

Incremental Cutover in Practice

You benefit from the new system almost immediately—as soon as the first service goes live. The benefits steadily increase over time as more traffic shifts⁷⁵. Value delivery starts immediately. You don’t wait for 100% completion.

Data Migration: Import Live Data Nightly

The new system imports data from the legacy system every night. This ensures the new system always has current data—no “data migration day” risk. Both systems stay synchronised during the parallel-running period. Data integrity tests run nightly alongside code tests.

Even during cutover, nightly builds continue. Issues discovered at 50% traffic become tomorrow’s spec improvements. The system converges even while serving production traffic.

Measuring Convergence: The Governance Dashboard

When to Declare “Production Ready”

• ☑ Characterisation test pass rate exceeds agreed threshold (typically 95%+)
• ☑ Shadow comparison shows <1% divergence on live data over a 2-week period
• ☑ Zero regressions for 7+ consecutive builds
• ☑ Domain experts have signed off on business logic accuracy
• ☑ Strangler Fig canary at 25%+ with no incidents for 2+ weeks

The Error Budget Approach

Not every test needs to pass to go to production. Apply a tiered approach to error tolerance:

This prevents “one test failure = stop everything” paralysis while maintaining absolute standards where they matter. Cosmetic imperfection is fine. Financial miscalculation is not.

“You don’t trust AI to build code because you’ve built a test harness. You’ve built SDLC and you can inspect the code. You don’t need to trust AI.”

“I think I could do an AI takeover of an application like that in a couple of months, doing nightly builds of an army of AI coding agents from a spec, using progressive resolution.”

Two months sounds aggressive. It IS aggressive. But for a specific class of legacy application—bounded, internal, with accessible data and available SMEs—it’s plausible. This chapter maps exactly when the two-month timeline holds, what it delivers, and what disqualifies an application from this category.

What Makes an App “Bounded”

Not every legacy application qualifies for a two-month takeover. The characteristics that make it achievable are specific and identifiable:

The RPG/AS400 Archetype

A client asking about RPG programming on AS400/Power Series. Nobody in the organisation wants to run that technology. Falling behind on governance and security.⁸² Escalating costs for specialised hardware and scarce skills. This is the archetype: a bounded LOB app that’s become a liability, sitting on technology that’s aging out faster than the workforce.

The Disqualifiers: When Two Months Is Fantasy

The Two-Month Timeline — Phase by Phase

Why the Timeline Is Realistic

10–20 core workflows at roughly 50 characterisation tests each = 500–1,000 tests. A coding swarm of 10–20 parallel agents can generate and test significant codebases overnight. The 48x acceleration documented in case studies⁸⁴ suggests that what once took months of human development compresses to days of AI development.

The limiting factor isn’t generation speed—it’s discovery speed. How fast can you capture and validate the spec? With task mining, the answer is days, not months.

What “Two Months” Actually Delivers

Honesty demands precision about what two months means:

• • It is NOT “perfect system in two months”
• • It IS “95%+ daily operation coverage in two months, with measured gaps and a convergence loop that continues closing them”
• • The remaining 5% may take another month of nightly builds to resolve
• • Some edge cases may be deliberately deferred (“we’ll handle that manually for now, automate in the next cycle”)

Honest framing: Two months to USABLE. Three months to SOLID. Ongoing nightly builds continue to improve.

The RPG Takeover — A Concrete Scenario

The Pipeline Applied

Weeks 1–2: Record 12 users across 3 roles. Export AS400 database. Extract RPG source code for AI analysis. Overnight decomposition begins immediately.

Week 3: Characterisation tests generated. The RPG developer reviews business rule extraction—his 30 years of knowledge gets encoded in the spec permanently. This is the critical window: capture his expertise before he retires.

Weeks 4–6: Nightly builds. Python/React replacement taking shape. Data migration scripts converting AS400 data nightly. Convergence climbing steadily.

Weeks 7–8: 93% convergence. Strangler Fig at 25%. The RPG developer is reviewing the new system, not maintaining the old one—his role has shifted from “the only person who can keep it running” to “the domain expert who validates the replacement.”

The RPG Developer’s New Role

Before: Single point of failure, maintaining code nobody else can read.

During: Domain expert reviewing AI-generated specs, validating business rules, catching edge cases.

After: Knowledge permanently encoded in the test harness and spec. Can retire without the company losing 30 years of institutional knowledge.⁸⁶

Don’t wait for the RPG programmer to retire—start while they can validate the spec.

“I think I could do an AI takeover of an application like that in a couple of months, doing nightly builds of an army of AI coding agents from a spec, using progressive resolution.”

The Bounded App Checklist

Score your legacy application against these criteria to determine if the two-month timeline applies:

Mostly green: Two months is realistic. This chapter applies.

Mixed yellow/green: Plan for 3–4 months. Some surprises expected.

Mostly red: Chapter 9 territory. Measured convergence, not a fixed timeline.

That alone is worth more than six months of traditional discovery.

This chapter applies the same 5-phase pipeline to the harder case: the enterprise system nobody fully understands, with undocumented integrations, decades of accumulated logic, and “spiritually compromised” data. The pipeline still works. The timeline stretches. The emphasis shifts from speed to measurable convergence.

The Enterprise Beast — What Makes It Different

The 65% over-budget rate and 447% catastrophic overruns from Chapter 1?⁸⁷ Those statistics come primarily from enterprise-scale modernisation. The discovery phase alone can take 6–12 months—and still miss critical integrations. Requirements documents for enterprise systems are stale before they’re finished. Big-bang cutovers on enterprise systems are where “catastrophic” failures happen.

The same 5 phases apply: Observe → Hypothesise → Build → Verify → Promote. But the difference is in how they’re applied:

• • Observe phase is longer and deeper — months, not weeks
• • Build is module-by-module, not system-wide
• • Verify includes extensive shadow comparison with live data
• • Promote uses Strangler Fig at a much more gradual pace
• • The convergence metric is the anchor — even if progress is slower, it’s measurable

Two Weeks to Know the Problem

The first sprint isn’t about replacing anything. It’s about understanding what you’re dealing with.

The Assessment Deliverable

Compare to traditional: after 6 months of meetings and requirements gathering, you often still don’t know these things with confidence.⁹³ The pipeline makes uncertainty measurable in 1–2 weeks rather than 6 months of discovery.

“The approach makes the uncertainty measurable. After 1–2 weeks of capture and harness building, you can estimate the remaining surface area far better than traditional discovery.”

Module-by-Module Replacement

Instead of replacing the entire system at once, replace it module by module. Start with the “greenest” module: bounded, well-understood, limited integrations. Apply the full 5-phase pipeline to that module. Strangler Fig⁸⁸ routes that module’s traffic to the new system while everything else stays on legacy.

Each successful module builds confidence and proves the approach.

The enterprise system becomes a hybrid during transition: gradually modernising, with each module independently testable and deployable. Legacy and new modules coexist. Data synchronisation between legacy and new happens nightly. Interface contracts between modules are established in the specification phase.

Hunting the Long Tail

The long tail is where enterprise complexity hides. After the first 80% converges quickly, the remaining 20% requires active, targeted hunting.

Long Tail Hunting Techniques

The principle: you don’t need to find everything upfront. The nightly build loop IS the discovery mechanism. Each cycle reveals more of the long tail.

The Convergence Curve Flattens — That’s OK

The convergence trajectory for enterprise systems looks different from bounded apps:

• • First 80% converges in weeks (just like the bounded app)
• • 80–90% takes longer—weeks to months, as edge cases emerge
• • 90–95% is the long tail—each additional percentage point requires more hunting
• • 95–99% may include deliberate compromises: “We’ll handle this manually for the first year”

The key insight: You know exactly where you are on this curve at all times. Traditional modernisation doesn’t.

Timeline Expectations for Enterprise

This is still dramatically better than traditional enterprise modernisation: 12–36 months,⁸⁹ $5–20M, 65% over-budget, with a big-bang cutover at the end. The AI pipeline approach delivers 6–18 months at a fraction of cost, module-by-module delivery,⁹⁰ and measurable convergence at every stage. Value delivery starts at Module 1—not at “project completion.”

The Knowledge Preservation Imperative

Enterprise legacy systems have the MOST accumulated knowledge, concentrated in the fewest people. Every year: 10% retirement rate.⁹¹ Irreplaceable knowledge walking out the door.

The assessment phase costs very little relative to the risk of doing nothing. For enterprise systems, hidden costs typically far exceed the $300,000 annual threshold where modernisation pays for itself within 18–24 months.⁹²

“Don’t wait for the RPG programmer to retire—start while they can validate the spec.”

The question isn’t whether AI will replace legacy systems. It’s whether you start while the people who understand yours are still around to validate the spec.

This final chapter pulls together the pipeline, the economics, and the practical steps. No new concepts—just the “what do I do Monday morning?” action list.

Three Clocks Are Ticking

Previously, you might have said five years. But everything’s sped up. You can deploy new systems and reimagine your operations in months instead of years. We’re in the singularity. Everything has accelerated.

The convergence of workforce crisis + AI capability + cost collapse creates a window that didn’t exist 2 years ago and may close differently in 2 years, as the workforce disappears further. The best time to start was when the RPG programmer was 60. The second best time is now, while they’re 62 and still available.

What You Need to Start

The First Two Weeks — Your Assessment Sprint

The Decision Point

The cost of this decision: 2 weeks of effort and a modest budget. Compare to: committing $5M and 18 months to a traditional approach with a 65% chance of going over-budget.⁸⁷

The Pipeline — Complete Summary

Why This Is Safer Than the Chatbot

Every output is reviewable (code diffs, test results, spec changes). Every build is testable (characterisation tests, integration tests, data comparison). Every deployment is rollbackable (Strangler Fig keeps legacy as fallback). Existing SDLC governance applies without modification.

This sits squarely on the Cognition Ladder at Rung 2 (Augment) and Rung 3 (Transcend)—batch, overnight, artefact-based.⁴⁶ This is where AI wins. Not Rung 1 (real-time customer interaction) where AI struggles with latency, governance, and human-advantage constraints.

The Mindset Shift

Legacy replacement isn’t just about technology. It’s about escaping the constraints of 1995-era system design and operating with 2026-era economics. The companies that replace legacy systems aren’t just cutting maintenance costs—they’re gaining the ability to change at modern speed. That’s the real competitive advantage.

It’s not vendors’ copilots trying to sell you a little bit of AI just to get some revenue and distract you from what you should be looking at. Your current system, maintained at $2M/year by people approaching retirement, with a 65% chance of going over-budget⁸⁷ if you try traditional modernisation—that’s the risky bet. The nightly convergence loop is the safe one.

Key Takeaways

Should You Start the Pipeline?

If 3+ questions are YES: Start the 2-week assessment sprint. The cost is low and the information is invaluable.

If fewer than 3: Build the economic case using the data in Chapters 1 and 2, then revisit.

“Everything has changed. It’s a complete reset.”