AI coding agents can accelerate legacy modernisation, but they should not be allowed to redesign an unfamiliar system from prompts alone. The safe operating model is evidence first: map the application, capture current behaviour in tests, define architectural boundaries, assign narrow changes to the agent, review every dependency and validate production outcomes. The agent produces options and implementation speed; accountable engineers retain decisions, risk ownership and release authority.

The biggest mistake is measuring success by generated code or closed tickets. A modernisation programme succeeds only when the application becomes easier to change, safer to operate and cheaper to own without altering business rules that users depend on.

Why legacy code is uniquely difficult for an AI coding agent

A legacy system is not merely old code. It is an accumulated operating model containing business rules, data conventions, exception paths, integration assumptions and workarounds that may exist nowhere else. Some apparently redundant branches protect month-end processing. An unusual database field may satisfy an old partner contract. A scheduled job may compensate for a failure in another system. An agent sees code and repository context; it does not automatically see the commercial history behind that code.

Large repositories also exceed practical context windows. Agents retrieve fragments, infer relationships and act with incomplete information. This can produce locally clean code that breaks cross-module behaviour. The danger increases when tests are weak, files are large, naming is inconsistent or production behaviour differs from documentation.

The confidence problem

Coding agents often produce fluent explanations and coherent patches even when their assumptions are wrong. Treat confidence as presentation, not evidence. Require traceability from every change to a requirement, observed behaviour, test, dependency or approved architectural decision.

The speed problem

Generation compresses implementation time, but review, testing, migration and operational validation do not disappear. If a team accepts larger batches because code arrives faster, risk can accumulate faster than reviewers can understand it. Limit work in progress and optimise for reviewed, deployable change rather than generated output.

Where AI coding agents create real value

The strongest use cases are bounded and verifiable. Agents can explain unfamiliar modules, map call paths, identify duplicated logic, draft characterisation tests, convert repetitive syntax, update framework APIs, generate documentation, propose dependency upgrades and prepare small refactoring patches. They are especially useful when the desired outcome is clear and the team has deterministic checks.

Agents can also reduce the cost of discovery. Instead of asking engineers to read every file manually, use the agent to produce a provisional application map, then verify it through code search, runtime traces, database analysis and interviews. This changes the economics of assessment without delegating architectural truth.

A safe modernisation operating model

1. Establish the business and technical baseline

Document the application’s users, critical workflows, service-level expectations, peak periods, regulatory obligations, data classifications, interfaces, deployment model and current pain. Capture lead time, change-failure rate, incident frequency, recovery time, infrastructure cost, defect escape rate and unsupported dependencies. Without a baseline, teams cannot distinguish genuine improvement from code churn.

2. Build a verified system map

Inventory repositories, runtime services, scheduled jobs, databases, queues, external APIs, secrets, infrastructure, owners and deployment pipelines. Combine static analysis with logs, traces, database queries and stakeholder interviews. Ask the agent to identify relationships and unanswered questions, but mark every relationship as observed, inferred or unverified.

3. Freeze behaviour with characterisation tests

Before changing architecture, capture what the system currently does. Prioritise revenue, authentication, permissions, financial calculations, data exports, integrations and recovery paths. Use production-like fixtures and golden-master comparisons where exact behaviour matters. Agent-generated tests are a starting point; reviewers must challenge whether the tests encode intended behaviour or simply repeat the implementation.

4. Define target boundaries before generating code

Specify which modules may change, which interfaces remain stable, what data contracts apply and what quality attributes the target must meet. Use an architecture decision record for material choices. A clear boundary prevents an agent from improving one layer by creating coupling in another.

5. Work in reversible slices

Prefer small vertical slices that can be deployed behind feature flags, compared with existing behaviour and rolled back independently. Useful patterns include branch by abstraction, strangler routing, parallel runs and expand-and-contract database changes. Each slice should have a named owner, acceptance tests, telemetry and rollback trigger.

6. Review at multiple levels

A pull-request review is not enough. Review generated changes for correctness, architecture, security, privacy, data migration, performance, operability, licensing and dependency provenance. Use automated checks for formatting, types, tests, vulnerabilities and secrets, but retain human review for business rules and system-level consequences.

7. Release with observability

