DEV Community: Anna

Claude Code email-sharing reports: 6 checks for what your coding agent sends out in 2026

Anna — Fri, 06 Nov 2026 20:47:44 +0000

A coding agent can leave a clean diff and an uncomfortable privacy question behind it. Getting agent-generated code merged sooner with fewer rollbacks matters, but a request carrying personal information to a website needs a different control from PR review.

I would separate those questions before trusting any coding agent with network access. For a high-velocity team, the practical starting point is small: know which identity the agent can reach, what it can send, and which boundary stops an unwanted request before execution.

The Claude Code privacy reports make that distinction unusually concrete. Reading them as proof that every request contains an email would overstate the evidence. Reading them as a problem that ordinary PR review automatically catches would miss the boundary entirely.

A reported privacy failure is not the same as a universal header

On November 5, a user opened Claude Code issue #107757, alleging that the tool disclosed their email in web-request User-Agent headers without permission. The reporter also attributed an increase in scam emails to that disclosure.

The report lists macOS and Claude Code 2.1.318. Other commenters describe similar concerns or tests of the safeguard. The reporter's exposure, the commenters' logs and any causal link between email-bearing requests and spam remain independently unverified here.

A later Hacker News comment from lydia_hallie, who says they work on Claude Code, acknowledges a mechanism: the account email was provided in model context, and the model sometimes inserted it into custom curl User-Agent headers as contact information.

The commenter says the email will be removed from that context in an upcoming release. An announced change is not a verified shipped fix. The same comment acknowledges that a built-in safeguard does not cover every case, including a script the agent writes and runs.

Custom requests versus the ordinary client header

In the surrounding HN discussion, eightysixfour posts a standard Claude Code header with no email. A normal client label and a custom header written for a particular task are different evidence.

A clean standard header does not disprove the reported custom-request behavior. Conversely, a custom request containing an address does not establish that the networking layer automatically attaches that address to every request.

The useful question is narrower: which information can a model place into a request it composes, and what requires approval before that request leaves?

Check which identity the agent can reach
Check every outbound route, including User-Agent
Check scripts as well as visible shell commands
Check the actual permission and network boundary
Check the version and the safeguard's documented limits
Check what the receiver and your evidence actually show

1. Check which identity the agent can reach

An account email in context is one source of identity. Repository history, author configuration, documentation and project files can supply others. Removing an account field may limit exposure without making the rest of the working environment anonymous.

I would inventory identity sources by category, not copy actual personal values into an audit ticket. A record can say "personal account identity available" or "repository author identity available" without creating another address list.

The distinction matters when a team uses separate work and personal identities. A request that legitimately needs an operator contact does not automatically need whichever address happens to be easiest for the model to find.

An approved public contact address is a policy choice. The agent should not substitute a personal address when that contact is unavailable. A destination's request for contact details is information about its access requirements, not permission from the user to disclose identity.

2. Check every outbound route, including User-Agent

User-Agent is a visible part of this report, but the privacy question is about the whole request. An address, project name or internal identifier can appear in a URL, another header, a request body or an uploaded file.

A synthetic request can illustrate the review without using anyone's identity:

Destination: approved.example
User-Agent: research-client/1.0
Query: public search terms only
Body: none
Attached files: none
Contact identity: absent unless explicitly approved

HTTPS protects a request in transit. The receiving service still receives the headers and other request data addressed to it. A sensitive value is not private from the destination because the connection is encrypted.

Project names deserve attention alongside email addresses. A generic client label and a label assembled from a confidential project title reveal different things, even when neither contains a personal address.

3. Check scripts as well as visible shell commands

A shell invocation can look harmless because the request lives elsewhere. Reviewing only python fetch.py says little about the headers, payload and file reads inside fetch.py.

The official privacy-mod README explicitly lists scripts, files and runtime-computed values among its limitations. A command-text check is not equivalent to following every value through the program that command launches.

For a proposed request, the relevant evidence includes the current script contents and the inputs the script will read. A previously approved script may behave differently after an edit or with a different environment.

Approval should describe the action actually under consideration. Permission to retrieve public documentation is not blanket permission to run any newly generated helper that happens to retrieve documentation too.

A trusted execution boundary should remain intact when a request is indirect. Moving the same data into a file or helper does not make the disclosure acceptable. An unexpected route is a reason to stop and inspect the request, not to search for a form the check misses.

4. Check the actual permission and network boundary

A rule written in prose expresses intent. A permission decision controls an action. Network isolation constrains which connections can occur. Each layer answers a different question, and calling all three "guardrails" can hide important gaps.

Anthropic's security documentation distinguishes command-text deny rules from sandbox network isolation. The documentation also separates permission modes: a classifier reviewing an action is not the same mechanism as a person approving that action.

A team should therefore know which mode is active and what an existing allow rule permits. An approval made earlier can affect later behavior; the presence of a permission system alone does not describe the effective policy.

For sensitive work, I would pair limited accessible data with enforced destination restrictions and narrowly scoped credentials. The exact implementation depends on the host and execution environment, so a generic checklist should not promise that one setting covers every tool.

5. Check the version and the safeguard's documented limits

In the issue, poteat describes cc-plugin-privacy as enabled by default in 2.1.317 and later. Some commenters report the safeguard missing or not refusing their tests. The comments are reports, not independently verified tests.

The official README describes a narrower check than a general personal-data filter. Certain shell tool inputs are refused when they contain the signed-in account address and name a User-Agent. The document describes text matching rather than parsing all possible request behavior.

The HN acknowledgement describes a check that asks before certain calls. The README says matching calls are refused without a prompt. I would preserve that difference rather than combine the descriptions into a broader protection claim.

The README also excludes web tools, addresses in other request locations, and several indirect forms. The document's own description is deliberately limited. A version containing the safeguard is not evidence that all outbound personal data is blocked.

Version, enabled configuration and documented coverage belong in the same record. A future release announcement should remain an announcement until the actual release and behavior have been checked.

6. Check what the receiver and your evidence actually show

A transcript can show a proposed command. A tool result can show that a command ran. Authorized destination logs may show a received request. None of those observations should silently stand in for the others.

A failed request can still be worth investigating, but an intended header does not prove a particular server stored it. Equally, a successful command does not establish which information a downstream service retained or later used.

For an authorized investigation, redacted local records and controlled destination logs are stronger than an agent's retrospective assurance. Real personal addresses and credentials do not belong in screenshots, public comments or a shared troubleshooting example.

The spam allegation needs a separate causal chain. An inbox change can motivate investigation without proving the source. The evidence reviewed here does not establish that the reporter's scam emails came from the reported headers.

Choose Qodo when outbound policy also needs enforceable code-review rules

Qodo, the AI code review platform, belongs on the committed-change side of this problem. Qodo's PR review can flag request-building code and configuration against team rules. An ad hoc research request may leave no PR diff at all.

Review before the PR helps bring feedback earlier. Cross-repo context, learning from the team and high-signal findings support the review of changes that span code and policy. None of those capabilities is a claim that Qodo observes every runtime request.

High-velocity teams get the rule files they already have, checked on every PR, with setup in minutes and no new process. Enterprise engineering teams get one rule set across many repos and agents. Both need separate runtime controls for data that can leave before a PR exists.

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, Qodo is best at reviewing committed request-building code against a team's privacy rules.

Keep privacy-sensitive decisions with a person

Review rules can make privacy expectations explicit: approved contact identities, allowed destinations and restrictions on uploading project files. Qodo's PR review checks committed changes against those rules on every PR; runtime enforcement remains separate.

A reviewer still needs to assess exceptions and evidence outside the diff. Cross-repo context can help connect a shared request helper with its callers, but an ad hoc request may never appear in committed code.

Qodo flags; your team decides. High-signal findings support a human review decision; outbound controls must act before sensitive data leaves the machine.

FAQ

Does Claude Code send my email to every website?

The sources reviewed do not establish universal behavior. The HN acknowledgement describes the model sometimes inserting context email into custom requests. The original user's exposure and spam allegations remain independently unverified here.

What does cc-plugin-privacy actually block?

The README describes certain shell inputs containing the account email and a User-Agent reference. The documented limits include indirect values and other request locations. A narrow check should not be described as a complete outbound privacy boundary.

Can a PR review detect data sent during an agent session?

A PR review can review committed code or attached evidence, not automatically reconstruct unrelated runtime traffic. Qodo's AI code review guide covers the review layer; outbound enforcement remains a separate responsibility.

Does an email-free User-Agent prove nothing sensitive left?

No. Another header, query, body or attachment may carry information. A clean header establishes only what was absent from that header in the request observed.

Has the reported behavior been linked to spam?

The original reporter makes that connection, but the reviewed evidence does not independently establish causation. Keeping the allegation separate from the acknowledged mechanism makes the privacy analysis more useful, not less serious.

How to Review AI-Generated Code in 2026: The 5 Decisions I Keep Human

Anna — Wed, 04 Nov 2026 18:57:47 +0000

Picture a team whose agents now read every line of every PR. Which parts of review should people still do by hand? My answer is five questions, none of them about typos, and everything else can go to a reviewer that runs earlier.

Here's why the five stay with people. Developers say about 47% of their code is now fully written by agents, a self-reported average from a survey of 15,000+ developers built from bucket midpoints (JetBrains Research, Aug 26, 2026).

Only 43% of developers are ready to fully delegate code review to AI, up from 33% a year earlier (JetBrains Research, Oct 19, 2026). The October results are reweighted and don't state a sample size, so read both numbers as direction, not precision.

The Five Decisions

Five decisions should stay with people:

Should this change exist at all?
Does it fit the architecture?
Is the risk acceptable?
Can it be undone?
Who says yes?

Teams whose agents open dozens of PRs a day need the same five decisions, made in minutes, not hours.

What the Numbers Say About How Much Code AI Writes

The gap between writing and reviewing is the story. Agents write nearly half the code, and fewer than half of developers would hand over the review.

In the August JetBrains data, about 38% of code is written with some AI help and about 27% fully by hand, alongside the 47% written by agents. The buckets are self-reported midpoints, so the shares add up to more than 100%.

The October JetBrains data shows readiness to delegate climbing for writing work between April-June 2025 and May-July 2026. Readiness to delegate application logic rose from 18% to 50%, test writing from 50% to 75%, and refactoring from 38% to 60%.

Review sits at 43%, and 54% aren't ready to delegate debugging. The same caveat applies, since the October results are reweighted and give no sample size.

Qodo, the AI code review platform, found the same pattern in its own survey. 25.8% of developers and 26.0% of engineering leaders name reviewing and validating AI code as the main constraint on delivery, according to the Qodo State of AI Code Quality 2026 (Censuswide, August 2026, self-reported).

Why Review Is the Step Developers Keep

Review is where someone answers for the change. My read is that the 57% who aren't ready to delegate review aren't simply wary of the tools, because the gap reflects who carries the outcome when a change goes wrong.

Reviewing AI code is also harder work. 36.4% of developers say reviewing takes the same time but more cognitive effort to spot hidden AI bugs, and 24.0% report lower trust in peer PRs because they don't know how much AI wrote, according to the same Qodo survey.

The system that writes the code shouldn't be the one that decides whether the code ships. People don't need to read every line, though, and human reviews were never the safest option on their own. Humans should keep the decisions, and hand the line-by-line reading to review that runs earlier.

Decision 1: Should This Change Exist at All?

No reviewer can tell you the feature was the wrong bet. AI review can summarize what changed and check the change against the linked ticket's stated intent, when the author or agent provides that context.

Scope, direction and taste stay human. One team at Anthropic that called its review bottleneck solved still kept human review for changes from outside the team, so someone asks "should we even do this?", according to the Claude Code team's Oct 15, 2026 post on solving code review (self-reported).

Every later decision assumes the change is worth making. For the basics behind the question, see what code review is and how AI changed it.

Decision 2: Does It Fit the Architecture?

Once a change is worth making, the next question is where the change lives. Architecture sits in people's heads and in other repos, so a diff alone rarely answers.

At PR review, cross-repo context can flag a change in one repo that breaks a consumer in another, and full codebase context beats diff-only review. AI can point at the conflict.

Whether the trade-off is worth it stays human. 38% of engineering leaders name keeping architecture consistent as one of their biggest quality and governance gaps, according to the same Qodo report, so the architecture fit call needs an owner who knows the system.

Decision 3: Is the Risk Acceptable?

Architecture fit leads straight to risk. AI can rank risk; only the owner can accept it.

AI review can put a severity on each finding and match review effort to the change. Qodo's default Auto mode, for example, picks a Fast, Balanced or Deep review for each PR. Route depth by blast radius, ownership and reversibility, so a config tweak and a payments change don't get the same pass.

Accepting a known risk on security, data exposure or compliance paths stays human. 28.7% of engineering leaders name security vulnerabilities or compliance issues as one of their biggest quality gaps, according to the same Qodo survey. A secure code review still needs a person who signs off.

Decision 4: Can It Be Undone?

Risk you can roll back is a different risk. Reversibility decides how much human attention a change deserves.

AI review can flag breaking changes, migrations and public-API edits so they don't hide inside a large PR. 19.0% of developers say PRs are now larger and harder to parse, which leads to review fatigue, according to the same Qodo survey.

Approving a one-way door, such as a schema migration, data deletion or a public contract change, stays human. A change you can revert in a minute can move on AI findings and a quick human glance. A change you can't revert deserves a slow, named review.

Picture a hypothetical PR where an agent renames a column in a migration. AI review flags that a reporting job still reads the old name, and the finding is right. A person still decides between a two-step rename, a backfill, or waiting until the job's owner signs off.

Decision 5: Who Says Yes?

Every decision above ends in approval, and approval is a person's name on the change. An agent's approval never counts as a person's, a rule the Claude Code team states in its Oct 15, 2026 post (self-reported).

Qodo keeps approval with people. Qodo flags; your team decides what blocks the merge, through branch protection and required reviewers.

CODEOWNERS files record who owns which path, so the right person says yes. The tool reports, and the owner approves.

How to Review AI-Generated Code So the Five Decisions Get Your Time

With the five decisions named, the rest of review should happen before a person opens the PR, which is how AI code review is meant to work. Move every mechanical catch earlier, so the human reads intent, not typos.

Let Review Before the PR Take the Mechanical Catches

Qodo's Agentic Toolbox lets a coding agent review its own local changes with the same engine as Qodo's PR review in your Git, through the CLI, the Codex and Claude Code plugins, or a Kiro Power.

Dave compares the tools for that step in Review Before the PR, so I'll stay on the human side here.

Let Learned Team Standards Carry the Repeat Calls

On GitHub, GitLab and Azure DevOps, Qodo's rules detection agent learns only from review comments developers accepted and acted on. For orgs that started with Qodo since Sep 1, 2026, mined rules are auto-approved by default, and rules whose findings are rarely fixed switch off automatically unless locked.

Record the Human Call

Dismiss reasons (False positive, Intentional, Fix later, Not specified) turn "ignored" into a recorded decision. The Previous reviews view shows each run, commit by commit, which is what governance and compliance teams ask for.

Developers get fewer, higher-signal findings and a recorded reason when they disagree. Leaders get standards the team owns, applied the same way on every PR. A separate reviewer matters here too, for the reasons in Qodo's post on why your coding agent shouldn't review its own code.

Choose Qodo When...

Choose Qodo when your team wants the agent to fix mechanical issues before a person opens the PR.

Choose Qodo when you want review standards learned from your own team's decisions.

Choose Qodo when you need every dismissal reason and review run on record in one place, whichever Git provider hosts the PR.

Both kinds of team get agent code merged sooner, with fewer rollbacks. Enterprise teams get one rule set across many repos and agents, reviews on five Git providers, single-tenant, on-prem and air-gapped options, and every finding logged and exportable.

High-velocity teams keep the rule files they already have, such as AGENTS.md and CLAUDE.md, and Qodo checks them on every PR, with setup measured in minutes and no new process.

Teams comparing the category can start with these AI code governance tools for enterprise teams.

Turn Each Human Decision Into the Next Rule

Every decision a person makes well once should become a standard the next review applies. Cache repeated judgment, so the system handles the repeat calls and senior engineers handle the new trade-offs.

The decisions that can't become rules are the five that stay human, starting with whether the change should exist at all. Track how long those five take with a few code review metrics leaders already watch.

Summary

Five decisions stay human. A person decides whether the change should exist, whether it fits the architecture, whether the risk is acceptable, whether it can be undone, and who says yes.

Everything else moves before the PR or into standards the team's own decisions taught the reviewer. The result is agent code merged sooner with fewer rollbacks, and a human part of review that stays small, fast and on record.

FAQ

How do you review AI-generated code?

Move mechanical checks before the PR, so a coding agent fixes them first. Keep the five human decisions for the PR, which cover whether the change should exist, architecture fit, risk, reversibility and approval.

What should a human still review in an AI-written PR?

A person should still own intent, architecture fit, accepted risk, one-way changes and the final approval. AI review can flag issues in all five areas, but each decision needs a named owner.

Can AI approve pull requests on its own?

AI review can recommend an approval, but an agent's approval shouldn't count as a person's. Most teams are better served keeping a named human approver. Qodo flags; your team decides what blocks the merge, through branch protection and required reviewers.

How much code is written by AI in 2026?

Developers say about 47% of their code is fully written by agents, according to JetBrains Research (Aug 26, 2026). The figure is self-reported, from an IDE vendor's survey, and built from bucket midpoints.

Is Qodo a test generation tool?

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, that makes it a strong fit for keeping the human review decision small, fast and on record.

AI Code Review ROI in 2026: The Pilot Math I'd Run Before Building Our Own Reviewer

Anna — Wed, 04 Nov 2026 18:52:02 +0000

Cloudflare's in-house AI reviewer averaged $1.19 a review in its first 30 days, according to the Cloudflare blog (April 2026). Picture a platform team showing that number to leadership. Somebody will ask why anyone would pay a vendor, and the fair answer starts with what the dollar leaves out.

So here's the math I'd run before either building or buying an AI code reviewer in 2026. You'll get a formula, a baseline to record, a sanity check against the published ROI models, and the build decision written out line by line.

TL;DR

Review is where the return is won or lost. 26.0% of engineering leaders name reviewing and validating AI-generated code as their primary delivery constraint (State of AI Code Quality 2026 from Qodo, the AI code review platform, August 2026).
Leaders can't show the return yet. 89% of executives say AI increases speed, but only 6% are sure they have clear examples of organization-wide AI ROI (Atlassian State of Teams 2026, April 2026).
The formula is short. Reviewer hours returned plus defects caught before merge, minus tool or build cost and triage time.
A dollar a review isn't the whole cost. Cloudflare's in-house reviewer averaged $1.19 a review, and someone still has to own prompts, evaluations and analytics (Cloudflare blog, April 2026).

Why the Return Shows Up at Review

AI output stalls in the review queue. A Harvard Business School working paper with Jellyfish data (January 2026, revised November 2026) found lines of code, commits and PRs all rose, while resolved Jira issues barely moved. The extra work piled up in review.

When review is the constraint, a tool that speeds up writing adds to the queue. A tool that makes review cheaper and better is where the return lands.

