AI code review: speed revolution or quality regression?
AI code review quality refers to how reliably AI systems assess pull requests, reduce review time, and still catch functional defects, security issues, and design problems without introducing new risks or blind spots into the software delivery pipeline.
The new data on AI-assisted review is blunt: you gain speed, but you risk shipping more problems. A large study of 207 GitHub projects and 1.02 million pull requests found that adding AI agents to reviews reduced review time by 2.5–4.5 days per thousand lines of code[KLOC]. That is a huge cycle-time win. However, the same study reports that AI-assisted reviews show review smells in 78–94% of pull requests, compared with 69–76% in human-only reviews. In other words, automated code review risks are not theoretical; they show up as measurable quality degradation. If teams treat these tools as drop-in replacements for human reviewers, they are trading away safety for speed.
Why AI code review smells more—and why that matters
Review smells are symptoms of weak or shallow review practice: rubber-stamping, missing critical comments, or focusing on style over semantics. The study points at a key culprit: teams often reuse the same AI reviewer identity across pull requests, shrinking review diversity and reinforcing the model’s blind spots over time. That is the opposite of the cross-checking we expect from healthy human review cultures.
This is where code review automation tradeoffs bite. Saving several days per KLOC looks attractive when you are under release pressure, but each smell is a hint that logic bugs, design flaws, or insecure defaults are slipping through. As more non-specialists across a company can write code that creates a security risk, weak AI review amplifies their mistakes instead of containing them. AI-assisted review should therefore be framed as triage, not sign-off. Let machines handle repetitive checks, but keep human reviewers as the final authority on risky changes and security-sensitive paths.
AI-generated code security: faster attackers, exposed defenders
The security context around AI-generated code is getting harsher. AI models today can autonomously discover, chain, and exploit software vulnerabilities at scale, which is why one panelist warned that organizations are going to need runtime shields to protect themselves before they have time to apply patches. In 2025 alone, 48,185 common vulnerabilities and exposures were published, with 20% rated critical or high severity. Against that backdrop, letting AI code review quality slip is asking for trouble.
AI-generated code security is doubly fragile because many more people in a company than a few years ago can now write code that creates a security risk. As one expert summarized, “However good your model is, it probably is not going to write absolutely secure code any more than a human does”. Combine more code, more authors, and non-deterministic models, and the attack surface explodes. Runtime shields based on eBPF are emerging as a practical response: they can safeguard file systems, block privilege escalations, and monitor network access while teams work through their 55‑day patch backlogs.
Platform teams’ new toolkit: AI-BOMs and runtime shields
Platform engineers are quietly rewriting their playbooks to keep up with both AI innovation and innovative AI attacks. One prediction is that companies will stop adopting open source wholesale and instead fork only the parts they use, to shrink their dependency graph. In parallel, they are extending software bills of materials with AI bills of materials (AI-BOMs) that track model weights, training datasets, and third-party APIs, closing gaps that could lead to data poisoning or supply chain surprises.
This is not a luxury; it is a survival mechanism in a world where shadow AI—the uglier cousin of shadow IT—brings more risks. Runtime shields round out the stack, giving platform teams a way to react at machine speed when n‑day threats and AI-driven exploits hit production. The sober takeaway: governance and runtime defenses must grow alongside code review automation. If your organization accelerates development with AI but neglects AI-BOMs and runtime shields, you are driving a race car with no brakes.
How teams should balance speed and oversight
Given the current evidence, the right posture is not to reject automated code review, but to constrain it. The study’s finding that early heavy adopters of LLM-based review saw no significant efficiency gains should be a warning: dropping AI into a broken process will not save you. Teams need intentional policies about when AI can approve changes, where human review is mandatory, and how to rotate AI reviewer identities to avoid monoculture smells.
At the same time, platform teams should onboard both humans and agents to internal platforms in a controlled way, rather than letting each department grow its own Frankenstein’s monster of ad-hoc AI tools. Remember: code review automation tradeoffs are not only about time-to-merge. They directly affect operational risk, incident rates, and customer trust. The practical rule of thumb is simple: use AI to reduce toil and latency, but keep humans accountable for high-impact decisions—and back them with AI-BOMs and runtime shields to stay ahead of the next exploit wave.
