You made coding faster. Guess where the bottleneck went next.

Somewhere in the last year, your team's code output went up. Pull requests are opened faster. The backlog of small fixes and routine changes started clearing quicker than it used to.

If delivery still feels roughly as slow as it did before, that's what happens when you speed up one part of a process without touching anything downstream of it.

Where the bottleneck actually goes

Key takeaway: Coding got faster. Review, approval, and spec quality didn't. The constraint didn't disappear; it just moved to whichever part of the process was never touched.

Writing code has always been the real constraint for a team shipping software at any scale, which is why so much time historically went into planning and specs before implementation started. AI removed that constraint. What it didn't touch was the surrounding work: making sure the change was reviewed properly, making sure the right person signed off, making sure the thing being built was specified clearly enough that building it was actually the correct next step

That shows up in three places, usually in this order.

1. The review queue. More code moving through means more pull requests landing on the same reviewers who were already at capacity. A senior engineer's review load can easily double or triple, much of it written by a model rather than a colleague they can walk over and ask a question.
2. Approvals. Once the queue backs up, teams start looking for ways to move things through faster. Some of that pressure is healthy, streamlining a genuinely slow process. Some of it quietly erodes the approval itself, a rubber stamp on something nobody actually read closely.
3. Specifications. An agent can only work from what it's given. A vague ticket that a human engineer would have clarified through a hallway conversation tends to get built literally, ambiguity and all. Product and engineering discover they're now relying on spec quality in a way they never had to before, because there's no longer a person quietly filling the gaps.

What to put in place before it gets worse

Key takeaway: The fix isn't more process everywhere. It's defining where a human decision is actually required and making sure engineering isn't the only function with a seat at the table.  

None of this is inevitable. It's a sign that a few specific pieces of structure are missing, and they're worth putting in place deliberately rather than waiting for the backlog to force the issue.

• Define where a human decision is actually required. Not every change needs the same level of scrutiny. A workflow that routes low-risk changes through lighter review and reserves close attention for anything touching production, data, or customer-facing behavior gets the backlog moving without lowering the bar where it matters.
• Make approval mean something specific. An approval that isn't tied to a defined check, does this match the spec, does this pass the tests that matter, is a name on a record, not a decision. Worth being explicit about what a reviewer is actually confirming when they approve something.
• Bring spec quality into the same conversation as code quality. If an agent is going to build directly from a ticket, the ticket needs the clarity a human developer used to supply informally. It replaces a conversation that used to happen invisibly with one that now has to happen on paper.
• Involve the people who aren't writing the code. This is where most teams stop short. The review and approval structure above tends to get built for engineers, by engineers, and product, design, and security end up bolted on afterward, if at all. A workflow that only routes decisions to engineering misses exactly the gates that would have caught a spec that never should have shipped, or a change that needed a security sign-off it never got.

The part that's easy to miss

Key takeaway: Adding more reviews makes the backlog worse, not better. The teams handling this well are routing decisions to the right person, not reviewing more.

The instinct, once a team notices this, is to add more review. More reviewers, more required approvals, more process. That usually makes the backlog worse because it adds friction everywhere instead of routing decisions to the people who should actually be making them.

The teams handling this well aren't reviewing more. They're routing better: engineering handles engineering decisions, product handles product decisions, security handles security decisions, and none of them are waiting in the same queue behind the others. That only works if the workflow itself understands the difference, rather than treating every change as an engineering approval by default.

Watch the Dispatch demo to see how the platform actually works, from an incoming issue through to a shipped change, with the decision points along the way.

Frequently asked questions (FAQ)

Why did AI coding tools make reviews slower instead of faster?   
They didn't make the review slower. They increased the volume of code reaching review without increasing the team's capacity to review it, which has the same practical effect.

Is more code review the right fix for this bottleneck?   
Not on its own. Adding review capacity without changing how decisions get routed usually just moves the backlog rather than clearing it. The more durable fix is routing each kind of decision to the person who should actually be making it.

Why do specs matter more now than they used to?   
Because a human developer working from an unclear ticket fills the gaps through judgment and conversation. An agent working from the same ticket builds close to exactly what's written, ambiguity included. Spec quality that used to be informally corrected now has to be explicit.

Who besides engineers should be involved in reviewing AI-generated changes?   
Whoever owns the decision, the change actually touches. Product for user-facing behavior, security for anything touching access or data, design for anything user-facing. Routing every decision through engineering by default misses the gates that matter most for each of those.