If you’re running a team where the engineers use coding agents, you’ve probably noticed that code review is now the thing everything queues behind. The code turns up faster than it ever did and the review step is still paced by humans, who haven’t got any faster. My position is that AI didn’t do anything dramatic here like break code review, so much as make it the bottleneck, and you don’t fix that by reviewing quicker or by telling the team to trust the model. You fix it by changing what a review is for: get the change proven inside the PR, using the sort of rigour that high-cadence delivery always needed and most of us never paid for, and then point the humans at the part of the change that warrants their attention rather than every line of it.
“Hands off the wheel” doesn’t land
I had a go at this with a team I ran, with a fair bit of trial and error, so what follows is what I’d do if I was standing in front of it again today. The one caveat I’ll make up front is that this is one team, one codebase and one stretch of time, and a sample size of me isn’t a law of nature.
The tempting move, especially if you’ve got the title to make it, is to rock up and tell the team to stop reviewing every line and trust the agent. I’d tell you not to, because I’ve seen how it lands: what the team hears is “stop looking at the thing that’s been catching real problems”, and they’re right to hear it that way because it has, so you get instant distrust and the queue’s still there. The team does need to rethink what a review is for, but the process has to earn that rather than have it decreed, and the honest version of the ask is “what would the agent have to show you, inside the PR, before you’d take one hand off the wheel?”
So there are two moves, and they go in order. The first is trust, which means the work gets proven rather than trusted. The second is attention, which is about where the humans look once they’re not looking at everything, and it only works as an ask rather than an order because the first one’s been done.
Prove the change in the PR
We’ve been here before. When “release to prod a dozen times a day” came along, what stopped most orgs getting there was exactly this: you need test automation deep enough and evidence of correctness reliable enough that nobody has to hand-check a release, and that shit was expensive to build, so most of us didn’t. Nobody noticed the gap because human review had enough slack to cover for the evidence we never built, and you had the luxury of putting that cadence in the “one day” column anyway. AI isn’t giving you that choice, because the agents took the slack away and landed on the same gap.
The lightweight step towards it, and this is a habit from well before coding agents, is that if a PR is asking to be trusted as proof that a change works, then the proof goes in the PR. That might be a screenshot, or a link to the log group where the thing ran, or the command you used and what it gave you back, and I mean the stuff CI can’t check or isn’t set up to check yet, not the tests it runs anyway. The shape I’d use is a PR template where every acceptance criterion lands in one of three buckets: verified, with the evidence; unverified, with why; or requires a human, for anything that needs a browser, a live domain, an MFA prompt or a deliberately broken deploy. Putting something in that third bucket is a perfectly good answer, and inventing evidence to avoid it is the kind of anti-pattern that defeats the purpose of the whole thing. I’ve been putting screenshots and logs into PRs like this for years, more out of habit than any real process, and it’s always paid for itself in trust. It’s the three-bucket breakdown itself that’s newer — I’ve pitched the shape to a team, but I haven’t run it with one yet.
The reason it works isn’t really the reviewer, it’s the author. To put a screenshot of the working feature in the PR you have to have made the feature work and looked at it, and to paste in the logs you have to have run the thing and read them, so it forces the author to check their own work in a way that “tests pass” never did, and the reviewer trusting it more is the upside on top. That holds whether the author is a person or an agent. You already use the agent to write the code, so why not use the agent to go and get the evidence too? An agent-written PR doesn’t turn up with screenshots on it, and my read is that’s on us, because we told it to pass the linter and get the unit tests green, those being the standards we’d bothered to write down, and we never said “and show me it works”. I realise that depending on what you’re building, that sort of line borders on being flippant in terms of its simplicity, but there are a lot of places you can go in terms of automated validation AI can drive. Give it browser automation and it’ll screenshot the result, tell it in the repo’s operating instructions that the change isn’t done until it’s captured the logs showing the event went where it was meant to, and the three buckets become something the agent fills in rather than something a human back-fills. And because it has to run the feature to get the screenshot, that’s where it finds the thing it broke, the same as a person would.
The hard part in the teams I’ve worked with recently wasn’t producing evidence, it was agreeing how much, and the engineers who wanted the most proof on backend changes were the front-end ones — when shit rolls downhill they’re the ones watching it break in front of a user, while a misbehaving backend service can do so silently. It looked like a disagreement about rigour and it wasn’t; it was an asymmetry in who pays when it’s wrong, and I’d be surprised if some version of that didn’t turn up on your team too. Start from your existing definition of done — usually some version of “appropriate unit tests added and passing” — and raise the bar first wherever that asymmetry is worst, rather than trying to fix it everywhere at once.
Once the proof has been in the PR and been right enough times in a row, asking people to ease up on the line-by-line stops being a decree and becomes a reasonable ask, and that’s the door the next bit walks through.
Point the eyes at the part that matters
Line-by-line review scales with how much time the reviewer has, and the rate the code comes in at stopped caring about that. The obvious fix is to have the AI review first, and I’d do that, but on its own it doesn’t help, because the review agent produces a wall of suggestions and nitpicks at the same rate the coding agent produces code, so the reviewer’s problem has moved from “read every line” to “read every comment”.
What I want is for the human’s time to land on the twenty per cent of a change that carries most of the risk, and the twenty is a finger in the air, the standard 80/20 thinking as a guiding principle rather than a metric. Two things got me most of the way there when I was reviewing agent output on that team, and I did them separately.
The first was making the AI review triageable. I gave the review agent a skill that constrained every finding to two lines of explanation and a small sample of the code, which is enough to decide whether a thing is worth keeping or binning without opening the diff. It’s not bulletproof, and it was helpful enough, which is a pretty good return on a short instruction file.
The second was writing down the soft spots and overlaying the findings against them, and the soft spots came from lived knowledge of the repo rather than anything the tooling could tell me. There are two kinds of signal worth writing down. One is around the behaviour of the team and what they complain about — what are the things that keep coming up in retros as things to change or stop? One example from a team I was running had us constantly seeing issues with the end to end test script not being updated consistently in line with the work being done in PRs — the test suite wasn’t run in CI at that point, so because it didn’t break the pipeline it wasn’t always front of mind for people. This became something that was easy to fix in terms of “put it in the CI path” but also agreeing on the behavioural standard was able to be codified in instructions in the repo too. The second is around specific parts of your repo that are known to be higher risk, or have a higher blast radius for things going wrong. For that same team changes to the storage layer were a good example, because it was an auditable source of truth and if things went south there, the implications around it were problematic in a lot of ways. You could pick a few other candidate areas easily enough too, but the reality is your team will know where the weaknesses in the app are, where the skeletons are and where they are sick of coming back to for “yet another bug ticket” — codify that knowledge too, and make it part of how you prioritise that triage in a PR review.
All this AI, and we still need the humans?
The whole of that last bit rests on someone actually knowing where the soft spots are, and that knowledge only exists because someone spent real time in the repo. That’s the same problem every team already had with a senior leaving and taking half of what everyone relied on with them, except now it’s worse, because more of the code gets written by something that was never in the room for any of the retros where you worked out where the bodies were buried.
I haven’t solved that on every team I’ve run, documentation problems continue to come up in different places and contexts. I’d bet some teams genuinely have figured this out — if yours has, none of this is for you. For the rest of us, the direction I’d be pointing at is putting that knowledge into markdown files that live alongside the code, written so a human and an agent can both read them and act on them the same way. I don’t know yet what level of detail actually changes what an agent does with a PR versus what just becomes more text nobody opens, and I’d expect that to keep shifting as both the models and the humans around them do. But it beats the alternative, which is leaving it in people’s heads and hoping nobody important quits this quarter.
That’s the bit that actually clears the queue this post opened with — not a faster review, but proof going in before the PR’s even opened and attention going where it’s earned once it is. What doesn’t go away is needing someone who still knows the repo well enough to say where those places are.
So yeah — we all still have documentation to write. Sorry not sorry.