跪拜 Guibai
← All articles
AI Programming · Testing · Code Standards

AI Code's Bottleneck Is Verification: A Three-Layer Acceptance System

By 挖掘狂人 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Teams shipping AI-generated code can get green pipelines that still deliver broken business logic, because tests inherit the same wrong assumptions. This system gives a concrete path to make verification independent from generation, so AI speed doesn't erode production trust.

Summary

AI-generated unit tests can pass while business logic is broken, because the tests share the same wrong assumptions as the implementation. That's the problem a Chinese team found after reviewing ~310,000 lines of AI-assisted code. They built a three-layer acceptance system to make AI output verifiable, blockable, and rollbackable.

The first layer encodes architecture contracts as machine-readable rules, such as layering, dependency whitelists, forbidden patterns, and DTO signatures, and runs CI checks that block merges. The second layer separates specification, verification, and implementation: freeze read-only business contracts before coding, then use mutation testing (e.g., PIT/Pitest) to inject small faults and confirm the tests can actually catch them. The third layer moves acceptance to runtime with metrics, logs, distributed tracing, and canary-stage behavior assertions that verify business side effects, idempotence, and state transitions under real traffic, not just HTTP 200s.

The system's stated goal is to install a brake and a yardstick on high-speed AI code production. Even if AI writes faster and faster, the decision of whether code is correct and fits the system's long-term design stays with humans.

Takeaways
— AI-generated unit tests can pass while business logic is broken when both come from the same wrong understanding.
— The team reviewed ~310,000 lines of AI-assisted code and saw blurred layering, inconsistent practices, and deeper dependency coupling.
— Industry data shows a significant share of AI-generated code needs manual debugging even after QA, with two to three redeployment cycles to confirm a fix.
— Layer 1: encode architecture contracts (layering, dependency whitelists, forbidden patterns, DTO signatures) into CI gates that block merges.
— Layer 2: freeze read-only business contracts before coding, then run mutation testing with PIT/Pitest to verify that AI-written tests can kill injected faults.
— Layer 3: extend acceptance to runtime with metrics, logs, distributed tracing, and canary behavior assertions for side effects, idempotence, and state transitions.
— The system's aim is to make AI output verifiable, blockable, and rollbackable, not to limit AI.
Conclusions

A single model generating both implementation and tests creates a shared source of error; separating specification, verification, and implementation breaks that chain.

Static gates and mutation testing cannot catch issues that only real traffic exposes, so runtime behavior evidence becomes the most trustworthy signal for production readiness.

As AI generation speeds up, verification becomes the bottleneck; the proposed solution adds brakes and a yardstick rather than slowing down generation.

Concepts & terms
ArchUnit
A Java library that enforces architecture rules (layering, dependency constraints) programmatically; used in CI to block merges when violations appear.
Mutation testing
A technique that injects small faults (e.g., changing a comparison operator, removing a null check) into source code to verify whether existing tests detect the change; a low kill rate means the tests don't cover the intended behavior.
PIT (Pitest)
A mutation testing tool for Java that produces a mutation score and can be wired into pipelines as a hard merge gate.
Shared-source error
When tests and implementation come from the same AI generation, they share the same wrong assumptions, so tests can pass while business logic is broken; the solution is to freeze independent contracts and use mutation testing.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