Testing AI-Generated Code: Gates That Actually Hold (2026)

The response is not to review harder. It is to move the gate from reading the diff to verifying the behaviour, and to spend the review capacity you do have on the questions a machine cannot answer.

For the longer-range view, see the future of software testing in AI-driven development.

In this guide

1. Why the usual gates stop working
2. Gate 1: the contract cannot move silently
3. Gate 2: mutation score, not coverage
4. Gate 3: no dependency arrives unreviewed
5. Gate 4: secrets
6. Do not let one model write both sides
7. The whole gate
8. Where human review should go now
9. What this changes about review culture
10. Reviewing at volume: what to read and what to skip
11. The metrics that tell you whether the gates are working
12. What does not change
13. Frequently asked questions about testing AI-generated code

Why the usual gates stop working

The two rows marked critically are the ones that changed status. They were always good practice; they are now load-bearing. If you are assembling the surrounding pipeline from scratch, what to measure in API quality gates covers the thresholds that sit alongside these four, and API testing in CI/CD covers wiring the gate itself into GitHub Actions, GitLab, or Jenkins — the same pipeline an agent-authored PR runs through, unmodified.

Gate 1: the contract cannot move silently

The single highest-value check, because it is fast, deterministic, and catches the class of change that breaks other people:

git show origin/main:openapi.yaml > /tmp/base.yaml
oasdiff breaking /tmp/base.yaml openapi.yaml --fail-on ERR

An assistant asked to "add pagination to the orders endpoint" will cheerfully change a response shape. That is fine when it was intended and reviewed, and a production incident when it was neither. The mechanics of comparing two spec versions and deciding what counts as breaking are covered in API schema validation and catching drift, and the consumer-side half in what API contract testing is.

Gate 2: mutation score, not coverage

Coverage answers "did this line run?". Mutation answers "would the suite notice if this line were wrong?" — which is the question you thought coverage was answering. For the wider set of coverage signals worth tracking, see how to measure API test coverage.

pip install mutmut
mutmut run --paths-to-mutate app/ --CI
mutmut results --all false | tee mutation.txt

# scripts/assert_mutation_score.py
import re, sys, argparse

p = argparse.ArgumentParser()
p.add_argument("report"); p.add_argument("--min", type=float, default=60.0)
a = p.parse_args()

text = open(a.report).read()
killed = len(re.findall(r"^\s*\d+:\s*killed", text, re.M))
survived = len(re.findall(r"^\s*\d+:\s*survived", text, re.M))
total = killed + survived
score = 100.0 * killed / total if total else 0.0

print(f"mutation score: {score:.1f}% ({killed} killed / {total} mutants)")
if score < a.min:
    print(f"::error::mutation score {score:.1f}% is below the {a.min}% floor")
sys.exit(0 if score >= a.min else 1)

Run it on changed files rather than the whole codebase to keep it affordable:

# .github/workflows/mutation.yml
- name: Mutate only what changed
  run: |
    CHANGED=$(git diff --name-only origin/${{ github.base_ref }} -- 'app/**/*.py' | tr '\n' ',')
    [ -n "$CHANGED" ] || { echo "no source changes"; exit 0; }
    mutmut run --paths-to-mutate "${CHANGED%,}" --CI
    mutmut results --all false > mutation.txt
    python scripts/assert_mutation_score.py mutation.txt --min 60

The first time a team runs this on a generated suite is usually instructive. Ninety per cent line coverage and a thirty per cent mutation score is a common and entirely explicable result: the tests call everything and assert almost nothing.

Gate 3: no dependency arrives unreviewed

Assistants suggest packages. Sometimes those packages do not exist, and sometimes something has been published under the name a model likes to suggest.

# .github/workflows/dependency-gate.yml
- name: Manifest changes require explicit review
  run: |
    if git diff --name-only origin/${{ github.base_ref }} \
         | grep -qE '(package-lock\.json|requirements\.txt|go\.sum|Cargo\.lock|pom\.xml)$'; then
      if ! git log -1 --pretty=%B | grep -q '\[deps-reviewed\]'; then
        echo "::error::dependency change needs a human review and a [deps-reviewed] marker"
        exit 1
      fi
    fi

- name: Every dependency actually exists and is not known-vulnerable
  run: |
    pip install pip-audit
    pip-audit --strict
    npm audit --audit-level=high

A commit-message marker is a blunt instrument, and it works precisely because it cannot be satisfied by a model — somebody has to type it.

Gate 4: secrets

