Code Is the New Assembly. Stop Reviewing It.

Gergely Orosz, the voice behind The Pragmatic Engineer with over a million subscribers, recently posted something that should alarm every engineering leader: he "cannot help but see the concept of code reviews fading away." A rock-solid, experienced engineer he'd spoken with had been reviewing all their AI-generated code — until Fable arrived. Then they stopped, except for key parts of the product. The review wasn't catching enough to justify the cost.

📖 Read the full version with charts and embedded sources on AgentConn →

View original post on X →

This isn't one person being lazy. It's a structural shift that three independent signals are now pointing to simultaneously: The Pragmatic Engineer's deep-dive on what's happening to code reviews, Alibaba's open-code-review tool exploding to 46K GitHub stars, and context-mode hitting 27K stars by making 98% of code output invisible. The convergence tells a single story: code is becoming an intermediate representation, and the industry is building the toolchain to stop reading it.

We wrote about the bottleneck quantitatively back in June — the 4.6x longer wait times, the 67% first-review failure rate, the 91% increase in review times. Those numbers described the problem. This article is about what comes after: the emerging consensus that the problem won't be solved by reading code faster. It'll be solved by making code irrelevant to read.

The Compiler Metaphor Nobody's Taking Far Enough

In a follow-up post, Orosz stated the thesis even more directly: "You don't generate code for PEOPLE but for the machine / for functionality. Does it work? Is it correct? If yes: code no longer matters and soon a human will probably not read it."

View original post on X →

This is the compiler metaphor taken to its logical conclusion. In the 1960s, assembly language programmers argued that compiler-generated code needed human review. They were right — early compilers produced inefficient, sometimes incorrect output. But within a decade, the quality of compiler output crossed a threshold where reviewing it became counterproductive. Nobody reviews GCC's register allocation decisions. Nobody audits LLVM's loop unrolling. The output is verified by running tests, checking benchmarks, and validating behavior — not by reading the generated code.

AI-generated application code is on the same trajectory. The quality isn't there yet for all domains (Orosz himself notes this won't apply to Linux kernel-level work "where there is no AI to write that code which has never been written before"). But for the vast majority of business application code — your CRUD APIs, your React components, your data pipelines — we're approaching the crossover point where human review adds less value than automated verification.

The crossover point: When the cost of human review (time, cognitive load, reviewer fatigue) exceeds the marginal bugs it catches beyond what automated verification already finds. Carnegie Mellon and Stanford researchers studying 802 developers found that the share of PRs receiving written human feedback has already fallen from 39% to 21% — reviewers are voting with their attention.

The Reading vs. Writing Asymmetry

