Code review has two jobs. Hand one to agents.

Coding agents gave the firms in a Harvard study 23% more pull requests on average, and the rate at which they closed issues and epics didn't change in any statistically significant way. Review time went up 49%. On October 19, the same problem became a question that hit 627 points on Hacker News: How to deal with shipping AI-written code you don't understand?

Here's our answer. Give the bug-hunting half of code review to checks that run without a person. Then spend your people on the other half, which no machine does for you: understanding the change. Review the decisions and the data flow before the diff exists, and prove you understand the change before it merges.

We build Definable with coding agents, and we merged more than 250 pull requests into our dev branch in October. All of that volume still needs someone to understand it.

Where the coding agent speedup went#

You can see the bottleneck in three data sets and one release. None of them is ours.

The first row is a Harvard study, as reported by Ars Technica: Jellyfish analytics from more than 700 firms, 2021 through March 2026. The 49% is the time from a pull request being submitted to being merged.

Beyond the 23% and the 49%, the share of pull requests with changes requested nearly doubled, and comments per pull request rose 35%. The authors say the gain was "absorbed by downstream constraints in the production process." Meanwhile 80% of those firms used some AI code review by March 2026, yet AI wrote only 23.3% of review comments.

The volume is real outside that study too. In Anthropic's monorepo (not the Claude Code repo), the Claude Code team's post says, changes landing per day went from about 2,500 in May to more than 30,000 in September. GitHub's Octoverse says more than 40% of pull requests there started with an agent's first draft by September 2026, up from 17% in March. Started with a draft, not written entirely by agents.

In Atlassian's survey, reported by LeadDev, 68% of developers said in 2025 that AI saved them 10 or more hours a week. Now 25% say so, and 65% regularly spend time reviewing, debugging and correcting AI-generated code. Will Larson measured his own company: Imprint's median review took about 33 minutes two years ago and takes about 77 now.

Postgres 19 isn't about agent-written code at all. The Register reports that it slipped to around November 19 after AI reviewers found more bugs than humans could fix, and most of those features were written before vibe coding was possible, says PostgreSQL committer Peter Eisentraut. It's the other side of the same problem. Machine review can find more than people can absorb. Eisentraut describes "staring at a list of forty defect reports", each with its own overhead even at three lines a fix, "and then you run out of time."

The bottleneck can move. From June to September, merged pull requests to Claude Code more than doubled while the share reverted fell by more than 40 percent. By the team's own report, they moved most of the reading to machines.

Jan van den Berg has a short update to Brooks's Law: adding agents to a project with unclear requirements "gets you the wrong answer faster."

Review was doing two jobs#

Review was never just a bug filter. The same Claude Code post says code review does two jobs: find and fix issues before they ship, and build shared context and understanding across the team. Larson lists four reasons for review, and knowledge sharing between author and reviewer is the first.

Read the Ask HN thread with that in mind. The title is about the second job: code you don't understand. But plenty of the answers are about the first. Commenter cadamsdotcom says that if the agent wrote the tests and watched them fail before starting the fix, "you have a lot of confidence." That's real, and it's mostly bug-finding. Commenter gavinray describes the other problem: "The further away I got from the implementation details, the fuzzier the semantics became."

Tests can't fix that. It's review's second job, and its output isn't a merged change. It's a person who can explain the system.

The Claude Code team asks a better question than "did a human read the code?" They call that an imprecise proxy for what could go wrong with this change, and which check is the right one to catch it. Most of those checks can be machines. "Does anyone on the team understand this change?" can't.

Hand the first job to machines#

