AI Makes Coding Faster, but Teams Are Cutting Risk Review Processes

AI coding assistants have significantly boosted code output speed, but delivery bottlenecks haven't disappeared—they've just shifted downstream to review, QA, and release stages. To clear the backlog of PRs, many teams are starting to "reduce friction" across the board, but in doing so they're inadvertently damaging critical risk interception mechanisms like code review. Based on first-hand developer observations, this article analyzes the logic for distinguishing "accidental friction" from "necessary friction" and explores the boundaries of engineering process optimization in the AI era.

AI Pushes the Bottleneck Downstream

AI coding agents have made writing code much faster. There's been plenty of discussion about "where the work went," and the consensus is: the workload has piled up downstream—planning and scheduling, review queues, QA testing, release approvals. PR counts have risen noticeably, but delivery dates have barely moved up.

Facing this backlog, the most common response is "reduce friction across the entire chain" so new code flows through each stage faster. According to feedback from multiple developers in technical communities, this approach does improve throughput in the short term, but that's exactly where the problem lies: when a team decides it has a speed problem, it tends to treat all friction as waste—yet some of that friction is actually providing critical protection.

PR (Pull Request) is a core mechanism in code collaboration platforms (like GitHub, GitLab): after a developer completes changes on a separate branch, they initiate a merge request, which must be reviewed, discussed, and approved by peers before it can be merged into the main branch. The length and dwell time of the PR queue are key indicators of a team's delivery health. AI coding agents have dramatically lowered the cost of submitting PRs—what used to take half a day of manual changes can now be generated in minutes—so PR counts have surged, but each PR still needs human review, CI checks, test validation, and other stages. The processing capacity of these stages hasn't increased in tandem, resulting in a backlog. Understanding this is important: PR backlog isn't a "slow coding" problem—it's a "review throughput" problem, so simply speeding up coding won't shorten the delivery cycle.

Two Types of Friction: Accidental and Necessary

The key to understanding this issue is dividing process friction into two categories.

Accidental friction is things like environment setup, hunting through documentation, or chasing a permission across four teams. This is pure overhead and should be reduced to zero. Most engineers have experienced being slowed down by these trivial matters, and cutting them is uncontroversial.

Necessary friction is that brief "wait, are we sure we want to do this?" before a change. This pause seems insignificant, but it's the team's cheapest insurance. It doesn't require complex approval hierarchies—it just leaves room for a question before code is merged.

The Water Filter Analogy: Friction Is a Prerequisite for Filtration

An analogy explains this: a filter needs friction to intercept impurities. Remove all friction, and water flows straight through, catching nothing; too much friction, and the water won't flow. Clean water comes from a balance between the two.

Code review is exactly this kind of friction—it's where high-risk changes are intercepted before users discover them. The principle of "make the common path the easy path" is great—until that common path runs straight through a high-risk change with no speed bumps along the way. Optimizing away all friction usually tears down guardrails along with bureaucracy. This state can last for a while, and you'll feel fast—until the first high-risk change with a bug slips through and affects all users.

Code review is one of the lowest-cost, highest-benefit quality assurance practices in software engineering. Research shows that the cost of fixing a defect before code is merged is typically an order of magnitude lower than fixing it after it's discovered in production. The value of code review isn't just catching bugs—it's also knowledge sharing, code style consistency, and finding security vulnerabilities and design flaws. The spread of AI-generated code makes review even more critical: AI may generate code that looks reasonable but contains subtle errors, shifting the reviewer's role from "checking syntax" to "verifying intent and risk." Therefore, cutting review steps may seem to increase speed, but actually pushes risk to a more costly stage.

Criteria: Benefits, Costs, and What You Lose

Distinguishing the two types of friction doesn't require a complex framework—the core is weighing pros and cons. Facing a step in the process, you can ask three questions: Does this friction have a benefit? What do you gain by removing it? What do you lose?

Take environment setup: it has no real benefit, fixing it recovers time, and you lose nothing—that's accidental friction.

Take the "wait, are we sure?" before a database migration: removing it saves a little time but loses the only moment when someone stops to ask "could this change hurt users?"—that's necessary friction.

From a practical standpoint, the teams that use AI best tend to place friction where the risk is and streamline everything else. This also means process optimization isn't about one-size-fits-all subtraction—it's structural adjustment based on risk distribution.

Database migration is a typical high-risk change scenario: it may modify table structures, rewrite data, affect online query performance, and once something goes wrong, it's often hard to roll back quickly, potentially causing data loss or service interruption. For this reason, the confirmation step before migration—even just a brief "are we sure?"—plays an irreplaceable risk interception role. The common feature of such necessary friction is: it occurs before irreversible or high-impact operations, costs very little, but can prevent catastrophic consequences. Identifying these nodes is a practical entry point for distinguishing accidental from necessary friction.

Implications for Teams

Before deleting the next step in your process, it's worth asking: what is this step buying you, and what would you lose by removing it?

AI has increased coding speed, but it hasn't changed one fact: software delivery risk doesn't disappear just because code is written faster. Review, testing, and release approvals exist precisely to stop errors before they reach users. Cutting them all as "friction" means building your speed advantage on a fragile assumption—that all changes are safe. And when that assumption breaks once, the cost often far exceeds the time saved.

One-line Summary

After AI accelerates coding, bottlenecks shift downstream; teams should distinguish accidental from necessary friction and preserve risk interception mechanisms.

Paragraph Summary

AI coding assistants have significantly boosted code output speed, but delivery bottlenecks haven't disappeared—they've shifted to review, QA, and release stages. Facing PR backlogs, many teams tend to "reduce friction" across the board, inadvertently damaging critical risk interception mechanisms like code review. The article divides process friction into two types: accidental friction (like environment setup, permission chasing) should be eliminated entirely; necessary friction (like risk confirmation before changes) must be preserved. The water filter analogy illustrates that friction is a prerequisite for intercepting risk—removing it all is like tearing down guardrails. To decide whether to keep friction, ask three questions: Does it have a benefit? What do you gain by removing it? What do you lose? Efficient teams place friction where the risk is and keep everything else lean.