Generated example code loves a realistic-looking credential, and generated tests love a hard-coded token — a failure mode examined in detail in JWT secret leakage in test files:

- name: Secret scan, including history
  run: |
    docker run --rm -v "$PWD:/repo" zricethezav/gitleaks:latest \
      detect --source=/repo --redact --exit-code 1

Pair it with a pre-commit hook so the finding is a blocked commit rather than an incident report:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks: [{ id: gitleaks }]

Do not let one model write both sides

The subtle failure: a model writes the implementation from a prompt, then writes the tests from the same prompt. Both encode the same misunderstanding, the suite is green, and the feature is wrong.

Break the loop by sourcing assertions independently:

# assertions derived from the declared contract, not from the implementation
schemathesis run openapi.yaml --url "$PREVIEW_URL" --checks all

Deriving the suite from the spec rather than the code is the whole point here; generating API tests from an OpenAPI spec with AI walks through that path end to end.

# or from a stated requirement, written by a human before the code existed
@pytest.mark.requirement("REQ-114")   # "quantity must be between 1 and 10,000"
@pytest.mark.parametrize("qty,expected", [(1, 201), (0, 422), (10_001, 422)])
def test_quantity_boundaries(api, qty, expected):
    assert api.post("/v1/orders", json={"sku": "A-1", "qty": qty}).status_code == expected

Either source is external to the model that wrote the code, which is the only property that matters.

The whole gate

# .github/workflows/generated-code-gate.yml
name: Change gate
on: pull_request
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }

      - name: 1. Contract cannot move silently
        run: |
          git show origin/${{ github.base_ref }}:openapi.yaml > /tmp/base.yaml
          oasdiff breaking /tmp/base.yaml openapi.yaml --fail-on ERR

      - name: 2. Behaviour matches the declared contract
        run: schemathesis run openapi.yaml --url "$PREVIEW_URL" --checks all

      - name: 3. The suite would notice a defect
        run: |
          mutmut run --paths-to-mutate app/ --CI
          mutmut results --all false > mutation.txt
          python scripts/assert_mutation_score.py mutation.txt --min 60

      - name: 4. Dependencies and secrets
        run: |
          pip-audit --strict
          docker run --rm -v "$PWD:/repo" zricethezav/gitleaks:latest detect --source=/repo --redact --exit-code 1

Four checks, none of which requires anyone to read a thousand lines of diff, and all of which fail loudly.

Where human review should go now

Machines do not judge requirements and they are poor at authorization logic in context. That is where the review budget belongs:

• Is this the right behaviour? Nothing automated knows what the business intended.
• Is this authorization decision correct? A generated endpoint that checks authentication but not ownership passes every test above and is a BOLA finding — the first entry in the OWASP API Security Top 10 and how to test each risk.
• Is this data handling acceptable? What gets logged, retained, returned in an error.
• Does this belong here at all? Generated code is fluent, which makes duplicated and misplaced logic easy to miss.

Everything else — style, obvious bugs, formatting, import order — was already automatable and should already be automated.

What this changes about review culture

The gates above are the mechanical half. The harder half is that "I reviewed it" now means something different, and teams that do not say so explicitly drift into a worse place than before.

The honest framing is that review has been re-scoped, not reduced. A reviewer is no longer certifying that they read every line — at current volumes nobody is doing that, and pretending otherwise is how rubber-stamping becomes the norm. What a reviewer can still certify is that the change does the right thing, that its authorization and data handling are correct, and that the automated gates covering everything else actually ran.

Make that explicit in the pull-request template so the expectation is stated rather than assumed:

<!-- .github/pull_request_template.md -->
## What changed and why

## How it was verified
- [ ] Contract diff clean, or the breaking change is intentional and agreed with consumers
- [ ] Mutation score holds on the changed files
- [ ] No dependency change, or `[deps-reviewed]` is in the commit message
- [ ] I have read and understood the authorization and data-handling paths in this change

## What I did NOT review line by line
<!-- Say so. An honest scope is more useful than an implied full read. -->

That last section is the one worth adding. A reviewer who states what they did not read gives the next person accurate information; a reviewer who implies they read everything gives them false confidence, which is the more expensive of the two.

Reviewing at volume: what to read and what to skip

The gates above exist because review capacity is fixed while generation is not. That makes review a triage problem, and triage needs an explicit rule rather than good intentions.

Read closely, always:

