The debate is often compressed into a provocative question: Should skilled developers stop reading AI-generated code?
My answer is no—but they should stop treating line-by-line reading as the only legitimate form of review. The scarce human skill is moving upward, from typing implementation to specifying behavior and judging evidence. Review should follow that shift without abandoning ownership.
TL;DR: should you review AI-generated code?
Question
Practical answer
Should every generated line receive equal attention?
No. Review depth should follow risk, novelty, reversibility, and test quality.
Can a developer safely ignore implementation details?
Only when the component is well-contained and its behavior is strongly verified.
Are tests enough?
No. They prove expected cases, not that the requirement, threat model, or architecture is correct.
Goals, interfaces, invariants, failure modes, security boundaries, migrations, and evidence.
What about junior developers?
They still need deliberate code reading and debugging to build the judgment that abstraction-level review requires.
What is the emerging workflow?
AI generates; automation checks; humans approve at a depth proportional to the cost of being wrong.
What antirez said—and what he did not say
The strongest version of the claim is easy to caricature: ask an agent for a feature, never inspect the code, and ship whatever passes a few tests. That is not a serious production method, and it is not necessary to accept that version to see the real bottleneck.
Modern coding agents can create thousands of lines faster than a human can read them. If an engineer insists on reviewing every generated line with equal intensity, generation speed quickly exceeds verification capacity. The constraint moves from writing code to deciding whether the code should be trusted.
Antirez’s post points at that mismatch. Time spent reading routine adapters or generated fixtures cannot also be spent checking whether the feature solves the right problem, whether the data model survives future changes, or whether the rollout can be reversed.
But “do not inspect every line” and “do not understand the system” are different claims. Antirez’s own earlier writing described reviewing every line of systems code when quality demanded it. The useful principle is contextual: implementation is sometimes a replaceable artifact; responsibility never is.
This is also why the discussion is more precise than the broad label vibe coding. A production engineer can delegate syntax while remaining rigorous about contracts, tests, observability, and risk. Conversely, someone can manually type code while misunderstanding the system they are changing.
The disagreement is really about the unit of review
Traditional code review treats the diff as the main object. A pull request arrives; another engineer reads the changed lines; comments lead to revisions; tests run; the change merges.
Agentic development produces a different shape of work. A human may define the desired behavior, let an agent plan and implement it, run automated checks, and then evaluate the result. The artifact worth reviewing is no longer only the diff. It is a chain:
Weak teams review only the implementation. Strong teams look for broken links anywhere in that chain.
If the specification is ambiguous, a beautifully written diff can still be wrong. If the tests were generated from the same misunderstanding as the code, a green suite can confirm the wrong behavior. If the interface leaks internal assumptions, every implementation behind it creates future debt. If telemetry is missing, QA may pass while production failures stay invisible.
That is why ThePrimeagen’s emphasis on interfaces and functions matters. The person who defines the boundaries controls much of the solution space. Chollet’s point about skill stratification follows from the same fact: experts possess mental models that let them specify better constraints and notice when evidence is incomplete. Stronger agents multiply that advantage.
Our guide to loop engineering describes this broader control cycle. The job is not to write one perfect prompt. It is to create a loop in which planning, execution, verification, and correction expose errors before users do.
That is a remarkable adoption claim, but it is frequently shortened into “75% of Google’s code is written by AI.” Three qualifiers matter:
It refers to new code, not the entire codebase.
Google has not published a detailed methodology for what counts as AI-generated.
The code is engineer-approved.
The last qualifier is the important one for this debate. Google’s number describes generation at scale with human accountability still present. It does not show that engineers stopped reviewing changes, and it gives us no basis to assume every change receives the same kind of review.
The full context is in our Google Cloud Next 2026 analysis. A company with mature tests, internal platforms, static analysis, staged rollouts, and observability can shift more review into automated evidence than a startup with a fragile test suite can. Copying the percentage without copying the quality system is cargo cult engineering.
Developers are using more AI while trusting it less
The 2025 Stack Overflow Developer Survey found that only 32.7% of respondents highly or somewhat trusted AI-tool accuracy, while 45.7% distrusted it. Trust had fallen by roughly ten percentage points from 2024 even as usage expanded.
That is not a contradiction. Developers can find an imperfect generator valuable if verification costs less than writing from scratch. Compilers are useful despite compile errors. Search engines are useful despite irrelevant results. The economic question is not whether an agent is always right; it is whether the complete loop produces a better outcome.
The answer still varies by task. A METR randomized study of experienced open-source developers found that early-2025 AI tools made participants 19% slower on real issues even though they believed they were faster. The sample was small—16 developers across 246 tasks—and the models were older than today’s strongest agents. It should not be generalized into “AI always slows experts.” It does show that prompting, waiting, checking, and correcting can consume the time generation appears to save.
A separate 2026 Code Review Agent Benchmark converted real human review findings into executable tests. Even the union of four evaluated tools recovered only 41.5% of the benchmark issues, and the researchers found that AI and human reviewers often noticed different problems. That result argues for complementary review, not replacing one reviewer with the other.
The lesson is uncomfortable but useful: generation quality and verification quality are separate capabilities. Buying a stronger coding model improves only one side automatically.
Replace uniform review with a risk ladder
The practical alternative to “read everything” is not “read nothing.” It is a review policy that spends human attention where failure is expensive.
Level
Typical work
Required evidence
Human review
0: disposable
Spikes, local scripts, prototypes with no real data
Runs successfully in an isolated environment
Outcome check; code reading optional
1: low risk
Copy changes, test fixtures, internal UI polish, mechanical refactors
Focused tests, lint, type checks, visual or runtime QA
Inspect the diff shape and unexpected files
2: product logic
User flows, pricing rules, API behavior, persisted state
Written acceptance criteria, contract tests, integration tests, rollback plan
Review interfaces, invariants, edge cases, and critical code paths
Close manual review by an accountable domain expert
Two variables can move a change up the ladder even if it looks small:
Irreversibility. A five-line destructive migration can be riskier than a 5,000-line generated test suite.
Weak evidence. An unfamiliar module without tests or production telemetry deserves more reading than a well-specified component behind a reliable contract.
Security boundaries deserve special care because an agent can produce code that is functionally correct and still dangerously permissive. The same principle appears in our MCP security guide: capability must be constrained deliberately; a successful tool call does not prove the permission model is safe.
A production workflow that does not make the human the bottleneck
Here is the review sequence I would use for a substantial agent-generated change.
1. Write the contract before generating the implementation
Define inputs, outputs, invariants, failure behavior, and non-goals. For a payment endpoint, this might include idempotency, currency precision, authorization, retry behavior, and which states are impossible.
An executable spec is even better. Schema validators, type-level constraints, property tests, and API contract tests reduce the number of ambiguous decisions the implementation can make.
2. Ask the agent to expose its plan and assumptions
The plan is often faster to audit than the final diff. Check which files will change, what existing patterns it will follow, which dependencies it will add, and what it considers out of scope.
This catches conceptual drift before it becomes thousands of plausible lines. It also makes scope expansion visible—a common failure mode when an agent “helpfully” rewrites adjacent code.
3. Separate implementation from verification
Do not ask only, “Did the tests pass?” Ask who designed the tests and what independent source defines correct behavior. If the same agent invents the requirement, writes the code, and writes tests that restate its own assumptions, the loop is internally consistent but not independent.
Useful checks include:
Existing regression tests written before the change
Tests derived directly from product acceptance criteria
Property and fuzz tests for large input spaces
Static analysis and dependency scanning
Browser, API, or device-level checks outside the implementation unit
A second reviewer—human or model—given the spec rather than the first agent’s reasoning
AI is particularly useful for building verification that does not alter production code, which is the strongest part of NeverSink’s position. Let the agent generate adversarial inputs, reproduce bugs, compare before-and-after behavior, and explain coverage gaps.
4. Review the diff by surprise, not by line count
Start with the file list and change shape. Why did a UI request modify authentication? Why did a bug fix add a dependency? Why did a refactor touch a migration? Unexpected scope is a higher-signal review target than familiar boilerplate.
Then inspect the code paths connected to money, identity, permissions, deletion, persistence, network access, and concurrency. Search explicitly for silent exception handling, broad permissions, disabled validation, insecure defaults, unbounded retries, and logs that may contain secrets. Our guide to secrets and prompt leaks in GitHub shows why seemingly incidental files and history can be part of the real security boundary.
5. Verify behavior in a realistic environment
Passing unit tests is not the finish line. Exercise the user flow, inspect logs and network calls, test failure recovery, and confirm the rollback path. For visible work, look at it. For performance-sensitive work, measure it. For data changes, rehearse restoration.
The agent can run these checks, but the accountable engineer decides whether the evidence is sufficient.
6. Preserve a small decision record
Record the contract, risky assumptions, tests run, and unresolved limitations. Generated implementation can be replaced cheaply; the reasoning behind a production decision is harder to reconstruct during an incident.
Why senior developers can review differently—but juniors should be careful
Chollet’s “power tool” framing captures a real asymmetry. Experienced engineers can glance at an interface and infer likely implementation risks because they have seen similar systems fail. They know which invariants deserve tests, which abstractions are suspicious, and when a clean benchmark hides operational complexity.
That ability came from reading, writing, and debugging a great deal of code.
A junior developer who skips directly to abstraction-level review may imitate the visible workflow without possessing the underlying model. They can approve a sensible-looking interface while missing a race condition, an authorization flaw, or a destructive default. This is the de-skilling risk explored in our article on AI-assisted developers who cannot debug.
Teams therefore need two policies, not one:
Production policy: review changes according to risk and evidence.
Learning policy: require developers to explain, trace, and sometimes implement critical mechanisms without agent assistance.
Those policies can coexist. A junior does not need to handwrite every CRUD endpoint, but they should be able to trace a request through the stack, explain why an authorization check is correctly placed, predict failure behavior, and debug a broken version. Code-reading drills and incident walkthroughs are training, even when they are not the fastest route to the next release.
My view: code can be disposable; accountability cannot
The best idea in the “stop reading code” argument is that source code is becoming a lower-cost representation of intent. When implementation is cheap to regenerate, teams should spend more energy clarifying the intent and proving the behavior.
The worst interpretation is that generated code becomes nobody’s responsibility.
Software is not correct because a model wrote it, a human wrote it, or a reviewer read every line. It is trustworthy when the team can explain what it must do, constrain what it may do, produce evidence that it behaves that way, observe it in production, and recover when assumptions fail.
So yes: stop worshipping line-by-line review as the only sign of engineering seriousness. Do not spend equal attention on generated glue and a credential boundary. Let automation inspect syntax, known vulnerability patterns, types, formatting, and broad regression surfaces.
But never outsource the decision that the evidence is enough. The human bottleneck is not a defect when the bottleneck is judgment.
A compact AI code-review checklist
Before merging an agent-generated production change, ask:
Is the intended behavior written independently of the implementation?
Are inputs, outputs, permissions, invariants, and failure states explicit?
Did the agent touch only the expected files and dependencies?
Do tests challenge the implementation rather than mirror it?
Which security, data, money, identity, and irreversible paths changed?
Did a human inspect those high-risk paths?
Was the behavior tested outside the narrow unit where it was generated?
Are logs, metrics, alerts, feature flags, and rollback sufficient?
Can the owner explain the change during an incident without asking the agent?
Is a junior learning from the change, or merely forwarding generated output?
If the team cannot answer those questions, the problem is not that nobody read line 847. The problem is that nobody owns the result.
This article reflects public posts and research available on July 13, 2026. Social-media debates can evolve, and coding-agent capabilities change quickly. Google’s 75% figure is a company statement without a published measurement methodology; the METR and code-review studies have specific samples and task designs that should not be generalized beyond their evidence.
