Using AI Coding Assistants to Understand Code You Didn't Write

AI assistants shine on legacy code: how to use Copilot-style tools to map, explain, and safely change an unfamiliar codebase without breaking it.

Most articles about AI coding assistants show them writing new code from a blank file. That is the easy case. The hard, expensive, everyday case is different: you inherit a codebase written by someone who left, with sparse comments, no tests, and a production system depending on it. Here, an assistant like GitHub Copilot is less a code generator and more a patient colleague who has read every file and never gets tired of your questions.

Used well, that colleague can turn weeks of archaeology into days. Used carelessly, it will confidently explain how the code should work rather than how it does. The difference is in how you ask.

Start with a map, not a fix

The instinct when handed a bug in unfamiliar code is to jump straight to the line that fails. Resist it. Spend the first session building a mental map with the assistant's help:

• Ask for a structural overview. Open the entry point and ask what the module is responsible for, what it depends on, and what calls it. Do this for the five or six files that matter most.
• Trace one request end to end. Pick a real user action and have the assistant walk you through the path, file by file. Verify each hop yourself by actually opening the code it points to.
• Ask what looks unusual. Assistants are good at spotting patterns that break convention: a global mutated from three places, a retry loop with no limit, a config value hardcoded in one environment.

The goal of this phase is not to change anything. It is to be able to predict what a change will do before you make it.

Make the assistant prove its claims

An AI explanation of code is a hypothesis, not documentation. The model may be pattern-matching on how similar code usually behaves rather than reading the specific logic in front of it. Treat every non-trivial claim as something to check.

Two habits make this cheap:

1. Ask for the exact line. "Where does the discount get applied?" should return a file and line reference, not a paragraph. If it cannot point to the code, be suspicious.
2. Ask for a failing case. "Give me an input where this function returns the wrong result." If the assistant produces one, run it. If it insists the function is correct, you have learned something about the code or about the limits of the explanation.

The assistant is fast at reading. You are still the one responsible for being right.

Write tests before you touch anything

Legacy code usually lacks tests, and this is where an assistant earns its keep. Ask it to generate characterization tests: tests that capture what the code currently does, including the odd behaviors. You are not asserting the code is correct. You are pinning down its present behavior so any change that alters it becomes visible.

A practical flow:

• Have the assistant draft tests for a function's obvious paths and edge cases.
• Run them. Some will fail because the assistant guessed at behavior. Those failures are useful: they show where the code surprises people.
• Adjust the expectations to match real output, commit, and only then start refactoring.

This converts the assistant's occasional wrong guess from a liability into a discovery tool.

Refactor in slices the assistant can hold

Large, sweeping rewrites are where AI tools do the most damage in legacy systems. The model loses track of implicit contracts, and you lose the ability to review the diff. Keep changes small enough that you can read every line:

• Extract one function, run the tests, commit.
• Rename for clarity, run the tests, commit.
• Replace one hand-rolled utility with a standard library call, run the tests, commit.

Ask the assistant to review each diff for behavior changes before you merge. A second pass by the same tool, framed as a review rather than a generation task, catches a surprising number of subtle regressions.

The takeaway

AI coding assistants are at their most valuable not when they write code for you, but when they help you understand code you would otherwise fear to touch. Map first, verify every explanation, lock behavior down with tests, and change things in slices small enough to review. The tool reads fast; your job is to make sure what it reads is what actually ships.