Review

A passing check only proves what it checked. When one agent writes the code and its tests, all of them can pass while the code does the wrong thing, because the tests came from the same misunderstanding.

Before agents, the person writing the tests had usually spent hours with the problem, so a green run carried that thinking with it. An agent produces code and tests in one breath, from one reading of your brief, in seconds. Green now tells you the two agree with each other.

Someone other than the author reads a change before it joins the main branch and decides whether it should. It is a judgement about the change, made by a person or an agent, on top of whatever the automatic checks said.

Review used to teach a second person the code as a side effect. With an agent as author, that side effect matters more: the author forgets everything when the session ends, so the reviewer may be the only one who ever understands the change.

A diff shows a change rather than a program: red lines went away, green lines arrived, and plain lines are context. You read it for what changed, and for what should have changed and did not.

Agents reformat, re-indent and move code as they go, and a whole-function re-indent can hide a removed check in plain sight. Learning a few ways to cut the noise pays for itself on the first agent-written pull request you read.

A review has an order: is this the right change, is it designed sensibly, does it work, is it tested, can it be read. Style comes last, because a linter should be handling it.

Agents rarely get syntax wrong. They solve the wrong problem, handle a case nobody asked about and miss the one you meant, add more than you asked for, and weaken a test to get to green. So those go first, and you stop as soon as an early one fails.

How far a change can reach: everything that imports it, calls it or relies on how it behaves, directly or through something else. A one-line change to shared code can have a bigger blast radius than a thousand new lines nobody uses yet.

An agent sees the file it is editing far better than the callers it hasn't opened, and a reviewer reading the diff sees only the lines that changed. Nobody in that exchange is looking at the code that will really break, unless someone goes and looks.

An agent marking its own work gives itself too high a mark. It checks what it meant to build rather than what it built, and from the inside those look the same.

"Are you sure?" is a weak question, because you are asking the same mind, with the same assumptions in front of it, to find what those assumptions hid. Separate the checker from the author and the check starts to mean something.

A new session with none of the conversation that produced the code, handed the diff and the spec and asked to judge it. It has no history to defend and no memory of why any of this seemed like a good idea.

This has no real equivalent before agents. You could never make a colleague forget a week of context on demand. Now a stranger who has read nothing is one command away and costs a few cents, so there is little excuse for letting an author mark its own work.

The words you give an AI reviewer. They set how hard it pushes, and they can move the verdict more than the code does. So the prompt is a setting with a cost on each side, and you choose it knowingly.

A sharper prompt catches a little more and blocks far more. Good code that gets blocked costs real time, and it teaches a team to ignore the reviewer. Missed bugs cost something too. Neither prompt is correct. The mistake is not knowing which trade you made.

A review finding has to come with what proves it: the line, the input, what happens and what should happen. A finding without that is an opinion, which is worth having, and which should not stop a merge.

A model writes a false finding in exactly the same confident voice as a true one. Asking for a failing input changes the job from persuading you to showing you. It also separates two questions that often get mixed up: is this true, and does it matter.

Reading code with nothing to check it against: no run, no stated intent, no question to answer. The reviewer fills the gap with what can be said about any code, which means small style points and warnings about things you may not need.

A reviewer needs a narrower job than "review this". Give it one behaviour to check and a way to check it, and the easy comments stop being the answer. Leave it open and you can spend your tokens, and your afternoon, on comments that were never going to change what the code does.

A product that reads your pull requests with a model and leaves comments on the lines it doubts. Most of them comment and leave the decision with a person.

They catch things no rule can express, and they cost tokens, take time, and give a different answer on a second run. Their vendors know this: the common default is that the bot's opinion is not an approval. Treat one as a very fast colleague who has never met your users.

Whoever merges a change answers for it, whoever or whatever typed it. That means being able to say what it does, what could go wrong, how you would notice, and how you would undo it.

An agent has nothing at stake. It won't be paged, can't be asked next month why it did this, and won't remember if you ask. This is what is left of the job when typing is cheap, and employers now say so in writing.

