Methodology & Process
Modernizing Legacy Systems with the Agent-Centric Development Cycle
Why modernization stalls, and how a disciplined harness changes the economics
Eastgate Software - German Engineering Standards. Enterprise-Grade Results.
Modernizing Legacy Systems with the Agent-Centric Development Cycle: Why modernization stalls, and how a disciplined harness changes the economics
Every company running software more than a few years old has a system nobody wants to touch. It works, it makes money, and every change to it is a small gamble, because nobody can prove a change did not break something until a customer finds out. The classic answer, laid out by Michael Feathers in Working Effectively with Legacy Code (2004), is to build a safety net of automated tests before changing anything. The answer was always right. It was also always too expensive. AI agents change that economics, but only if they work inside a disciplined structure: pointed at unprotected code without one, the best current evidence says they make experienced engineers slower, not faster. This paper explains how agents build the safety net, a second layer of agents attacks their work, and humans keep the final say on every decision that matters.
The Definition
What Is Legacy Code, Really?
Ask most people and they will say legacy code is old code, or badly written code. The more useful definition comes from Michael Feathers, whose book remains the standard reference on the subject: legacy code is code without tests.
Why is that the definition that matters? Because "tests" here does not mean a QA team clicking through screens. It means automated checks that run in seconds and tell you, every time anyone changes anything, whether the system still behaves the way it did before. A system with those checks can be changed confidently, whatever its age. A system without them cannot be changed safely by anyone: not your best engineer, not a new hire, and not an AI.
For a business leader, the translation is simple: legacy code is any system where change is a gamble. The symptoms are familiar:
- Small changes take weeks, because most of the time goes into manual re-checking and fear.
- Estimates balloon, because nobody knows what a change might break.
- Knowledge lives in one or two veterans' heads, and their calendar is your release schedule.
- 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.
The Bottleneck
Why Do Most Modernization Projects Stall?
When teams change untested systems, they work in what Feathers calls "Edit and Pray" mode: plan carefully, make the change, then poke around and hope. Feedback arrives days or weeks later, from QA or from customers. The alternative he prescribes is "Cover and Modify": first put a safety net of automated checks around the code, then make changes, and know within seconds whether anything broke.
| 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 |
If Cover and Modify has been the known best practice for twenty years, why does almost everyone still operate in Edit and Pray? Because of the cost curve. Building a safety net around a large untested system is enormous, painstaking work: understanding what the system actually does, untangling components so they can be tested at all, then writing the thousands of checks that pin its behavior down. On a system of real size, that is many months of senior engineering time producing nothing a customer can see. Under quarterly pressure, it is 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.
The Evidence
Doesn't AI Solve This? Not by Itself.
The obvious idea is to hand the legacy system to an AI coding assistant and let it modernize faster. This is where the evidence turns uncomfortable, and where most AI modernization pitches quietly stop citing anything.
An AI agent is very fast and tireless, and it has no more ability to sense a silent breakage in an untested system than a human does. Point an unsupervised AI at a legacy codebase and you get Edit and Pray at machine speed: more changes per day, each one landing in a system with no mechanism to catch what broke. Speed multiplies output, and it multiplies risk by exactly the same factor.
That is not a rhetorical flourish. It is what the measurements show, and the measurements split sharply depending on what the AI is pointed at.
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
Randomized controlled trial: experienced developers using current AI tooling on genuine issues in repositories they already knew well. They finished slower, and 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 is largest in exactly the conditions your systems do not have, namely small scope, clean context, and no hidden constraints, and it turns negative in exactly the conditions they do (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.
So the question was never whether AI is fast. It plainly is. The question is what catches it when it is confidently wrong.
The AI industry has converged on a name for that missing ingredient: the harness. The idea, described publicly by both OpenAI and Martin Fowler, is that a useful AI agent is a model plus a harness, the structure around it. The harness has two halves: guides that steer the AI before it acts (specifications, rules, and constraints that define what "correct" means), and sensors that check 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 test suite is a sensor layer. A legacy system, being code without tests, is a system with no harness for anyone, human or machine. Which means the Brownfield Paradox is not really a fact about AI. It is a fact about unprotected code: it punishes anything that moves quickly through it. AI simply moves more quickly than we ever did, so it collects the punishment faster. The first job of any credible AI-powered modernization, therefore, is not to change the code. It is to build the harness.
The Shift
How Does ACDC Change the Economics?
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 does something more valuable. It attacks the exact cost that has always killed modernization projects.
Recall what building the safety net requires: reading enormous amounts of code, untangling dependencies, and writing thousands of behavior-pinning tests. This work is high-volume, mechanical, and, critically, machine-checkable. That is precisely the profile of work where AI agents outperform humans by the widest margin, and where humans add the least unique value. Meanwhile, the parts that genuinely require judgment, such as deciding what the system should do, what counts as a bug, and what risk is acceptable, stay exactly where they belong: with people.
This split is not something we invented, and your engineers will not need convincing of it. The 2025 Stack Overflow Developer Survey found that 75-80% of developers already 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 not that insight. It is turning an instinct into a discipline that still holds under deadline pressure, when instinct is the first thing to go.
Builder agents
The volume work- Read the entire codebase, not a sample of it, and map how everything connects.
- Identify the safest points to isolate each component so it can be tested. Feathers calls these "seams": places where behavior can be redirected for testing without rewriting the surrounding code.
- Untangle dependencies using well-established, mechanical refactoring recipes.
- Generate the safety-net tests themselves, at a volume no human team could afford.
Reviewer agents
The adversarial pass- A separate agent, running under different instructions and with no stake in the Builder's answer, has exactly one job: find what the Builder got wrong.
- A deployed LLM pre-review system at a large technology company caught 60-75% of the issues human reviewers would have caught, before the code ever reached a person (Sun et al., FSE 2025).
- It does not replace the human gate. It makes the human gate affordable: your senior engineer opens a diff that has already survived an adversary.
Humans
The calls that matter- Which parts of the system matter most to the business, and in what order.
- Whether a strange behavior the agents uncover is a defect to fix or a quirk that customers and downstream systems depend on.
- Whether each change is approved to ship. Nothing merges without human sign-off.
The result is not "AI replaces the engineering team." It is that the safety net, the thing that was always too expensive to build, becomes affordable, and everything downstream of it becomes faster and safer.
The Core Technique
What Do "Characterization Tests" Mean for a Business Owner?
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.
The Sequence
How Does Modernization Proceed Without 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.
Independent Validation
Is This 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.
Governance
Where Exactly Do 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.
The Limits
Where Do We Not 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.
The Engagement
What Should You 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.
References
What Is This Paper Built On?
Every figure in this paper traces to a named source. Where a source is weak, we say so.
-
Michael C. Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004
The definition of legacy code, the safety-net discipline, characterization tests, and the incremental modernization strategy referenced throughout this paper.
-
The randomized controlled trial finding a 19% slowdown on complex real-world tasks.
-
The roughly 55% speedup on simple, isolated tasks.
-
The Brownfield Paradox, the Builder/Reviewer dual-agent split, the experience paradox, and the ad-hoc versus structured comparison. An exploratory practitioner study (N=52) whose survey findings are self-reported; cited here as practitioner sentiment, not as controlled measurement.
-
William Harding, AI Copilot Code Quality (GitClear), 2025
Additional review rounds and reviewer comments on pull requests containing AI-generated code.
-
Tao Sun et al., "BitsAI-CR: Automated Code Review via LLM in Practice," Proceedings of FSE 2025
The deployed LLM pre-review system catching 60-75% of the issues human reviewers identified.
-
Documentation return on investment and its effect on delivery performance.
-
The 2024 State of Developer Productivity, Cortex, 2024
Context-gathering as the largest reported productivity leak.
-
Stack Overflow Developer Survey 2025 (AI section)
The task-level split in AI adoption between documentation and testing versus core business logic.
-
Martin Fowler, "Harness Engineering for Coding Agent Users," martinfowler.com, 2025; and OpenAI, "Harness Engineering," openai.com, 2025
The harness concept: guides that steer AI before it acts, sensors that check its work after.
-
Eastgate Software, Our Agent-Centric Development Cycle (ACDC), 2026
Companion white paper covering the full methodology in technical depth.
FAQ
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
Ready to Make That System Safe to Change?
Start with a pilot on one subsystem you currently fear touching. We survey it, protect it with a live safety net, and ship one change through the full process, so you can measure the result before committing further.
Engineers
ACDC (Agent-Centric Development Cycle)
Retention
Partners, not vendors
Years
Enterprise delivery