Gates Are a Loss Function. Here Are the Four Ways They Fail.

A gate is a person reading. Everything that makes a person read worse makes the gate worse, and AI-DLC produces a lot of reading.

The ninth principle of the AI-DLC whitepaper says that human validations “act as a form of loss function”, identifying and pruning wasteful downstream work before it happens. It is the best sentence in the method. It explains why AI-DLC stops after every stage and waits for you, and why that stop is engineering rather than bureaucracy.

It is also where the method is weakest, and the documentation does not say so. The gate is a person, and the AI produces artifacts much faster than a person can read them carefully. In the rollout I followed inside a large engineering organization, the gates failed in four ways, over and over, and none of them was a tooling bug.

This article is about those four failures and the habits that hold up against them.

What a loss function does at a gate

In machine learning, a loss function measures how wrong a model’s output is, so training can correct it. The whitepaper borrows the idea. At each gate, a human measures how wrong the artifact is, so the workflow can correct it before the next stage builds on it.

The reason that matters is compounding. In AI-DLC every stage reads the previous stage’s output as its context. A vague requirement is not contained by the design stage. It is multiplied by it: the design encodes the vagueness as a decision, the Units encode the design, and the code encodes the Units. An ambiguity that cost one comment to fix at the requirements gate costs a redesign at the architecture gate and a rewrite in code review.

The same wrong decision, caught at different gates

The gate's value is not that it catches mistakes. It is that it catches them at the cheapest layer.

Where it gets caught	What it costs to fix
At the intent and requirements gate	A comment and a regenerated document. Minutes.
At the architecture gate	A new design and new ADRs before any code exists.
In code review	Rewriting a Unit that already passes its tests.
In production	An incident, and then all of the above.

What AI-DLC 2 checks before it asks you

A human at a gate is the last layer, not the only one. AI-DLC 2 stacks several checks so that by the time an artifact reaches you, the mechanical problems are already out of the way and your attention can go to judgment.

Checks that run before and at a gate in AI-DLC 2

1. 1

   Sensors

   Deterministic checks, such as a linter or a type check, that fire on the files a stage writes. Some are advisory, some block until fixed.

   +
2. 2

   Reviewer agents

   Two review-only agents judge requirements, stories, and mockups, or the technical design, and write a READY or NOT-READY verdict with findings. They never block. The human decides.

   +
3. 3

   Verification gates

   Automated traceability checks between phases: every requirement maps to a story, nothing is orphaned, the artifacts agree with each other.

   +
4. 4

   Your approval

   At the end of every stage outside Initialization: Approve or Request Changes, in your own words. Nothing moves until you answer.

Notice what the reviewer agents do. On an adversarial NOT-READY, the stage reruns, up to two times by default, and whatever is still unresolved goes to your gate as findings. That is a good design: it removes the obvious problems before they cost you attention. It also has a side effect worth naming. A gate that arrives with a clean review attached looks more trustworthy than it is. A READY verdict from a reviewer agent is one model’s opinion of another model’s work. Useful, and not the same as a person who knows the domain saying yes.

Construction has its own variant. In AI-DLC 2 you approve each Unit at a verified checkpoint, and the verification runs a command you authorized once. After that you can choose “Continue automatically” for ordinary checkpoints. Plan approval for each Unit, choosing the verification command, and every failure still come back to a human. The engine draws the line between what can be delegated and what cannot. The question is whether the human on the other side of that line is still reading.

Failure one: the artifact looks complete and says nothing

The first failure is the most dangerous because it looks like success.

A product lead I worked with during the rollout explained it with an analogy I now use everywhere. You get an email from your bank. It has the logo, the right colors, the formal tone. Because everything looks familiar, you stop checking the link. The familiarity switches off your skepticism, which is exactly what a phishing email counts on.

A generated requirements document does the same thing. It has the right sections, the right headings, the acceptance criteria in the right format. You recognize the shape of a good document and your brain marks it as good. Then you actually read it, sentence by sentence, and there is nothing in it. Plausible filler in the shape of a spec.

The structure of a document is easy to teach a model. The content of your domain is not. So the model reliably produces the part you check by glancing, and unreliably produces the part you only check by reading.

Failure two: the reviewer is tired

The second failure is arithmetic. The agent generates a requirements document, a set of stories, a domain design, and a list of Units in minutes. A person needs real time to read each one carefully, and the attention runs out long before the documents do.

In the rollout, the limit was about an hour. One engineer described the moment precisely after a long Inception: by the time the last documents arrived, they had no head left to review them, and they stopped because otherwise they would start approving anything. That is the honest version. Most people do not stop. They keep clicking Approve, and the gate keeps recording a decision nobody made.

Failure three: the reviewer does not know the domain

The third failure surprised people more than it should have. The engineers and product people with the deepest knowledge of the domain took longer at the gates. They interrogated every claim, disagreed with the agent, and rewrote its success criteria. The people with the least domain knowledge were faster. They accepted the first output.

It is the opposite of the usual story that AI helps juniors most. At a gate, the less you know, the more you trust, because you have nothing to compare the output with. Researchers call it automation bias, and it has been documented in human factors work since the 1990s: people overrely on automated output, especially when it looks authoritative.

The practical consequence for AI-DLC is about who stands at which gate. A junior engineer can run a workflow. A junior engineer should not be the only approver of a requirements document in a domain they joined last month. Give people time to learn the domain before you make them a gate, and pair a low-domain operator with a high-domain reviewer until then.

Failure four: the tenth approval

The fourth failure is trust that calibrates on history. The agent was right the first nine times today, so the tenth artifact gets a glance. Nothing about the tenth one is different. Your attention is.

