I have been thinking about how to scale thoughtful code review now that AI has made writing code cheap and fast. The obvious concern is that review becomes the bottleneck: one engineer can ask several agents to produce changes in parallel, while another engineer can still only understand one change at a time.

But calling review a bottleneck can make the wrong solution sound attractive. If we treat review as a line-by-line bug hunt, then the answer appears to be faster scanning, more automated comments, or less review. Thoughtful review does something more important. It asks whether a change belongs in the product, fits the architecture, preserves the codebase, and is something the team is prepared to own.

AI has not made that judgment cheap. It has changed where the cost lives.

A patch can be evidence before it becomes a commitment

A recent GitHub essay, The cost of saying yes has changed, makes a useful distinction: the first generated patch is not necessarily the product. It can be a price check.

Teams have learned to resist “small” requests because implementation often reveals hidden complexity. That instinct was rational when trying the change required a developer to stop other work, build context, and spend a day discovering what the request really meant. For a bounded class of changes, an agent can now produce a candidate faster than the team can finish debating its scope.

The candidate turns a vague estimate into something concrete. Did the change stay within the expected files? Does it fit an existing abstraction? Can it be tested without inventing new machinery? Did a display-only request unexpectedly reach into authorization or data retention? A patch can answer those questions without obligating the team to merge it.

This gives us three separate prices to consider: the cost to produce a change, the cost to validate it, and the cost to own it. AI has reduced the first price dramatically. It sometimes reduces the second. It does very little to reduce the third.

Cheap to write is not the same as cheap to own. A thousand-line change that passes its tests but that nobody can confidently explain is not inexpensive. It is a deferred bill.

Keep the bottleneck, change what reaches it

Farnam Street's mental model of bottlenecks separates accidental constraints from deliberate ones. A security checkpoint slows a system down for a reason. Human judgment at the merge boundary is also a deliberate constraint. The goal should not be to eliminate it, but to stop wasting it.

Reviewers should not be the first people to discover that the build fails, the new helper duplicates an existing utility, or the code does not follow a documented convention.

The author remains responsible for a generated change. “That's what the agent wrote” may explain where bad code came from, but it does not excuse submitting it. If your name is on the change, you should be able to explain why it exists, how it works, and why it is safe enough to merge. Before asking for another person's attention, understand the diff, run it, self-review it, and provide the evidence that makes it reviewable.

GitHub reported that developers who ran an automated self-review before opening a pull request removed enough routine issues to reduce back-and-forth by roughly a third. Their broader guidance is equally important: the developer who merges the code still owns it. AI can inspect mechanics and patterns; people remain responsible for architecture, product values, and tradeoffs.

A review-ready change should arrive with its purpose, constraints, test results, risk assessment, and a short explanation of anything surprising. For a bug fix, the strongest evidence is often a test that fails before the change and passes afterward. For a risky operational change, it may be a rollout and rollback plan. The reviewer should begin with evidence, not reconstruct intent from a diff.

Scale review depth with risk, not code provenance

Not every change deserves the same review. A copy correction, a well-contained refactor, and a new authorization rule should not wait in one queue or receive one level of scrutiny. The useful distinction is not AI-written versus human-written. It is reversible versus irreversible, local versus systemic, and familiar versus novel.

Low-risk changes can move through deterministic checks, automated review, and a lightweight human confirmation. Changes to business logic need a person to trace the critical path and challenge the failure cases. Changes involving authorization, billing, privacy, data retention, infrastructure, or public contracts need explicit domain ownership and a larger margin of safety.

This is the practical combination of scale and margin of safety. Processes do not scale by simple multiplication, and safety requires spare capacity proportional to uncertainty. Review effort should follow potential impact rather than treating every changed line as equal.

GitHub's guidance for reviewing agent pull requests follows this logic: check first for weakened CI, duplicated utilities, plausible but incorrect logic, and unsafe handling of untrusted input. Then trace one critical path end to end instead of merely scanning the surface. The objective is not equal attention. It is attention placed where an error would matter most.

Small changes are a control system

AI makes large changes deceptively easy to produce. It does not make them easy to understand. Small changes therefore become more important, not less.

