Most professional work is not greenfield. It is a codebase that already exists, often older than the people working on it, with conventions nobody wrote down and a schema nobody can change. This category is the model pointed at that codebase: summarising a change and flagging problems before a person reviews it, explaining a module, mapping how the parts connect, finding duplication and dead code, carrying out a refactor, upgrading a dependency, and writing the documentation that should have existed.
Some of that code was written by a model, and every other category in this section adds more. This is where all of their output ends up, for as long as anyone keeps it running.
What it is for
- A first pass on a pull request: a summary of what changed and the obvious problems flagged, so the person reviewing starts from intent rather than from line one.
- Finding your way around a codebase you inherited: where a behaviour lives, what calls what, why a strange piece of code might be there.
- Refactors that the type checker and the test suite can confirm.
- Dependency and framework upgrades, worked through one at a time.
- Documenting what exists, as a starting point that someone then corrects.
Who it suits
Engineers whose job is a codebase rather than a demo, which is most of them. Tech leads with a review queue growing faster than the team. Anyone handed a prototype from an AI app builder and asked to turn it into something a team can keep changing, which Taking over a generated prototype works through.
It suits people who already review well. The tool makes a good reviewer faster. It does not make anyone a reviewer.
How to tell this is your category
- The code exists before the request does.
- Your question is what this does, whether this change is safe, or how to change it without breaking anything, rather than what to build.
- If the question is whether the code works, and the answer you want is a test or a reproduction, that is AI testing and debugging. Review and testing lean on each other, and most real maintenance uses both.
What it costs you later
- A first pass that feels like a review. An automated review comments on everything with the same confidence, and ten remarks about naming can bury the one about authorisation. Its summary of a change is a claim about the change, not evidence of what it does. Tune it to flag less and matter more, and keep the call on design, security and whether the change belongs with a person. Code review is the new bottleneck is the longer argument.
- The same eyes twice. When the same kind of model writes a change and then reviews it, the review shares the assumptions that produced the change. A second opinion is worth most when it comes from somewhere the first one did not: a person, a test written from the requirements, a check that does not read the code at all.
- Refactors that change behaviour. A refactor promises the same behaviour in a better shape. Without tests that pin the current behaviour, quirks included, cleaner can quietly mean different. Characterise first, with tests that record what the code does today, then refactor in steps small enough that each one is checked.
- Ideal conventions over real ones. In an older codebase, an agent will tidy away the unusual pattern that exists on purpose, the module written differently for a reason nobody recorded. Write down the conventions the codebase actually follows, including the ones you would not choose today, and name what must not change: public interfaces, URLs, the schema, the merged migrations. Context engineering for AI coding agents covers where those notes should live.
- Upgrades from memory. A model knows a library as it was when the model was trained. It can write the old interface with confidence, or invent a migration step. Work from the library's own changelog and migration guide, upgrade one dependency at a time, and keep the suite green between each.
- Documentation that describes instead of explains. Generated documentation says what the code does, which the code already says. It rarely knows why, it can describe a bug as a feature, and it goes stale on the next change. Keep the documents that record decisions and reasons, and treat generated descriptions as a draft for someone who knows.
- Cleanup as churn. Pointing a tool at technical debt produces the largest diffs of all, touching many files with no visible change in behaviour. A cleanup nobody can review in one sitting gets approved on trust. Split it the way you would split a feature. Sizing tasks an AI coding agent can finish applies here unchanged.
Before an agent changes code you inherited
- Characterise it. Run it, map it, and find out what the tests cover and what they do not.
- Write down its real conventions and the things that cannot change, where the agent will read them.
- Pin the behaviour you are about to touch with tests, before touching it.
- Make one small change, and review it against what it was meant to do, not only against whether it reads well. Reviewing a change an agent made sets out the order of that review.
- Only then make the next one.
A codebase with no tests, undocumented conventions and a schema you cannot change is where an agent is most likely to do damage, and also where careful use of one helps most. The order above is what separates the two.