How AI helps analyse legacy code during modernisation, and where human review still matters

Open a ten-year-old codebase with no documentation and the first week goes on reading. Someone has to work out what the system does, which modules carry the business, and why an odd condition sits in the middle of the billing code. Legacy code analysis has always been slow and manual, and it has leaned on the few people who remember the original design.

Take a rule such as a 15% discount for customers older than three years. It may live in three places with three different thresholds, and nobody remembers which one is current.

AI coding assistants change the pace of that reading. They leave the accountability for the conclusions exactly where it was. This article sets out which analysis tasks an assistant handles reliably, where it goes wrong, which checks need an engineer, and how to build a review step that catches errors before they reach a plan.

AI is dependable at reading code and describing it: summarising modules, mapping calls, drafting documentation and proposing tests. It is unreliable at knowing what the business intended. Treat every output as a draft that an engineer verifies against people, reports and a running system.

Tasks an AI assistant usually handles well:

Tasks that need a human check every time:

AI reads unfamiliar code quickly and explains it in plain language, which is the part of legacy code analysis that used to consume the most time. It performs well on self-contained modules with clear inputs and outputs, and poorly where meaning sits outside the code.

Give an assistant a pricing module and it can describe the steps in order: how a base price is taken, which discounts apply, how rounding is handled and what is returned. A new engineer gets a working explanation in minutes instead of an afternoon of tracing.

The same approach helps with business rules. Asked to list the conditions that change an order status, an assistant can pull them out of nested branches and write them as short sentences that a product owner can read. That list is a hypothesis, and Thoughtworks engineers writing on martinfowler.com likewise treat such output as a starting point for conversation with subject experts. It describes what the code does, and the code may be wrong, out of date or bypassed.

Language is rarely the obstacle. Assistants read old dialects, unusual naming and sparse comments without much complaint, so a team can start on a codebase written in a language nobody on the team uses any more. Context is the obstacle: the assistant sees the file it was given and little of the habits, contracts and workarounds around it.

Use this stage to build a shared first map of the system, and keep it separate from the specification.

An assistant can build a useful map of calls, database access and unused code across a large repository in a short time. The map is usually incomplete where code connects through reflection, configuration, stored procedures or scheduled jobs. Treat it as a starting point for investigation.

Static references are the easy part. An assistant can list which services call a billing function, which tables a report touches and which classes no longer have a caller. It can also flag duplicated logic, such as two near-identical tax calculations that drifted apart over the years.

Gaps appear where the connection is invisible in the source. A job that runs at night and reads a table another service wrote, a class loaded by name from a config file, a stored procedure called from a reporting tool outside the repository: none of these leave a clear trail in the code the assistant was given.

A dead-code finding deserves the same caution. A function with no callers may run once a year in a month-end process, so confirm with logs or the people who operate the system before anyone deletes it.

AI can draft documentation from code and generate characterisation tests that record what the system does today. Both are valuable as a safety net for change. Neither tells you whether the current behaviour is correct, so someone who knows the intended behaviour must review them.

Documentation drafted from code tends to be accurate about structure and weak on purpose. A generated description of a function will list its parameters and branches, and it may say nothing about why the branch for customers in one region exists. Ask the engineer or analyst who knows the module to read the draft and add the reason.

Characterisation tests record current behaviour: given these inputs, the system returns these outputs. They let a team change code and see at once whether behaviour moved. An assistant can write a first batch quickly.

Coverage is the catch. Generated tests lean towards the happy path, and a test that passes against the old system only proves that the old system does what it does. Run the tests against the legacy system first, read the failures, and add cases for the awkward inputs that production has seen.

AI analysis fails in four recurring ways: it invents connections that do not exist, it misses rules that were never written down, it loses the thread in a large codebase, and it exposes code when the wrong tool is used. Each has a practical countermeasure, and two appear in the OWASP Top 10 for LLM applications as Misinformation and Sensitive Information Disclosure.

Invented connections. An assistant may describe a call between two modules because the names suggest one. Sample the claimed links and confirm each against the source.

Missing unwritten rules. Workarounds, client-specific exceptions and manual steps around the system rarely appear in code. The assistant cannot report what it never saw.

Lost context. On a large repository an assistant works with the part it was given. Conclusions about the whole system, built from a part, can be confidently wrong, so ask for the evidence behind a claim and the files it came from.

Code exposure. Pasting proprietary code into a consumer chat tool can breach contracts and internal policy. Use tools covered by an enterprise agreement with clear data terms, and keep sensitive repositories inside approved environments.

An engineer or process owner must verify any AI output that feeds a decision, and the UK's NCSC has warned that insecure AI-generated code spreads vulnerabilities when no human reviews it. The table below pairs each analysis task with the check to run and the sign that the output should be rejected. It works as a review checklist for any team.

Pick a sample large enough to mean something, and record what was checked and by whom. A review that leaves no trace is hard to defend later.

Three decisions stay with people whatever the tooling. These are decisions an assistant cannot own, because the facts behind them live in the business.

What to modernise first. Priority depends on revenue, risk, budget and team capacity, none of which sit in the repository.

Target architecture. Choosing between rehosting, refactoring and rebuilding is a judgement about cost, skills and the business plan.

Production risk. Downtime windows, data migration, rollback and compliance obligations need someone who answers for them.

A workable review process has five steps: budget the hours, cross-check against people and records, sample the rules, run the tests on the old system and log every decision. It is short enough to follow on every analysis task.

Where possible, keep the same engineer on a module from analysis through to sign-off, so context is not lost between steps. Practitioners describe the same pattern, with AI applied to defined tasks such as documenting code, extracting business rules and generating first tests while a senior engineer reviews every output; AI-assisted modernisation is one such write-up.