This one is hard to see from the inside, which is why it needs a mechanical answer instead of good intentions. Rubber-stamping by exhaustion is not a character flaw. It is what attention does under repetition, and the only defense is a habit that forces a real read regardless of how the last nine went.

The one-sentence rule

Here is the habit. Before you approve any artifact, say in one sentence what it commits you to and why it is right. Out loud, or in the chat, or to the person next to you.

If you can say it, you read it. If you cannot, you are not done, and the answer is to keep reading or to ask the agent, not to click Approve. It sounds trivial. It is the cheapest control I know that turns a rubber stamp back into a decision, because you cannot summarize a document you skimmed without noticing that you skimmed it.

Questions that make a gate real

1. 01

   Make the artifact explain its commitments.

   A summary in the agent's words shows you what it thinks it built. Compare that with what you thought you asked for.

   Type this

   Before I approve: in one sentence, what does this document commit us to? Then list every assumption in it that did not come from my answers.

2. 02

   Challenge the success criteria.

   Agents tend to define success as an artifact existing. Success is an outcome for the business. If the criterion is a deliverable, it is the wrong criterion.

   Type this

   The success criterion you wrote is a deliverable. Rewrite it as an outcome we can measure after release.

3. 03

   Get the second opinion in a fresh context.

   In the same session, the agent defends the decisions it made. With only the artifact in front of it, it critiques them.

   Type this

   /clear, then load only the artifact and ask: Produce a critique of this as if you hadn't written it.

4. 04

   Stop when you notice you are approving faster.

   The state file makes pausing free. An approval made in the second hour of a session is worth less than one made tomorrow morning.

   Type this

   Stop here. Commit what is approved, and we continue this stage in the next session.

Pace is a design decision, not a soft skill

Every one of the four failures gets worse with speed. So the most effective countermeasures in the rollout were about pace, not tools.

Keep approval sessions to about an hour. Split a long Inception across two sessions on different days instead of one three-hour marathon. Never chain Inception and Construction in the same sitting to save time: decisions approved by a tired team in Inception become rework in Construction, and the rework costs more than a second session would have. And have the manager sit in the first few mobs with the explicit job of calling the pause, because a team under pressure to look productive will not call it on its own.

None of this slows the method down in any way that matters. AI-DLC keeps state in files, so a paused workflow resumes exactly where it stopped. The only thing you lose by pausing is the illusion that approving faster was going faster.

Human in the loop, human on the loop

There is a bigger question underneath all of this: how much should a human approve at all?

Kief Morris drew the distinction clearly in Humans and Agents in Software Engineering Loops. A human in the loop approves each step. A human out of the loop is vibe coding. A human on the loop designs and improves the system the agents run in, the harness, and supervises its outcomes rather than every action. Augment Code’s guide to AIDLC frames it as the central operating decision: in the loop for high-risk decisions, on the loop for validated, well-constrained work.

Human in the loop

1. 01Approves every stage and every artifact
2. 02Right for high-risk, ambiguous, or regulated work
3. 03Breaks down when the volume of artifacts outruns attention

Human on the loop

1. 01Designs the gates, rules, and checks the agents run inside
2. 02Supervises outcomes and intervenes on failures
3. 03Only safe once the checks can carry the trust you removed

AI-DLC 2 already lets you make that move in a narrow place: choosing “Continue automatically” for ordinary Construction checkpoints is moving from in the loop to on the loop for that part of the work. It is the right move when the Unit has a real verification command, tests that mean something, and sensors that catch the mechanical problems. It is the wrong move when the only thing standing between the agent and your main branch is a tired person who stopped reading an hour ago.

That is the general rule, and it is the same one behind harness engineering: you earn the right to approve less by making the system check more. Enthusiasm does not count as verification.

FAQ

What does human on the loop mean?+

A human on the loop supervises the outcomes of an automated process and designs the rules and checks it runs inside, instead of approving every individual step. A human in the loop approves each step.

In AI-DLC terms, approving every stage is in the loop. Letting verified Construction checkpoints proceed automatically while you handle plans and failures is on the loop.

What is the difference between an approval gate and a verification gate in AI-DLC?+

An approval gate ends every stage outside Initialization and waits for a human to answer Approve or Request Changes. A verification gate runs between phases and is automated: it checks that the artifacts are traceable and consistent, for example that every requirement maps to a story. One checks judgment, the other checks links.

Can I turn off the approval gates in AI-DLC 2?+

Partly. In Construction you can let ordinary Unit checkpoints run automatically. Plan approval for each Unit, the choice of verification command, and every failure still require a human, and the human-presence guard cannot be lowered for a single workflow. The scope you pick also decides which stages run, and a stage that does not run has no gate.

Do reviewer agents replace human review?+

No. AI-DLC 2 has two review-only agents that write a READY or NOT-READY verdict with findings, and on an adversarial NOT-READY the stage reruns up to two times by default. They never block, and the human makes the call. They are good at catching obvious problems, and their clean verdicts can make a weak artifact look more trustworthy than it is.

How long should an approval session be?+

About an hour. In the rollout I followed, approvals after the first hour of reading generated documents turned into rubber stamps. Split long Inceptions across sessions. The state file means a pause costs nothing.

Who should approve an AI-DLC gate?+

Someone who knows the domain well enough to disagree with the agent. Low-domain reviewers accept the first output; high-domain reviewers interrogate it. Until a person knows the domain, pair them with someone who does.

Where to go next

The whitepaper is right: a gate is a loss function, and it is the cheapest place to catch a wrong decision. But a loss function that has stopped measuring is just a delay. Keep the sessions short, make the agent state its assumptions, use the one-sentence rule, and only move a gate from in the loop to on the loop when there is real verification behind it.