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.

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.

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.

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.

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:

- 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

# 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.
• 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.

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.

Related articles

The Future of Software Testing in AI-Driven Development | Agentic QA Tools | How to Test LLM Applications | API Quality Gates: What to Measure | Test Automation Best Practices for DevOps