Leaders feel the gap, since 90.0% say they're confident reporting AI's impact to executives or the board, but only 45.0% can trace AI activity to code changes (Qodo, August 2026).

The Formula, in Three Steps

I write the formula out in words so nobody can hide a variable.

Add up the return. Reviewer hours returned at a loaded hourly cost, plus the value of defects caught before merge.
Add up the cost. Tool or build cost, plus the time people spend triaging findings, false positives included.
Subtract. Divide by the cost if leadership wants a percentage.

Record a Baseline Before Anyone Turns the Tool On

Pick two or three repositories that look like the rest of your codebase, and record three numbers for the month before the pilot.

Review wait. Measure the time from PR opened to first human review.
Time to merge. Measure the time from PR opened to merged.
Defects found after merge. Count bugs traced back to a recent PR, from incident tickets or reverts.

Skip the quiet internal tool with three PRs a month, and skip the one service everybody is afraid to touch. No clean pre-AI baseline? Use the month before the pilot anyway. Dave's list of code review metrics covers which numbers hold up as a baseline.

Count Findings People Act On

Comment counts make any reviewer look busy. What matters is how many findings led to a decision, and how many led to a code change.

A tool with lots of findings and few accepted ones is costing you triage time, and the formula should show that. If accepted findings climb over the pilot weeks, developers are learning to trust the reviewer. If dismissals climb instead, tune the rules before anyone presents a number.

Price Each Review From Billing Data

Take what you spent in a billing period and divide by the reviews run in that period. Now you have a cost per review you can compare with a reviewer's hourly cost.

Count re-reviews too. The average Cloudflare merge request got reviewed 2.7 times as engineers pushed fixes (Cloudflare blog, April 2026), so cost per PR can be a multiple of cost per review.

Sanity-Check Against the 2026 ROI Models

Most published ROI figures are worked examples, and I use them as a sense check, never a promise.

Usage outran throughput. AI usage rose 65% while median PR throughput rose about 8% across 400+ companies, and DX's 300% ROI example for a 200-person org rests on its own assumptions (DX, April-May 2026).
Payback comes after a dip. DORA's ROI report describes a J-curve, a planned dip driven partly by a verification tax, the time spent checking AI output, before payback within the first year (DORA, April 2026).

Both point the same way, because usage alone doesn't pay and quality and review time decide the return.

Build vs Buy: What the Dollar Leaves Out

Cloudflare's write-up is the most detailed public account of an in-house build. In its first 30 days, the system ran 131,246 reviews across 48,095 merge requests, with a median review time of 3 minutes 39 seconds and a median cost of $0.98 (Cloudflare blog, April 2026).

The first version was "exactly as noisy as you might expect," in the team's words. Fixing the noise took "What NOT to Flag" prompt sections, tiered models and a dedicated reviewer for AGENTS.md files. Even then, Cloudflare says its reviewers "regularly struggle with" architectural awareness and cross-system impact.

The Hidden Line Items

Duplicate findings. Multi-persona reviewers repeat themselves, and cutting the repeats takes engineering time.
Prompt and rule upkeep. Every new convention or false-positive pattern means a prompt change with an owner.
Model upgrades. A new model can change findings overnight, so each upgrade needs a regression check.
Evaluation. Without a labeled collection of real bugs, nobody knows whether the reviewer got better or worse.
Governance. Leaders will ask for analytics, audit trails and per-team rules, and a script becomes a platform.

A homegrown reviewer often runs on the same model as the coding agent, so the two can share blind spots, and a bug can slip past both.

When I'd Build

I'd build only when all three conditions hold, which are one Git provider and one CI system, a named team to own the reviewer, and needs that diff-level checks cover. Miss any of the three, and the hidden line items usually cost more than buying.

Choose Qodo When the Return Has to Be Traceable

Qodo ships the context, analytics and upkeep a build has to recreate. Qodo runs as a reviewer separate from the agents writing the code, so the checker brings its own context and rules instead of the writer's session.

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, that focus matters most when leadership wants a review return traced from accepted findings to cost per review.

Choose Qodo When Review Spans Several Repositories

Qodo reviews each PR with cross-repo context, using an indexed view of your repositories. Cross-repo findings flag a change that breaks code in a related repository, the exact gap Cloudflare names in its build.

Choose Qodo When You Want Rules Learned From Your Team

On GitHub, GitLab and Azure DevOps, Qodo's rules detection agent turns review comments developers accepted into rules. Review presets (Recall, Precision, Velocity, Automation and Customization) let each team pick its trade-off, and teams can still write their unique checks as repository skills.

Choose Qodo When Leadership Wants High-Signal Data

Qodo's code review analytics report PRs impacted, Accepted findings, High-severity acceptance rate and Median time to merge. Median time to merge has data from 29 September 2026 and isn't shown with a severity, category or type filter, so read it unfiltered.

The billing page shows Reviews this period, which gives you cost per review directly. Qodo flags; your team decides what changes and what merges.

Qodo can review before the PR as well, through the Agentic Toolbox, so many fixes land before a human opens the diff. Dave covers that step in Review Before the PR.

Who Gets What

Every team gets the same outcome, agent code merged sooner with fewer rollbacks.

Enterprise engineering teams get one rule set across many repos and agents, exportable findings and a cost per review finance can audit.
High-velocity teams keep the rule files they already have, and Qodo checks them on every PR, with setup measured in minutes and no prompts or eval suite to babysit.

The Pilot Sheet I'd Bring to the Budget Meeting

Export the findings. Export findings.csv from the analytics dashboard.
Count accepted findings. Filter Attribution status for implemented (the finding led to a code change).
Weight by severity. Use the Action level column, where action_required means high severity.
Add time to merge. Compare the dashboard median with your baseline.
Add the cost. Divide the period's spend by reviews run.

Accepted high-severity findings become defects caught before merge. A short survey of the pilot team supplies triage time, and the drop in time to merge supports reviewer hours returned.

Summary

AI code review ROI comes from the review step, so measure the review step. Record a baseline, count findings people act on, price each review from billing data, and write out every hidden line item before comparing a vendor invoice with a token bill.

Build when you have one platform, an owner and diff-level needs. Otherwise, buy the reviewer and spend your engineers on the checks unique to you.

FAQ

How do we measure ROI without a pre-AI baseline?

Use the month before the pilot. The comparison you need is a reviewer with the tool against a reviewer without it, and Qodo's analytics and billing page give you accepted findings and cost per review from week one.

What's a realistic payback period?

Nobody has a 2026 benchmark for AI code review payback. DORA's illustrative calculator shows payback within the first year after a planned dip, so plan your own from pilot data.

Should we build our own AI reviewer?

Build only with one platform, a team to own it and diff-level needs. Choose Qodo when review spans repositories or leadership needs a traceable return, because Qodo reviews with cross-repo context and carries the upkeep a build would own.

Which metric matters most?

The best metric is accepted findings weighted by severity. A finding that changed code and would have reached production is the clearest return, and Qodo reports the high-severity acceptance rate directly.

Is Qodo a test generation tool?

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, the ROI case is strongest on the review side, where accepted findings and cost per review are easy to trace.

AI Code Governance Policy for Copilot, Cursor and Claude Code in 2026: One Rule, Three Agents

Anna — Wed, 04 Nov 2026 18:46:29 +0000

88% of software teams now use more than one AI coding assistant, and only 30% have full governance over adoption and oversight, according to Black Duck's State of AI-Powered Software Development report (March 2026). Most teams are running several agents under policies written for one.

So what does an AI code governance policy look like when your team runs Copilot, Cursor and Claude Code at once? Here's the version I'd write today, built on the vendor controls you already pay for.

TL;DR

Your policy has to name one rule list. Copilot, Cursor and Claude Code each read their own instruction files, and each vendor's console manages its own agent's copy.
Most teams already run several agents. Teams run several agents, and few govern them fully (Black Duck, State of AI-Powered Software Development, March 2026).
Leaders can't see what agents changed. 38.3% of engineering leaders name visibility into what agents create or modify as a top governance gap (State of AI Code Quality 2026 from Qodo, the AI code review platform, Censuswide, August 2026, self-reported).
Put the policy check at the pull request. Qodo checks every agent's PR against one rule list. Qodo flags; your team decides.

The Refund Rule That Split Into Three

Picture a payments team with one rule, "refunds use Money, never floats." Somebody copies the rule into .github/copilot-instructions.md, a .cursor/rules/ file and CLAUDE.md.

Now picture someone, six weeks later, who edits the Cursor copy and forgets the other two. Each agent now writes refund code against its own version of the rule, and every admin panel stays green. Nobody can say which version of your standards a given PR met.

Per-agent controls are good at their own job. Copilot's policies and content exclusion shape Copilot, Cursor's admin dashboard shapes Cursor, and Claude Code's managed settings shape Claude Code. None of them owns the policy across all three.

Write the Policy as Three Decisions

Governance rollouts tend to stall when they start as a product purchase. Governance works better as three questions, asked in order.

Decision 1: Which Agents Are Approved

Approve the agents people already use, and make the approved path the easy one. About one developer in five uses AI coding tools their employer hasn't approved (BairesDev Q3 2026 Dev Barometer, September 2026). A ban only pushes that use out of sight.

Device management tools can inventory extensions and local agent sessions, and AI gateways can control model access and spend. Both stop short of the code, so neither shows which agent wrote the refund change.

Decision 2: Which Vendor Controls Are On

Turn on every vendor's admin controls, and write down where each one stops. Here's how I'd describe the three, neutrally.

GitHub Copilot Business and Enterprise. Admins get policies, content exclusion, audit logs and usage metrics for Copilot. Copilot code review can run on every PR through rulesets.
Cursor Enterprise admin controls. Admins manage Privacy Mode, model access, an MCP allowlist and Team Rules inside Cursor. Bugbot reviews PRs with Team Rules and BUGBOT.md, and skips .cursor/rules by default, loading those files only when BUGBOT.md links to them.
Claude Code managed settings. Admins decide permission rules and managed hooks on developer machines. Claude Code Review follows a base-branch REVIEW.md, as Dave covers in his post on REVIEW.md and agent standards.

Each reviewer here comes from the same vendor as one of the writing agents. For that agent's code, the reviewer can share the writer's assumptions, which is why the next decision matters.

Decision 3: Who Checks Every Agent's Code

Most policies skip the review decision, and the review decision is the only one that looks at the code. Only 41% of developers say virtually no AI-written code reaches production without a specific human review (BairesDev, September 2026).

Developers already lean toward an outside checker. For security flaws in AI-generated code, 56% prefer a separate AI agent dedicated to security, against 30% who'd let the generating model check its own work, according to the same Black Duck report.

What the Policy Needs From a Reviewer

I'd write five requirements into the policy, and test every tool against the refund rule.

Every agent at the PR. Approved or not, every agent's code lands in a pull request.
One scoped rule list. Rules come from the files agents already read, scoped to an org, repo or path.
Evidence per PR. Leaders see which rules each PR met, plus what the team fixed or dismissed and why.
The same rules before the agent writes. The refund change starts from the current rule.
Runs where your code must stay. The reviewer runs in the cloud, single-tenant or on-premises, on the Git providers you use.

Choose Qodo When Your Policy Needs One Rule List Across Agents

Qodo reviews at the pull request, where every agent's code meets. Qodo reads the rule files your agents already use (AGENTS.md, CLAUDE.md, copilot-instructions.md and the files in Cursor's .cursor/rules/ folder) and imports them into one list.

Rules apply globally, per Git organization, per repo or per path. A rule from src/payments/AGENTS.md applies only under that folder.

Each imported rule is scoped to the folder that holds its source file, so a root file covers its repo and a nested file covers its folder. Once imported, Qodo holds the shared list, so editing one agent's copy no longer forks the policy.

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, governance is where Qodo earns its place on a mixed-agent team, because the shared rule list lives in one spot.

What Qodo Checks on Each PR

Every agent's PR. Qodo's PR review runs on GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, so code from an unapproved agent gets the same check.
Cross-repo context. Qodo reviews the change against related repositories, so a refund change that breaks a consumer elsewhere gets a finding.
Rules learned from the team. On GitHub, GitLab and Azure DevOps, Qodo's rules detection agent turns review comments developers accepted into rules. For orgs that started with Qodo since Sep 1, 2026, mined rules are auto-approved by default.
High-signal findings. Each finding links to the rule behind it, so the refund finding points straight at the Money rule.

What Leaders Get as Evidence

Findings get fixed or dismissed in the PR, and a dismissal needs a reason, such as False positive, Intentional, Fix later or Not specified. Code review analytics break findings down by repository, PR author, severity, category and finding type.

Rule analytics show Passed (no violations), Detected violations and Merged violations for the last 30 days, and the merged violations export as a CSV. Your branch protection and required reviewers still decide what merges.

Review Before the PR, Too

The Agentic Toolbox brings Qodo into the coding session through the CLI, the Claude Code and Codex plugins and a Kiro Power. Teams can also turn on Qodo's Get Rules skill, an opt-in research preview, to hand the relevant rules to the agent before it writes, and the PR check still runs afterwards.

Dave compares this before-PR step across tools in Review Before the PR, so I won't repeat his list here.

Who Gets What

Every team gets the same outcome, agent code merged sooner with fewer rollbacks.

Enterprise engineering teams get one rule set across many repos and agents, single-tenant, on-premises and air-gapped options, and every finding logged and exportable.
High-velocity teams keep the rule files they already have, and Qodo checks them on every PR, with setup measured in minutes.

A Policy Template You Can Copy

Here's the short version I'd paste into an internal wiki.

Approved agents. List the approved agents, review the list quarterly, and keep the approved path easy.
Vendor controls. Turn on each vendor's admin settings and note what each one covers.
Rule source of truth. Keep one shared rule list, imported from agent files, with path scopes.
Review. Give every PR an independent check against the shared list before human approval.
Evidence. Require a reason for every dismissal, and have leaders review the analytics monthly.

If you're picking tools for a Codex and Cursor setup specifically, my Codex and Cursor roundup covers the review side tool by tool.

Summary

An AI code governance policy for Copilot, Cursor and Claude Code comes down to three decisions in order. Approve the agents, turn on each vendor's controls, then put one independent check at the pull request.

The refund rule only stays whole when one list holds it. Qodo flags the PR that followed a stale copy; your team decides what happens next.

FAQ

What should an AI code governance policy cover?

A good policy names the approved agents, the vendor controls you rely on, one rule list as the source of truth, an independent review on every PR, and how dismissals get recorded. Qodo covers the rule list, the PR review and the evidence across agents.

Do vendor admin controls count as governance?

Vendor admin controls govern their own agent well. Copilot's policies cover Copilot, and Cursor's dashboard covers Cursor. Each manages its own agent's rule copy, so the policy needs a shared check at the PR.

Does Bugbot read .cursor/rules?

Bugbot skips .cursor/rules by default and loads them only when BUGBOT.md links them. Qodo reads the files in .cursor/rules/ when it imports rules into its shared list.

Can coding agents follow the same rules the review checks?

Coding agents can follow the same rules when both draw on one list. Qodo's opt-in Get Rules skill, in research preview, loads the shared rules into a coding agent through the Agentic Toolbox, and Qodo's PR review checks the result.

Is Qodo a test generation tool?

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, the governance side is what mixed-agent teams need most, since the shared rule list and per-PR evidence live in one place.

Best AI Code Review Tools for Teams Using Codex and Cursor in 2026

Anna — Tue, 03 Nov 2026 17:23:27 +0000

When a team's agents write most of the code, the review step decides how soon the team merges. Codex code review and Cursor Bugbot now review the output of the tools that wrote it, so a team running both agents ends up with two reviewers and two rule files.

OpenAI rebuilt its own Git backend, Pando, after Codex-driven pushes, merges and fetches pushed monorepo reliability at times below 90%. One engineer designed the architecture of Pando, and teams of agents implemented it, taking Pando from kick-off to production in 10 weeks, according to OpenAI's Nov 2, 2026 post on scaling Git at OpenAI.

At that volume, review becomes the next bottleneck. 25.8% of developers name reviewing and validating AI-generated code as their primary delivery constraint, according to the Qodo State of AI Code Quality 2026 (Censuswide, 500 US developers and 300 US leaders, August 2026, self-reported).

What This Guide Covers

Teams that run Codex and Cursor side by side see pull requests from both land in the same repos every day. Here is what this guide covers, in order:

How Codex code review works, locally and on GitHub
How Cursor code review works, before push and on the PR
A side-by-side table of four reviewers
The rule-file split between AGENTS.md and BUGBOT.md
What an outside reviewer adds for a mixed-agent team
How to test reviewers on your own PRs

High-velocity teams feel the split first, because the Codex half and the Cursor half each get a different reviewer. Engineering orgs with both agents across many teams and repos feel it later and harder, because every repo grows its own copy of the review standards.

TL;DR: Which AI Code Review Tool Fits a Team Using Codex and Cursor

Each bundled reviewer is strongest for the developers inside its own tool. An outside reviewer is the one that reads every PR from the whole team the same way. For the basics, see how AI code review works.

Codex code review runs /review in your checkout and @codex review on GitHub pull requests, with rules in AGENTS.md and a P0 and P1 focus on GitHub.

Cursor code review splits into Agent Review and /review-bugbot before you push, then Bugbot on every PR update, with rules in BUGBOT.md.

GitHub Copilot code review reviews in GitHub and in the major editors, with rules in Copilot's instruction files and AGENTS.md.

Qodo, the AI code review platform, is the independent review layer on every PR in your Git, whichever agent wrote the change, and Qodo's Agentic Toolbox runs the same review inside Codex before the PR exists. At OpenAI's volume, one standard across both agents matters more than a second opinion from the same tool.

How Codex Code Review Works

Codex reviews in two places with the same reviewer, in the terminal and on the PR, so the Codex half of a team gets one standard throughout.

Local Review With `/review`

Codex's built-in /review command reviews the changes in your Git checkout. In the CLI, you can review against a base branch, review uncommitted changes (staged, unstaged and untracked files), review a commit, or give custom review instructions.

The app and IDE extension support the base-branch and uncommitted scopes. Codex reports prioritized findings without changing your working tree.

The command appears only when the project sits inside a Git repository. Findings show up as inline comments in the review pane, and if you ask Codex to apply the fixes, your normal sandbox and approval settings apply.

PR Review With `@codex review`

On GitHub, a developer mentions @codex review in a PR comment, or the team turns on automatic reviews per repository. Codex posts a standard GitHub review, and on GitHub it flags only P0 and P1 issues, so comments stay on high-priority risks. GitLab merge request support is in preview.

# In your Codex session, inside a Git repo
/review
> Review against a base branch: main

# On a GitHub pull request
@codex review
@codex review for issues in the database migration

A tight P0 and P1 focus keeps noise down on the PR. One reviewer in the terminal and on the PR keeps the Codex half of the team on one standard.

After a review, a developer comments @codex fix the P1 issue, and Codex starts a cloud chat with the PR as context and can push a fix back to the branch when it has permission. Finding and fix both stay inside Codex.

