The AI Agent Bottleneck Nobody Talks About

New data circulating this week puts a number on something a lot of engineering leaders have been feeling for months: AI now authors just under half of all issues created in Linear, the project tracker used by thousands of software teams, and pull request volume across the industry has roughly tripled since agentic coding tools went mainstream. By the old math, that should mean software is shipping dramatically faster. It isn't. Development time, measured start to finish, is going up in a lot of these organizations, not down. Faros AI's telemetry across its customer base found AI usage correlates with 98% more pull requests, PRs that run 154% larger, and review times that stretch 91% longer than before. A CodeRabbit analysis of 470 open-source pull requests found roughly 1.7 times more issues in AI-co-authored code than in code written entirely by humans.

Put plainly: the machines got faster at producing work, and the humans responsible for checking that work didn't get faster at all. The bottleneck didn't disappear when AI agents showed up — it moved. It used to sit at "how fast can we write this," and now it sits at "how fast can we trust this," and almost nobody redesigned their process around that shift before turning the agents loose.

Why More Output Isn't the Metric That Matters

This same theme showed up from a different angle this week in how AI agent quality is starting to get judged: less on whether an agent's output sounds polished or plausible, and more on whether the task it was given actually got completed, end to end, without someone having to clean up after it. That's a meaningful shift, because "output volume" and "conversational polish" are exactly the metrics that make an AI agent rollout look successful in a demo and then quietly generate more work than it saves once it's running against real volume.

• An agent that writes 40 pull requests a week looks like 40 units of productivity — until each one needs a human reviewer to catch the 1.7x higher defect rate, and now your senior engineers spend their week reviewing instead of building.
• An agent that drafts issues, tickets, or documents faster than any human could isn't creating time savings if nobody downstream can process that volume any faster than before — it's creating a queue.
• "The agent finished the task" and "the agent produced something that looks like it finished the task" are different claims, and the gap between them is exactly where review time goes to die.
• GM's engineering org is the counter-example worth noting: they didn't just bolt AI agents onto their existing workflow — they redesigned the workflow around agents first, and tripled their merged pull requests as a result. Same underlying tools, opposite outcome, because the review and validation step was rebuilt to match the new input volume instead of left as-is.

What This Means If You're Deploying AI Agents, Not Just Buying One

This isn't only a software engineering problem. The same pattern shows up any time an AI agent is added to a workflow that has a human checkpoint downstream — customer support agents that draft replies someone still has to approve, document-processing agents that extract data someone still has to verify, sales agents that qualify leads someone still has to review before outreach. The volume goes up. The checkpoint doesn't get faster on its own. If nothing else changes, the checkpoint becomes the whole bottleneck, and the AI agent's speed gets erased by the queue behind it.

1. 1Before deploying an AI agent anywhere, identify the human checkpoint it feeds into and ask whether that checkpoint can actually absorb 2-3x its current volume — if the honest answer is no, the agent needs a redesigned handoff, not just a faster engine.
2. 2Track completion rate and time-to-resolution, not just output volume — an agent dashboard that only shows "tasks generated" or "replies drafted" is measuring the part of the process that was never the bottleneck.
3. 3Build validation into the agent's workflow, not after it — smaller, more frequent outputs that are easier to check beat large batches that overwhelm a reviewer, even if the large batch looks more impressive in a demo.
4. 4Treat AI agent output that skips review as a liability, not a win — the CodeRabbit data on defect rates in AI-co-authored work is a reason to keep the checkpoint, not a reason to remove it because the agent "seems reliable."
5. 5If an agent has been running for a while and nobody has measured whether things actually finish faster end-to-end, that's the audit worth doing before adding a second agent on top of the first one.

A Realistic Scenario

A Wizeb client running a mid-sized SaaS support desk deployed an AI agent to draft first-response replies to incoming tickets, expecting it to cut response time significantly. Ticket volume the agent touched went up fast — it drafted replies for nearly every incoming ticket within seconds. But average time-to-resolution barely moved, because every draft still routed through the same two senior support reps for approval, and now those two reps were reviewing three times as many drafts as they used to write themselves, many of which needed real edits. The fix wasn't a better agent — it was redesigning the checkpoint: routing high-confidence, low-risk replies (password resets, order status, FAQ-type questions) to auto-send with spot-check sampling, and reserving full human review only for tickets the agent flagged as ambiguous or high-stakes. Draft volume didn't change. Time-to-resolution dropped by more than half, because the review step finally matched the volume the agent was actually producing.

How Wizeb Approaches This

When we scope an AI agent implementation, the deliverable was never "an agent that produces output." It's a workflow where output and the capacity to check that output move together — which means the review, approval, or validation step gets redesigned as part of the same project, not left for the client to figure out after the agent is already generating more than anyone downstream can absorb. If you've deployed an AI agent and the output looks great but the thing it was supposed to speed up hasn't actually gotten faster, that's usually a scoping gap, not a model problem — and it's worth a conversation. Start at wizeb.com/services/ai-agents.

Three Questions Before Your Next AI Agent Deployment

1. 1What's the human checkpoint downstream of this agent, and can it actually handle 2-3x the volume the agent is about to send it?
2. 2Are you measuring how much the agent produces, or how much actually gets finished because of it — and do you know the difference in your own dashboards?
3. 3If this agent's output volume tripled overnight, would that be a win, or would it just move your bottleneck somewhere you're not watching yet?