• Anything touching authorization. A model will produce a plausible permission check that is subtly wrong, and no automated gate reliably catches an authorization bug that compiles and passes its own tests.
• Anything handling money, entitlements or personal data. The cost of being wrong is not proportional to the size of the diff.
• New dependencies. One line, unbounded consequences.
• Anything that changes a public contract. The contract diff gate flags it; a human still decides whether it was intended.

Skim, and rely on the gates:

• Generated tests. Reading a hundred assertions individually is not a good use of attention. Check that they were derived from the contract rather than from the implementation, and let mutation score judge whether they are worth anything.
• Mechanical refactors. If the suite holds and the contract diff is clean, the risk is low and the reading cost is high.
• Formatting and boilerplate. This is what automated checks are for.

The failure mode this avoids is uniform attention: reviewing every line of a large generated diff with equal care, which takes hours and produces less safety than twenty focused minutes on the authorization path. Reviewers who spread attention evenly get tired at exactly the point the risky code appears, because the risky code is rarely at the top of the diff.

The metrics that tell you whether the gates are working

Adopting these gates changes what is worth measuring, and two numbers answer whether the change helped.

Mutation score on changed files, tracked over time rather than as a single threshold. A codebase where generated tests are accumulating will show line coverage climbing while mutation score stays flat — that divergence is the clearest available signal that the suite is growing without getting stronger.

Review latency on the diffs that matter. If authorization changes are waiting as long as formatting changes, triage is not actually happening. Splitting review time by change category is uncomfortable to measure and is the thing that shows whether the policy is real.

A third number is worth watching even though it is noisy: the proportion of production incidents whose root cause was in code nobody read closely. It will be small, it will be arguable, and it is still the only direct measurement of whether the triage rule is drawn in the right place.

What does not change

It is worth being clear about the limits of this. Gates that verify behaviour do not replace understanding the system — they replace reading every line as the mechanism for catching defects. Someone still has to know what the service is supposed to do, or a contract diff is just a diff and a mutation score is just a number.

The teams that handle generated code well are not the ones with the most gates. They are the ones where a small number of people retain a clear model of the system's invariants, and the gates exist to protect those invariants automatically so that the humans are spending their attention on whether the invariants are still the right ones.

Frequently asked questions about testing AI-generated code

Why is line coverage a bad gate for AI-generated code? Because generated tests are unusually good at executing code without asserting anything meaningful about it. Coverage measures which lines ran; mutation score measures whether the suite would notice if those lines were wrong, which is the property you actually wanted.

What is mutation testing? A tool makes small changes to your source — flips a comparison, changes a constant — and re-runs the suite. Every mutant that survives is a change your tests did not catch. The percentage killed is a far better proxy for suite quality than coverage.

Should I let an AI write the tests for its own code? Only if the assertions come from an independent source such as a spec or a stated requirement. A model that writes both the implementation and the test from the same understanding will encode the same misunderstanding twice and produce a green suite.

How do I stop unreviewed dependencies arriving? Fail the build on any change to the lockfile or manifest that has not been explicitly reviewed, and run a vulnerability audit in the same job. Suggested packages that do not exist or are typosquats are a real and repeatedly observed failure mode.

What should human review focus on now? Requirements and security-relevant logic — whether the code does the right thing, and whether an authorization or data-handling decision is correct. Style, obvious bugs and formatting are the parts machines already handle.

Does this change the test pyramid? No, but it changes where the pressure is. More code per unit of review means more weight on automated contract and behavioural gates, and less reliance on a reviewer noticing something in a diff.

Sources and further reading

• Google Testing Blog — test sizing, flakiness and the limits of coverage as a metric.
• DORA State of DevOps research — the delivery-performance context for change gates.
• OWASP Top 10 for LLM Applications — over-reliance and insecure output handling, both relevant to generated code.
• NIST SP 800-218 (SSDF) — the secure development practices auditors expect these gates to satisfy.

Key takeaways

• The problem is arithmetic: generation outruns review capacity, so gates have to verify behaviour rather than depend on someone reading the diff.
• Line coverage stops meaning anything — generated tests execute code without asserting much. Gate on mutation score instead, restricted to changed files to keep it affordable.
• A contract diff is the cheapest high-value check: the API cannot change silently regardless of who wrote the change.
• Dependency review and secret scanning moved from good practice to load-bearing, because both failure modes are specific to how assistants write code.
• Never let one model write both the implementation and its tests from the same prompt — source assertions from a contract or a human-written requirement.
• Spend the human review you have on requirements, authorization and data handling; automate everything a machine already judges better.