Questions to ask before using an AI coding assistant on legacy code

Why ask questions before you point an assistant at legacy code

An AI coding assistant is a good tool for a lot of work. It drafts functions, explains unfamiliar syntax and speeds up routine edits. Legacy systems are a different case. A COBOL batch program or an Oracle Forms module often carries decades of business rules that nobody on the current team wrote and nobody fully remembers.

The risk is not that the assistant writes bad syntax. The risk is that it writes confident, plausible code that quietly drops or changes a rule it never saw. This checklist helps you decide whether an assistant is enough for the task in front of you, or whether you need a discovery step first. For background on how AI reads this kind of code, see how AI agents read legacy code.

Questions about context limits

Most assistants work on whatever fits in the window you give them: a file, a few files, or a snippet. Legacy systems rarely fit that shape. A single field can be touched by copybooks, shared libraries, stored procedures and screens spread across the whole estate.

  • How much of the system can the assistant see at once, and what happens to the parts it cannot see?
  • Can it follow a field across program boundaries, copybooks and database objects, or only inside the file you pasted?
  • Does it tell you when it is missing a dependency, or does it fill the gap with a guess?
  • Who decides which files go into the prompt, and how do you know that choice was complete?

If the honest answer is that a person picks files by hand and hopes, the assistant is working from a partial picture. That is fine for a self-contained change and risky for anything that crosses components.

Questions about business rule accuracy

In legacy code, the business rule is often the thing you cannot afford to lose, and it is rarely labeled. It lives in a condition, a rounding step or an order of operations. Documentation is usually incomplete or out of date, so the code is the only record.

  • Does the assistant explain what a rule does in business terms, or only restate the code line by line?
  • Can you trace each stated rule back to the exact source lines that support it?
  • If the assistant rewrites a routine, how will you confirm the old behavior and the new behavior match, including edge cases and error paths?
  • Who on your side is able to judge whether an explanation is right, given that the original authors may be gone?

A summary that sounds right but cannot be traced to source evidence is a claim, not knowledge. If you need the rules written down before anyone changes anything, read about how to extract business rules from COBOL code.

Questions about data handling

Legacy code in banking and insurance often sits next to regulated data, and the code itself can reveal how that data is processed. Before anything is uploaded or pasted, get clear answers.

  • Where does your code go when you use the assistant? Is it sent to an outside service, and under what terms?
  • Is your code retained, logged or used to train a model?
  • Does the tool need access to production data or only to source code and metadata?
  • Can it run inside your own environment if your security team requires that?
  • Do your compliance and audit obligations allow this kind of tool on this particular codebase?

Get these answers in writing from the vendor, and involve security early. Changing course after a codebase has already been shared is much harder than asking first.

Questions about verification, and when you need discovery first

Verification is where most legacy AI projects succeed or fail. Generated code that compiles is not the same as code that behaves the way the business expects.

  • What tests exist today for the code you are changing? If there are none, what will you compare the new behavior against?
  • Who reviews the output, and do they understand the original system well enough to catch a missing rule?
  • How will you find out what else a change touches before it reaches production?

A simple way to decide: an assistant is usually enough when the change is small, self-contained and covered by tests, and when someone on the team understands the surrounding logic. You likely need a discovery step first when the code is poorly understood, when a change crosses many components, when the original developers are gone, or when the work feeds a migration or audit. Discovery means mapping the rules, workflows and dependencies before anyone edits code. Our guide to legacy code analysis covers what that step involves, and AI-assisted legacy code modernization explains how it connects to the work that follows.

If you are weighing vendors for that step, the vendor evaluation questions page is a useful companion to this checklist.

Frequently asked questions

Can an AI coding assistant safely change COBOL or Oracle Forms code?

It can for small, self-contained changes that are covered by tests and understood by someone on the team. For changes that cross many components or touch rules nobody has documented, mapping the system first is the safer path.

Why do legacy systems cause problems for AI coding assistants?

Legacy systems often hold decades of business logic spread across programs, copybooks and database objects, with incomplete documentation. An assistant that sees only a few files may miss rules that live elsewhere.

What data handling questions should I ask before using an assistant on my code?

Ask where the code is sent, whether it is retained or used for training, whether production data is needed, and whether the tool can run in your own environment. Confirm that your security and compliance requirements allow it.

How do I verify that an assistant did not change a business rule?

Compare old and new behavior against tests or known outputs, including edge cases and error paths, and trace each stated rule back to the source lines that support it. Have someone who understands the original system review the result.

What is a discovery step and when do I need one?

Discovery means mapping the rules, workflows and dependencies in a system before anyone changes code. You likely need it when the code is poorly understood, the original developers are gone, or the work supports a migration or audit.