The New Bottleneck in Software Development Is Reviewing AI-Generated Code

TED's engineering team ran into a problem that sounds like success until you look closer. AI tools made TED's developers dramatically more productive at writing code. That productivity created a new bottleneck: pull requests grew large enough that reviewers couldn't keep pace, according to TED CTO Andy Merryman. The team wasn't short on code. It was short on the human attention needed to check the code before it shipped.

GitHub's answer, released in public preview at the end of July, is a feature called stacked pull requests. Instead of one enormous pull request covering an entire feature, developers (or their AI agents) break the change into an ordered series of smaller pull requests, each reviewable on its own, that merge together in a single action once every layer passes review. Vercel's Next.js team and connectivity engineers at WHOOP have already adopted the workflow, reporting that it turns a change nobody wanted to review into a stack of pieces someone actually can.

That's one answer to the bottleneck: build better tools for reviewing more code, faster. There's a second, more provocative one circulating among developers.

The case for reviewing less code, not more of it faster

Salvatore Sanfilippo, the creator of Redis and widely known by his handle antirez, published an argument this summer that cuts against the instinct to review every line an AI agent produces. His point: once you're generating enough code that a human can't meaningfully audit all of it, the value of trying shrinks. What still matters, he argues, is controlling the ideas behind the software, the architecture, the design decisions, the intent, rather than treating line-by-line code review as the primary way a developer stays in control of their own project.

That's a harder pill for a lot of engineering cultures to swallow than a better review tool. It asks developers to trust design docs and architectural intent over reading every diff, which is a real departure from how software teams have operated for decades. It also draws real pushback. Developers responding to the piece pointed out that AI models often drift from a stated design over a long session, introducing exactly the kind of inconsistency that a design doc alone won't catch. The practical middle ground several engineers described: have the agent write the design doc first, agree on it before any code gets generated, and use AI models themselves as a first-pass reviewer, since they're cheap to run and available at any hour.

Two answers to the same problem

GitHub's stacked pull requests and antirez's argument for reviewing ideas instead of code are responses to the same root problem from different directions. One makes human review scale further by shrinking what each review has to cover. The other asks whether human review, at the line level, is still the right checkpoint at all once an agent can generate a feature's worth of code in the time it used to take a developer to plan one.

Most teams will land somewhere between the two, not fully committed to either. Smaller, stacked changes make review more tractable no matter how you think about the deeper question of what a human reviewer should actually be checking for.

What this means for teams adopting AI coding tools

The volume of code an AI agent can generate isn't the constraint anymore. Review capacity is. That changes what a software development workflow needs to prioritize: not faster code generation, but a review process, whether that's smaller pull requests, better design docs written before code exists, or some combination, that can actually keep up with what the agents produce.