Your Processes Are Human-Shaped

Why Faster Gates Are the Wrong AI Fix

Why Faster Gates Are the Wrong AI Fix

Every approval step in your organization, every review gate, every CI check, was sized for one thing: the volume and the judgment of a human being producing work at human speed. AI just changed the volume by an order of magnitude. Almost nobody has done the AI review gate redesign that change demands. The instinctive fix is to make the gate faster. Add reviewers, add automation, add a second approval lane so things move. That instinct is exactly backwards, and the evidence is already sitting inside your engineering org, which got here first.

Why AI clogs the review gate instead of speeding it up

LinearB’s 2026 Engineering Benchmarks Report, built from 8.1 million pull requests across 4,800 teams in 42 countries, found that AI-generated pull requests wait more than 16 hours on average before a reviewer even picks them up, compared to roughly 200 minutes for unassisted work, a delay of more than five times. Once a reviewer actually opens an AI-generated PR, review moves faster than it does on manual code. But acceptance tells the real story: manual pull requests merge at close to 84.5 percent, AI-generated ones at 32.7 percent, less than half the rate. A separate benchmark, drawn from more than 250,000 developers by Opsera, puts a similar number on the same phenomenon from a different angle: AI-generated pull requests wait 4.6 times longer for review than human-written ones, even as the time it takes to produce a pull request in the first place dropped by up to 58 percent. The same report found AI-generated code carrying 15 to 18 percent more security vulnerabilities per line than human-written code, which is exactly the kind of thing a review gate exists to catch. Two different datasets, two different vendors, the same shape: the CI pipeline bottleneck from AI is not a speed problem upstream. It is a capacity problem downstream, at the exact point where a human is supposed to decide whether the work is actually good. Writing got faster. Judging did not. The queue backs up at the only station that never scaled. That is a code review story, but it is not only a code review story. Every approval chain in your organization, procurement sign-off, legal review, the marketing brand check, the finance close, has the same shape. AI raised the volume arriving at the gate. The gate is still staffed and structured for the old volume. Speeding up the gate does not fix a volume mismatch. It just processes more of the wrong thing, faster. Adding headcount to the gate is not the fix either, for the same reason adding engineers to a late project rarely makes it earlier. A second and third reviewer added to an undifferentiated queue mostly means more people skimming for the same surface-level issues, not more depth applied to the cases that need it. Capacity added to the wrong shape of gate produces the same shallow pass, just performed by more people, at higher cost. The problem was never that too few humans were watching the door. It is that nobody has decided which arrivals actually need a human at the door in the first place.

Toil vs protective friction: not every gate does the same job

Before you touch any approval workflow, you need to know what the gate is actually for, because gates are not one thing. Some exist to catch a real risk. Some exist because someone got burned once, years ago, and nobody has revisited the rule since. Google’s site reliability engineering practice has a name for the second kind: toil, work that is manual, repetitive, automatable, and devoid of enduring value, work that leaves the system in exactly the state it was in before, just later. A rubber-stamp approval that nobody has said no to in two years is toil. It produces the feeling of oversight without the substance of it, and every hour spent on it is an hour not spent on the review that actually catches something. Protective friction is the opposite. It is the step that exists because removing it would let something real slip through: a security review that has actually caught a vulnerability, a legal sign-off that has actually stopped a contract from going out with the wrong terms, a second set of eyes on a client deliverable that has actually caught a wrong number before a client saw it. This is the same distinction Voltage Control has argued for at the level of individual work: ask what a piece of friction is producing before you remove it, and design the developmental kind back in on purpose. The organizational version of that question is toil vs protective friction, and it is the first thing to ask about any gate before you touch its speed. You cannot tell the two apart by looking at how slow a gate is. Toil and protective friction both show up as delay on a process map. You can only tell them apart by asking what the gate is actually catching, which almost nobody does before reaching for the “make it faster” lever.

AI review gate redesign: name the reason, ask if it survives

