The evidence gap in AI-generated code releases

For most of software history, code review focused on what changed and who wrote it. AI-generated code inverts part of that assumption. The author may be a model, an agent, or a human working with an assistant. What matters is not who typed the code, but how the change was produced and whether its claims can be independently verified.

Provenance becomes the primary object of governance: model identity, prompt context, tool calls, editing session, and reviewer attestation. Without provenance, a reviewer cannot reconstruct the basis for the change. Without reconstruction, there is no verification.

In controlled internal reviews of AI-generated changes, the most common gap is not malicious code. It is missing evidence. A model claims a fix is safe. A test passes. A ticket closes. But the chain linking the original risk to the new artifact is broken or absent.

The result is a release decision made on assertion rather than proof. The organization may ship quickly, but it loses the ability to explain why the release was safe — which is exactly what auditors, regulators, and incident reviewers ask for later.

Closing the gap requires four controls. First, provenance capture at the IDE, MCP server, repository, and CI layers. Second, reviewer attestation that is bound to the specific artifact. Third, capping AI-generated claims at the detected evidence level until independent non-probabilistic evidence promotes them. Fourth, policy-version binding so the release decision is evaluated against the standard that applied at the time.

These controls do not block AI-generated code. They make it governable at the speed it is produced.

This note is based on internal analysis and synthetic scenarios, not a published customer study. Organizations vary in how they define acceptable evidence for AI-generated code. The controls described are architecture and process targets, not guarantees that every release will be safe.