Three Gates. Three Different Failures
Part 9 of 12 · Why AI Code Fails (And How to Fix It)
Three Gates. Three Different Failures.
Most teams who adopt a review-heavy AI process make the same mistake: they treat every review as the same review. A human looks at the work, decides whether it's good, says yes or no. They put that human review at the end — before merge — and call it one gate.
One gate catches one class of failures. The failures it misses happen earlier, in places a final review can't see.
The ANN SDLC has three gates. Each one catches something the other two structurally cannot.
Gate 1: Lock — Step 1, before requirements are written.
The purpose of this gate is to catch the constraint nobody thought to write down.
Before any requirements are drafted, before any ADR is considered, before the AI opens a file — a human reviews the business intent and asks: is this complete? Not "does this describe the feature?" but "does this contain every constraint that governs what an acceptable implementation looks like?"
For guest checkout, the Gate 1 review catches the GDPR email constraint. The developer who wrote the business intent knew that guest users shouldn't be emailed without permission, but wrote "marketing cannot email guests" without specifying that this meant explicit opt-in at checkout, non-negotiable. The Gate 1 reviewer — who's worked on GDPR compliance before — adds the specificity: "Marketing cannot email guest customers unless they explicitly opt in at checkout. This is non-negotiable for GDPR compliance."
That one sentence changes the requirements. The requirements change the implementation. The implementation includes an opt-in checkbox that defaults to unchecked, with the correct data handling for users who decline.
Without Gate 1, the opt-in requirement surfaces in a legal review six months after launch. With Gate 1, it surfaces in a ten-minute review session before a single requirement is written.
Gate 1 cannot catch requirements mismatches — the requirements don't exist yet. Gate 1 cannot catch ADR non-conformance — the code doesn't exist yet. Gate 1 catches missing constraints before they become expensive gaps.
Gate 2: Check — Step 6, before the PR opens.
The purpose of this gate is to catch the gap between what the AI built and what the requirements actually said.
After code generation is complete — after the AI has run the test suite, after CI is green, after the developer has done a quick look at the output — a human takes the requirements file and goes through the acceptance criteria one by one. Not the code. The requirements.
For guest checkout, the Gate 2 review catches the button. REQ-CHECKOUT-00010 says "Continue as guest" must be at equal visual weight to "Sign in." The AI implemented it as a TextButton below an ElevatedButton. The test suite confirmed the button exists. Gate 2 confirms the button is wrong.
The fix takes fifteen minutes. The PR doesn't open until it's fixed. The test that should have caught this — checking that both buttons have the same widget type and size — gets written now, added to the test suite, and enforced by CI forever after.
Gate 2 also catches the GDPR deletion handler gap. ADR-012 says GDPR deletion requests must include guest order cleanup by email, not uid. The developer implemented the deletion handler update in the Cloud Function but missed the batch deletion script for historical data. Gate 2 checks each ADR consequence against the implementation. The missing batch update is caught before commit.
Gate 2 cannot catch the missing constraint from Gate 1 — that conversation already happened. Gate 2 cannot catch system-wide implications the developer didn't know about — that's Gate 3. Gate 2 catches the gap between the requirements the team agreed to and the code that was actually generated.
Gate 3: Clear — Step 9, before merge to main.
The purpose of this gate is to catch the system-level implication nobody in the feature conversation knew to look for.
A senior engineer reviews the PR. They have the requirements, the ADR, the test results, and the diff. Their job is not to re-read every line. Their job is to confirm that the implementation follows the architectural decisions made in Phase I and that the change is safe for the system as a whole.
For guest checkout, Gate 3 catches something the developer and the Gate 2 reviewer both missed. The senior engineer knows that a weekly admin reporting query aggregates order data for financial reconciliation. It was written before guest orders existed. The impact analysis marked it "no change needed" — and that's technically correct, because the query runs against the full collection and guest orders will appear in it. But the query groups by userId. Guest orders have userId: null. They'll be grouped under null in the report, which the finance team will see as a new unexplained row in the reconciliation spreadsheet.
This isn't a bug. It's a compatibility issue that requires a conversation with the finance team and possibly a small update to the report formatting. Gate 3 catches it. The developer adds a note to the ADR's consequences section. The finance team is informed before the feature goes live. The Monday morning reconciliation report has no unexplained rows.
Gate 3 cannot replicate the constraint discovery of Gate 1 — that was six weeks ago. Gate 3 cannot replicate the requirements verification of Gate 2 — that's done, the PR is clean. Gate 3 provides the one thing neither previous gate could: system-wide context from someone who has worked across the entire codebase.
The failures each gate prevents.
| Gate | Catches | Cannot catch |
|---|---|---|
| Lock (Step 1) | Missing constraints in the business intent | Requirements mismatches, ADR drift, code bugs |
| Check (Step 6) | Gap between requirements and implementation | Business constraints not in the requirements, system-wide implications |
| Clear (Step 9) | System-level implications, ADR non-conformance | Everything the earlier gates already caught |
The common mistake is applying the same review logic at all three gates. A team that treats Gate 1 as "is this description good enough to start?" and Gate 2 as "does this code look right?" and Gate 3 as "does this PR look OK to merge?" is asking the wrong questions at each gate and missing the failures each gate was designed to find.
Gate 1 asks: is every constraint documented before requirements begin? Gate 2 asks: does the implementation satisfy every acceptance criterion? Gate 3 asks: does this change fit safely into the system as a whole?
Three questions. Three different information sets. Three different people, ideally — the product owner or lead at Gate 1, the developer at Gate 2, the senior engineer at Gate 3. The same person doing all three is better than one gate, but it's not equivalent to three separate perspectives applied at the right moment.
No exceptions for deadline pressure. No exceptions for "it's a small change." Small changes with no Gate 3 review are where silent regressions live — because small changes often touch system-wide code that the developer working on the feature doesn't fully understand. The value of Gate 3 scales inversely with the developer's system-wide knowledge. The less the developer knows about what else depends on the code they're changing, the more important it is that someone who does know reviews the change before it merges.
The three gates are not redundant. They're sequential filters, each one catching what the others structurally cannot. Remove any one of them, and the failures it catches start appearing in production.