A tired curly-haired engineer reaches for a big green approve button while a small navy robot stacks a toppling tower of pull request cards beside the desk.

Daily Digest

The Approve Button Still Has a Human Name on It

Agents made pull requests cheap. Reading them still costs the same.

By Osbel Morell

Osbel Morell is a software engineering leader who builds small tools at Alignata.

Essay · Oct 17 · 6 min read

An agent can open a pull request in the time it takes me to refill my coffee. It writes a tidy description, adds tests, and fixes the lint errors before anyone asks. Then the PR sits in a queue and waits for a person, because somebody still has to read it, figure out what it was trying to do, decide whether it did that, and click the green button with their own name attached.

That last step is where code review is starting to crack. Generating code got cheap. Verifying it didn't.

The cost moved downstream

For most of my career, writing the code was the slow part. Review was a check at the end, and it mostly worked because the author and the reviewer had spent the same week in the same codebase. You could ask "why did you do it this way?" and get an answer that came from someone who'd thought about it.

With agent-written code, the reviewer often gets a finished diff with none of that history. There's no hallway conversation behind it and no half-remembered tradeoff. The reviewer has to rebuild the intent from the ticket, the description, and the code itself, and only then start looking for the bug that's hiding in line 214. That work doesn't get faster because the code arrived faster. If anything it gets slower, since the diff is often larger and the "why" is thinner.

The numbers are starting to show it. In a September 8 deep dive, Gergely Orosz of The Pragmatic Engineer shared GitHub data on pull requests, commits, and new repos over three years and wrote that "the number of PRs opened has increased fivefold," with growth speeding up from the end of 2025, "when PRs and commits nearly doubled just in that period alone." GitHub's figure counts every PR, not just agent-written ones, so I wouldn't claim agents wrote most of that fivefold jump. But in a talk posted October 6, Orosz said GitHub's data also shows agent-only pull requests rising nearly 10x between January and August. The direction is hard to miss.

A Harvard study reported this week points the same way from a different angle. Looking at Jellyfish data from 718 software firms, the researchers found that adopting agentic tools lifted pull requests by 23 percent while average time to review a PR rose 49 percent, and resolved Jira issues didn't measurably change. More code went in. It didn't come out the other side as more shipped work.

Zombie reviews

When the queue outgrows the people, reviewers do the reasonable human thing. They find the path of least resistance.

Orosz has a name for what that looks like. In the same talk he described engineers "playing the theater of doing reviews" and said, "I just call these zombie code reviews." The approval still happens. The process still looks healthy on a dashboard. Nobody really read the change.

I don't think this is laziness. If you get forty PRs a day and each one deserves twenty minutes, the arithmetic simply doesn't close. An enterprise study posted to arXiv in July makes this concrete. At one company with a mandate to double merged PRs per engineer, overall PR volume grew 3.1 times while the pool of reviewers grew 1.5 times. The share of PRs with any human review fell from 89 percent to 68 percent, and reviews with an actual human comment fell from about 39 percent to about 21 percent. Silent approvals per reviewer roughly doubled. That's what a zombie review looks like in a spreadsheet.

Some teams have stopped pretending. Duckbill Group, a small startup whose CEO Mike Julian wrote "We ditched code review at Duckbill Group (mostly)," faced 60 open PRs for a team of five. They switched to a risk-based system: changes touching the public API or MCP, auth, the design system, non-additive schema changes, or agent skills still need a human, and a shell script adds a GitHub label to enforce that. Everything else ships on automated checks. They also tightened linting, raised unit test coverage to a floor of 85 percent, and added post-deploy observability. Merged PRs went from 353 to 684, and PRs without human review merged in a median of one hour, versus 26 hours for human-reviewed ones. Orosz also said in his talk that Ramp has started trusting engineers to skip review on certain non-critical code.

The word "mostly" in Julian's line is doing honest work. Orosz himself notes there's "more talk about dropping human code reviews than there is evidence of this actually happening, so far." What's spreading looks more like triage than abolition.

The review bots aren't the fix yet

The obvious answer is to have AI review the AI. Plenty of teams do, and there are dozens of vendors. The trouble is that a reviewer you can't trust adds work. Every comment has to be read and judged, and a bot that leaves twelve comments where one matters trains people to skim the bot too.

An April arXiv study of code review agents on agent-authored PRs found that PRs reviewed only by these agents merged 45.2 percent of the time, against 68.4 percent for human-only review, and were abandoned more often. Among closed bot-only PRs, 60.2 percent had review feedback with 30 percent or less actionable signal, and 12 of the 13 review agents studied averaged below 60 percent signal. Orosz reports that WeTravel, a Series C travel company, decided against AI code review because of the noise, and that a June re-evaluation showed improvement but still not enough. Uber's answer was to build uReview, a pipeline that grades bot comments and throws out the low-confidence and unimportant ones before a developer sees them.

That's the tell. The useful part of an AI reviewer is the filtering, and most teams don't have Uber's budget to build it.

What should a review be when the author isn't a person?

This is the question I keep coming back to as someone who has to sign off on what my team ships. Classic review did a few jobs at once. It caught bugs, but it also spread knowledge, kept the codebase coherent, and taught people. When the author is an agent, some of those jobs disappear. You can't mentor a model through a PR comment. Others get more important, because the agent has no memory of the system and no stake in it.

My working answer is that the review should move to the places where a human's judgment can't be swapped out. Those places are the intent and the blast radius. Before the code exists, someone should agree on what the change is for, what it must not touch, and how we'll know it worked. Orosz describes teams that review the plan, the tests, and the schema instead of every line of implementation, and that matches my instinct. A test suite you trust is a review that runs every time. A plan you agreed on gives the reviewer something to check the diff against besides vibes.

After the code exists, the human's job is narrower and sharper. Does this change do what we agreed? Does it reach anywhere it shouldn't? Is it small enough that I can actually hold it in my head? If the answer to the last one is no, the right review comment is "split this," and an agent can do that cheaply.

The part I won't give up is ownership. Whoever clicks approve is saying they understand the change well enough to be paged for it at 3 a.m. If nobody on the team can honestly say that, the change isn't reviewed, no matter how many checkmarks it has.

Where this goes

I don't expect review to vanish, and I don't expect it to survive in its old form either. The teams I'd bet on are doing the unglamorous version: sorting changes by risk, writing that sorting down in a script instead of a wiki page, spending real money on tests and observability, and keeping human attention for the changes that can actually hurt someone. Duckbill's results suggest that can work for a small team with good guardrails. It's too early to say how it holds up at scale, or what happens the first time a "low-risk" change turns out not to be.

The honest goal for the next year is modest. Make the approve button mean something again, even if fewer changes need one.