Every layer of review makes you 10x slower
Layers of approvals and code reviews can slow software delivery by an order of magnitude, and many engineers report that pull requests often wait hours or days not because they’re hard to review, but because of queueing, context-switching costs, and overloaded senior reviewers. Participants argue that AI coding agents don’t remove this bottleneck—if anything they risk flooding review queues with low-quality changes—so real gains require changing team culture and system design: smaller, trusted teams, shifting review into upfront design or pair programming, risk-based and sandboxed deployments, and tooling that prevents whole classes of errors instead of trying to inspect every change.
PR review latency and queuing
- Many report PR turnaround in days, not hours; 5-hour “wall-clock” delays are seen as optimistic.
- Core issue is queuing and context switching: reviewers batch reviews 1–2 times a day and are busy with their own work.
- A few teams enforce fast SLAs (e.g. 4 hours) via tooling and culture, but some find this interrupt-driven style stressful.
- Queuing-theory framing appears: if review throughput is fixed, 10x more PRs just creates massive backlogs and staleness.
AI-generated code and review bottlenecks
- Consensus: AI speeds coding but not review; if reviews are the bottleneck, more PRs can reduce team throughput.
- Reviewers complain of “AI slop”: duplicated helpers, random changes, unreviewed agent output, and rising defect rates.
- Some argue one engineer + AI can replace a team if they self-review rigorously; others say this ignores org politics, risk, and queue constraints.
- Strong push that authors must review AI output before burdening peers.
Alternatives and process experiments
- Suggestions to “shift review left”: up-front design sessions, daily alignment, pair/mob programming, and trunk-based development.
- Some teams effectively stop formal code review, relying on trust, strong safety nets, and fast rollback. Others see that as dangerous outside low-risk domains.
- Support for rotating “review duty” / support rotas to reduce ambiguity and speed reviews.
Planning vs doing
- Sharp split: some say an hour of planning saves 10 hours of work; others claim in software it’s often the reverse.
- Many describe a hybrid: minimal initial design, early spike/prototype, then iterative redesign as reality contradicts plans.
- Up-front design is seen as valuable for interfaces and risk boundaries, but overplanning is called out as “progress theater.”
Org size, approvals, and culture
- Multiple layers of management/approvals scale delays superlinearly; big organizations trade speed for perceived risk reduction.
- Several note incentives favor visible feature delivery over reviewing or deleting code, leading to neglected review queues and nitpicky, low-value comments.
- Trust, small teams, clear ownership, and sandboxed/blast-radius-limited environments are repeatedly cited as keys to moving fast without drowning in review.