When AI Makes Your Developers Too Fast for Your Own Process

A developer on my team finished a two-day story in three hours last month. Then sat idle for a day and a half, waiting for a product manager to clarify one sentence in the ticket.

The AI didn't fail. The pipeline around it did.

Something like this is happening on most AI-forward teams right now. They just haven't named it yet.

---

The bottleneck moved and nobody told the process

Sprint cadence, PRD quality, stakeholder availability, backlog grooming, QA. All of it was sized against human coding speed. Coding was the slow, expensive step. Everything upstream and downstream quietly expanded to fill that time.

Now coding takes hours, not days. The rest of the pipeline didn't shrink with it.

So the developer is idle. Not because the AI is slow. Because the spec is vague, the stakeholder is booked through Thursday, or the QA queue is three sprints deep.

Most teams respond by slowing the AI down. Only use it for small tasks. Keep it away from production code. This is a rational-sounding answer that preserves the old bottleneck on purpose. It guarantees you never rebalance.

---

The rebalanced pipeline

If code generation is the fast part, four things become the new bottlenecks in turn. Each one needs a different fix.

1. Requirements quality

Ambiguity was cheap when coding took three days. An engineer hit a gap, DMed someone, got an answer by lunch, and kept moving. The cost was a few minutes inside a multi-day task.

Now coding is half a day. Ambiguity costs more than the work itself. A vague acceptance criterion doesn't delay the task. It becomes the task.

Specs need to be tighter before work starts. Not longer. Tighter. Testable statements. Concrete examples. Explicit non-goals. If an AI agent can't write a passing test from the acceptance criteria, a human probably couldn't either.

2. Stakeholder availability

The product owner used to be a periodic check-in. Weekly grooming, sprint review, occasional Slack threads. That rhythm matched the pace of the work.

Now they're a critical-path resource. Your engineer finishes four tickets a day, and each one has one or two "I need to confirm this with someone" moments. If those sit in a queue for six hours, your engineer is back to producing one ticket a day.

A weekly grooming session is not a cadence anymore. It's a throttle.

3. QA and review

PR volume spikes. A reviewer who used to see three PRs a day is now looking at twelve.

Manual review at that volume becomes theater. Eyes glaze. Comments get shorter. "LGTM" starts to mean "I trust you."

Deterministic gates have to carry the first layer. Tests, types, linters, contract checks. The human reviewer reads architecture and intent. The machine reads correctness. If you flip those, reviewers become the bottleneck within a sprint.

4. Deployment

If merging is easy and deploying is weekly, merged code piles up in staging. A staging branch with forty merged PRs that nobody verified is not staging. It's a queue of unknown risks wearing a green label.

Deployment frequency has to track merge frequency. If you ship once a week, you can't merge thirty PRs a day. Well, you can. You just won't know what broke, or when, or which change caused it.

---

Where it breaks

Three failure modes show up consistently once teams start pushing AI hard.

First, teams that accelerate coding without tightening requirements produce more code, faster, in the wrong direction. Velocity charts climb. The demo rewinds half the week. The output looked healthy because the metric was lines merged, not outcomes shipped.

Second, stakeholders burn out the moment they become the bottleneck. The wrong fix is to book them into more meetings. They need tooling, not calendar space. Async spec reviews. Structured intake forms. Templates that force the right level of detail before a ticket enters the backlog.

Third, QA gets squeezed into a role it can't perform at this scale. Manual testing as the primary gate doesn't survive contact with AI-assisted throughput. The tradeoffs show up later, usually as a quiet increase in production incidents that no one connects back to the process change.

---

Implementation checklist

None of this requires new tooling. Most of it is process discipline.

• Audit your spec template. Every story should have acceptance criteria written as testable statements, not descriptions of behavior. If you can't write a test from it, it's not a spec.
• Make the product owner reachable async. Office hours, a dedicated channel, a response SLA. Anything that doesn't require a calendar invite to unblock a three-hour task.
• Move linters, type checks, and contract tests into required PR gates. Human review comes after the machine signs off, not instead of it.
• Track PR age, not just PR count. If the median merged PR is older than a day, your review process is throttling your engineers more than your spec process is.
• Decouple merge frequency and deploy frequency only deliberately. If staging has more than a week of unverified merges, you're shipping blind and calling it continuous delivery.
• Measure idle time alongside velocity. An engineer waiting on a spec looks like an engineer on a dashboard. They're not. They're a stranded resource.
• Review the pipeline quarterly. The shape of the bottleneck will keep moving as model capability improves. Whatever you fix this quarter probably won't be the constraint next quarter.

The developer isn't waiting on the AI. They're waiting on the sentence someone else hasn't written yet.

One question

The deeper point, which I go into more in Chapter 5.2 of the book, is that code generation being cheap exposes every other form of waste in your process. Requirement drafts that used to be "good enough" now aren't. Stakeholder rhythms that used to be "fine" now aren't. The old cadence was a shock absorber. AI took the absorber out.

Where is your team actually idle right now? And is it because the AI is slow, or because everything around it is still running at human speed?

For related field notes, browse the blog archive.