The pitch for AI coding tools usually sounds like this: generate code dramatically faster, ship more features, win. Then you adopt Copilot, Cursor, or Claude Code, your team writes more lines per hour, and your release cadence... stays the same. Sometimes it gets worse.

Frederick Van Brabant made this point in a recent post that hit the front page of Hacker News: code generation isn't where most engineering teams lose time. The queue is. We tested this lens against our own workflow and several teams we work with, and the math holds. Here's where AI actually compresses cycle time and where it just moves the wait somewhere else.

The bottleneck isn't typing speed

Walk a feature from idea to production and count the hours. For most teams that aren't pre-product-market-fit, the breakdown looks roughly like this:

• Specifying what to build: hours to days
• Writing the code: hours
• Code review wait: hours to days
• CI runs and flaky retries: 20-90 minutes per push
• QA, staging signoff, or product review: hours to days
• Deploy window or release train: hours to a week
• Post-deploy verification: hours

AI tools attack one row. The keystroke-to-working-code time drops, sometimes meaningfully. But if review takes two days and CI takes 40 minutes, shaving an hour off the writing step doesn't change when the code is in front of users. You produce more PRs and the review queue gets longer.

Faster code generation without faster review increases work-in-progress, not throughput. Little's Law: cycle time = WIP / throughput. Adding code without adding review capacity raises WIP and stretches every PR's wall-clock time.

There's a second-order effect that's worse. AI-assisted PRs are often larger because the cost of writing the next 200 lines feels free. Reviewers are still humans operating at human reading speeds. A 600-line PR doesn't get reviewed three times faster than a 200-line one; it gets reviewed slower, less carefully, or sits longer because nobody wants to start it.

Where AI actually moves the needle

Strip away the hype and AI tools compress cycle time in a handful of specific places:

1. Cold-start code. Boilerplate, scaffolding, test fixtures, migration files, the first 80% of a CRUD endpoint. If you'd otherwise spend 30 minutes looking up syntax for a library you touch once a quarter, Cursor or Claude Code knocks that to two minutes. Real time saved.

2. In-editor exploration. "Show me where this function is called and what shape the data is" used to be a grep-plus-mental-model exercise. AI agents that can search and read the codebase compress this to seconds. The win compounds for engineers new to a codebase.

3. Solo or async drafts. When there's no reviewer waiting and you're the only one looking at the code — spike, prototype, throwaway script — code-gen speed is the actual bottleneck and AI helps.

4. First-pass debugging. Pasting an error into Claude and getting a hypothesis is faster than searching Stack Overflow for the right thread. The wrong answer is usually cheap to discard.

That's roughly it. Look at the list — none of these affect the review queue, CI duration, deploy windows, or stakeholder review cycles, which is where most real wall-clock time goes for teams of five or more engineers.

What actually speeds up engineering

If you want shorter cycle times, target the rows that own the most hours, not the row that's loudest in the marketing copy:

Cut PR size. Teams that enforce 200-line-or-less PRs (with rare exceptions) review faster, ship faster, and find more bugs per PR. AI tools cut against this if you let them; use them to write the code, then split before opening the PR.

Shrink review latency, not review depth. Set a service level on first review — four hours during business hours is achievable for most teams. Pair on reviewing instead of doing each other's tickets. Make "review the open queue" a morning ritual.

Fix CI. A 40-minute CI run that fails on flakes every sixth or seventh push is a productivity tax most teams have stopped seeing. Quarantine flakes, parallelize, run impacted-only on PRs. Going from 40 minutes to 6 minutes saves more aggregate hours per quarter than any AI tool will.

Cut the meetings standing between code and deploy. Architecture review on a 300-line refactor. Standup updates that block someone from a deploy. "Quick syncs" that displace deep work. Each removed meeting hour is a real hour.

Default to async. Comments on PRs and design docs outperform meetings for engineering work that already has a written artifact. AI tools that summarize PRs or generate first-draft design docs help here — because they compress the cycle that bottlenecks the team, not the cycle that bottlenecks one person.

The right question before adopting an AI coding tool: "Which step in our current cycle does this compress?" If the answer is "writing code, the step that already takes the least time," expect modest gains. If the answer is "review, CI, or async coordination," expect meaningful gains.

The honest version of the AI productivity story: individual engineers can feel meaningfully faster on the parts of the job AI is good at, which is real and worth $20-40 a month per seat. Team cycle time barely moves until you also fix the queue. The teams shipping faster aren't the ones with the most aggressive Copilot rollout — they're the ones with small PRs, fast CI, and a four-hour review SLA who happen to also use AI in the editor.

That's not as catchy as the marketing pitch. It's what actually works.

---

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.