A one-page checklist for any change an assistant or agent wrote, whether it is yours or a teammate's. Green tests are not enough on their own. If the code and its tests came from the same prompt, they agree with each other even where both are wrong.
Before you open the diff
- Write down what was asked. Paste the ticket or request at the top of your notes. You will hold the change against it sentence by sentence.
- Write two or three tests of your own from the request: the main case, one edge it mentions, and one piece of bad input. Run them on the unchanged code and watch them fail.
- Set the level of checking using the table at the bottom of this page.
Reading the change
- Map it before you read it. List every file it touches (
git diff --stat, plusgit statusfor new files, whichgit diffleaves out). Which files did you expect, and which are a surprise? - Does it do what was asked? Note anything missing, especially the part of the request that made it hard. Note anything extra.
- What did it touch that nobody asked for? A "tidy-up" of working code is a second change with no request and no test. Justify it or remove it.
- Read the removed lines first. New code is what you asked for. Removed code is what you did not ask to lose.
- Did it change an existing test? An edited or deleted assertion changes the specification. Find the decision that allows it, or reject the change.
Running it
- Run the whole suite, not only the new tests. The new tests were written to pass. The old ones tell you what broke.
- Run your own tests from step 2. They say whether it meets the request. Its tests only say what it thought the request was.
- Try the edges: empty, zero, one, the limits, bad input, and how the new code meets existing state such as caches, saved data and other settings.
- Name what would break it. Pick the input, sequence or neighbouring change that would make it fail, and try the cheapest one.
Where AI code goes wrong at work
- Packages and APIs. Check that every new dependency exists, is the package you think it is, and is maintained. Check every unfamiliar method against the documentation for the version you actually run. Assistants invent plausible names and reproduce outdated usage.
- Security. Look at input validation, access checks, queries built from strings, secrets in code or logs, and anything that turns off a safety check "to make it work".
- Data. Do migrations run forwards and backwards? Do they cope with existing rows? Is anything deleted or overwritten?
- Failure paths. Missing config, timeouts, empty responses, retries. Generated code usually covers only the path where everything works.
- Fit. Does it follow the codebase's own patterns for errors, logging and naming, or does it bring in a second way of doing the same thing?
Before you approve
- Can you explain every line? A line you cannot explain is a line you are trusting, not checking.
- Would you be on call for it? If not, ask for changes or ask someone else to read it.
- Record the verdict: accept, fix or reject, with the evidence: a command and its output, or a line and the requirement it contradicts.
How much checking does a change need?
Ask two questions. How bad is it if this is wrong (risk)? How much does it reach (blast radius)? A change's size tells you neither: three lines of input validation need more care than a hundred lines of new, isolated code.
| Level | Examples | Check |
|---|---|---|
| Low | Copy, a log message, styling, an isolated script | Steps 4, 7, 9 and one edge |
| Medium | A change to an existing feature people use | The whole list, with your own tests first |
| High | Writes or deletes data, checks input, controls access, handles money, or changes code many callers share | The whole list, then try the risky cases by hand against a running copy with realistic data, and get a second reviewer |
Adapted from chapter 11 of Debugging Is the Skill by Ghost in the Repo, ghostintherepo.com. Free to print and share in your team.