Writing Code Review Rules in AGENTS.md

Codex searches the repo for AGENTS.md files and follows the code review rules in a ## Code Review Rules section. Root rules apply everywhere, and a nested AGENTS.md adds rules for the service below it, so each changed file carries only the guidance that covers it.

Keep the rules short. Start with two or three rules, state the safe path for each, and leave mechanical checks in CI, as OpenAI's Codex docs advise. Review rules don't replace tests, branch protections or required approvals, the same docs add.

The rules question gets harder once Cursor joins the repo.

How Cursor Code Review Works: Agent Review Before Push, Bugbot on the PR

Cursor splits review into a local layer and a PR layer that share one rules file, so the Cursor half of the team works from BUGBOT.md.

Agent Review and `/review-bugbot` Before You Push

Cursor Agent Review reviews local changes inside Cursor, at Quick or Deep depth. The /review-bugbot skill runs Bugbot from the agent before you push, and by default reviews every change on the branch against the base branch, committed and uncommitted. /review-bugbot runs in Cursor 3.7 or later, at cursor.com/agents, and in the Cursor CLI.

Local Bugbot reviews stay in sync with the PR. Cursor stores the patch ID of the reviewed diff, and when Bugbot on GitHub, GitLab or Bitbucket sees the same diff in a PR, Bugbot skips the repeat review and says so in a comment.

Bugbot on Every PR Update

Bugbot reviews automatically on every PR update, or on demand when someone comments cursor review or bugbot run. Bugbot reads existing top-level and inline PR comments to avoid repeating feedback, and each finding comes with Fix in Cursor and Fix in Web links. By default, follow-up runs review only the changes since the previous review.

Bugbot connects to GitHub (including Enterprise Server), GitLab (including self-hosted), Bitbucket (including Data Center), Azure DevOps Services and Cursor's own Origin. The Bugbot check concludes neutral by default when findings exist, and fails only when a team configures fail-on-unresolved.

Cursor Bugbot Rules in BUGBOT.md

Cursor Bugbot rules come from four places, merged in order: Team Rules from the dashboard, project .cursor/BUGBOT.md files (nested files apply to the folders below them), learned rules and manual rules. Bugbot learns from merged or closed PRs, and @cursor remember adds a learned rule inline.