A file in the repo that maps paths to the people or teams responsible for them, so a pull request touching those paths automatically asks the right reviewer. On GitHub it can also be made a requirement for merging.

An agent is happy to edit anything it can reach, and it has no idea that the payments folder is sensitive at your company. A code owners rule turns that knowledge into something the machine enforces, whoever or whatever opened the pull request.

The gap between how much code exists and how much of it anyone understands. Like money borrowed, it costs nothing today, and you pay later, in the time it takes to work out the code before you can safely change it.

Agents remove the friction that used to build understanding as a side effect. The code can be clean, tested and passing and still be something nobody on the team could change safely. No tool in your pipeline measures this.

A close cousin of comprehension debt, and many writers use the two as one. Where a difference is drawn, this one is about people rather than code: a team gradually losing its shared picture of how the system works and why.

One person can understand their corner and the team can still have lost the whole. That explains a team that can't make simple changes without breaking things, even with tidy code. It also shows why one person reading more diffs doesn't fix it.

Before accepting code, say what it does in your own words, including what it does on awkward inputs, then check yourself by running it. If reality disagrees with you, you have just found what you did not understand.

Reading code gives a strong feeling of understanding that often isn't real, and an agent's tidy explanation makes that feeling stronger. Predicting and then running is a test the feeling can fail. It is also the skill an interviewer is checking when they switch the agent off.

The point where agent-written work piles up waiting for someone to read it. Writing code got cheaper and reading didn't, so the queue in front of reviewers is now what limits how fast a team ships.

Producing more pull requests stops helping once they wait longer, and the pressure to clear the queue is exactly what produces careless approvals. It is also why individual speed-ups can vanish at team level.

Keeping each pull request to one reviewable idea, often a few hundred lines at most. Long changes get split so that each piece makes sense and passes its checks by itself.

An agent can produce 2,000 lines as easily as 20, and it doesn't feel the difference. The reviewer does. Long diffs get skimmed, and a skimmed diff is a diff that wasn't reviewed. Size is the limit you have to set, since nothing about the agent will.

A long change split into a chain of pull requests, each built on the one before it, so each can be reviewed alone and you don't have to wait for the first to merge before writing the next.

An agent works faster than any reviewer, so it will always want to carry on before the last piece has been read. A stack lets it, while keeping each piece small. The cost is that a fix low down means updating everything above, and that is the kind of chore you can hand to an agent.

Doing the work so a reviewer can check it cheaply: one idea per pull request, a description saying what changed and why, and pasted evidence that it works, with the output of what you ran. You spend your time to save theirs.

When reading is the bottleneck, the most useful thing an author can do is make reading easier. An agent will happily write a description that claims everything worked. A description that pastes the output has to be true, or at least it can be checked.

A review comment marked as small and optional: a matter of polish that the author can take or leave. The label tells them not to hold the change up for it.

To a person, "nit:" means "no rush". An agent told to address the review comments may treat every one as an order, including the ones you meant as a passing thought, so say which are optional. And if the same nit keeps coming up, make it a lint rule and stop saying it.

A blocking comment must be dealt with before the change can merge. A non-blocking one is advice. Saying which one you mean is half of what makes a review useful.

An AI reviewer can produce a dozen comments in seconds, written in the same serious tone. If all of them block, the queue stops; if none do, the real one gets lost. A good rule for agents: only what can be demonstrated blocks, and the rest goes in the notes.

Short for "looks good to me": the usual way to approve a pull request. It is supposed to be a claim that you read it and would stand behind it.

It costs four letters and carries your name. When agents make the diffs long and frequent, it's very easy to type without the reading behind it. Interviewers now look for exactly this.

Approving without really reviewing, because the last fifty were fine and there are ten more waiting. The approval still gets recorded, so from outside it looks exactly like a review.

The better the agent gets, the more dangerous this is. If it is right nineteen times in twenty, you learn to stop looking, and the twentieth goes through with your name on it. Human review is not a reliable backstop just because it exists.