Google's long-standing guidance on small changes predates generative AI, but reads like guidance for it: one self-contained concern, related tests, enough context for the reviewer, and a codebase that remains healthy after each merge. Small changes are reviewed more thoroughly, rejected with less waste, and rolled back more safely.

The best limit is conceptual rather than a rigid line count. A change should have one sentence of intent and one coherent reason to exist. Refactoring should usually be separated from behavioral change. A large generated feature should arrive as a sequence of reviewable steps, not as one impressive diff.

This also improves the price-check idea. A constrained probe is useful because it has a circuit breaker. Ask for the smallest patch, prohibit public contract changes, keep the work behind an existing flag, and name the files or subsystems it may touch. If the agent cannot stay within those boundaries, stop. The failed constraint is evidence that the request is larger than it appeared.

Turn recurring judgment into infrastructure

Senior reviewers often catch problems through tacit knowledge: the helper that already exists, the incident caused by a similar retry loop, or the architectural boundary that is obvious only after years in the system. If every generated change requires a senior engineer to repeat that knowledge manually, senior attention becomes the next accidental bottleneck.

Birgitta Böckeler describes encoding team standards as shared infrastructure. Architecture rules, common failure modes, security expectations, and review priorities can live in versioned repository instructions rather than in private prompts or memory. The same guidance can shape generation, self-review, and CI.

This is where Farnam Street's feedback loops become operational. A recurring review comment should not only repair the current patch. It should improve a test, linter, agent instruction, template, or architectural guardrail so that the next patch is better before a human sees it.

The aim is not to automate every judgment. Rules that are stable and mechanical belong in tooling. Judgment that depends on context should remain visible as judgment. Encoding the former creates more room for the latter.

Review continues after merge

Martin Fowler argues that code review is broader than pre-merge pull request review. It can happen earlier through design conversations and pairing, and later through refinement and observation. More importantly, review is not primarily a bug-catching mechanism. It steers the codebase and asks, “Should this be part of the product?”

That broader model matters when humans can no longer examine every generated semicolon with equal care. Tests explain and evaluate the behavior we can anticipate. Staged rollouts, observability, and production cohorts reveal what the system actually does under the traffic and interactions we did not imagine. A merge is not the end of validation; it is the point where a new kind of evidence becomes available.

The 2025 DORA research, based on nearly 5,000 technology professionals, describes AI as an amplifier. It was associated with higher throughput and product performance, but still with lower delivery stability. Teams benefited when they had strong automated testing, mature version control, loosely coupled architectures, and fast feedback loops. AI did not repair the delivery system around it. It intensified that system's existing strengths and weaknesses.

Measure confidence, not output

Incentives will determine whether any of this works. If a team rewards pull request count, lines changed, or visible activity, people and agents will produce more review inventory. The author receives the benefit of fast output while reviewers and future maintainers absorb the cost. That is an externality disguised as productivity.

Farnam Street's writing on the distorting power of incentives offers the warning: people find the shortest path to what is rewarded, while narrow measures hide second-order effects. Review speed should be considered alongside reviewer load, escaped defects, rework, rollback frequency, incident impact, and whether ownership is concentrated in a few people.

We should also resist redesigning the process around a handful of spectacular successes or failures. The mental model of sample size applies here. Teams need enough observations across different kinds of changes to learn which work can safely take the fast path and where additional review pays for itself.

The unit of scale is confidence

A scalable review system does not ask people to read faster. It reduces how much generated code requires fresh human judgment, and it places that judgment where it has the most leverage.

Generate bounded candidates to replace speculation with evidence. Make authors responsible for understanding and proving their changes. Keep batches small. Route review by risk. Automate the mechanical checks. Encode recurring lessons into the workflow. Use production as a continuation of validation, with margins of safety that match the stakes.

The question has shifted from “How much work is this?” to “Where is the real cost: producing it, validating it, or owning it?” Sometimes the cheapest responsible answer is to let an agent try. Sometimes a four-line change still deserves a hard no because it changes a promise the product must keep.

Code is becoming abundant. Confidence, context, and ownership are not. Thoughtful code review scales when we design the system around that scarcity.