A developer rests their chin on one hand while comparing two laptops on a plain desk
Use the explanation, then check it against what the code does.

AI for legacy code works best as a fast reader of the files you give it. It explains functions, summarizes modules, drafts tests and suggests refactors. It goes wrong on anything outside its context, such as other systems, runtime configuration, real data and the reason a rule exists, and it can be confidently wrong about all of them.

This post covers what the main tools do on old code, in their vendors' own words, where they fail, how to choose one, and how to use one without adding risk.

Key takeaways
  • AI assistants are good at local work on old code: explaining a function, summarizing a module, finding usages, drafting tests and translating syntax.
  • They go wrong on what they can't see: other systems, runtime configuration, production data and the business reason behind a rule.
  • There's no single best AI for legacy code. Choose by language, by where the code runs, and by where your code is allowed to go.
  • Write characterization tests first, check every explanation against behavior, and keep one named person responsible for each finding.
01

What AI coding assistants do well on legacy code

They're good at reading code nobody on the team wrote, a few files at a time: explaining a long function, summarizing a module, finding every use of a field, drafting tests, translating syntax and suggesting small refactorings. Here is what each vendor says its tool does, checked on 27 October 2026.

ToolWhat the vendor saysWorth knowing
GitHub CopilotIt "suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it" (GitHub Docs)GitHub's translation tutorial shows a Perl script moved to TypeScript, and warns that responses "are non-deterministic"
Claude Code"An agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools" (Claude Code docs)Lists "writing tests for untested code" among its uses
Cursor"Agent is Cursor's assistant that can complete complex coding tasks independently, run terminal commands, and edit code" (Cursor docs)Works inside the Cursor editor
Amazon Q DeveloperIn the IDE it "can chat about code, provide inline code completions, generate net new code, scan your code for security vulnerabilities, and make code upgrades and improvements" (AWS docs)On 30 April 2027, AWS "will discontinue support for Amazon Q Developer IDE plugins" (AWS notice)
AWS TransformFor mainframes: codebase analysis, documentation, business logic extraction, decomposition, and refactoring COBOL into Java (AWS docs)Covers z/OS COBOL and PL/I with JCL, CICS, BMS, Db2 and VSAM
IBM watsonx Code Assistant for Z"Explain code in natural language" and "Auto-refactor into modular services" (IBM)For COBOL to Java, "auto-generated unit tests to compare semantic equivalence"
02

Where AI goes wrong on old code

Michael Feathers, author of Working Effectively with Legacy Code, said in a 2024 interview, "I do use it to explain code to me quite often," but called what he gets back on a large class's responsibilities "kind of like eh, so-so." The failures share a cause: the tool sees text, not the running system.

  • Only what's in context. GitHub's responsible use page says of Copilot Spaces: "Not every file, document, or note in a space will be used in a response."
  • Other systems. The nightly file another team picks up isn't in the repository.
  • Runtime configuration and data. Reading the code can't reveal that status 9 means "closed by legal" in your data.
  • Business intent. An explanation of an odd rounding rule describes the arithmetic, not the agreement with finance behind it.
  • Confident but wrong. The same GitHub page warns that Copilot Chat "may generate code that appears valid but is not semantically or syntactically correct" and says to "Carefully review and test generated code." A fluent wrong explanation is harder to spot than broken code.
  • Invented APIs. Suggestions can call methods that don't exist in your version. The build catches these, which makes them the easy kind of error.
03

What is the best AI for legacy code?

There's no honest single answer, and rankings go stale fast. The best AI for legacy code is the one that handles your language, can work where your code is allowed to go, and fits how your team checks its work.

QuestionWhy it mattersWhat to check
Does it handle your language and platform?Mainframe COBOL, a VB6 desktop app and a Java 8 service are different problemsSupported languages and file types
Can your code go there?Contracts and regulations may limit where code and data are sentData handling, retention and training terms
Can it run your build and tests?A tool that runs tests can check its own suggestionsWhether it works in your build environment
How much of the codebase can it see?An answer about one file misses callers in anotherIndexing, context limits, file exclusions
Will it be supported long enough?One plugin above already has an end-of-support dateThe vendor's lifecycle notices
04

Is there an AI agent for legacy code?

Yes. An assistant suggests; an agent also edits files and runs commands to finish a task. Claude Code and Cursor's Agent work this way, GitHub says Copilot "works on tasks you assign it," and AWS calls AWS Transform "an agentic AI experience" (AWS). Agents suit repetitive, checkable work, such as an upgrade across many files with tests that must stay green. Without tests, an agent makes plausible changes faster than anyone can review them.

05

How to use AI to understand legacy code safely

  1. Write characterization tests first. Tests that pin today's behavior make each suggestion checkable. Our guide to refactoring legacy code covers how.
  2. Check every explanation against behavior. If the assistant says a function rejects orders over a limit, run it with one. Our method for understanding legacy code starts from the running system for this reason.
  3. Keep one human owner per finding. Whoever writes a finding into the documentation owns it, whichever tool drafted it.
  4. Keep secrets and regulated data out. Strip credentials and customer data, and read the vendor's data pages first, such as GitHub's content exclusion settings and Anthropic's data usage page for Claude Code.
  5. Change in small steps. AI legacy code refactoring goes wrong when the diff is too big to read.

The same caution applies to AI legacy code modernization. Translating syntax moves the code without modernizing the design: COBOL translated line by line into Java keeps COBOL's structure, and its rules stay undocumented. Our code audit checklist covers what people still need to read.

06

Where people still have to read the code

Whatever tools your team uses, someone has to own the conclusions. The 30-day assessment does that for one system. It's fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the system fits together, find the hidden architectural debt, and flag the security and compliance gaps. Every finding carries evidence a person has checked: a file, a setting, a test result or someone who confirmed it.

The report says in plain language what is broken and what it would take to fix it. Your own team can act on it, or we can do the work as a separate project with its own scope and price. The report stands on its own either way.

Ask us whether it's worth assessing. Tell us what the system runs on and what you've tried with AI so far. If a narrower check would answer your question, we'll say so.