# Review Gates

Explicit checkpoints where work must be approved before advancing, with defined criteria and an accountable reviewer.

**Rests on:** Acceptance Criteria, Spec-to-Code Pipeline

*Software Engineering · Spec-Driven Development*


## Why learn this

Review gates are the checkpoint that turns a specification into a controlled build. Without them, an AI coding agent can drift from your intent and you only find out when the code is wrong. Mastering review gates unlocks the rest of Spec-Driven Development: acceptance criteria you can test, traceability that catches drift early, and task cards you can delegate with confidence. They are the skill that separates 'vibe coding' from engineering.


## The intuition

Imagine you are building a house. You have a detailed blueprint, but the builders (AI agents) are fast and sometimes creative. If you never check their work against the blueprint, they might pour the foundation in the wrong place, use cheaper materials, or add a room you never asked for. A review gate is a formal stop at each stage—foundation, framing, wiring—where you, the accountable reviewer, compare the actual work to the criteria on your checklist. If it fails, work stops and gets corrected before you waste money building on top of a mistake. In software, the blueprint is the specification, and the review gate is where you—not the AI—decide if the code genuinely meets each requirement before the agent moves to the next task. This is the only point where human judgement actually enters the process; the spec does not enforce itself.


## An analogy

Think of a restaurant kitchen. The head chef (you) writes a detailed recipe (the specification). The junior cooks (AI agents) prepare the dishes. But the head chef does not just hand over the recipe and go home. At each course, before it is served, the chef tastes it and compares it to the recipe: Is the salt level right? Is the sauce the right consistency? Is the plating correct? If not, the dish is sent back. This taste test is the review gate. It works because the chef has defined what 'correct' means ahead of time—salt to taste, sauce thick enough to coat a spoon—not just 'make it nice.' The review gate breaks down if the chef has no criteria: then it is just taste, and every cook will get a different opinion. It also fails if the chef delegates the tasting to a junior cook without training, because they will apply their own standards. In AI, the recipe is your specification, the cooks are the agents, and the review gate is your formal approval step. The gate works only when the criteria are explicit and when you, the accountable reviewer, do the checking.


## Definition

A review gate is an explicit checkpoint in a workflow where work must be approved by a designated reviewer against predefined criteria before the process may continue.


## How it connects

You already know about engineered intent documents and product requirements from your library. Review gates build directly on those: the requirements define what 'good' looks like, and the gate enforces it. They also connect to acceptance criteria and traceability—your gate should check that each acceptance criterion is met, and that each links back to a requirement. Coming up, review gates are the foundation for test-driven development: you will learn to write tests that encode the criteria, and the gate becomes a test result.


## The mathematics

Most of this concept is not mathematical, but it rests on one simple mathematical operation: comparing two things for equality. You check whether the actual output equals the expected output. This is a branch of mathematics called arithmetic, because it is the most basic operation—checking if two numbers are the same. In code, you do this with the equals sign, but you have to be careful: in code, one equals sign means 'make this equal' and two equals signs mean 'check if equal.' For now, the idea is simple. Imagine you have a specification that says the total price of an order must be ₹1000. The agent's code calculates the total. You compare: is the calculated total exactly ₹1000? If yes, the gate passes. If no, the gate fails. This is the heart of a review gate: a yes/no comparison against a predefined standard. You will do this hundreds of times, and it is exactly the same arithmetic each time.

passed = (actual == expected)


## A worked example

```
Specification: the total cost of a shopping cart should be ₹1000. The agent writes code that adds item prices. The code outputs ₹1050. The review gate compares the output to the expected value.

Step 1: Expected total = ₹1000   # This is the criterion written in the spec.
Step 2: Actual output = ₹1050   # This is what the code produced.
Step 3: ₹1050 = ₹1000? No   # The comparison fails, so the gate is not passed.

Result: The review gate rejects the work. The agent must fix the code and resubmit.
```