Here is the actual move, and it is simple to state and uncomfortable to do: for every gate that AI volume is straining, name the specific reason it was built, then ask honestly whether that reason still holds. Most approval chains were never designed. They accreted. A step got added after an incident, a role got a sign-off because a reorg happened to route through their desk, a check got bolted on because a client once complained. Nobody sat down and decided the current shape on purpose. That is why almost nobody can answer, on the spot, why a particular approval exists. If you cannot name the reason quickly, that is diagnostic information, not an oversight to apologize for. It usually means the step is toil dressed up as governance. When the reason is real and still holds, the fix is not speed, it is fit: keep the human judgment where it is actually being exercised, and strip out everything around it that is not. A legal review that genuinely reads for risk should stay a legal review. The three rounds of formatting and routing that happen before a human lawyer ever sees the document are toil, and AI should eat every one of them, freeing up the lawyer’s attention for the reading that actually matters. Redesigning approval workflows for AI is rarely about removing the gate. It is about removing everything around the gate that was never doing the gate’s job in the first place, so the person staffing it can actually do theirs. When the reason does not survive the question, the honest move is to remove the gate entirely, not automate it. A sign-off that has not caught anything in years is not a candidate for a faster rubber stamp. It is a candidate for deletion. Keeping it, just quicker, gives you the same false sense of oversight you had before, plus a faster false sense of it. Run a concrete case through it. A procurement team requires three approvals on every vendor contract under fifty thousand dollars: a manager, a director, and a compliance reviewer. AI-assisted drafting triples the number of contracts moving through that chain in a quarter. Ask what each approval is actually catching. The manager sign-off usually turns out to be budget awareness, which a dashboard already provides in real time. The director sign-off is mostly a formality that has not blocked a contract in eighteen months. The compliance review is the one that has caught real problems: a vendor missing an insurance rider, a data-handling clause that should not have been there. Two of the three steps are toil wearing a compliance costume. The third is the whole reason the gate exists. Collapsing three approvals into the one that actually does the job is not a weaker process. It is the same process with the theater removed, and it is the only version that scales to the new volume without drowning the person doing the real reviewing.

Redesigning approval workflows for AI, done well

Picture a marketing team where every piece of AI-drafted content used to go through the same brand-review gate as everything else: one reviewer, one queue, first in first out. AI volume tripled what arrived in that queue in a quarter. The instinctive fix is to add reviewers or set an SLA. The redesign fix starts by asking what the brand review was actually protecting. Mostly it was catching voice drift and factual overreach, occasionally it was catching real legal exposure. Split the gate along that line and you get two different systems, not one faster one. Voice and factual checks against an explicit, written standard can be handled by a lighter pass, sometimes AI-assisted itself, because the standard is legible enough to check quickly. Legal exposure keeps the human gate, fully staffed, with volume filtered down to the cases that actually carry risk. The queue that used to back up on everything now backs up on almost nothing, because most of what used to sit in it never needed that reviewer’s judgment in the first place. That is what AI governance friction looks like when someone has actually done the work of separating it from toil, instead of running every case through the same undifferentiated gate at a faster clock speed. The gate gets smaller and sharper, not faster and the same shape. This is also, not coincidentally, the same discipline behind Stop Optimizing for Speed: when AI collapses the cost of producing work toward zero, optimizing the parts of the system built around production speed stops being the leverage point. The leverage point moves to wherever judgment still has to happen, and the job of leadership is to find that point precisely, not spread more speed evenly across a system that was never built for this volume in the first place.

The redesign is the discipline, not the delay

None of this is a case for slowing anything down. It is a case for looking honestly at what a gate was built to do before deciding whether to speed it up, narrow it, or remove it outright. The teams that skip that question and just add capacity to the existing gate will keep processing more of everything, including more of the noise, at higher cost, with no better catch rate than before. The teams that do the harder work, naming the reason, testing whether it survives, redesigning the gate around what is left, will end up with fewer approvals, staffed by people actually equipped to exercise judgment on what reaches them. That is a smaller system that catches more, not a faster system that catches the same amount later. Start with the gate that is under the most AI-driven strain right now, whichever one that is in your organization. Ask three questions of it before you touch its speed: what is this gate actually catching, has it caught anything real in the last year, and if you removed it tomorrow, who would notice and why. If the honest answers point to toil, cut it, do not automate it. If they point to something real, protect the person doing that judgment by stripping away everything around them that is not the judgment itself. Either answer is an AI review gate redesign. Neither one is a faster version of what you already have. Your processes were built for people. AI changed the volume flowing through them. The fix was never going to be a faster version of a system built for a world that no longer exists. It is redesigning the system around the judgment that is still, and will remain, irreducibly human. Want help finding which of your gates are toil and which are load-bearing before you scale AI volume through them? That diagnostic is exactly where Voltage Control starts an AI transformation engagement.