Developers have good reason to be skeptical of AI-generated code.
The 2025 Stack Overflow Developer Survey found that 46% of developers distrust AI output, while 33% trust it. The biggest frustration cited by 66% is output that’s almost right but not quite.
Security testing gives developers another reason to be careful. Veracode’s Spring 2026 testing found that 45% of code-generation tasks introduced a known security flaw when the models didn’t receive any security-specific guidance. Syntax correctness now exceeds 95%, but security performance has stayed around the same level.
Key Takeaways
- AI-assisted code doesn’t carry the same level of risk in every context. Changes involving authentication, permissions, sensitive data, dependencies, or critical business logic deserve more scrutiny than routine low-risk work.
- Reviewers need to know which changes are AI-assisted so they can apply the right controls and compare security, rework, and durability outcomes over time.
- A scalable review process combines automated security checks with targeted human review, then tracks what happens after the code ships to see whether the controls are actually working.
Why AI Code Review Should Be Risk-Based
Treating all AI-generated code as equally risky creates its own problem. A documentation change or routine configuration update doesn’t have the same consequences as a change involving authentication, sensitive data, permissions, or critical business logic. Applying the maximum level of scrutiny to every AI-assisted change can turn code review into the bottleneck that erases the speed gained during generation.
New Relic’s 2026 survey illustrates the other side of the problem: 62% of U.S. technology decision-makers said their teams often or always ship AI-generated code without line-by-line manual verification, while 82% reported at least one major production failure tied to AI code in the previous six months. Those findings show why the review process needs stronger ways to match scrutiny to risk.
What a Risk-Based AI Code Review Process Needs
1. Know Which Changes Are AI-Assisted
Reviewers need to know which changes are AI-assisted so they know what to look at more closely. That attribution also lets teams compare security findings, rework, and code durability between AI-assisted and human-written code.
Our guide to AI code share explains how editor telemetry, tool APIs, and commit metadata can help identify AI-assisted work across Copilot, Cursor, Claude Code, and other tools.
2. Apply More Scrutiny Where the Risk Is Higher
Not every change should be reviewed at the same depth.
Security-related areas, such as authentication, authorization, sensitive-data handling, dependency changes, and other high-impact paths, should trigger stronger review when AI contributes to the code. Routine, low-risk changes can continue through the normal review process when automated checks and team policy allow it.
Veracode's testing shows why that distinction matters: security performance varies significantly by vulnerability type. In its Spring 2026 update, AI-generated code passed 82% of SQL-injection tests and 86% of insecure-cryptography tests, but only 15% of cross-site-scripting tests and 13% of log-injection tests.
A useful review policy identifies the code and contexts where a security miss carries the greatest risk instead of simply telling reviewers to “check AI code more carefully.”
3. Automate Repeatable Security Checks
Human review is best spent on questions that require context and judgment.
Static application security testing can catch known vulnerability patterns before code reaches production. Software composition analysis can flag risky dependencies, while dynamic testing can help identify problems that appear only when an application is running. These controls work better when they’re built into the development workflow rather than saved for a final security check.
That doesn’t eliminate human review; it changes what reviewers spend their time on. Instead of manually hunting for every common vulnerability pattern, reviewers can focus more on whether the change fits the architecture, handles the intended business logic correctly, introduces unexpected permissions or data flows, and behaves appropriately in the surrounding system.
4. Measure What Gets Through Review
A rigorous review process can still miss problems.
Track security findings, requested changes, downstream rework, incidents, reverts, and code turnover for AI-assisted work. Then compare those signals with the organization’s human-written baseline.
Our AI-generated code quality measurement looks at those downstream signals across the full engineering organization rather than treating the review decision as the final quality verdict.
That feedback loop matters. If a specific tool, workflow, language, or task type repeatedly produces security findings after review, the team has evidence for where review standards need to change.
Frequently Asked Questions
Should we slow AI coding adoption until the security review process catches up?
Not necessarily. If AI-assisted code is already moving into production, the priority is to put appropriate controls around that work and measure the results. Higher-risk areas may need tighter restrictions until those controls are in place, but a blanket slowdown treats low- and high-risk work the same.
Does every line of AI-generated code need manual review?
No universal rule says it does.
New Relic’s finding that many teams ship AI code without line-by-line verification shows why review discipline matters. But line-by-line manual inspection of every change isn’t the only control. Automated testing, security scanning, risk-based review, and production monitoring all contribute to the safety net.
The appropriate review depth should reflect what the code does and what happens if it fails.
What should reviewers look for specifically in AI-assisted code?
Start with intent: does the change solve the problem the team actually meant to solve?
Then look at the areas where context matters most: security boundaries, data flow, permissions, dependencies, error handling, and whether the code fits existing architecture instead of creating a parallel solution the model didn’t know already existed.
For higher-risk changes, automated security testing should support that review rather than leaving the reviewer to catch every vulnerability manually.
Why hasn’t better syntax translated into better security?
Veracode found that syntax correctness has climbed from roughly 50% to more than 95%, while overall security performance has stayed near 55%. They think there are several possible reasons, including insecure patterns in training data and the greater contextual reasoning required for some security problems. That’s their analysis, not proof of a single cause.
Operationally, the important point is simpler: code that looks more polished isn’t necessarily more secure.
How do we know whether our AI review process is working?
Compare outcomes over time.
Track security findings and review changes for AI-assisted code, then follow the same work into production. If vulnerability findings, rework, incidents, or code turnover remain higher than the human-written baseline, the review process still has a gap.
Larridin’s developer productivity measurement connects AI-assisted work with downstream quality and delivery signals so teams can see where those gaps persist.
Build Review Around Risk, Not Fear of AI
AI-assisted development doesn’t require choosing between speed and security. What’s important is whether the review process can identify where AI-assisted code creates additional risk, apply the right controls there, and measure whether those controls hold up after the code ships.
Larridin connects AI contribution with review, quality, rework, and production outcomes so engineering leaders can see which workflows are producing durable code and which need stronger controls.
Book a discovery call to measure AI-assisted code quality across your engineering organization.