Using AI Coding Tools on an Undocumented Legacy Codebase

AI tooling shortens the reading phase of a takeover. It does not replace the reconnaissance, and it needs rules before it writes anything.

What it does well

• Summarizing unfamiliar code. A 900-line stored procedure or a code-behind file explained in a paragraph, with the tables it reads and writes.
• Tracing a call path. From a button click through the layers to the SQL that runs.
• Mapping a solution. Which projects reference which, where data access lives, where configuration is read.
• Drafting characterization tests. Tests that pin down what the code does today, so a later change can be checked against them.
• Translating older idioms. VB.NET, WebForms event handling, DataSets and inline SQL explained in current terms.
• Finding every usage of a column, a config key or an API before something changes.

Where it is confidently wrong

Anything outside the files it was given. It reads sp_UpdateUser and explains it accurately. It has no way to know that production calls sp_UpdateUser2, or that a trigger rewrites the row afterward. Scheduled tasks, database jobs and server configuration are outside its view unless you supply them.

Intent. It describes a nightly reprocessing job as redundant because the same records are processed during the day. The job exists because a partner sends corrected files late. The reason was never in the code.

Business rules. It can state that a discount applies when a field equals 3. What 3 means, and whether the rule is still correct, are questions for a person.

APIs that look right. It suggests a method that does not exist in the library version the project uses. The compiler catches this in code and nothing catches it in a written summary.

These errors read as fluently as the correct output, so every summary is a hypothesis until it is checked.

What it changes in the first two weeks

The reading goes faster: orientation in a large solution, first-draft documentation, a list of questions for the users. The verification takes the same time as before. Running the system, checking production configuration, reading the database and interviewing users still set the schedule. Expect the estimate to move on the reading and to stay put on the verification.

Rules before it writes code

1. Give it context first. Schema, configuration and the list of scheduled jobs, in addition to the code.
2. Verify summaries against the running system before acting on them.
3. Tests come first. Any change it writes is covered by a characterization test that passed against the old behavior.
4. Keep changes small enough to review line by line.
5. Leave alone anything that looks wrong until its history is understood.
6. Know your data rules. Confirm what the organization permits before production data or client code goes to a hosted model.

A good first exercise on your own codebase: have it explain the three largest stored procedures and list what each one reads and writes, then check one of them by hand. The gap between the two shows how much review its output needs.

Related: where to start with an inherited .NET codebase and how we build software with AI.