Most bottlenecks in a delivery pipeline are just friction, and only a few of them are the point. AI is very good at clearing the first kind and gives you no signal about which one it just cleared.
Right now the default move is to run every slow step through the same test: can this be faster. PRD taking too long? AI drafts it. PR review backing up the queue? AI reviews it. QA sign-off dragging past the sprint boundary? AI signs off. Most of that is a fair trade, so the instinct is not wrong. But somewhere in that pattern, we stopped asking a different question: what is this step actually for?
Not every bottleneck is friction. Some of them are checkpoints. Optimize away a checkpoint and the check stops happening, but whatever it existed to catch just goes uncaught. Nobody notices until it shows up three months later, in production, with nobody able to explain why the system was built that way in the first place.
Here's where I think the "use AI for everything" reflex breaks down. It treats every bottleneck as the same kind of problem, when there are really two kinds of checks happening across a delivery pipeline, and they are not interchangeable.
1. The consistency check.
Does this spec contradict itself?
Are the edge cases covered?
Does this PR match the pattern the rest of the codebase uses?
Does the test suite actually exercise the paths the ticket claims it exercises?
These are questions with an answer that exists independent of anyone's judgment. The information needed to answer them is already written down, in the spec, in the codebase, in the acceptance criteria. AI is good at this. Genuinely good, not hype-good. It doesn't get tired on page forty of a requirements doc. It doesn't skim the third PR of the day the way a reviewer running on their fourth coffee does.
2. The intent check.
Is this the right thing to build?
Does this still solve the problem we said we were solving?
or did the problem quietly change three sprints ago and nobody updated the doc?
Is this edge case actually worth handling, or is handling it going to cost us two weeks we don't have for a scenario that happens to point zero one percent of users?
These are not questions with an answer sitting in the artifact. They require someone who understands why the work exists, what the business is actually trying to get out of it, and what happens if we're wrong. That understanding usually lives in someone's head, not in the ticket.
The danger isn't that AI is bad at the intent check. It's that AI is confident at the intent check. It will give you a plausible-sounding answer to "is this the right thing to build" with the same tone of voice it uses for "does this spec contradict itself." Nothing in the output signals which kind of question just got answered. That's how a team ends up trusting a judgment call the way it trusts a fact check.
I've written before about cognitive debt, the interest a team pays when it accepts what AI produces without understanding it. Collapsing the intent check into the consistency check is how you take on the sharper version of that debt. Call it intent debt: the moment nobody can explain why a decision was made because the decision was never really made by anyone, it was just accepted.
Before you let AI take over a step, or before you let a human step become "just AI reviews it now," ask one question:
If we remove the human here, does anyone still understand the why?
Not "does the work still get done." Work gets done either way. The question is whether the reasoning behind the work survives the handoff. If the answer is yes, the human at that step was mostly doing consistency checking, and AI can probably absorb most of it. If the answer is no, that human was the intent check, and removing them doesn't remove the bottleneck. It removes the accountability, and leaves the bottleneck in place, just invisible now.
Here's how that test plays out at three points almost every delivery team has.
Notice the pattern? In every row, AI can absorb the half of the step that's checkable against something already written down. None of them can absorb the half that requires knowing why the thing exists. That's not a limitation that better prompting fixes, but the actual shape of the problem.
I want to be honest about the parts of this that don't resolve cleanly.
The line between consistency and intent isn't always obvious in the moment. A lot of PR review looks like pattern-matching until someone asks "wait, why are we even doing it this way," and that question was there the whole time, just quiet.
Teams under real delivery pressure will collapse these checks whether or not I write a blog post about it. The pressure to ship is not going away, and "keep a human in the loop for intent" is easy to say and expensive to actually staff.
And the test itself takes judgment to apply. Deciding whether a given review is really a consistency check or an intent check is, itself, an intent-level decision. This framework doesn't remove the need for someone senior enough to know the difference. If anything, it raises the bar on that person, because now they're the one deciding where the line sits for their own team.
At Forte Group, we've been introducing AI across delivery, code generation, review, test automation, sign-off gates, the whole pipeline. It was never really about whether AI can be trusted with judgment. It's about whether we're still deciding, on purpose, which judgment to hand over.
Optimizing away a bottleneck should be a decision, not a reflex. Before AI takes over the next step, ask the question first. . If someone can still explain the why after the human is gone, optimize it. If they can't, you're not removing a bottleneck. You're removing the last person who understood what the work was for.
If you're not sure which of your own checkpoints are still doing real work, that's worth a look before the next AI rollout, not after it. Happy to talk through it.
83% faster delivery. Under 10% rework. See exactly how Xceptor got there.