Instrument old and new paths with comparable metrics. Monitor errors, latency, resource use, queue depth, data reconciliation, user completion and business outcomes. A technically successful deployment that reduces conversion, delays settlement or increases support load is not a successful modernisation.

Repository controls that improve agent performance

Create concise repository instructions covering architecture, approved commands, coding standards, test expectations, security constraints and prohibited operations. Keep them specific: name the test command, required directories and dependency policy. Provide a glossary for domain terms and an application map that points to authoritative sources.

Restrict agent permissions by default. Separate read-only analysis from code-writing and deployment privileges. Protect production credentials, customer data and signing keys. Require approval before installing packages, changing infrastructure, modifying schemas or calling external services. Record prompts, tool calls, diffs and approvals for auditability.

How AI-assisted modernisation creates new technical debt

Duplicated abstractions

An agent may introduce a new helper without discovering an existing one. Over time, parallel abstractions fragment behaviour. Use architectural tests, dependency rules and duplicate detection, and require repository-wide search before adding shared components.

Test-shaped correctness

Generated code may satisfy visible tests while violating unstated requirements. Include mutation testing, property-based tests, contract tests and production shadow comparisons where appropriate. Review test quality separately from implementation quality.

Dependency inflation

Agents may solve small problems by adding packages. Every dependency adds maintenance, licensing and supply-chain exposure. Maintain an allowlist, require justification and prefer standard-library or existing platform capabilities when reasonable.

Unowned generated code

If nobody can explain a change, it is not maintainable. Make code comprehension part of the definition of done. The responsible engineer should be able to describe behaviour, failure modes, monitoring and rollback without relying on the agent transcript.

Build, refactor or replace: the decision framework

Use AI-assisted refactoring when business behaviour remains valuable, the architecture can evolve incrementally and operational risk makes replacement unattractive. Replatform when the core application is sound but infrastructure or runtime constraints dominate. Replace a component when it is commoditised, poorly differentiated and expensive to maintain. Rebuild only when current behaviour and architecture block the future business model and a controlled migration path exists.

Do not let agent capability determine strategy. The correct path comes from business value, system health, data risk, change frequency, available skills and migration economics.

Cost, timeline and team implications

AI can reduce time spent on discovery, repetitive conversion, documentation and first-draft testing. It does not remove product decisions, architecture, environment work, data migration, security review, user acceptance or change management. Budget by workstream rather than by generated lines of code: assessment, stabilisation, platform foundation, migration slices, verification, rollout and decommissioning.

A practical core team includes an accountable product owner, modernisation architect, engineers familiar with the existing system, quality engineering, platform or DevOps support and security involvement. Add data, compliance and domain specialists when workflows require them. The most important role is the person who can validate business behaviour.

Metrics that prove the programme is working

Track deployment frequency, lead time, change-failure rate, recovery time, escaped defects, vulnerability age, unsupported dependencies, test reliability, build duration, cloud cost, incident load and the percentage of critical workflows covered by telemetry. Pair these with business metrics such as task completion, conversion, fulfilment time and support demand.

Measure agent contribution separately: accepted-change rate, review rework, defects associated with generated changes, time saved by task type and the proportion of changes reviewers can explain. A high generation rate with high rework is not productivity.

How to choose a modernisation partner

Ask prospective partners to assess a representative slice before proposing a full transformation. Look for evidence of legacy discovery, incremental architecture, data migration, testing, security and production operations. Require them to explain how they govern coding agents, validate generated work and preserve business behaviour. Avoid proposals that promise automatic conversion without a dependency map, test strategy, rollback model or named technical owners.

Project Supply can audit a legacy application, establish the modernisation baseline, define a target architecture and deliver reversible migration slices with engineering, cloud, quality and security controls. Start with a scoped technical assessment rather than a commitment to rewrite.

A 90-day AI-assisted modernisation pilot

Days 1–15 should establish the baseline: system map, critical workflows, security boundaries, repository instructions, test gaps and measurable pain. Select one bounded workflow whose business owner is available. Do not begin with a cosmetic module that cannot prove the operating model.

Days 16–30 should create characterisation tests, observability and a reversible target boundary. Run the agent in read-only analysis first, compare its map with runtime evidence and document contradictions.

