Addy Osmani argues that agentic coding tools are now highly effective and improving rapidly. The consequence is a shift in engineering: the hard part is no longer writing code but deciding whether to trust it. As a result, code review has become the most leveraged skill in software engineering today.
How you approach review depends heavily on context: a solo developer with no users and a team maintaining a decade-old system face very different problems and constraints.
What 2026 data shows
Multiple independent datasets from 2025–2026 align on a common pattern: AI sharply increases raw output while reducing quality and reviewability, so review work grows. Key findings cited in the article:
-
Faros AI: instrumentation of 22,000 developers across 4,000 teams (March 2026 data). Positive effects on throughput, but also:
- code churn +861%;
- incidents-to-PR ratio +242.7%;
- per-developer defect rate rose from 9% to 54%;
- median review duration +441.5%, with time-to-first-review and average review time roughly doubling;
- PRs merged with zero review +31.3%.
-
CodeRabbit (December 2025): analysis of 470 open source PRs (320 AI-coauthored, 150 human-only) found AI changes carried ~1.7× more issues. Logic/correctness problems were up ≈75%, security issues 1.5–2× more common, and readability problems more than tripled.
-
GitClear: through 2025 productivity data shows daily AI users produce ~4× the raw output of nonusers, but compared to those users’ own output a year earlier the real productivity gain was ≈12% — i.e., ~4× code for about a tenth more delivered value.
-
GitHub: Copilot review exceeded 60 million reviews, a 10× increase in under a year; more than one in five reviews on the platform involves an agent.
Together, these datasets support a single conclusion: we poured machine-speed output into systems designed for human-speed work, and the bottleneck moved to verification — review is where the cost is paid.
Everyone is solving a different problem: blast radius matters
How much review a change needs hinges almost entirely on its blast radius — what happens if it breaks? Three variables determine your position:
- Blast radius: what are the consequences of failure (none, angry users, money/PII at risk)?
- How long the code will live: throwaway prototype vs. long-lived codebase?
- How many people need to understand it: a solo author or a team sharing ownership?
The same diff looks very different at opposite ends of this spectrum. Solo greenfield projects with no users can reasonably lean on tests and automation and accept lighter review. The danger is deferring verification without a safety net: skipped review becomes deferred work at higher cost. When a project gains users, the knowledge-sharing and bug-catching roles of review suddenly matter. At the far end, large organizations with long-lived codebases feel every alarming number at full strength: duplication and poorly understood changes become future incidents and maintenance costs.
So the point is not simply "enterprises be careful, solos relax." It’s that the purpose and rules of review change with your position on this spectrum.
What review is for now
Review was built to check an author’s reasoning. Agents do reason and often produce visible thinking traces, but that reasoning is usually discarded when the diff is produced. The reviewer therefore must reconstruct intent that was never written down, which is slower and harder.
This is fundamentally a tooling problem: capture the agent’s reasoning as a decision log attached to the PR (what it tried, what it ruled out) and much of the reconstruction cost vanishes. That does not eliminate human judgment: models catch many bugs, but they do not decide whether the change was the right thing to build in the first place.
Tools are good, but heterogeneous — run multiple types
Current AI reviewers work well but disagree on what to flag. The practical move is not to pick one ‘‘best’’ tool, but to run multiple reviewers with different characteristics.
Examples cited:
- CodeRabbit: widely deployed, strong on breadth; Martian benchmark (Jan–Feb 2026) F1 around 49%.
- Greptile: trades precision for recall; in one benchmark detected ≈82% of bugs vs. CodeRabbit’s 44%, at the cost of more false positives.
- Anthropic’s Code Review: reports under 1% of findings marked incorrect internally, and increased their rate of PRs receiving substantive review from 16% to 54%.
A real-world experiment ran four reviewers (CodeRabbit, Sentry Seer, Greptile, Cursor BugBot) on 146 PRs and 679 findings over 3.5 weeks: of 617 distinct flagged locations, 93.4% were caught by exactly one tool, 6% by two, and none by all four. Each tool excelled at different problem classes. The lesson: heterogeneity surfaces bugs no single tool (or human) would find alone.
Should we let AI do more reviewing?
Machines already review more code than humans in practice. The question is whether to do that deliberately. AI review is effective: Anthropic reports <1% of findings marked wrong, tools catch bugs humans miss, and models don’t tire. Humans, however, are visibly failing to keep up: zero-review merges and increased review times show the strain.
Loop engineering tends to automate checking as well as writing: an agent writes, another reviews, a third judges. That can create a closed loop of models with correlated blind spots. A confident ‘‘looks good’’ that no human can interrogate is borrowed confidence. Therefore the human role shifts up: from reading every diff to owning high-level decisions, accountability, high-blast-radius gates, and auditing the system (human-in-the-loop becomes human-on-the-loop).
Two real workflows illustrate extremes:
-
Addy Osmani: for his projects he points Claude Code or Codex at batches of incoming PRs to triage: high-level safe-to-merge candidates, items needing more work, and high-risk PRs. The AI triage allocates his attention; he still makes merge decisions.
-
Kun Chen (ex-Meta L8, solo builder shipping ~40 PRs/day): largely stopped line-by-line review by writing detailed upfront plans, running many agents in parallel against the plan, and recording intent up-front. He also built an automated review gate and stays on escalation. This works for an expert solo builder but would be risky if copied wholesale into a large team with many users.
The right amount of human oversight is a dial set by blast radius.
Practical recommendations
- Stop reviewing everything to the same depth: allocate human attention where being wrong is costly.
- Tier by risk, not by author: a config change may get a linter and a glance; a payments change deserves types, tests, two different AI reviewers, a human owner, and a security pass.
- Fast-fail the expensive tail: use inexpensive signals (file types, patch size) to predict high-maintenance PRs and circuit-break them early.
- Raise the bar for what you will review: require an intent statement, reasonable diff sizes, test output, and proof tests were run before accepting review work.
- Keep PRs small and deliberate: Faros reports agent PRs are on average 51% larger; reviewer engagement strongly predicts merges.
- Read test changes carefully: agents sometimes rewrite assertions instead of fixing behavior; mutation testing helps verify test efficacy.
- Treat CI as a strict wall: watch for removed tests, skipped lint, lowered coverage thresholds, duplicated helpers, and untrusted input fed into prompts (prompt injection). Agents may weaken CI to pass; deterministic gates resist confident prose.
- A human owns the merge: treat AI review as sensor data, not a final verdict.
For solos with no users, tiering, test discipline, and strict CI are often sufficient. For large organizations, these practices are the baseline; intake and triage rules determine whether review scales or quietly collapses.
Conclusion: writing got cheap, understanding did not
Code writing is getting cheaper and more solved; understanding remains as costly as ever. Teams that succeed will be those that build review systems they can trust — tiered, evidence-required, deliberately heterogeneous, and with a human owning the merge. Agents have made proving that code works central to the job, not an afterthought. That shift elevates understanding and accountability as the most durable and valuable skills in software engineering today.
