A Gate That Works, and a Gate That Only Looks Like One
RPIQ, what belongs at each stage of a quality gate pipeline, and the four questions that separate a gate with teeth from expensive decoration.
Last week, in The Speed Trap, I argued that AI has made us faster than we can justify — that the bottleneck was never writing the software, it was trusting it. I closed by promising three things: RPIQ, what belongs at each stage of a quality gate pipeline, and how to tell a gate that works from a gate that only looks like one.
Here they are, in that order.
The letter that changes the loop
RPIQ is Research, Plan, Implement, Quality. The first three letters are familiar to anyone who has worked with coding agents: understand the problem, decide the approach, write the code. The fourth is the one that matters.
Quality is usually not a stage. It is a thing that happens somewhere inside "implement," owned by whoever notices, performed when there is time. That arrangement survives at human speed because a human wrote the code and carries some memory of where the bodies are buried. It collapses at machine speed. When the code arrives faster than anyone can read it, "someone will catch it in review" stops being a process and becomes a wish.
Promoting Quality to a first-class stage — with its own entry conditions, its own outputs, and its own owner — is not a rebranding. It changes what the loop is for. The loop is no longer designed to produce code that is then inspected. It is designed to produce evidence, of which the code is one part.
There is a second thing the loop does, and it is easy to miss because it happens before any code exists. Plan is where the gates get defined — the pass conditions, and the evidence each stage owes the next. If you are inventing the pass condition after seeing the output, you are not running a gate. You are negotiating with one.
That is also what keeps three separate judgments separate: what was expected, what will be done, and what was delivered. Models collapse those three whenever the operator gives them the opportunity. Ask for an implementation without a plan and you get code, plus a confident account of why that code was the right thing to build — the judgment and the artefact come out of the same pass, which is what makes the judgment worthless.
That distinction sounds academic until you try to answer a simple question about something an agent built for you last Tuesday: how do you know it works? If the honest answer is "it looked right and nothing broke," you have an implementation loop with an inspection habit. You do not have a quality stage.
What belongs at each stage
A gate pipeline is not one big check at the end. It is a series of cheap, fast, specific checks, each placed where the feedback is still worth acting on. Here is the shape I use, and — more importantly — the logic for where things sit.
Commit: format, lint, dead code. The cheapest checks go closest to the keyboard. Formatting and linting are not quality in any deep sense, but they cost seconds and they eliminate an entire class of noise from every downstream review. Dead-code detection belongs here too, and it earns its place specifically because of how AI writes: agents generate helpers they never call, leave orphaned branches behind after a refactor, and rarely clean up after themselves. Tools like Periphery catch that debt while it is one commit old instead of one quarter old.
Pull request: the test suite and static analysis. This is where the substantive automated verification runs. In the BowSmith work I lean on roughly 70,000 automated tests, shaped as a pyramid — a wide base of unit tests, a middle band of integration tests, a thin layer of end-to-end. Duplication scanning runs here too, via PMD CPD, because copy-paste is the other signature failure mode of generated code: an agent asked to solve a problem it has already solved nearby will frequently solve it again rather than reuse.
One structural decision matters more than any individual tool: the verification fixtures live in a separate repository from the product code. It is a small piece of friction with a large payoff, because it makes it awkward to reshape a test so it flatters the code it is judging. Tests that live next to the thing they test, edited by the same agent in the same session, drift toward agreement.
CI: the full suite, in a clean environment. Re-running everything from scratch on a machine with no history catches the failures that only exist because of your machine — the cached artefact, the stale dependency, the environment variable someone set months ago and forgot. "It passes locally" is not a claim about the software.
Merge: review by a different model than the one that wrote the code. This is the gate people skip, and it is the one I would give up last.
The review bias nobody warns you about
When a model reviews its own output, it rubber-stamps itself. Not because it is lazy — because it is consistent. It brings the same assumptions to the review that it brought to the writing, the same gaps, the same confident wrong turns. Asking it to check its work is asking it to notice something it structurally cannot see. It will find typos. It will not find the misread requirement.
A different model brings different blind spots, and different blind spots is the entire mechanism. This is not an argument that the second model is smarter. It is an argument that independence is a property of the arrangement, not of the reviewer.
That is worth sitting with, because it generalises past AI. Independent review has always worked for this reason. We just never had such a clean demonstration of what happens when you remove the independence and keep the review.
How to tell a real gate from a decorative one
Most pipelines that fail do not fail because a gate is missing. They fail because a gate is present and does nothing.
Last week I said a gate is a decision, not a checkbox: a named owner, a defined input, an explicit pass condition, and a real consequence when it fails. That was the definition. These are the questions that tell you whether yours actually meet it — plus one the definition does not cover.
Can it block? A gate that reports but cannot stop the line is a dashboard. Dashboards are useful. They are not gates. If the answer to a red result is "we'll look at it later," you have already answered this question.
Does it fail for a reason you can name? A check that goes red for reasons nobody can articulate gets ignored within about three sprints — and the ignoring generalises. Flaky gates do not just fail to catch their own class of problem; they teach the team that red is ambient. One unreliable gate degrades every gate around it.
Is it independent of what it is judging? The fixtures in a separate repository, the reviewer that is a different model, the clean CI environment: these are all the same principle applied three times. A check that shares an origin with the thing it checks inherits its errors.
Does someone own the red? Not "who will fix the code" — who is accountable for the gate itself still being meaningful in six months. Unowned gates do not get deleted. They get weakened: a threshold relaxed here, a suite excluded there, until the gate is green by construction. That is the failure mode that hurts most, because from the outside it looks exactly like success.
A gate that passes all four is doing real work. A gate that fails two or more is costing you build minutes and buying you a feeling.
Where this is going
Speed is not the achievement. Justified speed is. Everything above is machinery in service of one claim: that when the machine writes the code, something other than optimism decides whether it ships.
I go into this in more depth — the orchestration surfaces, where trust actually gets produced, and what it means for teams that do not have a greenfield app to experiment on — in my chapter "Quality at Machine Speed: AI Orchestration, and the Future of Trust in Software Quality," in Erik Seversen's multi-author book The AI Transformation: Thriving Within Civilization's Next Big Disruption.
Next in the series: trust is produced, not felt — plausibility drift, surface inconsistency, silent regressions, and documentation rot. The four ways software stops being trustworthy without ever going red.
Earlier in this series: I Wrote a Chapter About Trust. A Machine Helped Me Test the Argument. · The Speed Trap
