← All briefings Briefing

Designing a hybrid AI-plus-human code review policy.

ai code reviewstatic analysiscode qualitydevsecops

AI-assisted coding is changing the volume and shape of code review. Developers produce more changes, faster, and many of those changes are drafted by models. The challenge for engineering leaders is to keep quality high without making review a bottleneck. Sonar’s framing is useful: deterministic static analysis can act as the trust layer between AI generation and production, while human reviewers focus on what machines cannot yet judge.

Why a hybrid policy is necessary

Neither full automation nor pure human review is sufficient on its own. Static analysis is fast, consistent and good at catching known categories of bug, vulnerability and style violation. It does not tire, play favourites or miss issues because it is in a hurry. But it cannot assess whether a change solves the right problem, respects domain constraints or fits the longer-term architecture.

Human reviewers bring context, judgement and accountability. They are also scarce, expensive and inconsistent when overloaded. A hybrid policy uses each for what it does best.

The role of deterministic analysis

Deterministic static analysis is particularly valuable for AI-generated code because it gives an objective, repeatable assessment. If a generated function introduces a SQL injection path, an insecure dependency or an unhandled exception, the scanner catches it every time. This removes some of the guesswork from human review and prevents obvious issues from reaching a colleague’s inbox.

The key word is deterministic. Unlike an AI reviewing AI, a rules-based analyser follows explicit, auditable logic. When it flags an issue, you can explain why. When it passes code, you know which checks were applied.

The role of human review

Human reviewers should spend less time on linting and formatting and more time on correctness, intent and integration. For AI-assisted changes, the reviewer should ask: does this change do what the developer claims? Are the assumptions valid? Does it handle failure cases? Does it introduce hidden complexity or new dependencies?

A useful convention is to require the author to annotate any AI-assisted sections and explain the reasoning behind non-obvious generated code. This makes the review conversation more focused.

Designing the policy

Start by defining which checks run automatically and which require human eyes. High-confidence automated checks, such as critical security rules and type errors, can block merging. Lower-confidence or stylistic findings can be warnings. Human review should be mandatory for changes that touch authentication, authorisation, data handling, public APIs or deployment pipelines.

Measure the outcomes. Track review time, defect escape rate and rework rate for AI-assisted versus human-written changes. Use the data to refine where the line between automation and human review should sit.

A well-designed hybrid policy also helps with recruitment and retention. Developers want to use AI tools, but they do not want to be held responsible for code they did not fully author. Clear rules about who reviews what, and which checks are automated, reduce ambiguity and make AI adoption sustainable.

Related briefings

Keep reading.

More from the team

Longer thinking →

Briefings are short reads on the news. For Burt's own thinking, see the Journal.