Quality gates for AI-generated code

When code appears faster than it can be read, quality assurance necessarily moves into automation. The question is then no longer whether gates are needed but which ones – and how they stay fast enough that nobody works around them.

1. Why gates decide now

A review that used to work implicitly, because somebody had thought about every line, no longer works the same way with generated code. Human attention is the scarcest resource in the process – it should be reserved for intent, architecture and risk. Everything that can be formalised belongs in the pipeline.

2. The minimum set

These checks should block the merge in every project – regardless of who or what produced the code:

build            # compiles / packages, no errors
unit-tests       # deterministic, fast, no external services
contract-tests   # implementation still matches the published API contract
architecture     # module boundaries and dependency rules hold
lint + format    # no style discussion inside code review
sast             # static application security testing
dependency-scan  # known vulnerabilities and license policy
secret-scan      # no credentials in the diff

What is notable is how little of this is AI-specific. The list is simply what a solid development process should have anyway – AI turns “should” into “must”.

3. Ordering and runtime

Ordering decides acceptance. Cheap checks that fail often belong at the front, so feedback arrives quickly:

1. Seconds: formatting, lint, secret scan, commit convention.
2. A few minutes: build, unit tests, architecture and contract tests.
3. Before the merge: integration tests, SAST, dependency and licence checks.
4. After the merge: end-to-end, load and deep security testing.

As a rule of thumb: feedback on a push within ten minutes. Beyond that, context switching sets in – and with it the pressure to allow exceptions. More on this in the deep dive CI/CD for AI-assisted software development.

4. Test quality instead of coverage

Line coverage is a particularly weak signal for generated code: it is trivial to push up and says little about depth of testing. More meaningful indicators are:

• Where the test cases come from. Derived from the requirement, not from the freshly generated implementation.
• Error and authorisation paths, not only the happy path.
• Boundaries and edge cases – empty, null, maximum, concurrent.
• Mutation testing for critical modules where the effort is justified: it measures whether tests actually notice defects.

A sensible gate rule is therefore not “85% coverage” but: no regression against the target branch, plus mandatory tests for new public interfaces.

5. Security checks

Three checks cover the majority of practically relevant cases:

• Secret scanning on the diff – the cheapest gate with the highest hit rate.
• Static analysis with a rule set tailored to the project. An unconfigured tool produces so many false positives that it gets ignored.
• Dependency checking for known vulnerabilities and licence compatibility.

In addition, it is worth reviewing authorisation logic explicitly – this is where generated code most often falls short.

6. Dependencies and licences

New dependencies are more frequent with generated code than with hand-written code – and not always the established ones. Three rules:

• Only packages from a curated source or an internal mirror.
• A licence allow-list, checked automatically.
• Make new dependencies visible – as their own note in the merge request, not buried in the lockfile diff.

7. Setting thresholds

8. Exceptions without a floodgate

There will be exceptions – the question is whether they stay visible. What works:

• A justification in the repository, not in chat.
• An expiry date for every exception, after which the gate applies again.
• Approval by a second person, not by the one submitting.
• Regular review of the active exceptions – a growing list is a signal, not a steady state.

9. Running the gates

Gates are software and age accordingly. Running them means keeping rule sets current, reducing false positives instead of ignoring them, fixing or removing flaky tests, and watching runtime. A gate nobody believes is worse than none – it costs time and still provides no assurance.

Checklist: quality gates

Conclusion

Quality gates are the point where AI speed turns into delivered value – or does not. They do not have to be sophisticated: the minimum set, executed quickly and enforced without exception, covers the bulk of it.

The rest is operational discipline: reduce noise, keep runtime short, keep exceptions visible. A gate you have to bypass to hit a deadline will be bypassed – and then it is no longer a gate but a delay.