Methodology & Process
Modernizing Legacy Systems with Structured AI
Why modernization stalls, and how Eastgate's ACDC harness turns structure into savings
Eastgate Software - German Engineering Standards. Enterprise-Grade Results.
Modernizing Legacy Systems with Structured AI
Why modernization stalls, and how Eastgate's ACDC harness turns structure into savings
Every company with legacy software has a system nobody dares touch, because nobody can prove a change is safe until a customer finds the break. Michael Feathers named the right answer back in 2004, a safety net of automated tests built before you touch anything. But it was too expensive back in the days, until now. AI agents can finally make that safety net affordable, but only inside a disciplined structure.
This paper shows how agents build the safety net, a second layer of agents checks their work, and humans keep the final call.
Eastgate Software Engineering 
What Legacy Code Really Means
Most people describe legacy code as old, tangled, and risky to touch. Indeed, legacy code is software that still works. It is built on decisions nobody remembers. That said, it grows harder to change every year. What that description leaves out is why the risk is there in the first place. Michael Feathers traces it to one specific gap in Working Effectively with Legacy Code, still the standard reference on the subject. Most legacy code is risky because it has no tests.
Tests, in this context, don't have to translate to a QA team clicking through screens by hand. They mean automated checks that run in seconds and tell you, every time anyone changes anything, whether the system still behaves the way it did before. Those checks are what let you change old code with confidence. Without them, even a strong engineer is guessing, and so is an AI. The symptoms are familiar:
- Small changes take weeks, because most of the time goes into manual double-checks and fear of doing it wrong.
- Estimates balloon, because nobody knows what a change might break.
- Your veterans' calendar is your release schedule, because knowledge lives in their heads.
- The phrase "don't touch that module" is said out loud in meetings, unironically.
None of these are personnel problems. They are the predictable cost of operating without a safety net.
Why Modernization Projects Stall
Feathers named this routine Edit and Pray. It starts with careful planning, moves into the change itself, and ends with someone nervously watching for signs that something broke. Feedback shows up days or weeks later, usually from QA or an angry customer. His alternative works the opposite way, called "Cover and Modify" - a safety net of automated checks that let you know within seconds whether anything broke.
| Dimension | Edit and Pray | Cover and Modify |
|---|---|---|
| How changes are made | Change first, then hope nothing broke | Protect the code first, then change it |
| When you learn something broke | Days or weeks later, often from a customer | Within seconds, from an automated check |
| What safety depends on | The memory of your most senior engineers | A repeatable, automated safety net |
| The long-term trajectory | The system gets scarier every year | The system gets easier to change every month |
Although this method has been around for nearly twenty years, everyone still operates in Edit and Pray. The main reason lies in the cost curve. Building a safety net around a large, untested system is painstaking work. Someone has to understand what the system actually does, untangle its components enough to test them at all, then write the thousands of checks that pin its behavior down. On a system of real size, that's many months of senior engineering time producing nothing a customer can see. Under quarterly pressure, it's the first thing cut, and the modernization project fails slowly from that moment.
The bottleneck of legacy modernization was never knowing what to do. It was the cost of the safety net.
Why AI Alone Doesn't Solve This
The obvious idea is to hand the legacy system to an AI coding assistant and let it modernize faster. However, it doesn't work like that in reality.
An AI agent is fast and tireless, but it has no more ability to sense a silent breakage in an untested system than a human does. An unsupervised AI at a legacy codebase certainly helps you ship faster. Yet shipping faster doesn't mean shipping safer. Every one of those changes moves through the system with nothing to catch what broke before a customer finds it. Speed multiplies output, and it multiplies risk by exactly the same factor.
55% faster
Simple, isolated tasks
Measured task completion speedup for developers using an AI coding assistant on small, self-contained work.
19% slower
Complex work in real codebases
A randomized controlled trial had experienced developers use AI tools on real issues in repositories they already knew well. They were slower, yet believed they had been faster.
A 55% speedup in the demo and a 19% slowdown in production is not a contradiction. It is a boundary, and a 2025 study of brownfield engineering practice gives it a useful name: the Brownfield Paradox. AI's measured advantage peaks under conditions your systems don't have. Those conditions are small scope, clean context, and no hidden constraints. The advantage turns negative right away once those conditions flip (Sharma, 2025).
The cost does not vanish. It relocates.
An analysis of pull requests containing AI-generated code found they required on average 1.3 additional review rounds and drew 15% more reviewer comments than human-written code (GitClear, 2025). Whatever the AI saves at the keyboard, it hands back at the review desk, and it hands it to your most senior people, who are the scarcest resource you have.
Nobody doubts that AI is fast, that was obvious from the start. What's still unproven is what catches it when it's confidently wrong.
According to OpenAI and Martin Fowler, a useful AI agent should include both the model itself plus a harness, the structure built around it. That harness is made of two components:
Input Guidance directs the AI before it acts, specifications, rules, and constraints that define what "correct" means.
Output Verification checks the AI's work after it acts, automated tests and reviews that catch problems before anything ships.
Feathers' safety net and the AI harness are the same thing, a legacy system with no tests has no harness at all, both for a human or an AI. That's why the Brownfield Paradox isn't about AI. It's about unprotected code, and it's the reason why you should build the harness before you touch the code.
How ACDC Changes the Game
ACDC, Agent-Centric Development Cycle, is Eastgate's implementation of harness engineering, a structured way of running AI agents under specifications, automated checks, and human approval gates. On greenfield projects, it delivers speed. On legacy systems, it attacks the exact cost that has always killed modernization projects.
Building the safety net requires reading enormous amounts of code and writing thousands of behavior-pinning tests. This work is high-volume and mechanical. It's machine-checkable, which is exactly the profile where AI agents outperform humans by the widest margin. It is also where humans add the least unique value. The parts that genuinely require judgment work differently. Deciding what the system should do, what counts as a bug, and what risk is acceptable stay with people, right where they belong.
AI is already popular amongst developers, what they need is to know how to use AI the right way. The 2025 Stack Overflow Developer Survey found that 75-80% of developers use AI for documentation, code explanation, and test generation, while only 40-50% will point it at core business logic or security-sensitive code. Left to their own judgment, developers route AI toward high-volume verifiable work and keep humans on the consequential decisions. Our contribution is turning that instinct into a discipline that still holds under deadline pressure. Here's what that discipline looks like broken down by role:
Builder agents
The volume work- Reads everything. Not a sample, the entire codebase, mapped for how it all connects.
- Finds testable seams. Feathers' term for the safest points to isolate a component so it can be tested without rewriting the code around it.
- Untangles dependencies. Using well-established, mechanical refactoring recipes.
- Writes the tests. At a volume no human team could afford.
Reviewer agents
The adversarial pass- Finds what's wrong. A separate agent, running under different instructions with no stake in the Builder's answer, has exactly one job.
- Catches it first. A deployed LLM pre-review system, called BitsAI-CR, at a large technology company raised its precision from 60% to 75% by adding a second filtering stage that caught its own false positives, all before the code reached a human reviewer.
- Affordable gate. The human gate still stands. Your senior engineer just opens a diff that has already survived an adversary.
Humans
The calls that matter- Priority calls. Which parts of the system matter most, and in what order.
- Defect or feature. Whether a strange behavior the agents uncover is a defect to fix, or a quirk that customers and downstream systems depend on.
- Final sign-off. Whether each change is approved to ship, nothing merges without it.
The result is not "AI replaces the engineering team." It is the safety net, the thing that was always too expensive to build, becomes affordable, and everything downstream of it becomes faster and safer.
What Characterization Tests Mean for Business Owners
One concept from the legacy code playbook deserves a plain-language explanation, because it is the heart of the whole approach and the place where human oversight matters most.
Before changing a legacy system, you need to record what it currently does. Feathers calls these characterization tests, and the crucial subtlety is this: they are not tests of what the system should do. They are a photograph of what it actually does, bugs and all.
That sounds strange until you have operated old software. In a system that has run for fifteen years, some of its "bugs" are load-bearing. A rounding quirk in an invoice calculation may be wrong on paper, but three downstream systems and a decade of financial records may depend on it. "Fixing" it silently would be a business incident, not an improvement.
Agents photograph everything
For each part of the system brought under protection, agents probe it, record its real behavior, and turn those recordings into automated checks, including the obscure edge cases a time-pressed human team would never get to.
Agents flag, humans decide
When the photographing turns up something that looks wrong, the agent's job is to raise its hand, not to fix it. A person with authority over the system decides: is this a defect we will fix deliberately, or behavior we must preserve?
Decisions become documentation
Every ruling is recorded. A side effect of making the system safe to change is that, often for the first time in years, its actual behavior is written down.
This step also produces the engagement's first tangible deliverable: a documented, human-reviewed account of what your system really does, backed by automated checks that enforce it. That asset is yours, in your repository, whatever happens next.
What that deliverable is worth
Research from Google Cloud's DORA program and the associated work of Forsgren et al. finds that investment in documentation infrastructure (decision records, design documents, API documentation) returns within 6 to 12 months, showing up as faster bug diagnosis, easier refactoring, and shorter onboarding. A 2024 survey of engineering leaders found that 26% named context-gathering as the single largest productivity leak across their entire delivery process (Cortex, 2024). The reason your changes take weeks is not that your engineers type slowly. It is that they spend the first week rediscovering what the system does, and then the next one afraid of what they might have missed. Writing that down once, and enforcing it with automated checks so it cannot drift back out of date, is among the highest-leverage things you can do to an old system.
How Modernization Avoids Betting the Business
A reasonable fear about any modernization effort is the big-bang rewrite: two years, a large budget, and a new system that must reach parity with the old one before anyone sees value. That is not this. The approach is incremental by design, and its structure follows Feathers' proven sequence: protect first, change second.
Phase 1 - Survey
Agents read the full codebase and produce a map. Nothing is modified.
How components depend on each other, where the safe intervention points are, which areas change most often. Your team ranks what matters by business value and risk. The output is not a slide deck. It is a written, version-controlled research document that lives in your repository: the dependency graph traced several levels deep, the architectural decisions we could recover from commit history and ticket references, the known risks, the explicit unknowns where behavior could not be established from the code alone, and the teams in the blast radius of any change. That document becomes the standing context every later agent run is grounded in. An agent working without it is an agent guessing, and guessing quickly.
Phase 2 - Protect
The system's behavior does not change. It becomes defended.
For the highest-priority areas, agents untangle dependencies and build the safety net of characterization tests, with humans adjudicating everything the process uncovers.
Phase 3 - Change
The work you wanted all along, now checked on every commit.
New features, bug fixes, performance improvements, architectural cleanup, all proceeding at speed because every change is instantly checked against the safety net. Where a change touches an area not yet protected, we use containment techniques from the same playbook: new functionality is built as fresh, fully tested code alongside the old, connected through a single, small, reviewable point, rather than by operating on the old code directly.
Phase 4 - Compound
Islands of test-covered code merge into continents.
Each protected area makes neighboring areas easier to protect. Each lesson learned is written into the harness as a new rule or check, so the process gets faster as it goes rather than slower. Over time the organization crosses the cultural threshold Feathers identifies precisely: from a state where change is feared to one where ease of change is the expectation.
You can stop after any phase and keep everything gained. There is no cliff, no parity deadline, and no point at which you are running two systems in parallel and praying.
Why This Isn't Just Eastgate's Opinion
A fair question to ask of any vendor's methodology. So it is worth saying plainly that we are not the only people who have arrived here.
In December 2025, an engineering leader who had previously run AI adoption at Amazon published a framework for this exact problem, developed from a different starting point and a different set of engagements. It is called D3 (Discover-Define-Deliver), and it was shaped with 52 practitioners, 84% of whom work in brownfield or mixed codebases and most of whom sit inside organizations of 3,000 engineers or more (Sharma, 2025). The structure it converged on:
| D3 (Sharma, 2025) | ACDC applied to legacy systems |
|---|---|
| Discover Agents map the codebase into a durable research artifact before anything is planned | Phase 1 - Survey Agents read the full codebase and produce the map |
| Define Options, plans, and risks, stress-tested by a Reviewer agent | Phase 2 - Protect Prioritize by business value, then build the safety net |
| Deliver Build, AI pre-review, then mandatory human review before merge | Phase 3 - Change Ship behind the net, human sign-off always |
| Human gate Mandatory between every phase | Four gates Intent, Judgment, Approval, Ownership |
Two groups, working independently on the same problem, landed on the same shape: understand before you plan, plan before you build, and put a human signature between every stage. That convergence should be worth more to you than either framework's opinion of itself. It suggests the structure is being discovered rather than invented, which is generally what happens when a structure is correct.
Structure vs. ad-hoc, in practitioners' own words
Before adopting a structured workflow, 68% of those 52 practitioners rated ad-hoc AI use as not useful or only slightly useful on their brownfield work. Afterward, 75% rated the structured workflow more useful than ad-hoc use. Same engineers, same tools, different process. These are self-reported perceptions from an exploratory study, not a controlled trial, and should be read as practitioner sentiment rather than as measured output. We cite them because the direction is consistent with the harder evidence above, not as a substitute for it.
Where we differ from D3 is the one place that matters most for legacy work: D3 has no safety-net phase. It plans carefully and it reviews carefully, but it never stops to pin down existing behavior before changing untested code. That is the Feathers half, and on a system where change is a gamble it is not optional. A plan reviewed by three agents and a human is still a plan being executed into a system that cannot tell you when it breaks.
Careful planning reduces the chance of a mistake. Only a safety net tells you that one happened.
Where Humans Stay in Control
For a CTO evaluating AI-assisted delivery, this is the governance question, and it deserves a direct answer. Human control is structural, not aspirational. It is built into where the gates sit.
Intent
Every change starts as a written specification a human has approved. Agents build from blueprints; they do not decide what to build.
Judgment
Every anomaly found in the legacy system is ruled on by a person (fix vs. preserve). Agents surface; they do not adjudicate.
Approval
Every change passes automated checks and human review before it ships. The agents' speed applies to producing and verifying work, never to skipping sign-off.
Ownership
Everything produced (tests, documentation, specifications, refactored code) lives in your repository in standard formats. No proprietary runtime, no lock-in to us or to any AI vendor.
The mental model we give clients: the safety net clamps the code, and the approval gates clamp the AI. Nothing about your system's behavior changes without a human signature.
Where We Don't Point Agents
A methodology that claims AI everywhere is a methodology that has not yet been used on anything that can hurt someone. Eastgate's mission-critical work runs in traffic control and industrial infrastructure, where a defect is not a bad quarter. So we draw the line explicitly, and we would rather you read it here than discover it mid-engagement. Agents are given no latitude, and the review gate is deliberately heavier, in four places.
Safety-critical control paths
Code where a failure can cause physical harm. Agents may read it, map it, and propose characterization tests for it. Changes to it are human-authored and human-reviewed, with the agent confined to analysis and verification.
Security-sensitive code
Cryptography, authentication, authorization, key handling. Reviewed by security specialists rather than delegated to an agent, whose training rewards code that looks conventional, which is not the same thing as code that holds up against an adversary.
Genuinely novel design
Where a problem has no established pattern, a model trained on established patterns is a liability rather than an asset. It will produce something plausible and familiar, which is the wrong answer expressed confidently.
Regulatory and compliance obligations
Where the requirement is a legal interpretation rather than a technical one, a human domain expert owns it.
None of this slows the modernization down, because none of it is where the cost lives. The cost lives in the volume work (reading, mapping, dependency-untangling, test generation) and that is exactly where the agents are pointed hardest. Being precise about the boundary is what makes it safe to be aggressive inside it.
What You Should Expect from an Engagement
Eastgate has spent 12+ years as a strategic engineering partner on long-life, mission-critical systems, including industrial and infrastructure software where "legacy" means code that has run reliably for decades and is expected to run for decades more. Across 500+ delivered projects, the pattern that works is consistency, not heroics: a small senior human core (an architect who owns the strategy and the judgment calls, plus engineers who operate the agent fleet), with agents doing the volume work under the harness's rules.
The experience paradox
That team shape is deliberate, and it cuts against a common assumption. The intuition is that AI is a force multiplier for less experienced engineers: hand a junior an agent and they perform like a senior. Practice reports the opposite. Senior engineers extract more value from AI than juniors do, because the binding constraint is not generating code, it is validating it. A senior recognizes at a glance when output is syntactically clean but architecturally wrong. A junior, lacking that pattern library, is likelier to accept plausible-looking code, or to spend a day debugging an implementation they never understood (Sharma, 2025). An agent fleet does not reduce the seniority you need. It raises it, and reduces how much of it you need.
We recommend starting the way we start every engagement: small and measurable. A typical pilot takes one subsystem you currently fear changing, runs the survey and protection phases on it, and hands you three things: a documented map of how it works, a live safety net around it, and a demonstration change shipped through the full process.
Measure it properly, because AI programs are unusually easy to fool yourself about. Recall that the developers in the METR trial believed they had been faster while being 19% slower. Take a baseline before we start, and re-measure at the end of the pilot.
Change lead time
On that subsystem: idea to production.
Review rounds per pull request, and time-to-merge
Read these together with the next item, never alone.
Defect escape rate after deployment
Faster merges can mean the work got better or the review got lazier, and the only way to tell those apart is whether defects follow.
Test and documentation coverage
On the protected area: what fraction of it now has an automated check that will notice a regression.
How the team feels about touching it
This sounds like the soft metric and it is the leading indicator. In brownfield work, engineer confidence and cognitive load predict long-term maintainability better than short-term velocity does. The pilot has succeeded when "don't touch that module" stops being said about that module.
Common Questions
Is it safe to let AI agents work on a critical system that has no tests? +
The agents' first assignment is not to change the system, it is to build the safety net around it. Behavioral changes begin only after that net is in place, and every change then passes an adversarial agent review, automated checks, and human approval before it ships. Pointing AI at an unprotected legacy system without that discipline is genuinely unsafe, which is exactly why the methodology exists.
Doesn't the research say AI makes experienced developers slower? +
On unprotected code, yes, and that is an argument for this methodology rather than against it. The 2025 METR randomized trial found experienced developers 19% slower with AI on complex, real-world codebases, with the lost time going into reviewing and repairing plausible but wrong output. That is precisely the failure this approach is built around: it is why agents construct the safety net before they change anything, and why a Reviewer agent attacks their output before a human spends attention on it. A team that adopts AI without changing its process should expect the METR result. That is the honest reading of the evidence, and we would rather you had it from us.
Will this turn into a big-bang rewrite? +
No. The approach is incremental by design: the system is surveyed, then protected and improved one prioritized area at a time, while it keeps running in production. You can pause after any phase and keep everything gained. The documentation, the tests, and the improvements all live in your own repository.
What happens when the process finds bugs in our system? +
They are flagged, not silently fixed. In old systems, some incorrect-looking behavior is actually depended on by customers or downstream systems. A person with authority over the system rules on each finding: fix it deliberately as a planned change, or preserve it and document it. Nothing changes without that decision.
How is this different from giving our team AI coding assistants? +
An assistant makes your existing process faster. If that process is "change it and hope," you get faster hoping. The methodology changes the process itself: specifications steer the AI before it works, a Reviewer agent and automated checks verify everything after, and human gates control what ships. The gap shows up in practitioners' own experience: in a 2025 study of 52 engineers working mostly on legacy systems, 68% rated ad-hoc AI use as not useful or only slightly useful, while 75% found a structured workflow more useful than ad-hoc use, the same people with the same tools, changing only the process around them (self-reported; Sharma, 2025). The difference lands not in typing speed but in regression rates, and in how quickly your system becomes safe to change.
Do we end up dependent on Eastgate or on a specific AI vendor? +
No. Every artifact the engagement produces (tests, specifications, documentation, refactored code) is standard, portable, and stored in your version control. The methodology runs on open, tool-agnostic foundations. If we finish and you never call us again, everything keeps working.
Read the Full White Paper
Detailed framework, implementation methodology, and actionable insights - available instantly with your business email.
About Eastgate Software
Eastgate Software is a strategic engineering partner headquartered in Hanoi, Vietnam, with offices in Aachen, Germany and Tokyo, Japan. With 200+ engineers, 93% team retention, and 12+ years of delivery excellence, we build mission-critical systems for clients including Siemens Mobility and Yunex Traffic.
Our ACDC (Agent-Centric Development Cycle) methodology combines German engineering discipline with Vietnamese engineering talent to deliver enterprise-grade results across Intelligent Transportation, FinTech, Retail, and Manufacturing.
Contact: [email protected] | (+84) 246.276.3566 | eastgate-software.com
Let's Work Together
Tell us what you're building. Our engineers will respond within 1 business day with a concrete next step - no sales script, no obligation.
- Email[email protected]
- Phone(+84) 246.276.3566
- Response TimeWithin 1 business day