In partnership with
As AI adoption in software development goes up, something predictable happens: code stops being the main bottleneck. And with one bottleneck removed, more appear.
AI agents are drafting code faster and with higher accuracy than many of us expected even a year ago. As we continue our AI enablement push at Zapier, I'm watching my teams ship more code, faster. That's the good news. The less obvious news is what you start to notice once that constraint loosens. By removing one problem, more surface.
The numbers are striking. According to Pullflow's State of AI Code Review 2025 (which looked at over 40 million pull requests), about one in seven PRs now involves AI agents, up from roughly 1% in early 2024. That's a 14x increase in under two years. AI agents authored over 335,000 PRs in 2025 alone. So we're not just using AI to write code; we're producing more code, and more of it is flowing into review.
Review isn't scaling with it. Research on agent-authored PRs shows that a large majority face longer review times, sit unreviewed, or get rejected. Code generation has accelerated. The capacity to review, align, and decide hasn't kept pace. So you get this odd situation: the part we worried about for years, writing the code, is less of a constraint, and the parts we took for granted, review and decision-making, are suddenly where things pile up.
A thank you from this week’s sponsor:
Every headline satisfies an opinion. Except ours.
Remember when the news was about what happened, not how to feel about it? 1440's Daily Digest is bringing that back. Every morning, they sift through 100+ sources to deliver a concise, unbiased briefing — no pundits, no paywalls, no politics. Just the facts, all in five minutes. For free.
Two places keep coming up in how I'm seeing this play out.
PR reviews. When more code is written in less time, the queue of open PRs grows. There are already agents that can review MRs: CodeRabbit, Copilot, and others show up in that Pullflow data for a reason. But there's still a measure of distrust in allowing an AI-generated PR to be entirely reviewed by AI. It feels like one layer of automation too many; we want a human in the loop. So even when AI helps with first-pass review or comments, the final call and the back-and-forth still land on people. I don't think we're far from a future where that changes, where AI-written code reviewed by AI is normal and trusted, but we're not there yet.
In the meantime, review is still a human-heavy, context-heavy job. You need to understand intent, spot design issues, catch the "almost right but not quite" mistakes that AI is famously good at producing. You're also reviewing for the stuff nobody asked for: the unknown unknowns that slip in when the code came from an agent. Reviewing AI-generated code can ask for a different muscle than writing code yourself, which is part of why the bottleneck shows up there first.
And review is where we catch quality and maintainability. When AI writes the code, code ownership and "who actually understands this in production?" matter more, not less. If your team's review capacity was sized for a world where coding was the slow step, it's now undersized. The mismatch is between where we sped up and where we didn't.
David Poll has a piece that sharpens this: code review isn't mainly about catching bugs. It answers a different question: "Should this be part of my product?" Tests tell you whether the code does what the author intended. Observability tells you what the system is actually doing. Code review is where you decide whether the author's intent was the right thing to build. So the bottleneck isn't really "review" in the sense of gatekeeping correctness. It's judgment. And when AI generates code, the code often doesn't carry the same implicit context about why it exists, so the judgment layer gets harder, not easier. Worth reading if you're thinking about what review is actually for and what needs to evolve.
Decision-making. The other bottleneck is less visible but just as real. It's not quite "what should we build?" in the way you might expect. Rapid prototyping is so much easier now. It takes less time and costs less to spin up a prototype than it does to get in a room for 30 minutes and decide whether something is worth exploring. So the old gate (meet, decide, then build) often flips. You can build first and decide after.
The bottleneck is what happens once you have more options: deciding what to invest in, what to ship, what to kill, and who gets to make that call when the cost of generating options has dropped. It's also in making broader architectural decisions and getting input from various parts of the company when everyone is moving much faster. Pausing to understand context and make a decision is akin to context switching from meeting to code, and that switch gets more expensive when everyone is moving faster.
When you can build faster, the question of what to build and whether it fits customer needs gets louder. Product discovery and understanding what actually matters accelerate too, and the pressure to decide well increases. The skill set shifts. Less "execute the plan" and more "does this belong in our product, and who owns that call?" That's a mindset shift from task execution to strategic oversight, and not every team or company is set up for it yet.
Many companies aren't ready to empower engineers with the autonomy this pace asks for. Leadership doesn't always see engineers as strategic thinkers. Convincing people that your engineers aren't just coders anymore, that they're making calls about what to build and how it fits the system, is part of the work. The gap shows up fast when the bottleneck moves. Enabling faster, informed decisions without endless review cycles means clarifying who has authority, what needs alignment, and what can ship without a committee. That's governance and curation, and it's becoming a bigger part of the job.
I'm not pretending to have this figured out. We have folks at Zapier focused specifically on developer impact and productivity, and a lot of the real work is happening there. What I'm doing is paying attention to what loosening the code bottleneck reveals.
For PR reviews: I'm interested in how we size review capacity, who does it, and how we avoid making it the place where velocity dies. That might mean clearer ownership (who reviews what), smaller PRs, lighter-weight or even solely AI-powered review for low-risk changes, or better tooling so reviewers can move faster without sacrificing quality. I don't have a single playbook. I'm watching what works.
For decision-making: I'm paying more attention to how we decide what to do with the options we can now generate so easily (what to invest in, what to ship, what to kill) and who has authority to make those calls. The goal is to make sure we're not stuck when we have more possibilities than we know what to do with. I'm also paying attention to whether we're set up for it. A lot of companies aren't ready to empower engineers with the autonomy this pace asks for, and leadership doesn't always see engineers as strategic thinkers yet. That gap shows up fast when the bottleneck moves.
If you're in a team or org that's leaning into AI for development, you're probably feeling some version of this. The bottleneck shift is a useful lens. The feedback loop shortens with AI, and the focus shifts to higher-order problems: architecture, design, strategic decisions. Still very much a human-centric problem, just a different kind.
Slowing down AI adoption isn't the solution here. We should stop assuming that "faster code" automatically means "faster outcomes," and we start deliberately investing in the parts of the process that are now the constraint.
I'm treating this as a learning tool. When code stops being the bottleneck, you get a clearer picture of where your process was already fragile. The next step is to notice where things are piling up and start treating review and decision-making as the constraints they've become.