Days 31–60 should deliver two or three small slices behind flags. Measure review time, rework, test quality, defects and deployment outcomes. Rotate reviewers so capability is not concentrated in one advocate.

Days 61–90 should run a production pilot, close documentation, test rollback and decide whether the method scales. The exit decision should state where agents are approved, restricted or prohibited.

Detailed technical control checklist

Repository context should identify domain boundaries, source-of-truth documents, approved dependencies, test commands and security restrictions. Access controls should separate analysis, code modification, package installation, infrastructure change and release. CI should enforce types, tests, dependency policy, secret scanning, static analysis and artefact provenance.

Architecture controls should prevent forbidden dependencies and cross-domain coupling. Data controls should protect production information, migration scripts and destructive operations. Operational controls should require telemetry, runbooks, alerts and rollback for every production slice. Governance should retain the model, prompt or instruction version, tool activity, approving engineer and resulting commit.

Industry scenarios

In banking, a generated refactor may alter rounding, settlement order or entitlement logic; use golden transaction sets and independent reconciliation. In healthcare, protect patient data and validate interoperability contracts and audit trails. In manufacturing, account for plant connectivity, batch jobs and equipment interfaces that may not exist in development environments. In ecommerce, test promotion, tax, inventory, fulfilment and analytics paths under real campaign load.

The engineering pattern is shared, but acceptance evidence must reflect the industry consequence.

Procurement questions for coding-agent platforms

Ask how repository content is stored, retained and used; which models and regions apply; how administrators restrict tools; how audit logs work; whether generated code includes provenance or licence risk controls; how data deletion and model changes are handled; and what enterprise support covers.

Run a security and architecture assessment before broad enablement. Platform approval does not approve every use case. Maintain a register of permitted repositories, data classes and autonomy levels.

The business case

Separate automation benefit from modernisation benefit. Agent benefit includes reduced discovery, documentation and repetitive conversion effort. Modernisation benefit includes faster releases, lower incidents, supported technology and reduced run cost. Avoid counting the same saving twice.

Model implementation, review, platform, security and change-management cost. Use pilot evidence to estimate scale. A credible business case includes downside scenarios where review or test work increases before capability improves.

Detailed execution checklist

Behaviour inventory

Record critical inputs, outputs, state transitions, exception paths and manual workarounds. Link each rule to code, runtime evidence and a domain owner. The inventory becomes the acceptance basis for agent-assisted change and prevents apparently cleaner code from removing behaviour the business still needs.

Agent task design

Define the exact files, goal, constraints, commands, test evidence and stopping condition. Ask the agent to state assumptions and unresolved questions before editing. A bounded task creates a reviewable diff; an open instruction such as modernise this repository creates uncontrolled architectural scope.

Independent verification

Have a reviewer validate code without relying on the generation narrative. Run tests in a clean environment, inspect dependency and security results, compare runtime behaviour and require the engineer to explain the change. Independence reduces automation bias.

Practitioner planning workbook

Pilot exit review

For pilot exit review, compare baseline delivery, reliability, security and review evidence; approve only bounded agent uses and document prohibited actions. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.

Scale decision

The scale decision workstream should estimate reviewer capacity, platform cost, repository readiness and domain ownership before adding teams. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.

Executive reporting

Treat executive reporting as an operating control: show value released, technical debt retired, critical failures, human rework and next risk decision. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.

Sources and further reading

GitHub: Modernizing legacy code with GitHub Copilot

GitHub: Modernizing Java applications with Copilot

AWS Prescriptive Guidance: Phased application modernisation

Microsoft VS Code: Copilot best practices

Talk to Project Supply

If your team wants to use coding agents without losing control of a business-critical application, Project Supply can run a technical audit and build an evidence-based modernisation roadmap. The engagement can cover architecture, code quality, test strategy, cloud, security, migration sequencing and delivery ownership.

Project Supply perspective

Project Supply approaches this topic as an operating and delivery decision, not a standalone technology purchase. Our software architecture, modernisation, cloud and production engineering work connects architecture, implementation, risk, measurement and ownership so the recommended change can move from assessment into a controlled production outcome.

Service pathway: Explore Project Supply Digital Engineering

Conversion pathway: Discuss this requirement with Project Supply