Technology

From Assistant to Agent: How to Use AI Coding Agents in Legacy Modernization Without Losing Control

Miłosz Cupiał
Head of Delivery
October 27, 2026
9
min read

Executive summary AI in software development has moved from autocomplete to agents: tools that take a task, plan the steps, change many files, run tests and propose a finished pull request. For organisations stuck with large legacy systems, that sounds like the answer to a decade of postponed modernisation. The early data is more nuanced. Teams using AI heavily produce far more code, but their pull requests are getting larger, contain more defects and take much longer to review. Analysts expect a large share of agentic AI projects to be cancelled because of unclear value, rising costs and weak governance. Agents can genuinely accelerate modernisation, but only when the work is well specified, protected by tests, broken into small steps and reviewed by people who understand the system. This article explains what agents do well in legacy code, where they fail, how to set up the guardrails and how to decide where to start.

What Changes When an Assistant Becomes an Agent

A coding assistant suggests the next line or function while a developer types. An agent works on a task. It reads the relevant parts of the codebase, decides which files to change, writes the code, runs the tests, interprets the results and iterates until it believes the task is done.

Gartner describes this as a shift from AI-assisted development to agentic software development that spans planning, coding and review. It expects that by 2027 most engineering teams using agentic coding will treat the traditional development environment as optional, moving control, governance and validation to automated platforms.

For legacy modernisation, the difference matters in two ways. Agents can handle repetitive, multi-file changes that would take developers weeks, such as upgrading a framework across hundreds of modules. At the same time, they can make many changes very quickly in a system that nobody fully understands, which is exactly where mistakes are most expensive.

What the Data Shows So Far

Adoption is high, but results are mixed. An analysis by Faros AI covering more than 10,000 developers found that teams with high AI adoption complete around 21% more tasks and merge almost twice as many pull requests. Its 2026 data, however, also showed that in such teams pull requests grew by 51%, bugs per pull request rose by 28% and review time increased fivefold.

At the strategic level, Gartner estimates that more than 40% of agentic AI projects could be cancelled by 2027 because of unclear value, rising costs and weak governance.

The pattern is consistent: agents increase output, but output is not the same as progress. In legacy systems, where hidden dependencies and undocumented behaviour are the norm, unmanaged output turns into rework, review backlogs and production incidents.

Where Agents Help in Legacy Modernisation

Agents are most useful where the task is clearly defined, the change follows a recognisable pattern and the result can be verified automatically.

TaskAgent suitabilityWhy
Analysing and documenting unfamiliar codeHighReads large codebases quickly, produces summaries and dependency maps for human review
Generating characterization testsHighCaptures current behaviour before changes, with expected values taken from real execution
Framework and library upgradesHighRepetitive, pattern-based changes across many files, verifiable by tests and builds
Migrating API calls or language versionsMedium to highWell-defined transformations, but edge cases need careful review
Extracting modules or servicesMediumAgents can do the mechanical work, but boundaries must be designed by architects
Redesigning core business logicLowRequires domain knowledge, trade-offs and decisions agents cannot own
Changes in safety-critical or regulated logicLowHuman authorship and verification remain essential

The best results come when people decide what should change and agents carry out the how.

Where Agents Fail

Missing context. Legacy systems contain knowledge that is not in the code: business rules agreed years ago, workarounds for specific customers, integrations documented nowhere. Agents cannot know what they cannot see.

Changes that are too large. Given a broad task, an agent may change dozens of files in one go. Large changes are harder to review and harder to roll back, and that is exactly when defects slip through.

Plausible but wrong code. Agent output usually looks clean and consistent. That makes subtle errors, such as a changed rounding rule or a missing null check, easier to overlook.

Weak tests. If tests are missing or shallow, an agent can make them pass without preserving the behaviour that matters. In legacy code, this is the most common source of hidden regressions.

Uncontrolled costs. Agents that run many iterations on complex tasks consume significant compute. Without limits and measurement, costs grow faster than value.

Guardrails That Make Agents Safe to Use

1. Protect the code with tests first. Before any agent changes legacy code, the current behaviour of the affected modules should be captured in characterization tests. This is the single most important precondition. An agent without a reliable test suite is working blind.

2. Specify tasks precisely. Good tasks have a clear scope, explicit constraints and a definition of done: which modules may change, which interfaces must stay stable, which tests must pass. The quality of the specification largely determines the quality of the result.

3. Keep changes small. Break modernisation into small, independently reviewable steps. Limit the size of pull requests that agents may open, and prefer a sequence of small changes over one large transformation.

