Explainability usually gets pitched as a comprehension aid, something that helps reviewers work faster and onboard sooner. When AI agents write a growing share of your code, explainability becomes a security control, because a change nobody can explain is a change nobody has actually reviewed, and unreviewed code ships with whatever it happens to contain.
This article covers what makes an AI-generated PR opaque, why that opacity is a security problem rather than an inconvenience, and what to require of every change before it merges.
What makes a PR opaque
A pull request is opaque when a reviewer can approve it without being able to answer the questions that determine whether it's safe. Opacity has recognizable ingredients:
There is no author to question. The person who opened the PR may have written a short prompt and accepted the output, so asking why the code handles authorization the way it does produces a shrug instead of a rationale. The reasoning that produced the change was never observable in the first place.
The diff is too large to reconstruct. Agents produce sprawling changes touching dozens of files, and nobody reads every generated line at that volume. Whatever understanding the reviewer builds comes from sampling.
The reach is invisible. Standard diffs only reveal modified lines, masking downstream blast radiuses like upstream callers, downstream interface consumers, or altered trust boundaries multiple hops away.
The polish hides the problems. AI-generated code tends to look clean and consistent, which defeats the visual instincts reviewers use to decide where to slow down.
Any one of these can be worked around on a single PR. Compounding across hundreds of PRs a month, they produce a codebase where approval and understanding have quietly come apart.
Why opacity is a security problem
The riskiest flaws are exactly the ones opacity conceals
Security review depends on context. Whether an endpoint is vulnerable depends on who should be allowed to call it, whether an object reference is safe depends on whose data it can reach, and none of that is visible in syntax alone. CodeRabbit research across 470 open-source pull requests found that security-issue rates in PRs classified as AI-co-authored were up to 2.74 times those in human-only PRs, with prominent patterns in improper password handling and insecure object references. These results describe the study's sample; authorship was inferred from repository signals. These flaws can depend on context about what the change is supposed to do, which is precisely the understanding an opaque PR withholds.
Review collapses quietly under volume
When PRs arrive faster than reviewers can understand them, reviewers may approve changes without establishing their behavior or security impact. Review counts and approval times do not show whether anyone checked authorization boundaries, dependencies, or failure modes. A review policy needs explicit requirements for those checks so that approval records describe the work performed.
Attackers don't need your code explained
Large language models are lowering the cost of vulnerability discovery, so attackers can probe more code and more paths than defenders relying on manual comprehension can keep up with. An attacker doesn't need to understand your change's intent to exploit its behavior. Defenders need to check whether that behavior matches the intended access rules and contracts. Missing context makes those checks harder.
Compliance requires proof, and opacity leaves none
Security programs eventually have to demonstrate that controls run. An opaque PR approved on trust leaves behind an approval record without an understanding record, and when an incident review or an audit asks what was known about a change before it shipped, the honest answer becomes uncomfortable. Explainability produces the artifact that makes review demonstrable: a durable account of what the change was understood to do at the moment someone vouched for it.
Explainability as a security control
Treating explainability as a security requirement means an opaque PR fails review by default, the same way a change that fails CI does. Before approval, every change should come with answers a reviewer can inspect:
Intent: What is this change trying to accomplish, stated plainly enough to check the diff against it? Scope beyond the stated intent is unreviewed change traveling under a reviewed change's approval.
Behavior: Which behaviors of the system are different after this merges, described at the level of contracts and effects rather than files?
Reach: What does the change touch across the codebase, including the dependencies and consumers that don't appear in the diff?
Evidence: What supports the claim that it works, beyond tests written by the same model that wrote the code? Suspected failure modes deserve reproduction and proof rather than assertion.
Producing those answers at agent volume takes automation with full codebase context, and the analysis has to be independent of whatever wrote the code, since a generator explaining its own output inherits its own blind spots. The explanation layer also can't stop at the merge. Code that was understood when it shipped becomes risky through interaction with everything merged after it, so the same scrutiny has to continue post-merge as the system around each change evolves.
What to require before merge
Turning the principle into policy is straightforward to state and worth writing down:
Every PR arrives with a walkthrough of intent and behavior, generated with codebase context rather than assembled by the author from memory.
Reach is established before approval, so no change merges with unknown consequences for the systems around it.
Security-relevant findings come with evidence, and disputed findings get reproduced instead of argued.
Approvals are recorded against the explanation, creating an audit trail of what was reviewed, what evidence supported the decision, and who approved it.
Post-merge monitoring watches for the risks that only emerge between changes.
The explanation work moves to automation, reviewers spend their time on judgment instead of reconstruction, and the changes that deserve scrutiny actually receive it.
Explainable, secure review with CodeRabbit
CodeRabbit is built to make every PR explainable before a human vouches for it, with security woven through the same workflow:
Walkthroughs before reading: Change Stack organizes large diffs into layered explanations of intent, behavior, and reach, generated from full codebase context.
Independent, evidence-backed review: Every change gets checked against your security posture and definition of done by a reviewer that didn't write the code, with sandbox verification that can reproduce suspected failure modes and add evidence to findings.
Security beyond the diff: CodeRabbit Security reasons across files, services, and authorization boundaries to find the contextual flaws pattern matching misses, before merge and after.
An audit trail by default: Findings, explanations, resolutions, and approvals document the checks performed and the decisions made. Those records support later investigation; they do not establish that every decision was correct.
Require documented intent, behavior, reach, and evidence before approving a change. Use the review record to identify unresolved questions and the checks needed to answer them.
