Gergely Orosz’s The Pragmatic Engineer: Five years is primarily a milestone piece — 1.1 million subscribers, the Brex Benchmark naming it the third most-expensed newsletter at startups globally — but buried in the retrospective is an observation that deserves more than a sentence: code review is becoming optional.
That one observation describes a structural shift in engineering, and it raises a management question the headline numbers do not answer. When the review gate dissolves, who holds quality authority?
stateDiagram-v2 direction TB state "AI generates code" as Gen state "Author self-reviews" as SelfRev state "Peer review gate" as PeerRev state "Testing" as Test state "Production" as Prod state "Structural regression" as Fail [*] --> Gen Gen --> SelfRev SelfRev --> PeerRev : Review required SelfRev --> Test : Review skipped PeerRev --> Test : Gate cleared Test --> Prod Prod --> [*] : Ships Prod --> Fail : Defect surfaces Fail --> Gen : Emergency rewrite
The rundown
Gergely Orosz published his five-year retrospective on September 1, 2026. The Pragmatic Engineer launched in 2021 and now reaches 1.1 million subscribers. The Brex Benchmark data cited in the piece places it as the third most-expensed newsletter at startups globally — a reasonable proxy for how seriously working engineers take it.
The retrospective documents three shifts that distinguish the current moment from where things stood at launch: legacy development environments are declining, code review is becoming optional in AI-assisted workflows, and AI agents are restructuring how engineering work is organized.
The code review observation is the one that carries the most operational weight for engineering leaders.
For the working software engineer
Code review has always served several functions simultaneously. It catches bugs. It enforces architectural consistency. It transfers knowledge across the team. It creates a checkpoint for shared norms about how the system is supposed to behave.
AI-assisted development changes the economics of each of those functions differently. The bug-catch rate of AI-generated code on common patterns may be comparable to reviewed human code. But the architectural consistency check and the knowledge transfer do not automatically survive the transition to optional review.
When AI writes more of the code, the review process does not become less important — it becomes more targeted. The question shifts from “does this conform to how we write code” to “does this behave correctly in the contexts we have not tested, at the integration points we have not fully modeled.” That is a harder question. It requires more context, not less rigor.
Engineers in AI-assisted teams who interpret “optional review” as “review is gone” are accepting a deferred cost. Structural problems in AI-generated code look like production incidents, not PR comments. The feedback loop is longer and more expensive.
For business owners and operators
If your engineering leads are telling you that AI has accelerated output, that is likely true. If they are also telling you that the team has eliminated code review to keep pace with the new output rate, pay careful attention to that second part.
Velocity and quality do not automatically scale together. The efficiency gains from AI code generation are real. The governance model for that code is still being worked out by most organizations, and the working-out period is when the accidents happen.
The practical question is not whether to allow AI-assisted development — that decision is already made, teams are using these tools whether or not there is a formal policy. The question is whether the existing quality authority has been reconfigured to match the new production rate.
If code reviews are being skipped without an explicit replacement — a designated architecture reviewer, a stronger automated testing gate, a named principal engineer who owns structural decisions — you have faster code delivery and a degraded catch rate for structural problems. That combination eventually surfaces as a production incident.
My take
At LERETA, I led thirty-plus developers through a multi-year modernization that included integrating an acquired Texas company’s technology into the flagship product rebuild. The acquired company’s data model and processing assumptions differed from our system’s in ways that were not fully visible during the initial assessment. The differences surfaced after integration had begun.
We had skipped a thorough architecture review on the acquisition’s data structures in the interest of moving faster. That decision cost months of rework. The code was correct on its own terms — both systems functioned independently. The problem was in the seams between them, and you only see those seams when someone with full system context reviews what is being connected.
That is exactly the class of problem that code review is designed to surface early, and exactly the class of problem that gets expensive when it surfaces in production instead. AI-generated code creates more seams, faster. The answer is not line-by-line review of everything — that is not realistic at the new output rate. The answer is sharper review at the structural level: the interfaces, the data contracts, the failure modes at integration points.
Someone in the organization has to own that review function explicitly. If it is not the tech lead, the fractional CTO, or a designated architecture reviewer, it defaults to production. That is not a safe default. The cost of a structural defect in production is an order of magnitude higher than the cost of catching it in review — and it was true before AI started writing code faster than teams can think about what it should connect to.
Gergely’s observation is accurate and worth taking seriously. The response to it is not panic about AI code quality. It is clarity about who, specifically, holds quality authority now that the review gate is optional.