4. Keep humans in the review loop. Every agent-generated change goes through the same review and approval process as human-written code. Reviewers should know which changes came from an agent and focus on behaviour, not formatting.

5. Restrict permissions. Agents should work in isolated environments with access only to the repositories and resources they need. They should not have direct access to production systems, production data or secrets.

6. Automate verification. Builds, tests, static analysis and security scanning should run on every change and block anything that fails. A pipeline supported by mature DevOps and cloud practices turns these checks into a reliable safety net rather than an afterthought.

7. Measure outcomes, not output. Track lead time, change failure rate, review time and rework alongside agent usage and cost. If more code leads to more incidents, the process needs adjusting, not more agents.

A Practical Way to Start

Assess before you automate. Not every part of a legacy system is ready for agents. Some modules have reasonable structure and test coverage; others are tightly coupled, poorly understood and business-critical. An AI refactoring assessment maps the codebase, identifies where agents can safely accelerate the work and where human-led redesign is needed, and produces a prioritised modernisation roadmap.

Pilot on a contained, well-understood task. A framework upgrade in a non-critical module or test generation for a single service is a good first step. It shows how agents behave in your codebase, what review effort they create and what the real cost is.

Build the workflow, not just the tooling. Task templates, review guidelines, permission models and metrics matter more than the choice of agent. Embedding these into the delivery process, as we describe on our AI-assisted software delivery page, is what turns a pilot into a repeatable practice.

Scale step by step. Extend agent use to further modules only when the metrics confirm that quality and stability are holding.

In one engagement with a DACH industrial software provider, most engineering time was going into maintaining legacy modules, leaving little capacity for modernisation. A phased introduction of AI tooling, prioritised by risk and impact and combined with hands-on enablement, freed up meaningful engineering capacity, reduced lead time for changes and improved release predictability. The gains came from sequencing and discipline, not from giving agents free rein.

Agents Do Not Replace Engineering Judgement

Agents change the economics of legacy modernisation. Work that was too tedious or too expensive to justify, such as upgrading dependencies across hundreds of modules or building test coverage for neglected code, becomes realistic. But the responsibility for understanding the system, deciding what should change and verifying that it still works stays with people.

Organisations that combine agents with clear specifications, solid tests, small steps and careful review will modernise faster and with less risk. Those that hand agents a legacy codebase and hope for the best will produce more code and more problems. If you want to find out where agents can safely accelerate the modernisation of your systems, let's talk about how our product and application engineering teams can plan and deliver it with you. For investors, the same discipline is increasingly visible in a technology due diligence, where governed use of AI is a sign of engineering maturity.

‍

FAQ

FAQ - How to Use AI Coding Agents in Legacy Modernization Without Losing Control

What is the difference between an AI coding assistant and an AI coding agent?

An assistant suggests code while a developer writes it, and the developer decides what to accept. An agent takes a task, plans the steps, changes multiple files, runs tests and iterates on its own until it proposes a finished result. Agents can do more work independently, which also makes guardrails and review more important.

Can AI agents modernise a legacy system on their own?

No. Agents can carry out well-defined, repetitive and verifiable tasks very effectively, but they lack the business context and architectural judgement needed to decide what a system should become. Modernisation still needs people to design the target, set priorities and verify results.

Why are tests so important before using agents on legacy code?

Tests are the only reliable way to confirm that an agent's changes have not altered important behaviour. In legacy code without tests, an agent can produce changes that compile and look correct but quietly break business rules. Characterization tests that capture current behaviour should come first.

How do we prevent agents from creating a review bottleneck?

Limit the size of changes agents may submit, break tasks into small steps, automate as many checks as possible in the pipeline and give reviewers clear guidelines on what to focus on. Measuring review time from the start shows early whether the bottleneck is growing.

Is it safe to give agents access to our codebase?

It can be, provided agents run in isolated environments with limited permissions, use approved tools with appropriate enterprise terms and have no access to production systems, production data or secrets. These rules should be defined before the first pilot.

Where is the best place to start with agents in legacy modernisation?

Start with an assessment of the codebase to identify modules that are suitable for agent-assisted work, then run a pilot on a contained task such as a framework upgrade or test generation. Use the results to define workflows and metrics before scaling to more critical parts of the system.

Articles you might be interested in

Vulnerability Management for Software Products: How to Detect, Assess and Respond Within 24 Hours

October 27, 2026
Minutes

Measuring the ROI of AI in the SDLC: DORA Metrics Instead of Productivity Claims

September 30, 2026
Minutes

AI in Software Delivery for Regulated Industries: How to Keep Auditability and Compliance Intact

September 30, 2026
Minutes