Traditional code review no longer keeps pace with how much code teams are shipping. Risk-based code review is the response: instead of giving every pull request the same scrutiny, you route human attention by risk, letting low-risk changes ship with light or automated review and reserving deep human review for the changes that are expensive to get wrong.
AI-assisted development produces pull requests faster than reviewers can look at them closely, and queues have grown. A 2026 study found that as reviewers saw more AI-authored pull requests, their approval rate climbed from 30.1% to 36.8%, while the inline comments they left dropped 22% and the time a PR sat in the queue more than tripled. Reviewers don't have more hours in the day, so many are cutting corners: skimming instead of reading closely, approving anything that looks fine, and slowing down only when something looks obviously wrong.
Dr. Martin Nettling, Senior Director of Engineering at Tealium, offered a blunt diagnosis for why this happens on a recent Braintrust podcast. Asked which link in the delivery pipeline he trusts least, the coding agents or the humans driving them, he names the human. His reasoning: people are lazy in a way that's usually productive, and that's what drives them to automate the right things. But they sometimes overstep, automating work whose value came from the act of producing it rather than from the finished artifact. Writing a weekly status report forces someone to reflect on the week. A Jira ticket, written properly, makes two people confirm they understood a task the same way. Hand those jobs to AI and the report and the ticket still get generated, but the reflection and the shared understanding they existed to create never happen. Code review has the same trap: once AI produces the artifact, people stop scrutinizing it as hard as they would their own work.
Reviewer defect-detection has a hard ceiling that predates AI entirely. In the largest study of code review ever run, SmartBear analyzed 2,500 reviews across 3.2 million lines of code at Cisco and found that a reviewer's ability to catch defects drops sharply past 200 to 400 lines in one sitting, or faster than about 500 lines an hour, regardless of skill. AI now generates enough code, fast enough, to routinely push past that ceiling. Either the bar for what gets reviewed drops across the board, or teams get selective about where they spend that attention.
At Tealium, Dr. Nettling built a risk-based code review process. Use this guide as a starting point to build the same thing for your own team.
Separate the tool from the person
In the podcast, Dr. Nettling describes reviewing a pull request that an engineer had built almost entirely with AI, and the output was bad. He reacted the way many reviewers do: he came down hard on the engineer.
He later realized this was a mistake. He didn't distrust the engineer. He had low confidence in a specific tool, used a specific way, on this specific PR. Those are different problems, and conflating them turns every weak AI-generated PR into a judgement on someone's competence. The person deserves trust separate from the tool in their hand. Instead of asking "why did you ship this," the question shifts to, "show me how you used [this tool], so we can fix the prompt or the workflow."
Dr. Nettling suggests a rule: a second or third comment on the same pull request is a signal to stop typing. Call the person and review the code together. Written comments work for quick, low-stakes notes. A long or contentious thread calls for a conversation instead.
What to stop reviewing, what to always review
Formatting and whitespace are a linter's job, not a reviewer's, and have been since most teams stopped fighting about tabs versus spaces years ago. Purely mechanical changes, like a rename, a version-only library bump, or a refactor that moves code without changing what it does, can lean on the existing test suite as the safety net. If tests still pass and behavior hasn't changed, a human doesn't necessarily need to read every line.
Anything touching a hot path, anything security- or data-adjacent, anything meant to run for years rather than get deleted next quarter, still deserves real scrutiny. Dr. Nettling offers a concrete example: his team upgraded a library from one major version to the next, and a battery of load tests that took a week to run found the upgrade had cut performance in half. No agent caught it, because no agent was running a week-long load test. The team rolled the change back.
GitHub's required reviewer rule lets teams mandate extra review specifically for paths like authentication code, layered on top of standard ownership rules. Researchers have proposed formalizing the same idea. In a 2026 framework paper, Hartwig Grabowski ties review rigor to blast radius and reversibility: changes to public contracts and core invariants get a mandatory human gate before merge, additive changes proceed with asynchronous review, and purely internal, reversible refactors need no human gate at all. Both point at the same three things:
Size
Test coverage
How close a change sits to long-lived, hard-to-reverse code
Tealium encodes this with labels: any PR over 1,000 lines gets flagged, as does one touching a file with no tests or changing a database schema. Authors can clear a label by fixing what it flags: split the PR, add the tests, explain the migration. The same labels aggregate up to the project level: green means no one needs to look, yellow means someone should check in, red means stop and open the box. A reviewer can tell where attention is needed without opening every PR to find out.
Build a review policy that separates code by lifespan
A weekend project that gets deleted within a year doesn't need the same review as code that runs a bank for twenty.
At one end sits a repo behind a throwaway internal tool. At the other, a repo behind a core service, with a long expected lifespan and a wide blast radius if it breaks. Classify the repos that way and review rigor can follow: experimental code ships with light or automated review, and tier-zero code gets mandatory human review specifically on the dimensions that matter for that tier (security, performance, data integrity).
A review is a tool, a starting point for making sure the codebase stays filled with high-quality, trusted code.
How to tier your reviews
Use the table below as a starting point and adjust for the needs of your specific organization.
Human attention should primarily be directed at the bottom three change types, with the highest associated risk.
How the Cortex engineering team runs code reviews
At Cortex, the first pass has moved off humans entirely, while the review itself has stayed just as human-centered as it's always been.
Every pull request gets a first pass from an internal review bot. It isn't one generic "review this" prompt. The bot fans out to specialist reviewers, and each repo defines its own specialists as plain markdown files: their main backend repo has specialists for security, performance, testing and risk, and the query engine. When a repo has a known sharp edge, the people who know where it breaks write a specialist for it, and that file lives in version control right alongside the code.
Two design choices keep this from sliding into "just trust the bot."
The bot never approves a PR on its own. It can request changes, but a human is always the one who signs off. It's there to make human review better, not replace it.
Every review ends with a human-effort recommendation, minimal, low, medium, or high, surfaced right on the PR. Reviewers spend their attention where the label says it's warranted, and the easy PRs stop clogging the queue.
The same specialists run locally too. Because they're just files in the repo, a PR review loop skill runs every specialist against the diff inside Claude Code, in-session, fixing findings and looping until clean, before one final authoritative pass runs in CI. Most of the review cycle now happens in seconds at the engineer's desk instead of round trips through GitHub.
By the time a person opens the PR, the repetitive first pass is done, and the reviewer's attention goes to the question the bot can't answer: whether this is the right change to make at all.
Watch the video below to learn more about Cortex's code review bot.
Where to start
Pick your highest-blast-radius repo, where a bad merge costs the most.
Write one specialist for that repo's biggest known risk, as a plain file in the repo, and run it as an AI first pass. The engineer who knows where it fails should write it.
Have that pass end with a human-effort label, from minimal to high, so senior review concentrates on the risky changes.
Run that check locally, before CI, rather than after a push.
Add a specialist each time a repo surfaces a new failure. The first version doesn't need to be complete. It needs a human accountable for the merge. A bot can request changes, but it never approves.
Specialists catch risk inside a pull request. For the standards that apply to every service, production readiness, test coverage, clear ownership, Cortex Scorecards scores each service against rules you set and re-checks them as the code changes, so you can see where every team stands without chasing it down in spreadsheets.
Key takeaways
Reviewer defect detection collapses past 200 to 400 lines in one sitting, or about 500 lines an hour, and AI routinely generates code faster than that.
As reviewers see more AI-authored PRs, approval rates rise and inline comments fall, so uniform review risks turning into rubber-stamping.
Route human attention by blast radius and reversibility: apply light or automated review to low-risk changes, gate high-risk ones.
Classify repos by lifespan and enforce the line with existing tools like CODEOWNERS, required-reviewer rules, or PR-size labels.
Keep human attention on the one question AI can't answer: whether this is the right change to make.
Frequently asked questions
What is risk-based code review?
Risk-based code review routes reviewer attention by risk instead of applying the same scrutiny to every pull request. Low-risk changes like formatting or behavior-preserving refactors ship with light or automated review, while high-risk changes like security, data, or hot-path edits get a mandatory high-effort human gate. The goal is to spend limited human judgment where a missed defect is expensive.
How many lines of code can a reviewer effectively review at once?
SmartBear's study of 2,500 reviews at Cisco found defect detection is strongest at 200 to 400 lines per sitting and drops sharply past a rate of about 500 lines an hour. Beyond that, reviewers skim rather than read, so large pull requests are better split before review.
Should AI-generated code be reviewed differently from human-written code?
The review criteria stay the same, but the volume and the failure modes change. AI produces more code faster, which pushes reviewers past the defect-detection ceiling, and studies show approval rates climb while inline comments fall as reviewers see more agent-authored PRs. Routing that code through automated first-pass review and reserving human attention for high-risk changes keeps scrutiny where it matters.
Which code changes still require a human reviewer?
At Cortex, all PRs are still signed-off by a human reviewer. The difference is level of human-effort. Changes with high blast radius and low reversibility: anything touching authentication, data, or a hot path, plus schema changes and breaking changes to public contracts require high-human effort and often multiple human reviewers. Formatting, version-only bumps, and internal refactors covered by passing tests can lean on lighter human review.
Listen to the full Braintrust episode with Dr. Martin Nettling here.
