An agent changed nine files unattended and no author can explain them — how does that change your review?

## Review normally runs on an assumption about the author When a colleague hands you a change, the review leans on something nobody says out loud: **behind every line there is a person who had a reason.** That assumption does real work: it lets you skim what looks ordinary, it turns an odd line into a question rather than a defect, and it gives you somewhere to send the question. An unattended agent run removes the assumption and leaves the code behind. Nine files of a warehouse stock-count feature were touched while you were elsewhere; the change builds, it reads fluently, and nobody can tell you why the third file needed a new branch. What replaces it is weaker than people expect. An unexplained line may encode a real constraint the run found in the codebase. It may equally be residue from an approach that was started and half-abandoned, a shape that fits code the run had seen far more of than yours, or the silent resolution of an ambiguity in your request that you never heard about. **The line itself does not tell you which**, and nothing recorded the difference. | | a colleague's change | an unattended run's change | |---|---|---| | an odd line implies | they know something you do not | nothing in particular | | resolving the question | ask them | reconstruct it, or take the line out | | the narrative | their account of the intent | the request you gave, and nothing else | | an explanation offered later | recall of a decision | text produced from the code as it stands | | who answers for it | author and reviewer | whoever ran it and whoever approves it | ## The burden of justification flips With a person, an unexplained line is presumed innocent until you ask. Here the presumption has nothing to rest on, so invert it: **every behaviour in the change is accounted for by the request or by the code around it, and whatever is left over is an open item.** Open does not mean wrong — a leftover is not automatically a defect — it means you close it before approving, by reading the thing it touches, by taking it out to see what depends on it, or by asking whoever ran the session what they had asked for — which bounds the question even if it cannot answer it. That inversion is most of the discipline, and it is cheap. It costs a comment per leftover on an ordinary change. It gets expensive only when the change is large — the situation that produces this question in the first place. ## An explanation given afterwards is not a record The obvious move is to ask the agent why. It will answer fluently, and the answer is worth something: it tells you what the code appears to intend, which is a reasonable place to start checking. **It is not a record of the decision.** It is produced after the fact, from the same code and the same assumptions, so it tends to agree with the change whether or not the change is right. Treat it as a hypothesis you then verify against the request or against the thing the line touches — never as the evidence that closes the item. ## An order of reading that works without a narrative A colleague's change usually arrives with a story: here is the problem, here is the approach, here is the boring part. Without one, build it yourself before reading line by line. 1. **Read the request first.** You need to know what you are grading against before the change tells you what to expect; open the diff first and it supplies the very expectations you were supposed to bring. 2. **Map the change.** For each file, decide whether it alters behaviour or merely follows on from a file that does — a signature update, new wiring, moved lines. 3. **Read the behaviour-changing files closely**, especially where they touch stored data or cross a boundary you do not own. 4. **Read the follow-on files for consistency** rather than for correctness: does each one match the change that forced it? 5. **Collect the leftovers** — behaviour you cannot trace to the request — and close each one deliberately. If you cannot tell which group a file belongs to, that is the file to read first: it means you do not yet understand what the change does. ## Where accountability sits The register that matters in an interview is plain: **you answer for what you approve.** "The agent wrote it" describes the keyboard, not the responsibility, and it will not be an acceptable answer when the stock counts stop reconciling next quarter. It is also why "too big to review, approve it and fix forward" is the wrong instinct — fixing forward is a plan for the defects you can already see. ## What this does not mean - It does not mean generated changes are wrong more often than handwritten ones; a reviewer cannot tell that from a diff, and it is not the point. - It does not mean every unexplained line is a defect — only that it is checked rather than assumed to be deliberate. - It does not mean watching the session replaces reading the result: watching follows a narrative, review checks an artefact, and the two catch different things.