Studies of production incidents at mid-scale engineering orgs show that AI-generated code passes standard PR review at roughly the same rate as human-written code, yet causes 2.4x more post-merge incidents in the first 30 days. That gap is the governance problem. Code review alone will not close it.
The instinct is to treat this as a tooling problem: add a linter, tune the AI model, enforce prompting standards. Those help at the margins. The structural issue is that code review was designed around an implicit model of authorship. A reviewer reads a diff and mentally simulates the author's intent, fills in gaps, asks clarifying questions. When the author is a language model, that simulation breaks down. The model had no intent. It had a probability distribution. Reviewers who don't know this are still filling in gaps. They're just filling them in wrong.
What your current review process does not catch
Standard PR review catches obvious logic errors, style violations, and things that look wrong at a glance. What it reliably misses in AI-generated code falls into three categories.
First, plausible-but-wrong behavior at edge cases. AI models optimize for code that looks correct and compiles. They are not optimizing for correctness at the p99 input, the empty payload, the race condition on reconnect. A reviewer reading fluent, well-commented code is primed to approve it. The edge case failure shows up in production two weeks later.
Second, architectural drift. A model generating a data-access layer does not know that your team decided six months ago to never call the database directly from service handlers. It will generate technically valid code that violates a constraint existing only in a decision doc and institutional memory. No linter catches that.
Third, security assumptions baked into training data. Models trained on public code inherit the security posture of public code, which is not great. They will generate JWTs without expiry validation, SQL with parameterized queries 90% of the time, and retry logic without backoff jitter because most examples online omit it.
None of these are things a faster review or a stricter prompt will reliably prevent. They require a verification layer that operates at a different level than the diff.
The governance checkpoints that actually work
Think of AI-assisted code as having three distinct risk surfaces that require three distinct checkpoints. You do not need to block every PR. You need to route PRs to the right checkpoint based on what they touch.
Checkpoint 1: Intent verification before the diff is written. The cheapest place to catch a problem is before code exists. Require that AI-assisted features start with a lightweight intent doc: what system state does this change, what contracts does it touch, what failure modes are acceptable. This is not a full design doc. It is a structured prompt artifact that travels with the PR. Reviewers check the code against the intent doc, not against their intuition. Teams that implement this cut AI-related rollbacks by roughly 40% in the first quarter, because the mismatch between intent and output becomes visible.
Checkpoint 2: Automated architecture conformance. Your architectural constraints should be machine-readable. If they live only in a wiki, they will not be checked. Invest one sprint in encoding your top ten architectural rules as static analysis policies: no direct DB calls from handlers, all external API calls go through the client abstraction layer, secrets never in config structs. Tools like Semgrep let you write these as custom rules without a compiler background. Route every AI-generated PR through these policies as a required CI check, not a suggestion.
Checkpoint 3: Behavioral verification at the PR boundary. This is the hardest and most important one. You need tests that were not written by the same model that wrote the code. This sounds obvious. Almost nobody does it. If a developer asks Claude to generate a function and then asks Claude to generate the tests, the tests will inherit the same misunderstanding the function has. Require that behavioral tests for AI-generated logic be authored by a human or by a separate, independently prompted model run. The goal is adversarial coverage: someone or something actively trying to break the assumption baked into the generated code.
OpenThunder is built around exactly this model: it runs independent verification against your architecture, security constraints, and stated intent before a change ships, without relying on the same model that generated the code.
A practical implementation for a team of twenty engineers looks like this. Any PR tagged with an AI-assist label gets routed through all three checkpoints. The intent doc is a two-field template in your PR description. The architecture conformance check runs in CI. The behavioral verification requirement is enforced by a branch protection rule that requires a human approval specifically on the test coverage, separate from the general approval. Total overhead per PR: roughly 45 minutes the first few times, under 20 minutes once the team has the habit.
The policy should also include a classification for high-risk surfaces: authentication code, billing logic, anything touching PII, anything that writes to a ledger. For those, add a fourth checkpoint: a dedicated security-focused review that treats the AI-generated code as untrusted input, the same posture you would take reviewing code from a contractor who had never worked in your codebase. This is not insulting to the AI. It is accurate.
One thing engineering leaders consistently get wrong: they implement these checkpoints for new features and then exempt refactors. Refactors are where AI-generated code causes the most damage. They touch the most surface area with the lowest perceived risk. Apply the same routing logic to any AI-assisted change above a threshold line count, regardless of whether it is labeled a feature.
The org-level version of this framework requires two things from leadership. First, a clear policy statement that AI-assisted code is not self-certifying. It does not come with the implicit trust gradient that human-authored code gets from authorship history and accountability. Second, metrics. Track AI-assist incident rate separately from baseline. If your AI-assist rollback rate is not lower than your baseline rollback rate within two quarters of implementing these checkpoints, something in the process is not working and you need to find it.
OpenThunder surfaces exactly these metrics as part of its verification pipeline, so the data to have that conversation exists without building a separate analytics layer.
The checkpoints above are not bureaucracy. They are the minimum viable governance layer for a technology that ships code faster than human reviewers can reason about it.
See what OpenThunder verifies
OpenThunder independently verifies AI-assisted changes against your architecture, security constraints, and stated intent before they reach production, without depending on the model that generated the code in the first place. If you are building the governance layer your org needs right now, start here.
The release confidence problem is not that AI writes bad code; it is that your current process has no way to know the difference until production tells you.