The bottleneck moved
For most of 2026, the bottleneck in software production has moved from coding to review. Opus 4.5 and GPT 5.4 are writing more code, at most companies, than their human counterparts. The constraint is no longer the typing. The constraint is the human looking at what the typing produced and deciding whether it's safe to ship.
The Pragmatic Engineer newsletter's pulse-check is consistent with what engineering leaders are saying off the record. Director-level folks are calling review the new bottleneck. The number of pull requests per developer has gone up. The mean size of a pull request has gone up. The cognitive load per review has gone up, not down, because the human has to reconstruct the intent the LLM never explicitly stated.
The vendor boom
A new category of tools has appeared to absorb the load. The Pragmatic Engineer list is long: Greptile, Sourcery, CodeRabbit, Graphite Reviewer (which also has a PR-agent), Coderabbit, and the built-in review features in Claude Code, Cursor, GitHub Copilot, and the new entrant from Cognition. Tools that previously didn't touch code review are adding it, including Linear, Sentry, and Atlassian's Compass, on the argument that they already have the context to do it well.
The interesting move is what the in-house teams are doing. Uber's Code Inbox is the case study. Code Inbox doesn't just route PRs; it tries to estimate the risk of a change and route the high-risk ones to humans who can actually catch the problems. Cloudflare built an in-house review flow. Faire built one. HubSpot built one. The common pattern: in-house, integrated with the existing monorepo tooling, tuned to the team's specific failure modes. Vendors are a starting point, but the teams shipping the most code seem to outgrow them.
The burnout problem nobody is solving
The harder problem is on the human side. Engineers are reporting two failure modes in parallel. First, devs who used to put real effort into review now rubber-stamp anything an AI reviewer has already approved, on the assumption that the AI caught the obvious bugs. Second, the engineers still putting in real effort are drowning, because the volume of PRs is up and the quality of incoming code is more variable than it used to be.
The net effect is the worst of both worlds: less actual review per PR, more total review burden per engineer, and a creeping sense that the code going into the codebase has not been looked at by a human who was trying to find problems. The teams that are handling this best are the ones that treat review as a system to design, with explicit roles for human and AI, rather than a free-for-all where everyone approves everything.
What to do about it
Three patterns from the Pragmatic Engineer survey that look durable. First, separate risk levels. High-risk changes get a human review by a senior engineer with context. Low-risk changes get an AI review plus a quick human sanity check. Second, make AI review opinions cheap to ignore. If the AI says "looks good," the human shouldn't have to argue with it. If the AI says "this might break X," the human should be able to accept or override in one click. Third, measure review health. If your median time-to-first-review is climbing, you have a load problem. If your change-failure rate is climbing, you have a quality problem. The two metrics are independent, and a healthy review process has to keep both in range.