## From scratch, in Python

```python
def check_review_gate(actual, expected):
    if actual == expected:
        return "PASS"
    else:
        return "FAIL"

# Example usage
total_from_code = 1050
expected_total = 1000
result = check_review_gate(total_from_code, expected_total)
print(result)  # prints FAIL

# A list of criteria to check
def review_gate(criteria):
    # criteria is a list of (name, actual, expected) tuples
    all_passed = True
    for name, actual, expected in criteria:
        if actual != expected:
            print(f"FAIL: {name} - got {actual}, expected {expected}")
            all_passed = False
        else:
            print(f"PASS: {name}")
    return all_passed

# Example: checking multiple requirements
criteria = [
    ("total_cost", 1050, 1000),
    ("item_count", 3, 3),
    ("discount_applied", True, True),
]
gate_passed = review_gate(criteria)
print("Gate passed:", gate_passed)
```


## What the code does

First, I define a function called check_review_gate that takes two values: actual and expected. If they are equal, it returns 'PASS', otherwise 'FAIL'. This is the simplest possible review gate. I then use it: the code produced ₹1050, the spec expected ₹1000, so it prints FAIL. Next, I show a more realistic version: a function that takes a list of criteria. A list is an ordered collection of items, written in square brackets. Here, each item is a tuple, which is like a list but written in parentheses, and cannot be changed. Each tuple has three parts: a name, the actual value, and the expected value. The function loops over each tuple, checks if actual equals expected, and prints PASS or FAIL. It also tracks if any failed. This loop is how you would review a specification with many requirements.


## Common misconceptions

**Review gates are only for managers** — I do not need this; I am not a manager, I just write code.

Even a solo developer using an AI agent is accountable for the output. Without a gate, the agent's mistakes become your mistakes. In fact: Review gates are part of the engineering process. You are the reviewer, even if you are also the implementer.

**If the spec is clear, no review is needed** — If I write a perfect specification, the AI agent will follow it exactly, so why bother reviewing?

The spec does not enforce itself. Agents interpret, skip details, or misunderstand. Review is the only guarantee. In fact: The spec is the standard, but the review is the control. Both are necessary.

**A review is just a quick look** — I can just glance at the code and tell if it is right.

Without explicit criteria, you are relying on intuition, which is unreliable and cannot be automated. In fact: A review must have defined criteria that the output is checked against.

**Review gates slow things down** — Stopping to review every step will make the project take twice as long.

Finding an error early is cheaper than fixing it later. A gate prevents wasted work downstream. In fact: The small delay is an investment that reduces rework.


## In short

Review gates are explicit checkpoints where work must be approved against defined criteria before advancing. You are the accountable reviewer. The spec defines the criteria; the gate enforces them. In AI, this is where human judgement lands—the code does not check itself.


## Where this is used

In large language models (LLMs), review gates are used during fine-tuning and safety alignment. For example, when training a chatbot, the output of a model is compared against a set of human-approved response templates. If the model's output deviates, it is flagged and the training is adjusted. In small models running on devices, review gates are used in speech recognition: an on-device model transcribes a voice command, and a gate checks if the transcription matches a set of allowed commands before executing anything. In retrieval-augmented generation, after an LLM retrieves documents and generates an answer, a review gate verifies that every factual claim in the answer appears in the retrieved documents. If not, the answer is rejected and the system retries with a different query. In agentic systems that plan and call tools, review gates are the safety mechanism: an agent proposes an action (like sending an email), and a gate checks it against rules (like 'never send to more than 10 recipients') before allowing it. In everyday applied machine learning, review gates are used in model deployment: a new model's predictions are compared against the old model on a validation set, and the gate blocks deployment if accuracy drops by more than 1%. Developers implement these gates in code as conditionals—if statements that compare the output to a threshold—and they are crucial to prevent silent failures.


---

Read this on the web: https://basavapurushottam.com/learn-ai/review-gates