Project rules in .cursor/rules/*.mdc don't apply to Bugbot runs, as Cursor's Bugbot docs state. A rule a developer wrote for Cursor's coding agent doesn't reach Cursor's reviewer unless someone copies it into BUGBOT.md.

Codex Code Review vs Cursor Bugbot vs Copilot: Side by Side

For a team, the three bundled reviewers differ most on where rules live and which Git platforms they cover. Here is each on the same rows, with Qodo as the fourth column.

	Codex code review	Cursor Bugbot	GitHub Copilot code review	Qodo
Trigger on PR	`@codex review`, automatic reviews	Every PR update; `cursor review`, `bugbot run`	Automatic per user, repo or org; manual request	Automatic on PR open; `/agentic_review`
Local review	`/review` in Codex	Agent Review, `/review-bugbot`	VS Code, Visual Studio, Xcode, JetBrains IDEs	Agentic Toolbox: CLI `qodo review`, plugins for Codex and Claude Code, a Kiro Power, MCP
Rule file	AGENTS.md `## Code Review Rules`	`.cursor/BUGBOT.md`, Team Rules, learned rules	`.github/copilot-instructions.md`, `*.instructions.md`, AGENTS.md	Imported repo files (AGENTS.md, CLAUDE.md, copilot-instructions.md, `.cursor/rules`), plus learned rules
Git platforms	GitHub; GitLab in preview	GitHub, GitLab, Bitbucket, Azure DevOps Services, Origin	GitHub; Azure DevOps in public preview	GitHub, GitLab, Bitbucket, Azure DevOps, Gerrit
Fix loop	`@codex fix`	Fix in Cursor, Fix in Web, Autofix	Suggested changes; hand-off to Copilot cloud agent (public preview)	Follow-up reviews focus on your latest fixes
CI or merge status	Standard GitHub review	Check is neutral by default; fails if configured	Comment review by default; approvals off by default	Advisory findings; your team decides what blocks the merge
Effort levels	`review_model` setting (CLI); GitHub reviews flag P0 and P1 only	Low, Default, High, Smart	Lite, Balanced (default), Max (public preview)	Auto (default) picks Fast, Balanced or Deep
Pricing model	Included in ChatGPT Plus, Pro, Business and Enterprise; GitHub reviews count as Code Review usage	Usage-based	AI credits per review	Pro Team credit packs; Enterprise plans

Two vendor caveats support layering. Copilot won't spot every problem and its feedback should be supplemented with human review, as GitHub's Copilot docs note, and Codex review rules don't replace tests or required approvals, according to OpenAI's docs. For more on Copilot's reviewer, see this glossary entry on GitHub Copilot code review.

One Rulebook for a Team on Both Agents: AGENTS.md, BUGBOT.md and a Shared Review Layer

The rule file one half of the team wrote for its reviewer is invisible to the other half's reviewer.

Where Each Reviewer Reads Its Rules

Codex reads review rules from the ## Code Review Rules section of AGENTS.md. Bugbot reads BUGBOT.md and skips .cursor/rules by default. Copilot reads copilot-instructions.md, *.instructions.md and AGENTS.md. A team with both agents ends up with two or three rule files per repo, and the copies drift apart.

Take one illustrative rule, "money values never use floats". The Codex half writes the rule into AGENTS.md, the Cursor half writes the rule into BUGBOT.md, and three months later only one copy covers the new refunds service. Both reviewers pass their own PRs, and the team's standard now depends on which agent opened the PR.

How Qodo Reads the Same Rule Files

Qodo imports rules from repo files such as AGENTS.md, CLAUDE.md, copilot-instructions.md and the .cursor/rules files that Bugbot skips by default.

Since Qodo 3.2, teams choose which files and folders count as rule sources. Qodo's rules detection agent adds rules learned from review comments the team accepted and acted on, so the standards grow from your own decisions.

Qodo's rules detection agent learns only from accepted comments that led to code changes, on GitHub, GitLab and Azure DevOps. Admins choose whether mined rules wait for approval. Enterprise teams get one rulebook scoped by folder and applied across Git organizations, instead of one file per agent per repo.

A Practical Split for Mixed Teams

One practical split keeps shared standards in AGENTS.md and Bugbot-only notes in BUGBOT.md. Codex and Copilot both read AGENTS.md, so the shared file covers two of the three reviewers. For the wider idea, see this glossary entry on AGENTS.md files.

Writing the rules well matters as much as where they live. A rule that names the safe path and the reason holds up across reviewers, and this guide to custom review rules covers the patterns that work.

Why the Reviewer Should Sit Outside the Tool That Wrote the Code

A reviewer bundled into the writing tool shares its context, and sometimes its blind spots. An outside reviewer reads every PR from the team the same way, whichever agent wrote it.

Same Tool, Same Assumptions

A second agent called "reviewer" can share the first agent's wrong assumption about the ticket. The system that generates code shouldn't decide whether the code ships, and you shouldn't review code with the same tool that wrote it. For the longer argument, see the case for an independent verification layer.

For the Developers on Codex: Qodo's Agentic Toolbox Inside Codex

Qodo's Agentic Toolbox runs the same review locally, through the CLI, as a plugin for Codex and Claude Code, as a Kiro Power, or through MCP. Qodo retired its IDE plugin on Nov 1, so local review now runs through the Agentic Toolbox.

Inside Codex, the Reviewer skill in Qodo's Agentic Toolbox reviews the agent's local changes with the same engine that will review the PR in your Git.

Installing Qodo's Codex plugin takes four steps:

Open ChatGPT on Desktop and select Codex.
Click Plugins in the left navigation bar.
Type Qodo in the search field.
Click + next to Qodo to install the plugin.

After installing, add Qodo's default instructions template to AGENTS.md, so Codex knows when to call the review. Developers who prefer the terminal can install the Agentic Toolbox with curl -fsSL https://get.qodo.ai | sh (Node.js 20+) and run qodo review.

Qodo's local review works on uncommitted and untracked changes, and only the base commit has to be on your Git provider.

For the Developers on Cursor: Qodo in Your Git

Whatever editor or agent wrote the change, Qodo reviews the pull request in GitHub, GitLab, Bitbucket, Azure DevOps or Gerrit. The Cursor half of the team needs nothing new in the editor, because the review runs where the PR lives.

What Qodo's PR Review Reads

Qodo's PR review reads cross-repo context, so a change in one repo that breaks a consumer in another repo gets flagged at PR review. PR history shows how the team handled similar findings before. Since Qodo 3.2, follow-up reviews focus on your latest fixes, and the first review of a PR is never narrowed.

Context is where AI review still falls short for many teams. 38% of engineering leaders name keeping architecture consistent as one of their biggest quality and governance gaps, according to the same Qodo report. Qodo flags; your team decides what blocks the merge.

Choose Qodo When Your Team Runs Codex and Cursor Side by Side

A team with two agents often has two rule files, and its PRs look fine inside each tool. Qodo gives every PR one standard and one reviewer.

Signs Qodo Is the Right Pick

Choose Qodo when your team runs Codex and Cursor side by side and wants one independent reviewer on every PR.

Choose Qodo when you want your Codex developers' agents to check their changes with the same engine that will review the PR, before the PR exists.

Choose Qodo when a change in one repo can break another and you want that break flagged at PR review.

Choose Qodo when you want rules learned from your own team's accepted review comments, and fewer, higher-signal findings for everyone on the team.

What Each Kind of Team Gets

Both kinds of team get agent code merged sooner, with fewer rollbacks. High-velocity teams keep the rule files they already have, AGENTS.md for Codex and .cursor/rules for Cursor, and Qodo checks them on every PR, with setup measured in minutes and no new process.

Enterprise teams get one rulebook across many repos and both agents, reviews on GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, single-tenant, on-prem and air-gapped options, and every finding logged and exportable. For more options, see these enterprise code review tools.

Qodo fits teams that need one independent review layer across Codex, Cursor and the five Git providers Qodo supports, because Qodo reviews the code both agents write against one rulebook, before the PR and on the PR. For the GitHub and GitLab view, see this list of agentic AI code reviewers.

How Your Team Can Test AI Code Reviewers on Its Own PRs

A team should count fixed findings, not comments. A reviewer that leaves 40 comments and gets two fixed costs more attention than a reviewer that leaves five and gets four fixed.

A Five-Step Test

Pick 10 to 20 recent merged PRs from both Codex and Cursor developers, each with a known follow-up fix.
Run each reviewer on the same PRs at a comparable effort level.
Record findings a person would act on, findings the team would dismiss, and misses.
Compare noise per PR across the reviewers.
Check where each reviewer reads its rules, and whether one rule change reaches all of them.

Keep the Test Fair

Qodo's fix loop optimization narrows follow-up reviews to your latest fixes. If you benchmark for maximum recall, Qodo's docs suggest switching the optimization off. Benchmarks are easy to misread, and this breakdown of AI review benchmarks shows what false-positive numbers do and don't mean.

Edge cases deserve their own column in the test.

36.4% of developers say reviewing AI-generated code now takes more cognitive effort to spot hidden AI bugs, according to the same Qodo survey, so seed a few PRs where the follow-up fix was an edge case. For how a review loop should end, see my notes on an agentic review loop.

Summary

Codex reviews locally with /review and on GitHub with @codex review, reading rules from AGENTS.md. Cursor splits review into Agent Review before push and Bugbot on the PR, reading rules from BUGBOT.md.

Copilot reviews in GitHub and the editor. Rule files don't carry across a mixed-agent team, so an outside reviewer gives every PR from the team the same standards. One reviewer and one rulebook on every PR means agent code from both halves of the team merges sooner, with fewer rollbacks.

For the basics behind all four tools, start with what code review is.

For a wider shortlist beyond Codex and Cursor, see these code review tools for enterprise teams.

FAQ

What does Codex `/review` check?

In the CLI, Codex's /review checks the changes in your Git checkout against a base branch, your uncommitted changes, a single commit, or custom instructions. Codex reports prioritized findings without changing your working tree.

Is Cursor Bugbot free?

Bugbot bills by usage, under Cursor's May 2026 pricing update. Individual accounts draw first on included usage, then on prepaid credit, while teams bill from prepaid credit, and Cursor's pricing page lists current rates.

What's the difference between Bugbot and Agent Review?

Agent Review is a local review inside Cursor, at Quick or Deep depth. Bugbot reviews pull requests on every update and posts a CI status, and /review-bugbot runs the same Bugbot review from the agent before you push.

Can Codex review GitLab merge requests?

GitLab merge request support in Codex code review is in preview. GitHub pull request review is generally available.

Does Qodo work with Cursor?

Qodo reviews the pull request in GitHub, GitLab, Bitbucket, Azure DevOps or Gerrit, whatever editor or agent wrote the change. The Cursor half of a team gets Qodo's review on every PR with nothing new to install in the editor.

Can one team use Codex and Cursor with the same review rules?

Keep shared standards in AGENTS.md, which Codex and Copilot both read, and Bugbot-only notes in BUGBOT.md. Then add one outside reviewer on the PR that imports the repo's rule files, so every PR meets the same standard.

Is Qodo a test generation tool?

Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, that makes it a strong fit for teams running Codex and Cursor side by side who want one independent reviewer on every pull request.

How AI Code Review Speeds Up Developer Onboarding and Learning

Anna — Wed, 28 Oct 2026 22:01:45 +0000

New hires learn most of a codebase from PR comments, and the seniors writing them are often a time zone away and repeat conventions nobody wrote down. I've sat on both sides of that review. AI code review that knows your rules shortens onboarding, as long as juniors keep thinking for themselves.

TL;DR

Most onboarding happens in PR comments. New hires learn conventions from PR comments, and most early-career engineers in a 2026 survey already use LLMs daily (arXiv 2609.27973, August 2026), so the question is whether their AI knows your codebase.
Diff-only review teaches the wrong lesson. A new developer's real gap is project context, and a reviewer that only sees changed lines can't fill it.
Unwritten conventions need a source. A reviewer that learns rules from your existing code and PR history can explain the conventions nobody documented.
Qodo is my pick because it explains each finding against your own codebase and rules. New developers learn your conventions on their first PRs and can ask Qodo why. Pick it when new hires join a codebase full of conventions nobody wrote down.
Juniors still have to think. AI review helps learning when juniors verify and ask for explanations, and hurts it when they click accept.

Why Code Review Is Where Developer Onboarding Really Happens

Most onboarding docs cover the setup steps. They tell you how to clone the repo, run the tests and get access to staging. They rarely tell you why the payments service retries the way it does, or which helper the team uses instead of the obvious library.

New developers learn that from PR comments. A senior writes "we don't call the database from handlers here, use the repository layer," and the newcomer learns a rule that lives in no document. Multiply that by every PR in the first month and you've described most of the actual onboarding.

Seniors carry the mentoring load on top of their own work. Every hour a senior spends explaining naming rules is an hour they don't spend on design.

Case study: LoopUp's senior engineers spent a large share of their time on PR review and mentoring before they added AI review (Qodo case study, April 2026).

Distributed teams feel slow review more, because a reviewer six hours away turns every round of comments into a day and a first PR into a week-long wait. Qodo's roundup of the best code review tools for distributed teams covers tools built for that gap.

New developers already learn with AI tools, and most early-career software engineers in a small survey use LLMs daily (arXiv 2609.27973, August 2026). Many developers picked up a new skill or language this year, and many of those learners used AI tools to do it (Stack Overflow Developer Survey, October 2026).

For onboarding, what matters is whether the AI a new developer uses knows anything about your codebase, and that comes down to context.

Full Codebase Context vs Diff-Only Review: Why It Decides What a New Developer Learns

A diff shows the line that changed. The convention that line breaks usually lives somewhere else: in a shared helper, in a sibling service, or in a pattern the team settled on two years ago.

A diff-only reviewer can tell a new developer that a function is long or that a variable name is unclear. The same reviewer can't tell them that the team already has a retry helper in the platform package, because the helper isn't in the diff.

The glossary page on full codebase context walks through the difference in more detail.

What a New Developer Learns From Each Reviewer

What the new developer needs	Diff-only reviewer	Reviewer with full codebase context
Is this line correct?	Yes, within the diff	Yes
Does a helper for this already exist?	Can't see other files	Points to the existing helper
Does this match how the team does it?	Generic best practice	The team's own rules and past PRs
What else does this change touch?	Can't see callers	Related files and services
Why does the convention exist?	No source to explain from	Links the finding to the rule or code it came from

The gap matters more in a large monolithic architecture, where one module quietly depends on five others. A new developer can't see those links yet, and a reviewer that can't see them either just confirms the newcomer's blind spot.

For a new hire, almost every line is code they didn't write, which makes understanding it the whole job in week one. A context engine closes that gap by indexing the whole codebase, so the reviewer sees the links the newcomer can't.

Teams that build their own reviewers run into the same wall. Cloudflare's in-house reviewers see the diff and surrounding code but "regularly struggle with" architectural awareness and cross-system impact (Cloudflare blog, April 2026).

Codebase Onboarding: Learning Conventions Nobody Wrote Down

Every team has conventions that live only in senior engineers' heads, and the hard question for any reviewer is how it learns those implicit patterns and which existing code counts as the right example.

Where the Rules Come From

Qodo builds its Review Standards from your codebase, your pull request history and your requirements, and once rules are turned on, every review agent applies them first. Rules come into Qodo three ways.

Manual rules. A lead describes a rule in plain language in the portal, and Qodo turns it into a rule.
File-based rules. Qodo imports rules from AGENTS.md, CLAUDE.md and other supported files, automatically on push.
Rule Miner. Qodo finds recurring review patterns in your PR history and turns them into rules. Rule Miner works on GitHub, GitLab and Azure DevOps, in multi-tenant and single-tenant deployments.

Depending on configuration, mined rules either go live or wait in a Pending tab for a lead to approve, and mined rules go live by default for organizations that started using Qodo since September 1, 2026.

Here's the kind of rule I mean. Say the team logs everything through a shared logger with request IDs, and nobody ever wrote that down. A new developer adds a print statement for debugging and forgets to remove it.

With the rule in place, Qodo's finding tells the new developer that the team uses structured logging through the shared logger, why request IDs matter for tracing, and which call to use instead. The senior doesn't have to type that comment for the fifth time this quarter.

Team insight findings come from a team profile that reviews the pull request the way the most relevant teammates would. For a new developer, team insight findings are the closest thing to having the right senior read the PR before the senior actually does.

How Qodo Speeds Up Ramp-Up Time on Every PR

Ramp-up time is mostly the time a new developer spends finding context. Qodo shortens that search at a few points in the PR loop, and each point lines up with a question new developers ask.

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for teams that want every new developer's PR reviewed against the conventions nobody wrote down.

PR summaries come first. The /agentic_describe command generates a structured summary of a pull request, so a new developer reviewing a teammate's PR can read what changed before reading the code.

Findings come next. Every finding states what needs attention, why it matters and how to fix it, ranked by severity. The "why it matters" part is the onboarding part, because it turns a correction into a lesson.

New developers often don't ask questions because they don't want to bother anyone. Qodo's PR chat lets them ask Qodo to explain a finding or answer a question about the PR, right in the PR thread, without waiting for a senior.

For bigger questions, Codebase Wisdom in the Agentic Toolbox answers questions grounded in your organization's code, repository relationships and PR history. Onboarding to a new codebase is a listed use case, with example questions like "Explain the payments architecture" and "Where should I start if I'm working on authentication?"

Codebase Wisdom runs through the CLI, MCP, and plugins for Claude Code, Codex and Kiro Power. Qodo's glossary page on Claude Code plugins covers how an agent loads tools like Codebase Wisdom. New developers can use the one that matches their editor and agent.

Qodo's IDE plugin for VS Code, JetBrains IDEs and Visual Studio was retired on November 1, 2026, so new developers bring Qodo into their editor through the Agentic Toolbox instead. Qodo's pull request review isn't affected.

The Software Map gives a live view of the system across repositories, with dependencies, service relationships and contracts mapped automatically. For a new hire, a map like that beats a wiki diagram that someone drew last year.

Leads see patterns, not people's mistakes. Qodo's analytics break findings down by repository, PR author, severity, category and finding type, and rule analytics show which rules fire most often.

A lead can spot the finding types that come up most in each new hire's PRs, then pair the new hire with the right senior for an hour instead of repeating the same comment across ten PRs.

Qodo is advisory throughout. Qodo comments on the PR, and the new developer and their human reviewer decide what to change and when to merge.

Hands-On: A New Developer's First Week With Qodo

Here's the first week I'd hand a new hire, built from Qodo's setup guides. Your team's version will differ, but the order holds up.

Day One: Install the Toolbox

The Agentic Toolbox needs Node.js 20 or later. On macOS or Linux, install it and list the tools you have access to:

curl -fsSL https://get.qodo.ai | sh
qodo tools

On-prem teams get their own install command from the Home page in the Qodo portal. Once the tools are installed, the coding agent can call them as part of its workflow, and the new developer just asks questions in plain language.

Days Two and Three: Ask Before Touching Code

Before the first ticket, the new developer asks the agent how the module they'll work on fits into the system. Good first questions are "How are these repositories connected?" and "Which services depend on the billing API?" The answers come from your code and PR history, so the newcomer reads real examples, not generic tutorials.

Days Four and Five: The First PR

The first PR goes up, and Qodo reviews it. The new developer reads each finding, asks Qodo to explain anything unclear, and fixes what makes sense. The senior reviews after that, and spends their comments on the design question, not the logging rule.

Weeks Two to Four: From Findings to Habits

Over the next few weeks, the same findings should come up less often for the same person. If they keep coming up, that's a coaching conversation for the lead, and the analytics show which finding types to talk about.

Keeping Onboarding Docs Honest

Stale docs mislead new hires and AI agents in the same way. Both read the README and AGENTS.md first, and both trust what they find there.

Cloudflare's in-house review system includes a reviewer that checks whether a repo's AGENTS.md is still up to date, because those files go stale quickly (Cloudflare blog, April 2026). In Cloudflare's example, a team migrates from Jest to Vitest, forgets to update the instructions, and the AI keeps trying to write Jest tests.

Qodo keeps review in step with the docs. Rules import from AGENTS.md and CLAUDE.md on every push, so when the team fixes the instruction file, review picks up the change. A new hire then gets findings that match the docs they just read.

Qodo deactivates rules whose findings are rarely fixed, unless a lead locks them. A rule nobody follows any more stops generating comments, which keeps new hires from learning conventions the team already dropped.

One habit helps on the human side. When a PR changes how the team does something, such as a new test framework or a new logger, the PR template can ask whether AGENTS.md or the README needs an update too. The next new hire then reads the current way, and so does every agent.

How Juniors Keep Learning When AI Reviews Their Code

AI review can make learning worse. A junior who accepts every finding without reading it learns to click, not to code.

Junior developers who verify output before accepting it and ask the tool for explanations keep their AI use sustainable. Juniors who skip those steps end up with shallow learning, in a small interview study (arXiv 2607.24606, July 2026). The study is qualitative, but the pattern matches what I've seen on teams.

Make every Qodo finding something the junior can explain, and treat asking Qodo why as part of the work.

Leads can check this in one-on-ones. Ask the new hire to explain one finding they accepted that week and why the convention exists. If they can't, they accepted it without learning, and the next PR is a good place to slow down.

Human reviewers drift as well. Repeat reviewers approved agent-authored PRs more often over several months, which suggests scrutiny can slip as people get used to the tool (arXiv 2606.22721, June 2026). Seniors reviewing juniors' AI-assisted PRs should keep asking the design questions.

A junior's assistant-written PR still needs an independent reviewer. You shouldn't review code with the same tool that wrote it, because the reviewer inherits the writer's blind spots.

Review built into an editor needs the same independent pass before merge. Qodo's glossary on Windsurf code review covers that setup.

What Seniors Get Back

The split I'd aim for is easy to describe. AI review takes naming, missing tests and known rule breaks, the comments seniors repeat most. Seniors keep design, architecture and the "should we build this at all" questions.

DORA's March 2026 guidance on AI-assisted development points the same way, advising teams to give AI feedback to the author while they write the code (DORA Insights, March 2026). For a new hire, the findings then arrive while the code is still fresh in their head, and the senior opens a cleaner PR.

Seniors get their best hours back, and new developers get two kinds of feedback: fast, specific findings on every PR, and slower, deeper conversations with a person. Qodo's guide to code review best practices covers how to keep the human half of that split healthy.

If you're rolling this out, start with one team that has a new hire starting soon. Import your AGENTS.md, let Rule Miner suggest rules where your platform supports it, and ask the seniors which comments they're tired of writing.

The Academy lesson on AI code review rollout covers the steps after the pilot.

Then watch the new hire's PRs. If the senior's comments shift from conventions to design, the setup is working.

FAQ

Can AI code review help new developers learn team conventions sooner?

AI code review helps new developers learn conventions sooner when the reviewer knows them. A generic reviewer can only flag generic issues. Qodo applies rules imported from AGENTS.md and mined from PR history on GitHub, GitLab and Azure DevOps, and every finding explains why it matters.

How does an AI reviewer pick up conventions nobody wrote down?

An AI reviewer picks up unwritten conventions from your existing code and PR history. Qodo uses three routes: manual rules a lead writes, rules imported from files like AGENTS.md, and Rule Miner, which mines PR history on GitHub, GitLab and Azure DevOps. The developer onboarding glossary page covers the idea in more depth.

Will juniors lean on AI review instead of learning?

Juniors lean on AI review instead of learning when nobody asks them to explain their changes. A July 2026 interview study found juniors who verify before accepting and ask for explanations keep learning (arXiv 2607.24606). Qodo's PR chat makes "explain why" one question away, so make it part of every first-month PR.

Can an AI reviewer explain an unfamiliar part of the codebase?

An AI reviewer can explain an unfamiliar part of the codebase when it answers from your own code. Qodo does that through PR chat on a specific finding and through Codebase Wisdom for broader questions, so the answers point to real files rather than general advice.

How should seniors' mentoring time change?

Seniors should spend less time on repeated convention comments and more on design. A good sign is a senior commenting on approach, not formatting. Qodo's analytics show which finding types come up most in new hires' PRs, so seniors can coach the pattern once instead of commenting ten times.

Bitbucket AI Code Review: 3 Things I Didn't Expect

Anna — Wed, 28 Oct 2026 22:01:32 +0000

I expected Bitbucket AI code review to copy the GitHub story, and I hit three surprises instead. The first covers Bitbucket Data Center, the second Bitbucket Cloud, and the third both. I checked every claim below against vendor docs in October 2026, because the listicles I started with didn't agree with each other.

TL;DR

Vendor listicles disagree on Data Center support. Two 2026 listicles gave opposite answers for the same tool, so the vendor's own support table is the only source I trust.
Atlassian's reviewer bills the PR author. Rovo Dev code review draws credits from the author's allocation, and Free plans cover about 2 to 8 reviews per user before reviews stop (Atlassian, October 2026).
Bitbucket Data Center isn't going away in 2029. Atlassian exempted Bitbucket from the March 28, 2029 Data Center end of life, so DC support is a long-term need.
Qodo is my pick because it reviews PRs on Bitbucket Cloud and Data Center, air-gapped included. Qodo connects through one wizard, uses your own model endpoint and reviews code from any agent. Pick it when your team runs Data Center, or Cloud and Data Center side by side.

The Bitbucket AI Code Review Tools I Compared

Qodo: best for teams on Bitbucket Cloud, Data Center or both
Rovo Dev code review: best for Atlassian Cloud teams that want review inside Rovo and keep PRs small
CodeRabbit: best for teams that want a hosted reviewer on Cloud or Data Center
A browser extension on a local model: best for individual reviewers on Data Center

Tool	Best for	Bitbucket Cloud	Bitbucket Data Center	Who pays per review
Qodo	Teams on Cloud, Data Center or both	Yes	Yes, including on-prem and air-gapped	Workspace credits
Rovo Dev code review	Atlassian Cloud teams that want review inside Rovo	Yes	Not documented	The PR author's Rovo Dev credits
CodeRabbit	A hosted reviewer on Cloud or Data Center	Yes	Yes, through a bot user	Not documented
Browser extension (ThinkReview)	Individual reviewers on Data Center	Yes, with an API token	Yes, with an HTTP access token	The extension's review credits, or a local model

Surprise 1: The Lists Disagree on Who Supports Data Center

My first search for Data Center support turned up two 2026 listicles from code review vendors. One said a tool supported Data Center, and the other said the same tool didn't. One of them still used Qodo's old name, so its research predated the rebrand.

I went to the docs instead. Qodo's deployment table lists Bitbucket Data Center under multi-tenant, single-tenant, on-premises and air-gapped. Bitbucket Cloud runs multi-tenant and single-tenant, the two models a cloud product needs.

A Bitbucket code review tool either documents Data Center support on its own site or I treat it as unsupported until a vendor engineer shows me. Listicles are where I start, not where I decide.

When the docs are vague, I'd ask the vendor three questions. Which Data Center versions do you test against? Does the reviewer run inside my network or call in from yours? Who creates the bot user? A vendor that answers all three in writing usually supports Data Center properly.

Surprise 2: Rovo Dev Code Review Runs on the Author's Credits

Rovo Dev is Atlassian's AI agent, and code review is one of its jobs. I assumed a workspace would pay for reviews like build minutes. Credits come out of the PR author's allocation instead (Atlassian Rovo Dev activation page, October 2026), and that billing model changed five things I hadn't planned for.

What the Credit Model Means Day to Day

Reviews stop when the author runs out. Atlassian says reviews don't run if the author has no credits left, and only the author can trigger one manually.
Free plans cover a handful of reviews. The rollout page lists 350 Rovo Dev credits per user on Free, which Atlassian describes as "about 2 to 8 code reviews per user".
Standard adds more credits. Each Standard user gets 2,000 credits per month.
Every commit can cost credits. Atlassian suggests running reviews only when a PR is created, or on request, to cut credit usage.
Big PRs may get nothing. PRs with more than 10,000 changed lines, or repos over 20 GB, may get no comments.

Atlassian's rollout page covers compliance too. Rovo Dev hasn't been externally audited for ISO 27001 and SOC 2 compliance yet, isn't HIPAA compliant and doesn't support data residency (Atlassian, October 2026). Regulated teams should read that page before a pilot.

There's one more catch for me. Rovo Dev also writes code, and you shouldn't review code with the same tool that wrote it, because the reviewer inherits the writer's blind spots. In one study, models caught fewer injected errors when the review ran in the session that wrote the work (arXiv 2603.12123, March 2026).

Surprise 3: Bitbucket Data Center Isn't Going Away

I expected Data Center to vanish with the rest of Atlassian's Data Center line. Impacted products reach end of life on March 28, 2029, but Bitbucket and Bamboo Data Center will not (Atlassian Data Center end-of-life notice).

Existing Data Center customers get a Hybrid License covering Data Center and Cloud from early 2027. Atlassian names compliance, data sovereignty and air-gapped requirements as reasons customers stay on Data Center. Security researchers describe the same limit for AI review, where source code can't be sent to an externally hosted model (arXiv 2610.27383, October 2026).

Atlassian also keeps building for agents on Data Center. Bitbucket Data Center 10.5.0, released on September 29, 2026, added a bundled server for the Model Context Protocol, and admins limit the tools it exposes with a whitelist file. A reviewer that only supports Cloud leaves those teams out for years.

Data Center's long future changed the buying question for me. I'd planned to pick a Cloud-first reviewer and live with gaps until a migration. Now I'd pick a reviewer that treats Data Center as a first-class platform, because the hybrid license means some teams will run both for a long time.

AI Code Review on Bitbucket Data Center

Data Center is where the reviewer choice gets hard, because the server sits inside your network. A hosted reviewer needs a way in for webhooks and a way out for comments. An on-prem reviewer runs next to Bitbucket and never leaves the building.

Qodo handles both cases. The same Data Center wizard works for multi-tenant, single-tenant and on-premises deployments, and air-gapped installs forward model calls to your own OpenAI-compatible endpoint, so code never leaves the network. The air-gapped code review setup is the one regulated Bitbucket shops tend to ask about.

Regulated teams usually shortlist from secure code review tools first, and Data Center support is the filter that shortens that list most.

For the air-gapped route, the platform team installs Qodo on Kubernetes with a mirrored image bundle and points the bundled gateway at an internal model endpoint. Once that endpoint is configured, Qodo needs no outbound access to a public model API, and the Bitbucket connection itself runs through the same wizard below.

Hands-On: Connecting Qodo to Bitbucket Data Center

The wizard starts in the Qodo portal. In the Data Center docs I read, the flow looks short. You pick Bitbucket, then the self-hosted option, and Qodo asks how you want the bot account created. Configuration typically takes around five minutes, and on Data Center the new wizard brings Review Standards and findings with it.

Automatic Setup

Enter the server URL and an admin login. Qodo uses the administrator credentials once to create a dedicated account, scope it to the projects you pick and configure webhooks, and discards them afterward.
Choose repositories. Picking a project includes every repository in it, including ones added later.
Finish. Qodo creates the qodo-bot account, registers the webhooks and warns you before its token expires.

Manual Setup

If my security team didn't want to hand admin credentials to any vendor, manual setup, which arrived in Qodo 3.0 on October 1, 2026, is the route I'd pick.

Ask an admin for a dedicated user. The username must contain qodo, such as svc-qodo, and the user needs write access to the projects Qodo should review.
Enter that user's credentials and test the connection. Qodo checks that the username contains qodo.
Create the webhook yourself. In manual mode, you create the webhook for the chosen repositories in Bitbucket.

What Works Differently on Bitbucket

Qodo on Bitbucket runs the same review loop as on GitHub, with a few Bitbucket-specific touches worth knowing before the first PR. Reviews run on every push, and Qodo updates its findings as you commit fixes.

Findings arrive in full as standard markdown, since Bitbucket has no collapsible sections, and older resolved findings move to the Qodo portal to keep long PRs readable.

Two settings exist only on Bitbucket and Gerrit. One shows section titles inside each finding, and the other links each finding in the summary to its inline comment, which helps on long PRs.

Jira works as ticket context, so Qodo can check a PR against the linked issue's acceptance criteria. Atlassian shops get review tied to the ticket, and the review commands, /agentic_review, /agentic_describe and /ask, all work on Bitbucket the way they do elsewhere.

What I'd Check Before Installing Any Bitbucket AI Reviewer

The three surprises gave me the first three checks, which are docs over listicles, who pays and where code goes. Reading the Data Center setup docs added setup permissions, and planning review across many teams added governance and independence. I'd run every Bitbucket AI reviewer through them, in this order.

Cloud, Data Center or both, per the vendor's docs. A listicle isn't evidence, so I look for the vendor's own support table.
Who pays per review and what gets skipped. Per-author credits, size limits and rate limits all decide which PRs get reviewed.
Where code and model calls go. On Data Center, check whether the reviewer runs on-prem and whether it can use your own model endpoint.
Setup permissions. Note whether the tool needs admin credentials, a bot user, a webhook or an outbound tunnel.
Governance across many repos. Rules and findings should roll up across projects, not live in one repo's config.
Independence from your coding agent. The reviewer shouldn't be the agent that wrote the change.

The academy guide to the Bitbucket AI code review goes deeper on each check.

How I Evaluated

I read each tool's own Bitbucket setup, billing and deployment docs in October 2026 and scored them against the six checks. "Not documented" means I couldn't find it in the vendor's public docs.

Check	Qodo	Rovo Dev code review	CodeRabbit	Browser extension
Cloud and Data Center	Both	Cloud	Both	Both
Who pays, what gets skipped	Workspace credits with an optional monthly spending cap	Author's credits; large PRs may be skipped	Not documented	Review credits, or a local model
Where code and model calls go	Your network on-prem or air-gapped	Atlassian cloud	CodeRabbit cloud; reverse tunnel for private instances	Your browser and local model
Setup permissions	Admin once, or a qodo-named user plus webhook	Repository connection in Rovo	Bot user, HTTP access token, OAuth consumer	Personal HTTP access token
Governance across repos	Rules and findings on Cloud and Data Center	Not documented	Not documented	No
Independent of the coding agent	Yes, reviews code from any agent	Same vendor as the agent	Yes	Depends on the model

The Tools

1. Qodo: Best for Teams on Bitbucket Cloud, Data Center or Both

Tool Overview

Qodo is a code review platform that reviews pull requests on Bitbucket Cloud and Bitbucket Data Center, along with GitHub, GitLab, Azure DevOps and Gerrit. On Data Center, Qodo runs multi-tenant, single-tenant, on-premises or air-gapped, which makes it my pick for Data Center teams that need on-prem or air-gapped review.

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for teams reviewing PRs on Bitbucket Cloud and Data Center, air-gapped installs included.

Main Features

One Data Center wizard. Automatic setup uses admin credentials once, and manual setup works with an admin-created user and webhook.
Air-gapped Data Center. The bundled gateway forwards model calls to your own OpenAI-compatible endpoint.
Jira ticket context. Reviews can check PRs against the linked Jira issue.
Governance across repositories. Organization rules, findings and the Repositories page cover Bitbucket Cloud, and on Data Center the new wizard brings Review Standards, findings and the Repositories page.
Usage-based billing. Workspace credits replace seats, with a 14-day trial and an optional spending cap.

Runs in your browser. Nothing installs on a server, and you don't need an admin.
Local models. Ollama keeps code on your machine.
Personal scope. Each reviewer installs and configures it alone.

Best For

A browser extension is best for one developer who wants a second opinion on Data Center PRs today.

How It Ranked

With a local model, the extension keeps code on your machine and needs no admin. Nothing rolls up across a team, so it can't cover the governance check.

Conclusion

Checking Data Center support in the vendor's docs, knowing who pays for each review and planning for Data Center past 2029 all point to the same answer. Qodo passed those checks on Cloud and Data Center, air-gapped included, as an independent reviewer. Pick Qodo when one reviewer has to cover every Bitbucket you run.

Teams that also run GitHub or GitLab can compare options in our roundup of tools for GitLab AI code review, where Qodo reviews with the same loop.

Qodo's earlier post on Bitbucket code review covers the human side of the workflow.

FAQ

Does AI code review work the same on Bitbucket Cloud and Data Center?

AI code review works almost the same on Bitbucket Cloud and Data Center. Qodo reviews PRs on both with the same review commands and markdown comments. Data Center adds on-prem and air-gapped deployment, and wiki-based configuration stays a Cloud option.

Can I run AI code review on-prem or air-gapped with Bitbucket?

You can run AI code review on-prem or air-gapped with Bitbucket Data Center. Qodo supports on-premises and air-gapped deployments for Bitbucket Data Center, with model calls going to your own endpoint.

How much does Rovo Dev cost?

Rovo Dev includes 350 credits per user on Free, about 2 to 8 code reviews, and 2,000 credits per Standard user each month, and credits come from the PR author (Atlassian, October 2026). Qodo bills the workspace through credits instead, with an optional spending cap, so reviews don't stop when one author runs out.

Does AI code review work with Bitbucket Pipelines?

AI code review works alongside Bitbucket Pipelines rather than inside it. Qodo reviews pull requests through webhooks, so it works the same whether you build with Bitbucket Pipelines, Jenkins or another CI system.

What permissions does a Bitbucket reviewer need?

A Bitbucket reviewer needs either admin credentials once or a dedicated bot user. For Qodo on Data Center, that means admin credentials used once, or a user whose name contains qodo with write access, plus a webhook an admin creates.

Which features differ from GitHub?

On Bitbucket, Qodo comments use standard markdown, and two display settings exist only on Bitbucket and Gerrit.

Inline comment severity thresholds, feedback on draft PRs, chat on code suggestions, Rule Miner and Relevance run on GitHub and GitLab, with draft-PR feedback and Rule Miner on Azure DevOps and severity thresholds on Gerrit, and none of them run on Bitbucket.

Best Automated Code Review Tools for Enterprise Engineering Teams in 2026

Anna — Wed, 28 Oct 2026 20:04:33 +0000

At enterprise scale, choosing automated code review tools stops being a bug-finding question and becomes a governance one. I spend a lot of my time with engineering orgs that run hundreds of repositories, and they need a reviewer that holds one rulebook, shows leaders what every team ships and traces a change across repositories. I ranked the tools I'd shortlist on exactly that.

TL;DR

Enterprise review is a governance problem as much as a bug-finding one: only 37.0% of surveyed engineering leaders report having policy enforcement that works across teams and repositories (Qodo, State of AI Code Quality 2026, August 2026).
Qodo ranks first because Qodo gives engineering leaders one view of review across every repository and Git organization, from org-wide rules to an Analytics dashboard and the Software Map.
GitHub Copilot code review ships inside GitHub, but you shouldn't review code with the same tool that wrote it.
SonarQube, Codacy and Snyk Code are rule-based scanners for static analysis, quality gates and security checks.

The Best Automated Code Review Tools for Enterprise Teams, Ranked

Qodo and GitHub Copilot code review are AI reviewers, and SonarQube, Codacy and Snyk Code are rule-based scanners whose quality gates run in CI next to Qodo's advisory findings.

Qodo
GitHub Copilot code review
SonarQube
Codacy
Snyk Code

Tool	Best for	Git platforms (per vendor docs)	Starting price (Oct 2026)
Qodo	Engineering leaders who govern review across many repositories and Git organizations	GitHub, GitLab, Bitbucket, Azure DevOps, Gerrit	Custom Enterprise plans; Pro Team from $30 for 2,500 credits after a 14-day trial
GitHub Copilot code review	An AI first pass inside GitHub, with an independent reviewer for the final check	GitHub, Azure DevOps (public preview)	Included in paid Copilot plans, plus Actions minutes on GitHub's runners
SonarQube	Deterministic quality gates in CI pipelines	Major Git platforms and CI tools	Team from $34 a month for up to 100k lines of code; Enterprise above 50 developers
Codacy	One static analysis configuration across groups of repositories	GitHub, GitLab, Bitbucket	$18 per developer a month, billed yearly
Snyk Code	Security findings in code and dependencies from one vendor	Native Git integrations; Snyk Broker for self-hosted Git on Enterprise	Free, Team from $25 a month

Why Enterprise Code Review Breaks Past a Few Dozen Repositories

Enterprise review fails in places a single-repo demo never shows you, and review itself has become a bottleneck: 26.0% of surveyed engineering leaders name reviewing and validating AI-generated code as their primary delivery constraint (Qodo, State of AI Code Quality 2026, August 2026).

Standards Drift When Every Team Configures Its Own Reviewer

Standards drift once every team keeps its own review config, since a hundred repos then carry a hundred slightly different rule files. Platform teams want one shared version of org-wide standards with room for a stricter path in the payments code or a looser one in internal tooling. Per-repo config files make layered rules hard to audit.

Leaders Lose Sight of What Gets Flagged and What Ships Anyway

Visibility is what directors and VPs of Engineering ask me about most, because a bot comment on a pull request (PR) is invisible outside that PR. Leaders want to know which repositories ignore findings, which rules keep firing and which PR authors resolve issues before merge. Without that record, AI code governance has no numbers behind it.

In a Multi-Repo System, a Change in One Repository Breaks a Service in Another

Breakage across repository lines hurts most at scale, because no single PR contains the whole picture. A renamed field in a shared software development kit (SDK) passes every check in its own repo, and the consumer service fails after the next deploy. Most AI reviewers read the diff plus the repo it lives in, so the reviewer needs extra context, configured or discovered, before it can see the downstream caller.

Drifting rule files, findings leaders never see and cross-repo breakage all happen outside the one PR a typical reviewer reads, so the fix has to work at the level of the whole organization.

What Makes a Great Automated Code Review Tool for Enterprise Teams

Criteria for Enterprise Code Review, in Order of Weight

Shared rules. Rules live in one place and apply org-wide, per Git organization, per repo or per path, with admins approving changes.
Leader visibility. Leaders see findings and outcomes across repositories and PR authors without opening individual PRs.
Cross-repo context. The reviewer reads related repositories, so a breaking change outside the diff still shows up on the PR.
Independence. The reviewer is a separate system from the assistant or agent that wrote the change. You shouldn't review code with the same tool that wrote it, because a reviewer from the same tool shares the generator's assumptions and blind spots, and the gap widens as agents write more of the code.
Git coverage. Review works on every provider and deployment model the org runs today, including self-hosted and air-gapped setups.

Qodo ranks first because Qodo gives leaders one place to define rules for every Git organization and one view of what happens to every finding, and governance and leader visibility are where Qodo pulls furthest ahead.

How I Evaluated the Tools

I compared AI reviewers and code quality tools on shared rules, leader visibility, cross-repo context, independence and Git coverage, using each vendor's docs and pricing pages, checked between October 26 and 28, 2026. Qodo's own ranking of agentic code review tools for enterprise teams goes deeper on the agent-based reviewers in this list.

Tool	Shared rules	Leader visibility	Cross-repo context	Independence	Git coverage
Qodo	Global, Git org, repo and path, with admin approval by default	Analytics by repository and PR author, CSV export	Discovered or defined relationships, across providers	Separate reviewer	GitHub, GitLab, Bitbucket, Azure DevOps, Gerrit; on-prem and air-gapped options
GitHub Copilot code review	Repository and organization custom instructions	Usage metrics on PRs reviewed, time to merge and suggestions applied	Repository context	Shares a vendor with Copilot coding	GitHub, Azure DevOps (public preview)
SonarQube	Quality gates	Portfolios on Enterprise	Per project	Separate analyzer	Major Git platforms and CI tools
Codacy	Up to 30 coding standards per org	Trends across teams and projects	Per repository	Separate analyzer	GitHub, GitLab, Bitbucket
Snyk Code	Security rules	Issue tracking with Jira export	Interfile, within a repo	Separate analyzer	Native Git integrations; Snyk Broker on Enterprise

Automated Code Review Tools for Enterprise Teams, Reviewed

1. Qodo: One View of Review Across Every Repository and Git Organization

Tool Overview

Qodo is the AI code review platform for organizations that run many repositories across more than one Git provider, built as quality control for the agentic software factory. Qodo gives leaders shared rules, visibility into every team and tracing across repositories from one place.

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for enterprise teams that need one review standard across every repository and Git provider.

Main Features

Shared rules. Rules apply globally or to specific Git organizations, repositories and path patterns, so a payments org can run stricter rules than internal tooling, and members' new rules wait for admin approval by default (rules docs). Git organization settings, added in Qodo 3.1, sit between workspace and repository settings (portal configuration docs).

Leader visibility. The Analytics dashboard, new in Qodo 3.0, shows finding activity and acceptance by repository and by PR author, with spreadsheet (CSV) export, and Rules analytics shows which rules keep firing and how often issues get resolved, so leaders can track code quality metrics across the org without opening a single PR.

Cross-repo tracing. The Software Map gives leaders a live view of the system across repositories, with dependencies, service relationships and contracts mapped automatically and updated with every pull request. Cross-repository review uses repository relationships, discovered automatically since Qodo 2.5 (June 30) and across the whole organization since Qodo 2.10, or defined by your team, to trace impact in both directions, even across Git providers, and a Cross-repo finding links straight to the affected lines in the other repository.

Every review draws on the full codebase, PR history, linked tickets and your org standards. Findings are advisory, so your branch protection rules still decide what merges. Qodo reviews PRs on GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, with multi-tenant, single-tenant and on-prem deployments, plus air-gapped options for self-managed providers.

Best For

Qodo gives engineering orgs with dozens to hundreds of repositories, more than one Git provider or a central platform team one standard and one view of review.

How It Ranked

Qodo ranks first on shared rules, leader visibility and Git coverage, with org-level governance and leader visibility furthest ahead. On independence, Qodo reviews every PR as a separate system, whichever assistant or agent wrote the change.

Case study: LoopUp configured Qodo at the organization level across hundreds of repositories

Configuring Qodo at the organization level across its GitHub repositories gave LoopUp one review setup for a platform of hundreds of repositories, with engineers in London, San Francisco and Jakarta. LoopUp says Qodo now does "about 90% of that initial review" before humans step in (LoopUp case study, April 2026).

2. GitHub Copilot Code Review: Review Built Into GitHub

Main Features

Coding standards apply the same tool and code pattern configuration to many repositories, up to 30 standards per organization. Gate policies define the quality bar for PRs, and the Team plan lists an AI Reviewer for pull requests plus trends across teams and projects. SSO and audit logs sit on the Business plan. Codacy connects to GitHub, GitLab and Bitbucket.

Best For

Codacy suits teams that want one static analysis configuration shared across groups of repositories.

How It Ranked

Codacy applies one coding standard to many repositories, so shared rules is its highest criterion. Codacy docs don't describe tracing impact into related repositories, which puts Codacy second among the scanners.

5. Snyk Code: SAST in the IDE, CLI and PR

Tool Overview

Snyk Code is a static application security testing (SAST) tool that scans code in the editor (IDE), the CLI, PR checks and the API.

Main Features

Interfile analysis is available for every language Snyk Code supports except Ruby. Snyk Broker connects Snyk to on-premises and private-network systems on Enterprise plans. Snyk Open Source covers dependencies on the same platform.

Best For

Snyk Code suits security teams that want code and dependency findings from one vendor.

How It Ranked

Snyk Code focuses on security findings and sits next to an AI reviewer rather than in place of one. Security focus and per-repo scope put Snyk Code third among the scanners, and a wider comparison of secure code review tools covers the security side of review in more depth.

Hands-On: Rolling Out Qodo Across a Git Organization

Enterprise rollout is mostly configuration. For a structured pilot first, use Qodo's guide to run a proof of concept to scope the repositories and success criteria.

My Rollout Order for a Git Organization

One review process for every provider. Connect each Git provider your org uses through the Qodo installation wizard, from GitHub and GitLab to Bitbucket, Azure DevOps or Gerrit. Cross-repo review only sees repositories installed through the wizard, so reinstall any repository connected with an older method.
Workspace defaults first, then Git organization overrides. On the Configurations page, switch between Workspace, Git organization and Repository. Git organization settings override the workspace, and repository settings override both.
Scoped rules. Keep org-wide rules global, then limit stricter ones to the Git organizations, repositories or paths that need them, such as payments.
Analytics after the first week. Open the Analytics dashboard by repository and by PR author to see which teams act on findings, then check Rules analytics on the Review Standards page to see which rules keep firing before you tighten anything.

Conclusion

At enterprise scale, code review is a governance job: apply one rulebook, let leaders see what every team ships and trace a change across every repository. Qodo handles shared rules, leader visibility and cross-repo tracing as an independent reviewer across GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, which is why I'd start an enterprise shortlist with Qodo.

FAQ

What are the best automated code review tools for enterprise engineering teams?

The best automated code review tools for enterprise engineering teams combine shared rules, reporting for leaders and context across repositories. Qodo leads in 2026, with Git organization settings to govern rules, an Analytics dashboard for leader visibility, and the Software Map and cross-repo review to trace changes across repositories.

What are the best code quality tools for multi-repo environments?

The best code quality tools for multi-repo environments share one configuration across repositories and see how repositories depend on each other. Codacy and SonarQube share static analysis settings across many repos. Qodo traces each change into the repositories that depend on it and applies the same scoped rules across them.

What are the best code quality tools for enterprise teams?

The best code quality tools for enterprise teams pair a rule-based scanner with an AI reviewer that applies org-wide standards. SonarQube, Codacy and Snyk Code cover quality gates, static analysis and security findings in CI. Qodo adds the review layer, with rules scoped by Git organization, repository and path, and an Analytics dashboard that shows leaders how every team acts on findings.

What are the best automated code review tools for complex codebases?

The best automated code review tools for complex codebases read beyond the diff, into the wider codebase, PR history and related services. Qodo draws on the full codebase, PR history, linked tickets and org standards for every review, and the Qodo Software Map shows how modules and services connect.

Can an automated reviewer catch a breaking change in another repository?

An automated reviewer can catch a breaking change in another repository when it knows how the repositories relate. Qodo discovers or accepts those relationships and raises a Cross-repo finding that links to the affected lines.

Why shouldn't a coding assistant review its own code?

A coding assistant shouldn't review its own code because the reviewer then shares the generator's assumptions and blind spots. A separate reviewer brings its own context and rules to every PR, and Qodo reviews each change independently, whichever assistant or agent wrote it.

How do enterprise teams keep the same review rules across hundreds of repositories?

Enterprise teams keep the same review rules across hundreds of repositories by defining rules once and scoping overrides where needed. In Qodo, rules apply globally or to specific Git organizations, repositories and paths, members' rules wait for admin approval by default, and Git organization settings cover every repo in that organization.

10 Best Tools to Catch Bugs in AI-Generated Code Before Merge (2026)

Anna — Tue, 27 Oct 2026 00:58:57 +0000

AI-written pull requests pass lint, types, scans and their own tests, so the bugs that reach main are logic flaws, missing edge cases and breaks outside the diff. I put a four-layer pre-merge pipeline in front of AI-generated code and ranked 10 tools by the layer each one fills.

TL;DR

AI-generated code fails where it looks finished. The bugs that pass lint, types and scans are logic flaws, missing edge cases and breaks outside the diff.
The review you rely on is getting weaker. 28.2% of developers say they care a lot about AI code quality but rely on their existing review to catch issues (State of AI Code Quality 2026, August 2026).
Catch AI-generated bugs in four layers. Deterministic checks and security scanners block the merge in CI (the automated checks on every push). Context-aware AI review and app tests find what needs intent or a running app.
Qodo is my #1 because it checks whether AI code does what the ticket asks. Qodo reads each change with your codebase, related repos, the linked ticket and your team's rules, before the pull request (PR) exists and on the PR.

The 10 Best Tools to Catch Bugs in AI-Generated Code Before Merge, by Layer

Qodo: logic, edge-case and cross-repo bugs (Layer 3)
Cursor Bugbot: AI PR review billed through a Cursor plan (Layer 3)
CodeRabbit: AI PR review with linked-repo context (Layer 3)
Augment Code: review inside a coding-agent platform (Layer 3)
SonarQube: rule-based quality gate in CI (Layers 1 and 2)
GitHub CodeQL: security queries in GitHub code scanning (Layer 2)
Semgrep: pattern rules you write (Layer 2)
Snyk Code: static application security testing (SAST) next to dependency scanning (Layer 2)
TestSprite: generated end-to-end tests (Layer 4)
Shiplight: browser tests stored as YAML files (Layer 4)

Tool	Layer	Best for	Price as of October 2026
Qodo	Context-aware AI review (CLI and PR)	Teams merging agent-written PRs who need intent, rules and related repos checked before merge	14-day free trial; Pro Team from $30 a month for 2,500 credits; Enterprise custom
Cursor Bugbot	AI PR review	Engineering groups that write in Cursor and want PR review on the same plan	Usage-based on Cursor's Premium and higher plans, Teams and Enterprise
CodeRabbit	AI PR review	Reviewers who want a walkthrough of each PR with linked issues and past PRs	Essentials $24/user/month annual ($30 monthly); Team $48 annual ($60 monthly)
Augment Code	AI PR review	Organizations that run writing and review on one agent platform	Standard $20/month flat for up to 50 seats
SonarQube	Deterministic quality gate	Teams who want a rule-based quality gate in CI for 30+ languages	Free tier; Team from $34/month
GitHub CodeQL	Security scanner	Security teams on GitHub who run vulnerability queries in code scanning	Free on public repos; GitHub Code Security for private
Semgrep	Security scanner	Security teams who write and test their own pattern rules	Free up to 10 contributors; Teams $30/contributor/month
Snyk Code	Security scanner	Security teams who want code and dependency findings from one vendor	Free; Team $25/month for up to 10 developers
TestSprite	App tests	QA teams who want end-to-end tests generated against a staging app	Free; Starter $19/month; Standard $39/month
Shiplight	App tests	Developers who want agent-written browser tests kept in the repo	Free; Pro $60/month

Why Lint, Types and Scanners Miss AI-Written Bugs

Most AI-written bugs that get through fall into three gaps your checks can't see.

Logic Flaws and Missing Edge Cases

A coding agent writes code that matches the prompt, and the prompt rarely mentions the empty list or the retry that runs twice.

Agent-written tests rarely catch the flaw either. Up to 17% of regression tests written by large language models (LLMs) for 145 merged PRs asserted the faulty behavior (arXiv, October 2026).

Breaking Changes From AI Refactors

Agent PRs introduce potential breaking changes less often than human ones overall, 3.45% against 7.40%, but in refactors, which touch shared code, the agent rate climbs to 6.72% (Safer Builders, Risky Maintainers, Mining Software Repositories conference, MSR 2026).

Agent PRs that reported top confidence still introduced potential breaking changes in 3.16% of commits. A renamed field in shared code passes every check in your repo and breaks a caller in another repo.

Team Rules No Scanner Knows

Every team has rules that live in nobody's linter, like "tenant ID on every query". Agents miss team rules too: only 34.6% of developers say their agents always follow organizational standards (State of AI Code Quality 2026, August 2026).

The agent shouldn't be the last check on its own work. You shouldn't review code with the same tool that wrote it, because the same tool shares the agent's assumptions and misses the same edge cases.

Two AI-Written PRs That Pass Every Check

PR 1: A Refund Helper With a Missing Edge Case

An agent adds a refund helper (illustrative).

def refund(order):
    payment = order.payments[-1]   # IndexError when the order has no payments
    payment.refund(payment.amount) # no guard if this payment was already refunded

Lint, types, the agent's happy-path test and the scanner all pass. The ticket says "refund the latest captured payment, once", and nothing in the diff checks either half.

PR 2: A Field Rename That Breaks Another Repo

The agent renames a field in payments-lib (illustrative).

 class InvoiceSerializer:
-    amount_cents: int
+    amount: int

billing-service, in another repo, still reads invoice.amount_cents, and every check in payments-lib passes.

The 4-Layer Pre-Merge Pipeline for AI-Generated Code

My pipeline runs four layers, ordered by how deterministic each check is, and only the deterministic layers should block a merge on their own. The pipeline diagram shows that order, with the two blocking layers in CI. Layered review gets a longer write-up in Qodo's guide to layered code review.

Layer 1: Deterministic Checks That Block the Merge

Lint, type checks and unit tests give the same result every time, so make them required checks. The refund helper and the rename both pass Layer 1.

Layer 2: Security Scanners and Their Limits

SAST tools match known patterns such as injection or hardcoded secrets, so block on critical findings.

Across 302.6k AI-authored commits in 6,299 GitHub repos, code smells made up 89.3% of the 484,366 issues those commits introduced, as flagged by ESLint, Pylint and Semgrep, against 6.0% correctness and 4.7% security issues (Debt Behind the AI Boom, March 2026). The refund helper and the rename pass Layer 2 as well.

Layer 3: Context-Aware AI Review Before Merge

Context changes what an agent gets right. Giving a coding agent a dependency map between code and tests cut regressions from 6.08% to 1.82% on 100 tasks from SWE-bench Verified, a benchmark of real GitHub issues, while instructions alone pushed regressions to 9.94% (TDAD, March 2026). Context-aware review brings codebase, ticket and rule context to the PR.

The refund helper and the rename both show up at Layer 3: the ticket exposes the second refund, and knowing billing-service exposes the stale amount_cents read.

Layer 4: End-to-End Tests Against the Running App

End-to-end tests against staging catch what agent-written unit tests miss.

The two-PR diagram walks both PRs through the layers: Layers 1 and 2 pass both, Layer 3 flags both, and Layer 4 catches a bug only if its flow is in the suite.

Making Sure Someone Reads AI Review Findings

Layer 3 only works if someone reads the findings, and attention fades as agent PRs pile up. Across 11,429 reviews, repeat reviewers went from approving 30.1% of agent PRs to 36.8%, while their inline comments fell 22% (Habituation at the Gate, June 2026).

HiBob, an HR platform with 200+ developers, shipped a release that broke a most-used mobile flow for ten days. Qodo had flagged the error on the original PR, and the reviewers missed the feedback (HiBob case study, May 2026).

HiBob's fix was a process step: the PR author now checks a box confirming they addressed Qodo's comments before a second human reviewer is assigned.

What a Context-Aware AI Reviewer Has to Do to Verify AI-Generated Pull Requests

The reviewer reads the change with the rest of the codebase and related repos. A related repo is where the amount_cents rename breaks.
The reviewer uses the ticket as context and checks your team's rules. The ticket's "once" flags the second refund.
The reviewer runs before the PR exists. The empty-list guard gets added while the change is still in the agent's context.
The reviewer explains each finding and records dismissals. A dismissal keeps its reason, so a step like HiBob's checkbox has a record behind it.
The reviewer works next to deterministic CI checks. Scanners and tests give branch protection a yes or no.

How I Evaluated the 10 Tools

I tested every tool on the same three questions, using its docs and pricing in October 2026: does it catch the refund helper's missing guards, does it catch the amount_cents rename in another repo, and how does its result reach the merge, as a blocking check or as findings the team resolves?

The 10 Tools Ranked on the Refund Helper and the Rename

1. Qodo Catches Logic, Edge-Case and Cross-Repo Bugs Before Merge

Tool Overview

Qodo reviews each change with intent and context, so it catches the bugs that pass every deterministic check. Qodo's PR review runs on GitHub, GitLab, Bitbucket and Azure DevOps, plus Gerrit on Enterprise. Specialized agents check correctness, standards, architecture and risk in parallel, and a judge agent filters their findings.

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for catching the logic, edge-case and cross-repo bugs that pass your tests, so Qodo covers Layer 3 of this pipeline.

Main Features

Context beyond the diff. The review reads the full codebase, and the Qodo Context Engine adds PR history, linked tickets and your standards.
Cross-repo review and blast radius. Cross-repo review links repositories across Git providers and posts a Cross-repo finding linked to the affected lines. When you turn on blast radius labels, Qodo rates each PR Small, Medium or Large by the scope and sensitivity of the change.
Your team's rules. Qodo Rules imports rules from files you already have, such as AGENTS.md and CLAUDE.md, and a rule from src/payments/AGENTS.md applies only under src/payments/. On GitHub and GitLab, Rule Miner generates rules from your PR history.
Review before a pull request exists. The Qodo Agentic Toolbox brings the same engine to the terminal and coding agents (Claude Code and Codex plugins, Kiro Power, any Model Context Protocol (MCP) client). The Reviewer skill checks local changes with your session's intent attached.
Findings you resolve or dismiss with a reason. Findings come ranked by severity with a fix, and each dismissal records a reason such as false positive or fix later.
Pricing as of October 2026. Qodo starts with a 14-day free trial, then Pro Team from $30 a month for a 2,500-credit pack, pooled across the team, with custom Enterprise pricing.

# install the Qodo Agentic Toolbox (Node.js 20+)
curl -fsSL https://get.qodo.ai | sh

# review local changes before opening a pull request
qodo review

YAML tests in the repo. Tests change in the same PR as the code.
Results on the PR. Reviewers see a broken flow next to the diff.

Best For

Shiplight is best for developers who want agent-written browser tests kept in the repo.

How It Ranked

Shiplight catches both bugs when a browser flow exercises them, so coverage depends on the flows in the suite, as with TestSprite.

Comparison Table: The 10 Tools on the Two PRs

Tool	Layer	Refund helper	`amount_cents` rename	Result at merge	Best for
Qodo	3: context-aware AI review	Flagged from the ticket's "once"	`Cross-repo` finding on `billing-service`	Findings the team fixes or dismisses with a reason	Teams merging agent-written PRs who need intent, rules and related repos checked before merge
Cursor Bugbot	3: AI PR review	In scope	Missed: other repo	PR check can fail on unresolved findings	Engineering groups that write in Cursor and want PR review on the same plan
CodeRabbit	3: AI PR review	In scope	In scope when `billing-service` is linked	PR comments	Reviewers who want a walkthrough of each PR with linked issues and past PRs
Augment Code	3: AI PR review	In scope	In scope when `billing-service` is declared	PR comments	Organizations that run writing and review on one agent platform
SonarQube	1 and 2: quality gate	Passes	Passes	Gate passes	Teams who want a rule-based quality gate in CI for 30+ languages
GitHub CodeQL	2: security scanner	Passes	Passes	No alert	Security teams on GitHub who run vulnerability queries in code scanning
Semgrep	2: security scanner	Only with a pattern written for it	Passes	No finding without a pattern	Security teams who write and test their own pattern rules
Snyk Code	2: security scanner	Passes	Passes	No finding	Security teams who want code and dependency findings from one vendor
TestSprite	4: app tests	Caught if the flow is tested	Caught if the flow is tested	Failing test on the PR	QA teams who want end-to-end tests generated against a staging app
Shiplight	4: app tests	Caught if the flow is tested	Caught if the flow is tested	Failing test on the PR	Developers who want agent-written browser tests kept in the repo

Conclusion: Catching Bugs in AI-Generated Code Takes a Pipeline

Let CI block on deterministic checks and a scanner such as CodeQL or Semgrep. Give Layer 3 to an independent reviewer with the ticket, your rules and related repos as context, and make reading the reviewer's findings a required step. In both PRs, Qodo is where the second refund and the stale amount_cents read show up.

FAQ

How do you verify an AI-generated pull request before merge?

Verify an AI-generated pull request with four layers: deterministic checks, security scanners, context-aware review and app tests. Qodo covers context-aware review.

Our coding assistant already reviews its own code. What does a separate reviewer add?

A separate reviewer brings context the writing agent doesn't carry, such as related repos, PR history and your rules. Qodo brings that context to every PR, whichever agent wrote the code.

We already run static analysis and security scanners. What does AI review catch that they don't?

AI review catches logic errors, missing edge cases and breaking changes in related repos. Scanners still find known vulnerability patterns, so Qodo runs next to Snyk Code, CodeQL or Semgrep.

Can AI code review understand what a change is supposed to do?

AI code review understands what a change is supposed to do when the reviewer reads the ticket behind the change. Qodo's review uses the linked ticket as context.

Can developers run the same review before opening a pull request?

Developers can run the same review before opening a pull request. Qodo's Reviewer skill checks local changes with the same engine as the PR review, from the terminal or a coding agent.

How do you prove an AI reviewer is catching real problems?

Track what your team does with each finding: Qodo's code review analytics show acted-on and accepted findings by type, severity, repository and author over up to 365 days.

Trunk-Based Development With Coding Agents: What Replaces Code Review?

Anna — Tue, 20 Oct 2026 13:54:49 +0000

TL;DR: Trunk-Based Development With Coding Agents

On August 13th, Amp's Will Dollman explained why Amp's trunk-based development, with engineers pushing straight to main and no pull requests, still fits SOC 2. The controls: restricted push access, signed commits, CI that blocks bad changes, and commits that link to the agent thread that wrote them.
On October 13th, at Paradigm Frontiers 2026, Quinn Slack said Amp has "never done any code review" and that "the agent thread actually can replace the PR."
On September 2nd, Thoughtworks CTO Rachel Laycock argued for moving judgment earlier and reviewing by exception instead of inspecting every change.
My take: trunk-based development with coding agents doesn't delete review. Review moves to five places: before the push, the CI gate, the trace back to the agent thread, the rollout after deploy, and owners for load-bearing code.
Qodo puts a real review in the first of those places: it reviews the agent's local changes against main with the same engine it uses for pull requests, and hands the agent your team's rules before it writes code.

What Trunk-Based Development Looks Like When Coding Agents Push to Main

Trunk-based development is a branching model where everyone integrates small changes into one shared branch, the trunk (main in most Git repos), at least once a day. Some teams use branches that live for a few hours and get a quick review. The purest version skips branches and commits straight to main, with CI (the automated build-and-test pipeline that runs on every push) catching what breaks.

Coding agents push trunk-based development to its extreme. When an agent can write, test and ship a change in one session, a pull request that waits a day for a human approval is the slowest step between the idea and production.

Paul Duvall, founder of Redacted Ventures and author of a Jolt Award-winning book on CI, said on The Agentic Review podcast (July 2nd) that "the whole PR approach of waiting for someone to review it has always been a problem." Coding agents didn't create the PR queue; they made it too long to ignore.

How Amp Ships With No Pull Requests and Still Fits SOC 2

Amp builds a coding agent, and builds it with Amp. In Amp's note "That's not SOC 2 compliant" (August 13th), Will Dollman writes that skipping pull requests "was a deliberate choice from the first commit." When SOC 2 work started, the auditors asked what Amp's change process was instead.

Will Dollman's summary in Amp's SOC 2 note: "SOC 2 doesn't require pull requests. It requires that you think about your risks." The Trust Services Criteria behind SOC 2 ask that changes are "authorized, tested, approved, and recorded," and Amp built one control for each part of that sentence.

Control	What Amp does	What it gives an auditor	What it leaves open
Restricted push access	Push access to main follows business function; every engineer can push	Authorized: a clear answer to who can change main, and why	Anyone with access can push anything
Signed commits	GitHub enforces verified signatures on main	A verifiable author on every commit	Who pushed, not whether anyone checked the change
Automated CI	Tests, infrastructure checks and security checks on every change; "Bad changes block `main`"	Tested: evidence that each change passed the pipeline	Only what the tests check; a change can edit its own tests
Audit trail	Commits link to the Amp thread that wrote them; CI/CD records the path from commit to deploy	Recorded: the diff plus the conversation behind it	A record of what happened, not a second opinion

Amp's SOC 2 note is direct about what's missing from its list of controls: "And no, code review isn't on the list." In the Hacker News thread on Amp's note, the top technical question was about approvals. One commenter asked "how are we demonstrating approval without any evidence of change reviews?" An Amp engineer replied: "We...just read the commits, and talk to each other."

Quinn Slack, founder and former CEO of Sourcegraph and now on the Amp team, went further at Paradigm Frontiers 2026 on October 13th. Quinn Slack said Amp invites teammates into the agent thread when it wants a second opinion, and that "the agent thread actually can replace the PR." His advice for everyone else: start by skipping review on 20% of pull requests, and start "risk scoring them."

Where Review Goes in Trunk-Based Development With Coding Agents

Review in trunk-based development with coding agents doesn't disappear; it spreads across five places. Amp's SOC 2 note and two Amp talks from October 13th, Quinn Slack's keynote and a talk by Amp engineer Thorsten Ball, show the pattern: the checks a pull request used to bundle are still there.

The five-stop diagram of review in trunk-based development spreads the single PR review box along the trunk. The first stop carries the most weight, because it's the last point where a finding costs one more agent turn instead of a revert.

1. Before the Push: Agent Proof Plus a Pre-Push Code Review

Thorsten Ball, an engineer on the Amp team, asks agents for "irrefutable proof that this works now" before he looks at a change: demo videos, test matrices and logs from the agent's own cloud machine. Thorsten Ball's talk also describes CI running inside the agent's machine before the push and again after it.

Birgitta BÃ¶ckeler, Distinguished Engineer at Thoughtworks, maps out where pre-integration checks belong in her article on guides and sensors for coding agents (April 2nd). Birgitta BÃ¶ckeler asks "What is reasonably fast and should be run even before integration, or even before a commit is even created?" Her examples: "linters, fast test suites, basic code review agent."

Proof and review answer different questions. Proof shows the change works; a review asks whether it follows the team's standards, misses an edge case, or breaks a caller in a file the agent never opened. In a push-to-main workflow, the pre-push routine is the only place that second question gets asked before the code lands.

AGENTS.md Pre-Push Checklist and Commit Template

Here's the pre-push section I'd add to an AGENTS.md file, plus the commit format it points to. A CLI code review of the branch against main is the closest thing to a PR review that can run before a push.

<!-- AGENTS.md: before you push to main -->
## Before you push to main
1. Run the formatter, type check and fast tests. Paste the summary in the thread.
2. Review your diff against origin/main with context: what changed, why, the ticket.
   Fix findings that hold up. Note any you skip, and why. Two review rounds at most.
3. Touching a load-bearing path (see LOAD-BEARING.md)? Stop and add the owner to the thread.
4. Put new user-facing behavior behind a feature flag. Write the revert rule first.
5. Commit with the trailers below, then push.

## Commit message
fix(billing): retry idempotent invoice writes on timeout

Why: duplicate invoices after gateway timeouts (PAY-482)
Agent-Thread: <link to the agent thread>
Flag: billing_retry_v2 (revert if the 5xx rate goes up after rollout)
Proof: unit + e2e runs in thread; review findings fixed: 2, skipped: 1 (reason in thread)

The two-round review cap in step 2 of the AGENTS.md checklist matters. An agent that reviews and fixes its own work in a loop needs a stopping rule, which I covered in how to make an agentic loop converge in AI code review.

2. The CI Gate That Blocks Bad Changes on Main

Amp's SOC 2 note describes the CI gate on main in one line: "Every change runs through the full validation pipeline: tests, infrastructure checks, security checks. Bad changes block main." In trunk-based development with coding agents, CI is the one check nobody can skip, so the checks that must never fail belong there.

Paul Duvall described a deterministic layer on The Agentic Review: rules that check things like signed commits, prompt injection and code smells, run from an agent hook. "This is not LLMs. These are rules that are in place," Paul Duvall said. I'd put the same kind of rules in CI: tests, type checks, secret and dependency scans, and architecture rules written as tests.

The weak spot of a CI gate came up in the Hacker News thread on Amp's SOC 2 note. One commenter pointed out that "the code change can just modify the same tests or verifications that will be run on it." A CI gate alone won't catch an agent that weakens a test to get green. My fix: have CI flag any commit that changes code and its tests together, and send changes to tests, CI config and policy files to a named owner.

3. The Trace: Commits That Link Back to the Agent Thread

Amp's audit trail is the most transferable idea in Will Dollman's note. Commits link to their agent threads, "so the record isn't just a diff, it's everything that led up to it." A pull request used to hold the why; now the agent thread holds it.

Few teams link commits to agent threads today. In Qodo's code quality report, Censuswide surveyed 300 U.S. engineering leaders at organizations already using AI meaningfully in the software development lifecycle (August 2026). Only 45.0% of those leaders reported traceability from AI activity to code changes.

Thorsten Ball showed why the commit-to-thread trace pays off: Amp's agent reads the earlier thread behind a change before touching it, so it learns why a teammate flagged a feature in the first place. Quinn Slack framed the goal as getting human intent "into the code, into somewhere near the code, so that a future agent can find it."

Two habits make the commit-to-thread trace work outside Amp. Put the thread link, ticket, flag and proof in commit trailers, like the template above. Keep agent threads for as long as their code runs in production, because a dead link in an audit trail is a gap. For the team side of this problem, see my piece on cognitive debt and why nobody needs the whole codebase in their head.

4. After the Deploy: Feature Flags, Monitoring and Fast Reverts

Amp moves a big part of review to production. In Thorsten Ball's talk, he asks the agent to ship a change and "monitor the rollout," and the agent wakes itself up later to report that the commit is live, inference errors didn't increase, but users see a regression. Thorsten Ball's next prompt: "Let's revert it."

Quinn Slack described the access behind Amp's rollout monitoring: Amp's agent has read-only access to production data and logs, and broader access needs a temporary grant that a human approves. New features ship behind feature flags, and the agent checks how flagged users fare before the flag comes off.

The rollout loop diagram shows the decision point after a deploy: widen or revert. Write the revert rule before the push, so the agent isn't deciding after the fact what counts as broken.

5. Human Owners for Load-Bearing Code

Thorsten Ball's rule is short: "I only review load-bearing code." He explains why the rule works: near the edges of a system there's more tolerance for errors, and "a CSS error is not the same as a broken database migration."

Amp runs with no fixed code ownership, according to Quinn Slack's keynote, which works for a team of about 20 people who all know the code. A bigger team needs a written list of load-bearing paths and a person for each. A CODEOWNERS file is the usual place for that list, and the same file can tell the agent when to stop and pull a human into the thread.

Nirmal Jingar, a senior engineering leader in enterprise AI and supply chain technology, put risk-based review in tiers on The Agentic Review (August 19th): "we have to define the governance for every problem at every level. And based on that, you can decide how fast you can move." For his low-risk systems, Nirmal Jingar said, "maybe tier three, tier four, I can be fully agentic."

The risk ladder diagram sorts trunk-based changes by how much a mistake would cost: copy and styling at the bottom, service logic in the middle, migrations, auth, billing and CI config at the top. Each rung adds one more check, and only the top rung needs a human owner before the push.

Where Trunk-Based Development With No PRs Breaks Down

Amp's SOC 2 note names the limit of trunk-based development with no PRs. "We're 20 people, mostly engineers, and everyone is close to the code," Will Dollman writes, adding that "we're not going to pretend a 2,000-person company should let everyone push to main."

Compliance is the first wall most teams hit when they drop pull requests. Emilie Schario, VP of Engineering at Anaconda and co-founder of Kilo, said on The Agentic Review (September 4th) that before changing who reviews what, you should "talk to your compliance folks and understand what your org's compliance obligations are." Qodo's glossary entry on SOC 2 compliance for code review makes the same point from the other side: neither SOC 2 nor ISO 27001 makes a pull request compliant by itself.

On the September 4th episode of The Agentic Review, Itamar Friedman, co-founder and CEO of Qodo, floated a middle path for bigger organizations: batch agent changes into a larger unit, and "before that version or subversion or subtag is merged into main, then a human is reviewing that." In Itamar Friedman's framing, "Humans are still in charge of the outcome, of the reliability, of the maintainability."

Governance worries are real at the leadership level. In Qodo's code quality report, 29.7% of the surveyed engineering leaders named governance and visibility as the area where they're most at risk of losing control. Here's how I'd compare three ways to run review once agents write most of the code.

	PR on every change	Amp-style push to main	Middle path I'd try on a bigger team
Who can change main	Anyone with merge rights, after approval	Every engineer with push access	Agents and engineers on low-risk paths; owners on load-bearing paths
Where review happens	In the PR, before merge	Agent proof before the push; rollout monitoring after	Context-aware review before the push; human review on load-bearing changes
Approval evidence	PR approvals	Signed commit plus the agent thread	Signed commit, thread link, findings handled, owner sign-off where required
Tests and CI	On the PR branch, then on main	In the agent's machine, then after push; bad changes block main	Same as Amp, plus an owner for changes to tests and CI config
Audit trail	PR comments and history	Commit links to the agent thread; CI/CD records commit to deploy	Commit trailers: thread, ticket, flag, proof
Rollout	Merge, then deploy	Feature flags, agent watches logs, revert or fix forward	Feature flags with revert rules written before the push
Best fit	Large teams, regulated code, open source	Small, high-trust teams close to the code	Teams that want speed on low-risk code and a named owner on risky code

Rachel Laycock's review-by-exception list is a good starting point for deciding which changes count as load-bearing: a fundamental architectural change, "something crossing a sensitive security boundary, a change with a huge blast radius, an unfamiliar part of a critical system," or anything the team isn't confident about.

Where Qodo Fits in Trunk-Based Development With Coding Agents

Qodo is the AI code review platform I'd wire into a coding agent's push routine, because in trunk-based development with no PRs, the review has to happen before the code lands. Qodo's Reviewer skill runs qodo review on the agent's local committed and uncommitted changes against a base branch, with the same engine Qodo uses for pull request review. Only the base commit has to be pushed; the agent's work can stay local until it's clean.

Qodo's Reviewer takes the context a diff can't carry: a summary of intent, key decisions and links to the ticket, spec or design. The agent can record deliberate decisions so Qodo doesn't flag them again, and it gets machine-readable findings it can fix and re-check. Kiran Naragund walks through the full loop in Shift Left Code Review: How Qodo Turns Your Coding Agent Into Its Own First Reviewer.

Qodo works before the first line of code exists. Qodo's Get Rules skill hands the agent the global and repository rules that apply to the current task before implementation starts. All Qodo agents run on the Context Engine, which reasons over repositories, pull request history, organizational rules and workflows, so a review looks past the changed lines to the system around them.

Qodo helps after the deploy. When a rollout goes wrong, Qodo's Codebase Wisdom skill lets the agent investigate the regression and identify the change that introduced it, using repository relationships, pull request history and the current Git state.

Most teams will keep pull requests for load-bearing paths and regulated repos, and Qodo covers those too. Qodo reviews each pull request automatically with full codebase context, and its blast radius label classifies each change's risk on GitHub, GitLab and Azure DevOps, so owners see which pull requests need the closest look. Qodo's findings are advisory, and a dismissed finding keeps its reason on record; your CI and branch rules still decide what lands on main.

For the bigger picture, Qodo's guide to shift left code review and its walkthrough of the code review process are good next reads, along with Nnenna Ndukwe's piece on why reviewing AI-generated code after the PR is too late.

Conclusion: Trunk-Based Development Moves Review, It Doesn't Remove It

Amp's no-PR workflow is a real system, not a missing step. Push access, signed commits, a CI gate and commits linked to agent threads give an auditor what a pull request used to, and Amp still reviews load-bearing code and watches every rollout.

Trunk-based development with coding agents works when the five stops are explicit: a review and proof before the push, a CI gate the agent can't talk its way past, a trace back to the thread, a rollout with a revert rule, and an owner for every load-bearing path. Skip one, and the missing pull request becomes a missing check.

Would your team drop pull requests for low-risk code if the five review stops were in place? Tell me in the comments.

FAQ About Trunk-Based Development With Coding Agents

Can you do trunk-based development without code review?

Trunk-based development without code review on every change is possible for small, high-trust teams with strong tests, as Amp's push-to-main workflow shows. The checks move instead of disappearing: proof and review before the push, CI on main, traces and rollout monitoring. Qodo reviews the agent's local changes against main before the push, so code lands already reviewed.

Is pushing directly to main SOC 2 compliant?

Pushing directly to main can be SOC 2 compliant, because SOC 2 asks that changes are authorized, tested, approved and recorded, not that they go through pull requests. Amp worked with its auditors on controls built on push access, signed commits, CI and commit-to-thread traces. Check your own obligations with your compliance team. Where you keep pull requests, Qodo records the reason behind every dismissed finding.

Where does code review run when coding agents push straight to main?

Code review runs inside the agent's session when coding agents push straight to main: the agent reviews its diff against main before the push, and humans review load-bearing changes or join the agent thread. Qodo's qodo review runs from the CLI, from MCP clients and from coding agent plugins, so the same review engine works wherever the agent does.

Can team rules guide a coding agent before it writes code?

Team rules can guide a coding agent before it writes code when the agent loads them at the start of a task instead of meeting them in review. Qodo's Get Rules skill retrieves the global and repository rules that apply to the current task before implementation starts, and Qodo's review checks the result against your standards afterward.

How does AI code review fit alongside CI checks and static analysis?

AI code review fits alongside CI checks and static analysis as the layer for questions deterministic tools can't answer, such as whether a change matches its intent or breaks a caller in another file. Keep linters, tests and scanners in CI as the gate on main. Qodo reviews changes with full codebase context before the push and in pull requests, and CI stays the gate.

Cognitive Debt: Nobody Needs the Whole Codebase in Their Head

Anna — Mon, 19 Oct 2026 15:58:49 +0000

TL;DR

On October 15th, Anthropic's Claude Code team wrote: "Nobody on the team keeps a complete mental model of Claude Code in their head, and we don't think anyone needs to." When someone needs to learn a slice of the code, they ask Claude for an explainer.
Margaret-Anne Storey, a computer science professor at the University of Victoria, defines cognitive debt as the erosion of shared understanding across a team. Her paper agrees that nobody needs the whole system in their head, and also tells teams to "resist the automation of understanding."
On April 15th, Thoughtworks put codebase cognitive debt on its Technology Radar with a "Caution" rating, because AI-driven change velocity is outpacing what teams understand.
My take: the hot take is right about the whole codebase and wrong if it means nobody needs the why. Cognitive debt builds up when intent, ownership and design decisions live in nobody's head and nobody's files.
Qodo keeps the why attached to every change. Its PR summaries capture each pull request's intent, its review checks the code against the linked ticket, and its Software Map shows how repositories connect as pull requests land.

What Cognitive Debt Means for a Codebase

Cognitive debt in a codebase is the gap between what the system does and what the team understands about how and why it works. Margaret-Anne Storey's paper From Technical Debt to Cognitive and Intent Debt (first posted March 23rd, revised April 6th) calls cognitive debt "a team-level, project-level property" and splits software health into three kinds of debt.

Debt	Where it lives	What it makes harder	One sign you have it
Technical debt	Code	Changing the system	Simple fixes keep breaking nearby code
Cognitive debt	People	Understanding the system	A change does something nobody predicted
Intent debt	Artifacts: specs, ADRs, tests, agent instructions	Knowing what the system is for	An agent ships correct code that misses the point

Margaret-Anne Storey sums up the three debts in three lines: "Technical debt makes systems harder to change. Cognitive debt makes systems harder to understand. Intent debt makes it difficult to know what the system is actually for." The third line matters most for agent-written code, because a coding agent can read your code but not the reasons behind it.

Storey's paper notes that "cognitive debt" also describes lower brain engagement in individual people using AI, and that "comprehension debt" is the gap between the code a developer can generate with AI and what they understand. The team-level version is the one that hurts a codebase, because a whole team can lose the plot while each person feels fine.

Simon Willison, co-creator of the Django web framework, described the individual kind of cognitive debt on his blog (February 15th). After prompting new features into existence without reviewing their implementations, Simon Willison wrote, "I've found myself getting lost in my own projects," and said he no longer had "a firm mental model of what they can do and how they work."

The triple debt diagram puts each debt in its own layer: code, people and artifacts. The middle layer, people, is the one an on-demand explainer touches, and the bottom layer, artifacts, is the one that holds the why.

The Hot Take: Nobody Needs the Whole Codebase in Their Head

Anthropic's Claude Code team says code review has two jobs, in an October 15th post by Addy Osmani, Morgan Westlee Lunt and Qing Wang: finding and fixing issues, and building "shared context and codebase understanding across the team." The hot take sits in a short section on the second job.

The Claude Code team asks the question directly: "If machines do most of the reading, how does anyone learn the code?" Their answer is on-demand explainers. When a team member wants to understand part of the codebase, they ask Claude to write an explainer for exactly that slice, which "takes minutes and reflects the code as it is today." Some team members have Claude build a small artifact that visualizes the code, and the team works in open Slack channels so people see what others build.

Volume is why line-by-line reading stopped working at Anthropic: in Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September, according to the Claude Code team's post. The post is also honest about the gap: "We don't have a formal process for this."

Where the Claude Code Team Is Right

The "whole codebase" half of the hot take is old news, in a good way. Margaret-Anne Storey's paper cites a 1988 field study showing that no one developer understands all of a large system, and states that "Software development has never required any one person to understand an entire system." A team needs enough shared understanding, spread across people and artifacts, to change the system safely.

Anthropic's Claude Code team is also right that trivial diffs teach very little. Their line: "A one-line copy change teaches you almost nothing. An explainer for the module you're about to change teaches you a lot." A fresh explainer also beats an onboarding doc nobody has touched since the last reorg.

Liz Fong-Jones, Technical Fellow at Honeycomb, made the attention argument on The Agentic Review podcast (September 30th). "When you try to have humans pay attention to everything, it's assigning no value to the humans," she said, because "it's saying everything is important; therefore, nothing is important." Human attention has to be spent on purpose.

Where the Hot Take Gets Risky

Margaret-Anne Storey's paper contains a warning that reads like a reply to the explainer habit. Under the heading "Resist the automation of understanding," she writes that generating explanations without the team doing the hard thinking "substitutes the appearance of understanding for the real thing and makes cognitive debt harder to detect."

Margaret-Anne Storey's paper also names the mechanism behind fake understanding: cognitive surrender, a term from Wharton researchers Steven D. Shaw and Gideon Nave for adopting AI output with minimal scrutiny. Storey's paper cites Shaw and Nave's finding that cognitive surrender inflates confidence even when the AI is wrong, so "the team feels they understand the system better than they do." An explainer you skim and accept is a quick route to that feeling.

An on-demand explainer also only knows what the code says, and the code holds the what, not the why. In Qodo's code quality report, Censuswide surveyed 500 U.S. developers at organizations already using AI meaningfully in the software development lifecycle (August 2026). 13.2% of those developers picked understanding whether code matches its intent as their single greatest AI code review challenge. An explainer generated from the code can't answer the intent question, because the intent was never in the code.

The two-column card splits what an on-demand explainer can read from the code from what it can't. The right-hand column, with the reasons, rejected options, hidden constraints and the owner, is where cognitive debt and intent debt build up when nobody writes anything down.

Emilie Schario, VP of Engineering at Anaconda and co-founder of Kilo, drew the ownership line on The Agentic Review (September 4th): "In the August 2026 era, I would say PRs still have to have a human responsible for them." For Emilie Schario, the owner's job covers "the feature and understanding: did we build the right thing to solve the user's problem?" No explainer answers that question for the owner.

How to Spot Cognitive Debt on Your Team

Cognitive debt is hard to see because it lives in people, not in files. Margaret-Anne Storey's paper lists five signals. I've added what each signal tends to look like on a team where coding agents write most of the code, plus a cheap check for each.

Signal (from Storey's paper)	What it looks like with coding agents	Cheap check
Resistance to change	People avoid an agent-built module and send the agent in instead	Which modules has no person reviewed in depth this quarter?
Unexpected results	A change does something nobody predicted, and the agent's explanation is the first anyone hears of it	Count "we didn't expect that" items in retros
Slow onboarding	New joiners find docs that say what the code does, not why	Days until a new joiner's first non-trivial PR
Lost transactive memory (who knows what)	Everyone asks their own AI session, so nobody knows who knows a system	Can the team name an owner for every service?
Low bus factor	One person, or one person's prompt history, holds the context	How many people can approve changes on each critical path?

Intent debt has its own signals in Margaret-Anne Storey's paper. Behavior drifts away from what stakeholders expect. Non-functional constraints such as performance budgets and privacy rules live in a few heads and get forgotten. AI agents need lots of clarification, burn more tokens than expected, or write code that is technically correct but misses the point.

Thoughtworks describes where the two debts lead in its Technology Radar entry on codebase cognitive debt. Weaker system understanding makes developers worse at steering AI, and combined with growing technical debt it forms a reinforcing loop. At the tipping point, in the Radar's words, "small changes trigger unexpected failures."

The loop diagram shows why cognitive debt compounds: each lap makes the next change harder to reason about. The exit arrow points at the step a team controls, which is writing down intent and sharing understanding on purpose.

6 Ways to Pay Down Cognitive Debt Without Reading Every Diff

Reading every diff is off the table at agent volume. Here are the six practices I'd use to keep a team's shared understanding healthy anyway, mostly from Margaret-Anne Storey's paper and the Thoughtworks Radar, with my notes for teams that ship agent-written code.

1. Use the Explainer, Then Explain It Back

An on-demand explainer is a fine first step. The step that builds understanding comes after it: explain the module back to a teammate, or walk through the agent-built code together before a big change. Margaret-Anne Storey's paper recommends "system walkthroughs where developers explain code they did not write." I'd rather spend 20 minutes on a walkthrough than a week chasing a regression in code nobody could explain.

2. Write the Why Down Where Agents and People Both Read It

Intent debt is the debt you can pay down with files. Architecture decision records (ADRs), tickets with acceptance criteria, tests that state their purpose and agent instruction files such as AGENTS.md or CLAUDE.md all carry intent that the code alone can't. Margaret-Anne Storey's paper adds a timing rule: "Intent is best captured at the moment key decisions are made."

Liz Fong-Jones, Technical Fellow at Honeycomb, said on The Agentic Review that teams now write down implicit assumptions for AI, and that "writing these things down is to everyone's benefit, both the new joiners in your organization as well as to the AI's benefit." With code cheap to write, Liz Fong-Jones argued, teams "can and should be doing that ADR process for every major change."

Here's the intent block I'd add to a pull request template. A coding agent can fill in most of the intent block, but the person who directed the agent should write or check the "Rejected, and why" line, because no explainer can recover a rejected option later.

<!-- .github/pull_request_template.md: intent block -->
## Why this change
Ticket: PROJ-123
Problem in one sentence:

## Decisions
- Chose:
- Rejected, and why:
- Constraint the code doesn't show (perf budget, privacy rule, API contract):

## To understand this change, read
- Module, ADR or doc:
- Person to ask:

3. Map Owners Instead of Every Line

Nobody needs the whole codebase, but every part of the codebase needs somebody. A CODEOWNERS file names who reviews which paths, which turns "who knows this?" into a lookup instead of a Slack hunt. Margaret-Anne Storey's paper lists low bus factor and lost transactive memory as cognitive debt signals, and an ownership map is the cheapest fix for both.

4. Move Human Review Up to Design and Intent

Liz Fong-Jones described how her teams moved peer review earlier on The Agentic Review: "doing peer reviews more often at the design stage or at the, you know, hey, is my specification to the agent correct?" Liz Fong-Jones said keeping those conversations human matters "because we think that it's important for engineers to have ownership of the design decisions."

Liz Fong-Jones also reframed what people check in the code itself: "does this have fidelity with the design that we as humans put together and we agreed upon?" A design review builds shared understanding before the code exists, which is cheaper than rebuilding it after. For the code-level side of agent work, I wrote about reviewing 15 agent PRs as one work package and about making the agent-to-reviewer loop converge.

5. Treat Surprises as Lessons for the Whole Team

Unexpected results are the most reliable cognitive debt signal in Margaret-Anne Storey's paper, so every surprise points at a slice of the system the team has lost. Storey's paper recommends retrospectives and post-mortems "to help collectively rebuild mental models that may have frayed." I'd add one question to every retro: which part of the system did we misunderstand, and where is the why written down now?

6. Measure Cognitive Debt With Two Cheap Signals

Margaret-Anne Storey's paper suggests tracking onboarding time, knowledge concentration and "the gap between documented intent and actual behavior." The Thoughtworks Radar adds team cognitive load and architectural fitness functions that check key constraints automatically. I'd start with two numbers: days until a new joiner ships a non-trivial PR, and how many people can approve changes on each critical path. If either number gets worse while output goes up, cognitive debt is growing.

Where Qodo Fits When Nobody Holds the Whole Codebase

Qodo is the AI code review platform I'd put in front of agent-written code when nobody holds the whole codebase in their head, because Qodo keeps the intent and the system context attached to every change. Qodo's Context Engine reasons over repositories, pull request history, organizational rules and workflows, so a review looks past the changed lines to the system around them.

Qodo's PR summaries read the full codebase instead of only the diff. Each Qodo summary captures the intent of the change, estimates review time and adds Walkthroughs: a Description, a Diagram and a High-Level Assessment of what changed, how and why. A reviewer starts with the why before reading a line, which is the opposite of cognitive surrender.

Qodo also checks code against the intent written outside the repository. Qodo's ticket context pulls the linked ticket from Jira, Linear, Azure DevOps, Monday.com, GitHub Issues or GitLab Issues, and the review flags missing or incomplete requirements and changes that don't clearly support the stated goal. An optional Qodo setting flags changes that look unrelated to the ticket, one of the ways intent debt shows up in a PR.

Qodo's Software Map gives the team the system view nobody keeps in their head. The Software Map shows how repositories connect, which downstream repositories depend on a change, which services consume a contract and where review findings pile up. Qodo derives the map from the code and updates it as pull requests land, so there's no architecture diagram to keep current.

Qodo's PR chat keeps decisions on the record. A reviewer can ask Qodo to explain a finding inside the pull request, or dismiss it in plain language, such as "@qodo this is intentional, we want to keep the legacy behavior," and Qodo records the dismissal with the reason. The next person finds the why next to the code.

A Qodo PR summary is still an AI explanation, so I treat it the way Margaret-Anne Storey suggests treating any explainer: as material for a person to reason with, with the ticket and the system map attached. For more on context, see my piece on how AI coding agents get codebase context and Qodo's guide to AI code review.

Conclusion: Nobody Needs the Whole Codebase, Everyone Needs the Why

Anthropic's Claude Code team is right that nobody needs the whole codebase in their head, and software never worked that way anyway. Cognitive debt starts when the team stops sharing the theory of the system and nobody writes down why the code is the way it is.

Use explainers, then explain the code back. Write intent into ADRs, tickets, PR templates and agent instruction files. Keep an ownership map, move human review up to design, mine every surprise for a lesson and track two cheap signals. For the review side, Qodo's code review best practices is a good next read.

How does your team keep shared understanding now that agents write most of the code? Tell me in the comments.

FAQ About Cognitive Debt

What is cognitive debt in software development?

Cognitive debt in software development is the erosion of a team's shared understanding of how and why a system works. Margaret-Anne Storey calls it a team-level property that grows when AI-written change outpaces what people understand. Qodo keeps each change's intent and system context visible in review, so the team keeps up.

Does every developer need to understand the whole codebase?

No developer needs to understand the whole codebase, and large systems have always depended on understanding spread across a team. What a team needs is an owner for every part and a written why for key decisions. Qodo's Software Map shows how repositories connect, so nobody has to memorize the system.

Can AI explainers replace code review for sharing knowledge?

AI explainers can't replace code review for sharing knowledge on their own, because an explainer generated from code knows the what but not the why. Pair explainers with walkthroughs and written intent. Qodo's PR summaries include the change's intent and the linked ticket, which gives reviewers the why that a code-only explainer misses.

Can code review use requirements from outside the repository?

Code review can use requirements from outside the repository when the review tool reads the linked ticket. Qodo pulls title, description and other fields from Jira, Linear, Azure DevOps, Monday.com, GitHub Issues and GitLab Issues, then flags missing requirements and changes that don't support the ticket's goal.

How does AI code review keep codebase context current?

AI code review keeps codebase context current by learning from the code and the pull requests as they change, instead of relying on curated docs. Qodo's Context Engine indexes repositories and pull request history, and Qodo's Software Map updates as pull requests land, so context doesn't depend on someone updating a diagram.

How to Make an Agentic Loop Converge in AI Code Review

Anna — Mon, 19 Oct 2026 14:09:52 +0000

TL;DR

On October 15th, Anthropic's Claude Code team wrote that one pull request (PR) went through "more than fifty rounds of review and fixes overnight before its author stopped it." The agentic loop between their coding agent and their AI reviewer had no exit.
When the Claude Code team ran git blame on what their reviewer kept flagging, about 59% was code that had been there since the reviewer's first pass. Late rounds were mostly finding old bugs.
A paper by Ruihan Lin and Jiheng Zhang, revised in September, treats AI review as a capacity decision. In their calibrated study, a review-everything rule fell up to 57.6% short of the best plan when maintainers weren't the bottleneck.
My recipe for an agentic loop in AI code review: cap the rounds, re-review only the new diff, flag bug classes, never repeat a finding, label pre-existing code and turn repeat findings into rules.
Qodo builds the exit into the loop. Its Agentic Toolbox tells coding agents to run one review-and-fix pass by default, stop when another round won't make meaningful progress, and give every finding an explicit outcome.

What an Agentic Loop Looks Like in AI Code Review

An agentic loop is a model calling tools in a cycle until a task is done: act, check the result, act again. Sydney Runkle of LangChain describes a second layer in The Art of Loop Engineering (June 16th): a verification loop, where a grader checks the agent's output and sends feedback when it falls short. An AI reviewer on a pull request is that grader.

The agentic loop in AI code review has two agents in it:

A coding agent writes the change and opens a PR.
A code review agent reads the diff and posts findings.
The coding agent fixes every finding and pushes a commit.
The new commit triggers another review, until the reviewer comes back clean.

"Until the reviewer comes back clean" is the weak spot of the review loop. It assumes the AI reviewer eventually runs out of things to say. Two language models can keep each other busy all night, and nobody is awake to call time.

Why a Review Loop Between Two Agents Doesn't Stop on Its Own

Four forces keep a review loop between a coding agent and an AI reviewer running:

Agents fix nits. Anthropic's Claude Code team put it plainly in their October 15th post: "A person can wave off a nit in seconds. An agent fixes it, which means another commit and another round of review."
Each round re-reads old code. A full re-review reads the whole PR again, including lines that were there in round one.
Agent runs are random. Bjarni Haukur Bjarnason, AndrÃ© Silva and Martin Monperrus studied 60,000 agent runs for On Randomness in Agentic Evals (revised March 25th). Scores varied even at temperature 0, and runs on the same task diverged "often within the first few percent of tokens." My reading: a fresh review pass over the same code won't land on the same findings either.
Reviewers reject good work. In the SWE-Review benchmark data (July 7th) that Ruihan Lin and Jiheng Zhang used to calibrate their paper, the AI reviewer asked for revisions on 5.8% to 25.9% of changes that already resolved their issue, depending on the generator. Each false rejection buys another round.

Signs Your Agentic Loop Will Converge or Run All Night

Signal	Loop that converges	Loop that runs all night
Round limit	Hard cap, then the author steps back	None
What re-review reads	Only the diff since the last round	The whole PR, every round
Repeated findings	Never posted twice	Same finding, new wording
Finding scope	One finding per bug class	One comment per line
Code the PR didn't touch	Labelled pre-existing, not blocking	Treated as the author's bug
Exit condition	No new blocking findings	Reviewer runs out of things to say

The right-hand column of the convergence table is the default when you wire a coding agent to an AI reviewer and change nothing else.

What the 50-Round Pull Request Teaches About Review Loops

Anthropic's Claude Code team described its review flow in an October 15th post by Addy Osmani, Morgan Westlee Lunt and Qing Wang. On their PRs, every finding has to be fixed or resolved with a reason, and "often an agent picks up the fix overnight." One CLI (command-line interface) PR went through more than fifty rounds that way before its author stopped it. The post's verdict: "Review has to converge."

The git blame result is the part of the 50-round story that matters most for anyone building an agentic loop. About 59% of what the reviewer kept flagging was code that had been there since its first pass. In the Claude Code team's words, "The reviewer was rarely finding new bugs, it was finding a few more old ones each round."

The stacked bar shows what the reviewer's repeat flags were made of in the 50-round story. The big block, about 59%, points at code the reviewer had already read in round one, which was never part of any later fix.

The Claude Code team admitted they had "gotten used to running several rounds by default, since each pass catches something new." Their fix had four parts:

A round cap. After three rounds, the reviewer asks the author to step back and reconsider the approach.
Diff-only re-review after the first few passes.
Bug classes. The reviewer flags the class of bug, so the author fixes every instance in one go.
No repeats of findings already posted.

The Claude Code team now tracks rounds-to-pass alongside recall, and their written priority is "catching real bugs first and cutting review rounds second." I like that order. A review loop that converges in one round but misses the bug hasn't saved anyone time.

Why More AI Review Rounds Can Cost More Than They Catch

Ruihan Lin and Jiheng Zhang, researchers at the Hong Kong University of Science and Technology, model the path from coding agent to human approval as a queue in "When to Screen, When to Bypass: LLM-Judges in Resource-Scarce AI-Human Workflow", first posted March 14th and revised September 16th. Their headline: "AI review is a capacity decision as much as an accuracy decision."

Ruihan Lin and Jiheng Zhang split AI reviewer mistakes into two kinds, and each one bills a different resource. A false acceptance passes a defective change and costs maintainer time later. A false rejection sends a merge-ready change back and costs another coding-agent run.

The Lin and Zhang calibrated study puts numbers on the trade-off. A rule that reviews everything fell up to 57.6% short of the best plan when maintainers weren't scarce, and adaptive routing beat both "always review" and "never review" on 62.7% of the capacity grid. The paper even finds a phase where "an informative reviewer is deliberately left idle because its rework displaces new work."

The phase chart shows the four regimes in Ruihan Lin and Jiheng Zhang's single-category model as maintainer capacity grows: full review, reviewer saturation, deliberate throttling and bypass. In the throttling phase a good reviewer gets held back, because its false rejections eat coding-agent time. The paper studies routing, not round caps, but my reading for review loops is simple: every extra review round has a price, even a round that finds something.

Human attention is the other bill an overnight review loop runs up. For Qodo's code quality report, Censuswide surveyed 500 U.S. developers at organizations already using AI meaningfully in the software development lifecycle (August 2026), and 36.4% said reviewing AI-generated code takes the same time but more cognitive effort. Fifty rounds of agent chatter is a lot to read with your morning coffee.

6 Rules to Make an Agentic Loop Converge in Code Review

These are the six rules I'd write into any agentic loop where an AI reviewer talks to a coding agent. Rules 1 to 4 come from the Claude Code team's fix. Rules 5 and 6 are my additions.

1. Cap the Rounds, Then Make the Author Step Back

Give the review loop a hard number. The Claude Code team uses three rounds, and that's where I'd start. At the cap, the question changes from "what's wrong with this line?" to "is this the right approach?" Send the PR to a person with a summary of what's open and where agent and reviewer disagree.

2. Re-Review Only the New Diff After the First Passes

The first one or two review rounds should read the whole PR with repository context. After that, the reviewer reads only the commits since its last review, plus the code they touch. Diff-only re-review goes straight at the 59% problem: code the reviewer already read stops coming back as fresh work.

3. Flag the Class of Bug, Not One Line

Four comments about four missing timeouts become four fixes, four commits and four more reviews. One finding that says "outbound HTTP calls in these 4 handlers have no timeout" becomes one commit. Ask your code review agent to group findings by bug class and list every location.

4. Never Repeat a Finding, and Remember Decisions

Give every finding a stable ID and keep a ledger of what the reviewer already posted. When the author resolves a finding with a reason, such as "intended, see architecture decision record ADR-12," the next round should read that reason and stay quiet. Without a ledger, the same finding comes back in new words and the coding agent "fixes" it again.

5. Label Pre-Existing Code Instead of Blocking on It

Bugs in lines the PR didn't touch are real, but they don't belong to this PR. Label them pre-existing, file them and keep them out of the exit condition. If that pile gets big, my bug triage guide for AI review findings covers how I'd sort it.

6. Move Repeat Findings Into Rules and Lint

When the AI reviewer flags the same thing across many PRs, fix it at the source. The Claude Code team does that with a skill, a lint rule or an update to their instruction files. Deterministic checks go in lint, and conventions go in rules the coding agent loads before it writes code.

Liz Fong-Jones, Technical Fellow at Honeycomb, said on The Agentic Review podcast (September 30th) that "it's a waste of your human's time to be acting as human linters," and that "part of code review is toil." A coding agent re-fixing the same convention every round is toil with a token bill.

Loading rules up front matters because coding agents don't always follow standards on their own. In Qodo's code quality report, only 34.6% of the 500 surveyed U.S. developers said agents always follow organizational standards. I wrote more on that in how AI code review enforces coding standards.

A Review Loop Policy You Can Copy

Here's the six-rule review loop policy as config. The YAML isn't any tool's format; treat it as a spec for whoever wires your coding agent to your AI reviewer.

# review-loop.yaml: stop rules for an agent-to-agent review loop
review_loop:
  max_rounds: 3                    # rule 1: hard cap
  on_cap: summarize_and_ask_human  # what's open, what was tried, disagreements
  full_review_rounds: 2            # rule 2: rounds 1-2 read the whole PR
  later_rounds_read: diff_since_last_review
  findings:
    group_by_bug_class: true       # rule 3: one finding, every location
    skip_already_posted: true      # rule 4: stable IDs in a ledger
    respect_resolved_reasons: true
    preexisting_code: label_only   # rule 5: file it, don't block on it
  exit_when:
    - no_new_blocking_findings
    - same_findings_as_last_round  # no progress, so stop
  propose_rule_after_repeats: 3    # rule 6: seen on 3+ PRs, make it a rule

The flowchart shows the three exits every review loop needs: the round cap, "no new blocking findings" and "no progress since last round." Only one path goes back to the coding agent, and it passes all three checks first.

How to Measure Whether Your Review Loop Converges

Rounds-to-pass is the first number to watch, next to recall, because a loop that converges by missing bugs is just a quiet loop. Here's the dashboard I'd build for an agentic loop in AI code review:

Metric	What it tells you	Healthy direction	Where to get it
Rounds-to-pass	How long agent and reviewer argue per PR	Down, mostly 1 to 2	Review events per PR
Cap hits per week	PRs where the approach is the problem	Low, each read by a person	Loop logs
Repeat-finding rate	Findings posted again in a later round	Near zero	Ledger with stable IDs
Findings on pre-existing lines	Reviewer re-mining old code	Down after diff-only re-review	`git blame` on flagged lines
Dismissed as wrong or intentional	Reviewer noise	Down as rules improve	Resolution reasons
Recall on known bugs	Whether the cap hides real misses	Flat or up	Replay of past incident PRs

The "dismissed as wrong or intentional" row in the review loop dashboard is the cheapest noise signal you have. Anthropic's Claude Code team sorts every reviewer comment by how the person on the PR responded: fixed, wrong, intentional or didn't matter. With two agents in the loop, the coding agent's skip reasons give you the same data.

Gil Elbaz, co-founder and Chief AI Officer at Onyx Security, raised the cost of agents talking to agents on The Agentic Review (July 22nd). Gil Elbaz asked whether many agents talking to each other nonstop pays off, and answered: "Maybe. But maybe there needs to be certain rules in place and guardrails in place around that as well." Itamar Friedman, co-founder and CEO of Qodo, replied: "We call it bot gossip."

Where Qodo Fits in a Converging Review Loop

Qodo is the AI code review platform I'd put inside any agentic loop, because Qodo treats convergence as part of review. The Qodo Agentic Toolbox brings Qodo review, rules and codebase context into the coding agent you already use, through a CLI, MCP (Model Context Protocol), plugins for Claude Code and Codex, and Kiro Power.

As of October 2026, the Qodo Agentic Toolbox ships a default template for your AGENTS.md or CLAUDE.md file, and the template reads like a review loop policy:

"Perform one review-and-fix pass by default."
"Continue with another round when it is useful to validate meaningful fixes or when the user requests it, within an agreed limit."
"Evaluate every finding against the code and intent; fix only findings that are sound and in scope."
Finish when the findings are addressed or another round wouldn't make meaningful progress, "and report what remains."

Qodo's local pre-PR review, the shift-left code review step of the loop, takes the coding session's context along with the diff: intent, key decisions and links to the ticket or design. Qodo's docs name a use for that context that matches the never-repeat rule: "Record deliberate decisions so the reviewer does not re-flag them as issues."

Qodo's Review Resolver skill closes the loop on the PR side. The coding agent resolves only the findings you scope, by severity, category or a single finding, and every Qodo finding ends as fixed, skipped with a reason or reported without changes. Nothing is silently ignored.

Qodo also turns repeat findings into rules. Qodo's Rule Miner learns rules from review comments developers accepted and acted on, and dismissed suggestions weaken an active rule's signal over time. Qodo's rule analytics show how often each rule passes, gets violated or gets merged anyway, so noisy rules show up before they feed another loop.

Itamar Friedman, co-founder and CEO of Qodo, said on The Agentic Review with Liz Fong-Jones: "maybe we will almost completely rely on AI code review agents, AI quality agents, to work together with the coding agent in tandem." Qodo's loop defaults give that tandem a stop condition. For review across many agent PRs, see my piece on reviewing 15 agent PRs as one work package and Qodo's guide to agentic workflows.

Conclusion: Give Every Agentic Loop an Exit

A coding agent and an AI reviewer will happily trade commits until morning. The 50-round PR from Anthropic's Claude Code team shows the pattern, and the git blame result shows the cause: late rounds mostly dig up old code.

Write the exit before you wire the agentic loop. Cap rounds at three, re-review only the new diff, group findings by bug class, keep a ledger, label pre-existing code and turn repeat findings into rules. Then watch rounds-to-pass next to recall. For the human side, Qodo's code review best practices and its guide to AI PR review are good next reads.

What's the highest round count you've seen between your coding agent and your reviewer? Tell me in the comments.

FAQ About Agentic Loops and AI Code Review

What is an agentic loop in AI code review?

An agentic loop in AI code review is the cycle where a coding agent writes a change, an AI reviewer posts findings, the agent fixes them and the reviewer checks again. The loop ends on a stop condition such as a round cap or no new blocking findings. Qodo's Agentic Toolbox runs one review-and-fix pass by default and stops when another round wouldn't make meaningful progress.

How many review rounds should a code review agent run?

A code review agent should run one or two full rounds and stop at a hard cap, such as three. Anthropic's Claude Code team caps at three rounds, then asks the author to step back. Qodo's default template allows extra rounds only within an agreed limit and reports what remains.

What is loop engineering?

Loop engineering is the practice of designing the loops around an AI agent: the agent loop, verification loops with a grader, event triggers and stop conditions. A review loop between a coding agent and an AI reviewer is a verification loop. Qodo acts as that grader, and every Qodo finding ends as fixed, skipped with a reason or reported.

How can AI code review avoid generic noise?

AI code review avoids generic noise with repository-specific context, team rules and a memory of decisions already made. Qodo reviews with your codebase context and Review Standards, and its pre-PR review records deliberate decisions so they aren't flagged again.

Could AI review findings create another bottleneck for the team?

AI review findings create a bottleneck when every finding triggers a new commit and a new round, or when findings pile up for a person in the morning. Round caps and diff-only re-review tie the finding count to new code. Qodo gives every finding an explicit outcome, so a person reads a short summary instead of a long thread.

How do we manage human review capacity when agents write most of the code?

Manage human review capacity by letting the agentic loop handle routine findings and sending people the PRs that hit the cap or touch risky code. Qodo runs review before and after the PR exists, so human time goes to design calls.