Legacy code is code that works while nobody remembers why. An agent can help, as long as you do not open with edits.
Step 1. Reconnaissance without changes
Make the first session read-only. Change nothing and draw a map.
Ask questions instead of requesting a file-by-file summary:
- where the entry points are
- which part is business logic and which is plumbing
- what gets called most often
- which external dependencies exist and what happens if they go down
You can read the files yourself, so a summary adds nothing. The links between them are what you are missing.
Step 2. Find what you can break safely
Before you touch anything, decide how you will find out that you broke it.
No tests? Then your first change is not a refactor. It is a test around the code you are about to touch, even a rough one, even for a single scenario.
Agents write these tests well because the job is mechanical: pin down current behavior and improve nothing.
Step 3. Pin down what the code does, not what it should do
A common mistake on legacy is to write a test for the correct behavior right away. It fails on the first run, and you cannot tell whether you found a bug or misunderstood something.
Start with a test for what is there. It must pass against the untouched code. After that you can change things.
Step 4. Edit in small steps
Nobody can review a ten-file diff in an unfamiliar project. Five diffs of two files each are reviewable.
Watch the deleted lines in particular. When refactoring, an agent readily drops whatever looks redundant. In legacy code the thing that looks redundant is often the guard against a rare case, the very reason the file exists.
What to ask so it pays off
Bad: "refactor this file".
Good: "explain why this check is here and what breaks if I remove it".
The answer to the second question gives you understanding. The answer to the first gives you a diff you cannot verify.
About spend
Reconnaissance across a large repository means a large context, and context is billed at every step. So do the reconnaissance once and write the result to a file instead of re-asking in each new session.
After that, work with the files that matter, not the whole project. On the bill the difference usually reaches an order of magnitude.
In short
Map first, then a test that pins current behavior, then small edits. Ask about reasons and do not just order a refactor. Save what the reconnaissance found so you do not pay for it twice.