If Review Is The Bottleneck, Maybe The Bottle's Too Full

GitHub says it saw more than 1.2 billion commits in a single week this October. That is over 400% more than the same week last year, and more than all of 2025. The post, published after GitHub Universe, asks the obvious follow-up: do you feel 400% more productive?

The answer, for most teams, is no. GitHub points to Faros AI's Acceleration Whiplash report (March 2026, telemetry from 22,000 developers). Median time in review rose 441% as teams moved to heavy AI use, and 31% more PRs merged with no review at all. Nobody chose to stop reviewing. The volume just outran the reviewers.

Atlassian's State of Developer Experience 2026 report shows the same gap from the developer's side. 87% of developers say AI helps them ship faster, but 65% spend time correcting AI work that missed the original intent. Meanwhile 60% say AI use itself is treated as a productivity signal where they work.

GitHub's answer is to put agents on the surrounding work too, splitting changes into stacked PRs, running AI review first and having agents fix failing checks. That will help. But it is a vendor selling more agents as the fix for agents, and it says little about the human part, such as who owns a merge and how a reviewer learns why a change was made.

Here's my problem with that framing. Everyone, GitHub included, treats review as the bottleneck and asks how to widen it. I'm not sure review is the problem. I think we're trying to put too much in the bottle.

When code was expensive to write, cost did a lot of quiet filtering for us. Half-baked ideas died in planning because nobody wanted to spend a sprint on them. Agents removed that filter, and we haven't replaced it with anything. So we build what we can build, not what we should, and the review queue is where the bill shows up.

A 441% jump in review time might be telling us less about reviewers and more about what we ask agents to make. Before adding another AI reviewer, it's worth asking how many of those PRs needed to exist at all. Deciding what not to build is still a human job, and it may be the one that needs the most attention right now.

In The Loop

Agents triple commits, but releases barely move. Christian Bird's 21-minute talk at UC Irvine pulls together this year's research on why more code hasn't meant faster delivery. The core finding is from an NBER working paper by Demirer, Musolff and Yang on GitHub telemetry: autonomous agents raised commits by 240%, but projects by only 80% and releases by 30%. (An earlier version of the paper put these at 180%, 50% and 30%.) The authors read the drop at each stage as human bottlenecks. A companion benchmark from Bird's group found review agents did much worse on proprietary code than on open source, because they lacked project context. (Talk given 30 October, back this week on Hacker News.)

An attacking agent found what pen tests missed. Dosu's CEO Devin Stein published a post-mortem on 8 November. An attacker using the ARTEX framework found a years-old missing check on org invitations that several penetration tests had missed. The damage spread because CI runs on pull requests could reach production credentials. Dosu has cut CI off from those secrets, moved deployments to short-lived credentials and will run agent-based pen tests on a schedule. Check your own pipeline for the same path.

Two to four agents is the human limit. A post on mager.co looks at what parallel agents cost the person running them. The author reviews close to 1,000 pull requests a month and reckons they read three to four times more than before. Their rule is two to four active sessions, counted as active until the output is reviewed, with one coordinating thread per project and agents asked for short replies that say what changed, what needs a decision and where the evidence is. It's one person's impression, not a study, but it's a good starting point for a team norm.

Agents took the tasks juniors learned from. This post on DEV argues AI isn't so much removing junior jobs as removing the small tickets, debugging and test writing that used to teach people the work. The risk it names is "mistaking a completed task for acquired competence". For teams, it suggests keeping bounded tickets, pairing, review rotations and production shadowing for new engineers. It also suggests measuring whether engineers can explain the systems they maintain, not how much AI they use.

Treat agent sessions as history, not scrollback. Atuin, the open source shell history tool, added Threads in version 18.24. It keeps an encrypted, searchable record of coding agent sessions, lets you resume one on another machine or fork it into a different agent, and runs an MCP server so agents can search past sessions. Capture is opt-in. Team sharing is still in development, and that's the part to watch, because a shared record of how a change was reasoned through is what reviewers keep asking for. (Launched 27 October, on the Hacker News front page this week.)

Write the first paragraph of every agent PR yourself. Most changes to Simon Willison's projects now arrive as pull requests opened by Claude Code or Codex. Their descriptions are accurate but long, so he writes a short opening paragraph on what the PR is for and whether it needs attention. The agent's full text goes inside a collapsed details and summary block, labelled with the model name. Reviewers see the human's intent first and can open the rest if they need it. First step: agree this as the convention for agent PRs in one repo for a fortnight, then ask your reviewers whether it helped.

Something To Try

Ask your agent to write in Simplified Technical English. I built a skill for this. ste-it-skill makes an agent write in Simplified Technical English, a controlled form of English designed so every reader takes the same meaning. Its light level covers PR descriptions, commit messages and release notes, and its strict level is for text agents read, such as procedures and requirements. It leaves code, paths and identifiers alone and comes with a Python checker for the mechanical problems. It works in Claude Code and GitHub Copilot, and it's MIT licensed. Ask for STE in your next PR description and compare it with your last one.

Food For Thought

Pick one agent-built change your team merged last month. If it had been wrong, what check other than a person reading the diff would have caught it?