AI Agents Write More Code. Review Decides What Ships.

This was the week the numbers caught up with the hype. GitHub reported that more than 40% of pull requests now start with an AI agent's first draft. A Harvard study of hundreds of software companies found that agents sharply increase code output—yet finished software barely moves. And Atlassian's latest developer survey found most engineers feel no less friction than before AI.

The founder takeaway: your AI coding budget is not the constraint anymore. Your review capacity is. If you do not redesign how code gets reviewed, tested, and approved, agents will simply fill a queue faster.

<>What changed this month

Three data sets landed within weeks of each other, and they point in the same direction.

• Agents are now the default first draft. GitHub's Octoverse 2026 report says agent-started pull requests rose from 17% in March to more than 40% in September—about 110 million in September alone. Merged pull requests more than tripled to 1.3 billion for the year.
• More code did not mean more software. In Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard researchers Fiona Chen and James Stratton analyzed engineering activity across more than 650 firms. Their conclusion is blunt: adoption "substantially increases code output but has much smaller effects on final software output," and "code review becomes the bottleneck."
• Developers feel it. Atlassian's State of Developer Experience Report 2026 found 87% of developers say AI helps them ship faster, but only 28% feel noticeably less friction—and 49% spend four or more hours a week reviewing AI output and correcting prompts.

At GitHub Universe, GitHub also launched tooling that lets teams run multiple agents in parallel across repositories and return the results as pull requests (InfoWorld). That makes the review problem more urgent, not less. Ten parallel agents can produce ten pull requests that someone still has to understand.

<>Why the gains disappear in review

Writing code was never most of the job. The Harvard team's analysis, as summarized by Maven Enterprise, estimates engineers spend roughly 30–40% of their time writing code. The rest is planning, reviewing, testing, and deploying. Speed up one stage and the queue moves to the next one.

The August version of the paper, as reported by Yahoo Tech, found that after agent adoption:

• Lines of code rose about 30% and pull requests about 23%.
• Resolved issues and completed epics showed no statistically significant increase.
• Time from pull request submission to merge rose 49%, about 3.45 more days.
• The share of pull requests needing revisions nearly doubled, and comments per pull request rose 35%.

The October revision of the paper, built on a larger data set, keeps the same diagnosis: code waits longer to reach a reviewer, spends longer in active review, and receives more requested changes (Chen and Stratton). In plain terms, there is both more code to review and more work per review.

<>Why this hits startups harder

At a large company, a review backlog is an efficiency problem. At a startup, it is a runway problem.

Your review capacity is usually one or two senior engineers—often including a technical founder. Those are the same people responsible for architecture, hiring, customer escalations, and investor updates. When agents triple the number of pull requests, those people become the queue.

The Harvard data also found the share of workers doing code review rose 14% after agent adoption (Yahoo Tech). In a ten-person team, that is not a rounding error. It is your best engineer spending her week approving diffs instead of designing the next release.

There is a measurement trap, too. Atlassian found 60% of developers say AI usage is treated as a productivity signal, and 41% sometimes use AI more than necessary because they feel expected to (InfoQ). If your dashboard rewards activity, you will get more activity.

<>Five controls that turn agent output into shipped software

The answer is not to slow agents down. It is to design a review system that can absorb their output. Here is the operating model we use with clients.

<>1. Classify risk before anyone reviews

Not every change deserves the same scrutiny. Define three tiers and label each pull request before it enters the queue:

• Low risk: copy, styling, documentation, isolated tests, and dependency patches with passing checks. Eligible for a fast, lightweight review.
• Standard: feature work inside a well-tested module. One qualified reviewer.
• High risk: authentication, authorization, payments, personal data, infrastructure, migrations, and public APIs. Senior review, plus explicit sign-off on intent.

Encode the tiers with path-based ownership rules so the routing is automatic, not a judgment call at 6 p.m. on a Friday.

<>2. Limit the size of every change

Agent-started pull requests touch multiple files more often than human ones—87% versus 79%, according to GitHub. Large, sprawling diffs are where review time explodes.

Set a simple rule: one intent per pull request. Ask agents to split work into stacked pull requests, which more than 264,000 developers had used by September after a July preview launch (Octoverse 2026). If a reviewer cannot explain the change's purpose and risk in a single sitting, send it back.

<>3. Automate proof before a human looks

A human reviewer should never be the first line of defense against a failing test or an obvious vulnerability. Before review, require:

• Passing unit and integration tests, with new tests for new behavior.
• Type checks, linting, and dependency and secret scanning.
• A preview deployment or recorded run for user-facing changes.
• A short agent-written summary: what changed, why, what was not tested, and what the reviewer should look at first.

AI review tools belong here as filters. The Harvard study found the review bottleneck persisted even as most firms adopted AI code review (Maven Enterprise). Use them to catch mechanical issues, not to replace judgment.

<>4. Focus senior judgment where it matters

Atlassian found 75% of developers now carry more responsibility for validating the quality and safety of AI-generated output (Atlassian). That responsibility should be concentrated, not spread thin.

Your most experienced engineers should spend review time on questions automation cannot answer: Does this solve the right problem? Does it respect our authorization model? Will this data model hold up in a year? Everything else should arrive pre-verified.

This is also where specs pay off. When an agent works from a clear statement of intent and acceptance criteria, the reviewer checks the result against the spec instead of reverse-engineering what the agent was trying to do. We covered that workflow in Code Isn't Your Bottleneck Anymore. Your Process Is.

<>5. Measure flow, not activity

Drop lines of code, commit counts, and AI usage from your leadership dashboard. Track these instead:

• Time to first review: how long a pull request waits before a human touches it.
• Time to merge: the end-to-end review cycle.
• Change failure rate: how often a merged change causes an incident or rollback.
• Outcomes shipped: customer-facing issues resolved and features released per week.

If code volume is rising and these numbers are flat or worse, you have a review bottleneck—regardless of how productive the team feels.

<>A two-week plan for founders

You do not need a reorganization to start. In the next two weeks:

1. Day 1–2: Pull your last 30 days of pull request data. Measure time to first review and time to merge.
2. Day 3–5: Write your three risk tiers and map them to code ownership rules.
3. Week 2: Add a pull request template that requires an agent summary, test evidence, and risk tier. Set a size limit.
4. End of week 2: Compare the metrics. Decide where to add review capacity—automation, a senior hire, or an embedded partner—based on where the queue actually is.

<>Frequently asked questions

<>Do AI coding agents make startups ship more software?

Not automatically. Large-scale research found agents substantially increase code output but have much smaller effects on finished software, because review becomes the bottleneck. Teams ship more when they redesign review to absorb the extra volume.

<>Can AI code review tools fix the review bottleneck?

They help with mechanical checks, but they do not replace human judgment on intent, security, data, and architecture. Use them to filter and prepare changes so senior engineers spend limited time on decisions that carry real risk.

<>What should founders measure instead of lines of code?

Time to first review, time to merge, change failure rate, and customer-facing outcomes shipped per week. Lines of code and AI usage are activity metrics that can rise while delivery stays flat.

<>How small should an agent-generated pull request be?

Small enough that one reviewer can understand its intent and risk in a single sitting. Use one intent per pull request and split related work into stacked pull requests.

<>Where SAMO fits

At SAMO Technologies, we help founders build engineering systems where AI agents increase what ships, not just what gets written. That means risk-tiered review, automated verification, clear specs, and senior engineers who can absorb review load without stalling your roadmap.

If your pull request queue is growing faster than your release notes, bring us your last month of delivery data. Talk with SAMO Technologies about where your bottleneck really is and the fastest way to clear it.