ThePrimeagen articulated the underlying asymmetry in a conversation with Lex Fridman: the difference between writing code and reading code is the difference between two fundamentally different cognitive activities. Writing is creative and directional — you know what you're building. Reading someone else's code (or an AI's code) requires reconstructing intent from syntax, and that reconstruction is expensive.

Addy Osmani, engineering lead at Google, nailed why this asymmetry is getting worse in his June 2026 essay "Agentic Code Review": "Agents made writing code almost free. Understanding code still costs what it always did." Human authors carry their intent into the review — they can explain why a particular approach was chosen. Agent reasoning is typically discarded, so reviewers must reconstruct the "why" from scratch.

View original post →

The numbers Osmani cites from Faros AI are staggering:

Code churn up 861% across 22,000 developers
Incidents-to-PR ratio up 242.7% — more PRs are causing more production incidents
Per-developer defect rate rose from 9% to 54%
PRs merged with zero review up 31.3%

That last figure is the quiet crisis. Nearly a third of all PRs are shipping with no human eyes at all. Not because teams decided review was unnecessary — but because the review queue is so deep that changes are merging before anyone gets to them.

Three Tools, One Direction

The convergence signal that prompted this article comes from three tools that, independently, point toward code-as-IR:

1. Alibaba's open-code-review (46.3K Stars)

Open Code Review is a hybrid code review CLI that's been running inside Alibaba for two years before being open-sourced. The key insight in its architecture: it splits review into deterministic engineering (file selection, template-based rule matching, comment positioning) and LLM judgment (dynamic context retrieval, scenario-tuned prompts). The deterministic layer handles what must be correct. The LLM handles what requires judgment.

This is exactly the compiler model. Compilers don't use heuristics for register allocation — they use proven algorithms. They use heuristics for optimization decisions where correctness isn't at stake. Open Code Review applies the same split to code review.

On their AACR-Bench (50 repos, 200 PRs, 10 languages, 1,505 annotated issues validated by 80+ senior engineers), they claim higher precision and F1 than Claude Code while using roughly one-ninth the tokens. The deliberate trade-off: lower recall, because in review, false positives are more damaging than missed issues.

2. mksglu/context-mode (26.7K Stars)

Context Mode is an MCP server that sandboxes tool output so AI agents process data without flooding their context window. The headline benchmark: 315 KB of raw output becomes 5.4 KB — a 98% reduction.

Why does this matter for the code-as-IR thesis? Because Context Mode is a tool built for a world where even the AI doesn't need to see the code. It's not helping humans read AI output. It's helping AI avoid generating readable output in the first place. The agent runs scripts that process data and print only results. The code is generated, executed, and discarded — never presented for human consumption.

This is the IR pattern made explicit: code is generated as a means to an end (computing a result), not as an artifact to be read.

3. Semgrep's Auto-Approve Vision

Daghan Altas at Semgrep published "The End Is Nigh for Code Review" on October 9. His proposal: auto-approve routine changes when verification evidence meets policy, and escalate only consequential changes to humans.

View original post →

The data backing this is from a Carnegie Mellon and Stanford study of 802 developers across nearly 200,000 PRs through April 2026:

PR volume grew 3.1x while the reviewer pool grew only 1.5x
The share of PRs receiving written human feedback fell from 39% to 21%
AI-authored PRs took ~20% longer from first human review to merge

Meanwhile, GitHub's monthly commits doubled from 1.4 billion to 2.9 billion between April and August 2026. By August, GitHub reportedly saw more agent-authored PRs than human-authored ones.

Semgrep's pilot runs four automated checks (knowledge transfer, product alignment, design, correctness) and targets under 1% of PRs needing human review at steady state. That's not "AI-assisted review." That's review elimination for the long tail.

Ankit Jain's Five-Layer Trust Model

The most complete framework for what replaces code review comes from Ankit Jain, CEO of Aviator, who first argued in a Latent.Space guest post that "human-written code died in 2025, and code reviews will die in 2026." He then presented a refined version at AI Engineer World's Fair 2026:

His five-layer trust model, inspired by the Swiss cheese model of accident prevention:

Compare multiple options — Run several agents on the same task, rank outputs by verification results, diff size, and dependency count
Deterministic guardrails — Tests, type checks, linters, contract verification, organization-wide invariants
Human-defined acceptance criteria — BDD-style behavior specs that machines verify, so humans don't read implementation unless something fails
Permission systems as architecture — Limit each agent's file access to the task scope; escalate sensitive changes (auth, schema, dependencies) to humans
Adversarial verification — Separate the coding agent from the verifying agent; optionally add an agent that tries to break the code

View original post on Latent.Space →

Notice what's absent from every layer: humans reading code. The human role in this model is defining intent (layer 3), setting boundaries (layer 4), and making architectural decisions. The verification is automated. The code is an IR that the verification pipeline processes — not an artifact that humans consume.

⚠️ The Contrarian Corner: Code Review Is How Teams Think Together

Addy Osmani's counterargument deserves serious weight: code review isn't just a bug-finding process. It's how teams share knowledge, align on architectural decisions, and maintain collective ownership of the codebase. His multi-tool experiment found that when four AI review tools ran on the same 146 PRs, 93.4% of flagged locations were caught by exactly one tool — meaning no single tool (and no single AI reviewer) provides comprehensive coverage.

The risk of the IR model is that you end up with an organization where only the AI "understands" the codebase. When something breaks in a way that doesn't match your acceptance criteria — and it will — nobody has the mental model to debug it. Jesse Skinner's "Cleaning Up After AI Rockstar Developers" describes exactly this failure mode: a codebase that nobody can reason about, requiring 10GB of RAM to compile, generated across dozens of disconnected AI sessions.

View on Hacker News →

The honest answer is that both sides are partially right. Code review as we know it — line-by-line human reading of diffs — is dying because the volume makes it impossible. But the functions that code review served (knowledge sharing, alignment, quality control) need to migrate somewhere. The five-layer trust model is a plausible destination for quality control. The knowledge-sharing and alignment functions are still unaccounted for.

What the Community Is Saying

The Pragmatic Engineer's September 2026 deep-dive captured seven distinct approaches teams are taking, and the spectrum is telling:

Teams that dropped review entirely:

Duckbill Group made reviews optional — PRs merged rose from 353 to 684 (+94%), median merge time dropped from 26 hours to 1 hour
Mike Julian, Duckbill CEO: "We ditched code review at Duckbill Group (mostly)"

Teams doubling down on review but changing what they review:

Jackie Luo, Sigil CEO: "Understand the product over the code"
Multiple teams reviewing plans, tests, and database schemas instead of implementation code

Teams watching quality metrics deteriorate:

CircleCI's 2026 data: feature-branch throughput up 59% YoY, but main-branch throughput actually fell
Opsera reports AI-generated PRs wait 4.6x longer before a human reviewer even opens them

Teams using AI to review AI:

GitHub Copilot code review: 60M+ reviews processed, 10x growth in under a year
Anthropic's Code Review for Claude Code: "substantive review rose from 16% to 54%"

The Hacker News thread "There is an AI code review bubble" — 351 points, 249 comments — captures the skepticism that many practitioners feel. The top arguments: most AI review tools are "fancy linters" that miss the bugs humans actually worry about, and the real value of review was never bug-finding but knowledge sharing.

View on Hacker News →

The pattern across all these responses isn't disagreement about the problem — it's disagreement about how fast to let go of the old model. The teams shipping fastest have stopped reviewing code. The teams most worried about quality are reviewing different artifacts (specs, tests, schemas). Almost nobody is claiming that scaling human line-by-line review is the answer.

What This Means for You

If you lead an engineering team, here's the practical framework:

Stop doing:

Requiring human review of every PR regardless of blast radius
Measuring review coverage as a quality metric (it measures effort, not outcomes)
Treating AI-generated code review comments as equivalent to human review

Start doing:

Classify changes by blast radius. Auth logic, database schemas, API contracts, and payment flows get human review. CRUD endpoints, UI tweaks, and test additions get automated verification only.
Write acceptance criteria before generating code. The intent specification is the artifact that matters. If your agents are generating code without a written behavior spec, you're skipping the most important step.
Run multiple AI reviewers in parallel. Osmani's data shows 93.4% non-overlap between tools. Running two catches roughly twice as many issues as running one. Open-code-review and Semgrep are good starting points.
Invest in deterministic verification layers. Type systems, contract tests, mutation testing, and property-based testing don't have the blind spots that probabilistic AI review has. Your guardrail stack matters more than your review process.
Track what review actually catches. If your human reviewers are finding the same categories of issues that your CI pipeline catches, the review is redundant. If they're finding architectural misalignment, that's the signal to invest in better specs, not more review.

The uncomfortable truth: The teams that will win the next two years aren't the ones that figure out how to review AI code faster. They're the ones that figure out how to specify intent precisely enough that reviewing code becomes unnecessary — just as specifying types precisely enough made reviewing assembly unnecessary.

The Road Ahead

The compiler metaphor has a natural endpoint: once compiler output became reliable enough, the entire profession reorganized around writing in higher-level languages. The equivalent shift for AI-generated code is from reviewing implementations to reviewing specifications.

We're not there yet. The tools are immature — context-mode is less than a year old, open-code-review just open-sourced this year, and Semgrep's auto-approve pilot is measured in weeks. The five-layer trust model is a framework, not a product. And the knowledge-sharing function of code review hasn't found its replacement.

But the direction is clear. When GitHub's monthly commits doubled in four months, when a third of PRs ship with zero review, when experienced engineers tell Gergely Orosz they've stopped reading AI-generated code — that's not a trend you can reverse with better review tooling. That's a paradigm shift.

Code is becoming an intermediate representation. The teams that recognize this earliest will build their workflows around intent specification and verified output. The teams that don't will drown in a review queue that grows faster than any number of human reviewers can drain it.

The slow death of code review isn't a crisis. It's an evolution. The question is whether your team evolves with it — or gets buried under the PRs.

Want to go deeper on the verification stack that replaces review? Read our breakdown of the guardrail patterns that actually work, or start with the complete guide to AI coding agents if you're catching up on the landscape.

Originally published at AgentConn