Start with a number of ours. On October 24 we added a test that counts the functions in our backend modules taking more than three real parameters (self, the database session and route handlers don't count). It counted 151. By October 28 it counted 30, and a change that pushes it back up fails our test suite unless someone edits the number on purpose. Three of the habits below are ours; the other four come from teams that published their numbers.

1. Make the agent watch the test fail first (ours). The bug-fixing skill we use tells agents to turn the repro into a failing test and "Watch it fail." It's cadamsdotcom's point too.
2. Put AI review on every pull request (Claude Code team). When the Claude Code team launched its AI reviewer, the share of internal PRs getting substantive review comments went from 16% to 54%. Postgres shows how much LLM review can turn up.
3. Turn written rules into tests (ours). Most of our architecture tests read the source with Python's ast module "so a broken rule fails here rather than in review." The three-parameter rule from our design guide for coding agents is the counted test above: the number over the limit is written into the test, and a change that moves it fails until someone updates it.
4. Review standards and intent separately (ours). When we ask for a review, a review skill we adopted sends two sub-agents that never see each other's work. One asks whether the code follows our documented standards. The other asks whether it does what the issue asked. A change can pass one and fail the other, so we report them apart.
5. Cap the rounds (Claude Code team). One Claude Code CLI PR went through more than fifty rounds of review and fixes overnight. Their reviewer now asks the author to step back after three.
6. Tier review by risk (Claude Code team). In their table, low-risk changes need no person once automated checks are green, medium needs one, high needs two. "The change sets the tier, not the author." The lighter paths are only for authors on the repo's trusted list, and an agent's approval never counts as a person's.
7. Prove it, where failure is expensive (Anthropic). Anthropic says it took 20 person-years to formally verify the seL4 kernel, and that Claude, after patching the bugs it found, proved no crashes on any input up to 64 MB for 239 entry points across 123 OSS-Fuzz libraries, under assumptions the post spells out. The limit, in their words: a proof checker can't tell you whether your spec matches reality.

One warning from Larson. He calls it meat proxy review: a team has its local harness review pull requests, then uses harnesses to answer the harness-generated comments. It's a bottleneck that looks like a solution and makes things worse. Pasting your agent's comments into a PR isn't review. It's a relay.

Spend people on the second job#

Review decisions, not diffs. Commenter busch_j puts it best: review the decisions, not the code diffs. A decision reads like "deleting an account removes the row for good." It takes a minute to check and a diff takes an hour to hide in. For us that means plans before code. Our plans live in a tasks/ folder: 354 plans so far, and 302 of them sketch the change's data flow. One plan's goal reads:

Limits follow the person, not the interface; retries never charge twice; concurrent requests
cannot slip past a limit; owners set the limits; a policy change asks only for what is newly
missing.

You can disagree with that in a minute, before a single line exists.

Plans make a change of mind easy to check, too. This one called for a new agent_policies table with a revision counter. Neither got built. The plan's "As built" note, dated October 27, gives the reason in one line: "nothing would read a revision yet." You can weigh that in ten seconds. In a diff, the same decision is a table that isn't there. Only three of our plans carry an "As built" note so far. We'd like more.

Quiz yourself before it ships. A Show HN project called Sphinx is a Git hook that asks you a question about what your agent's code does. A reviewer that never saw your chat reads the diff and asks what happens when things go wrong. Its landing page carries a line, credited deadpan to Sun Tzu: "You can outsource your thinking, but not your understanding." You don't need the tool for the test, which a dev.to author states well: if you'd need to go back to the chat window to answer, you're not ready to answer.

Ask for an explainer of the slice you're about to change. Nobody on the Claude Code team keeps a complete mental model of it, they write, and they don't think anyone needs to. They ask Claude for an explainer of exactly that slice, which takes minutes and reflects the code as it is today.

Own what you prompted. Their rule: whoever prompted the change is on the hook for it. Alex Ewerlöf's version is blunter: you cannot be accountable for what you don't understand. He adds the line we'd put on the wall: "AI can explain it to you but it cannot understand it for you."

What we haven't solved#

Our pull request count measures activity, not understanding. A plan can be wrong, and our Spec reviewer checks the code against the issue or plan it's given, so a wrong plan can pass both reviewers. And our test still counts 30 functions in our backend modules over the three-parameter limit. It fails when that number grows; it doesn't fix the 30. Larson's own status is a fair summary of the field: we've absolutely not solved it.

There's a human cost too. Orestis Ioannou writes that the capacity to implement ideas has grown much faster than his capacity to think about them. In his words, "being able to do more keeps turning into doing more." A 99-point comment in an r/ExperiencedDevs thread on AI and engineering culture says AI amplifies whatever engineering culture is already there. We think that's right.

A checklist for this week#

1. Make the agent show a failing test before the fix.
2. Turn every written rule, and every review comment you've made twice, into a check.
3. Review standards and intent separately.
4. Cap review rounds at three.
5. Tier review by risk, not by author.
6. Read the plan and its data flow before the diff.
7. Before you merge, answer one question about what happens when it fails, without the chat window.
8. Watch reverts and incidents, not PR counts.

If you want a similar check for the agent's behavior itself, we wrote about grading the run, not just the answer.

Let the machines read the lines. Make sure a person can still explain the system.