The Z/L Continuum: Should AI Engineers Still Read Code?

At the same AI Engineer Europe conference, one speaker said code was free; another insisted that engineers read every line of critical code. Add the engineer who has deleted his IDE, and the practical question becomes unavoidable: should you still read the code your agents produce in 2026? Alex Volkov calls the space between those positions the Zechner–Lopopolo continuum. Its starting constraint is simple: “code got cheap, attention didn't.”

The backdrop is a sharp change in what agents can accomplish. Volkov places the inflection in December 2025 and points to WTF Happened in 2025?, a collection of examples of that acceleration. He describes a METR chart as showing models completing tasks that would take engineers more than 16 hours. Here, hours measure human-equivalent task difficulty at a specified success probability, not uninterrupted autonomous runtime; METR also warns that estimates above 16 hours are unreliable with its existing task suite.

When Volkov asks who still writes most of their code by hand, the room offers little resistance to his premise: engineering is shifting from typing to supervising agents. Boris Cherny, creator of Claude Code, is his example. Volkov reports that Claude Code authors all of Cherny's code, that he ships 20–30 pull requests or more, and that he has deleted his IDE; no reporting period accompanies the PR count. The claimed change is in the layer of work, not the disappearance of engineering.

The organizational numbers need precise denominators. Anthropic reports that, as of May 2026, more than 80% of production-merged lines were attributable to Claude. That is narrower than saying that 80% of all code is AI-written. Volkov then contrasts GitHub's roughly one billion commits in 2025 with a projection of 14 billion for 2026. The latter is an annualized projection from 275 million weekly commits, repeated by Anthropic, rather than a completed annual total. Volkov describes much of the growth as AI-assisted. Whatever the eventual total, the review problem is already clear: producing more changes does not produce more human attention.

Volkov uses the AI Engineer World's Fair as a barometer for changes in the profession, having attended every edition. He describes this gathering as three times the previous year's size, with approximately 7,000 people and 36 tracks. Against that backdrop, he returns to two Europe talks and plays the first excerpt: Ryan Lopopolo from OpenAI on why implementation no longer deserves the same share of an engineer's attention.

Lopopolo's position begins with code being cheap to produce and refactor. The valuable work moves into the prompt and the guardrails that produce acceptable implementations. His instruction to reject poor output is paired with a less glib operational requirement: accept short-term velocity losses to investigate where agents struggle. If an agent repeatedly makes a mess, continuing to generate code faster is not the remedy. Someone must examine the task and improve the conditions under which it gets done.

The memorable packaging is the invitation to become a “token billionaire.” Volkov credits Lopopolo with inspiring the conference's token-billionaire lounge and golden card. Behind that exuberance is a claim about allocation: abundant generation lets engineers spend more effort shaping the process that generates code.

Mario Zechner, creator of Pi, opens from the other direction: slow down. His provocative example is the product proudly advertised as entirely agent-built while its quality deteriorates. Agents can compound errors without learning from them, encounter no immediate bottleneck, and leave the engineer to absorb the delayed pain. When users report a production failure, an engineer who has never read the implementation may have little basis for diagnosing it.

Zechner's distinction is already more selective than the slogan suggests: non-critical code can be delegated freely; critical code requires reading every line. Volkov says these two talks ranked sixth and seventh among AI Engineer's most-watched YouTube videos. For a technical leader, their popularity signals an active disagreement inside teams: how much review is enough, and what quality standard survives the increase in output?

Volkov arrives at this question through years of observing the field. He hosts the weekly ThursdAI podcast and newsletter, describes three and a half years of tracking model releases, and introduces himself as an AI evangelist at Weights & Biases and CoreWeave. His conference coverage began in 2023; conversations in hallways and speaker rooms supplied the initial continuum.

At first, he asks people where they stand on a line: are they a Zechner who reads everything, or a Lopopolo who lets agents proceed without looking? He then admits that this framing is wrong. Before explaining why, he asks the audience to examine its actual behavior. Who has committed code they never inspected? Who still reads every line of critical code? Leaders should answer for the people supervising agents on their teams, too. These are questions about how changes reach users, not merely about comfort with AI.

The optimistic position has a real claim on output. Volkov portrays Lopopolo as unusually bullish even within OpenAI, with access to tokens that makes large-scale delegation natural. He jokes about renaming him after Codex's --yolo flag, which he compares with bypassing Claude Code's permission checks. The joke captures a willingness to spend tokens and remove friction; it does not establish what evidence should be required before a change ships.

For evidence, Volkov turns to Faros AI's Acceleration Whiplash findings, which he introduces as an April 2026 survey. Faros actually describes two years of telemetry from 22,000 developers across more than 4,000 teams, comparing each organization's periods of lowest and highest AI adoption. Its 861% increase concerns the quarterly ratio of deleted to added lines in merged code, not deletions per pull request. That distinction matters: this measures churn relative to additions, not simply how much code each PR removes.

Anthropic supplies another output measure, but again the unit matters. Its detailed comparison reports eightfold growth in merged lines per engineer per day in Q2 2026 versus 2024. Volkov summarizes this as eight times more code per quarter than in 2025; the published detailed metric uses a different denominator and baseline. Both examples concern the volume of engineering activity. Neither, by itself, establishes the quality of the resulting product.

Volkov makes that gap tangible with a guessing game: whose status page is full of incident markings? The answer is Claude, and he says the service was down when the screenshot was taken. He compares the page to a Christmas tree, then immediately qualifies the inference: scale and other factors may explain the outages. GitHub has also suffered operational problems. The demonstration is a reminder that output and stability are different properties, not evidence that AI-written code caused those incidents.

The Faros findings give the concern a more specific shape. These are relative changes between organizational adoption periods:

The incidents-to-PR ratio is not the probability that any individual PR causes an incident. The published bugs figure is 54% higher, rather than the sixfold increase stated in the talk. Volkov also describes unreviewed PRs as lacking either human or agent review; the report summary does not establish that exact distinction. His practical warning remains direct: do not merge changes with no review.

Anthropic's essay When AI builds itself extends the question into recursive self-improvement. Volkov contrasts a future in which acceleration subsides with futures involving orders-of-magnitude productivity growth. The published essay presents three scenarios, rather than the two summarized onstage; the large productivity multipliers belong to possible futures, not measured outcomes. The immediate organizational observation is more concrete: increasing code output has made human code review a bottleneck.

Amdahl's law explains why that constraint becomes more visible. Accelerating one part of a workflow cannot eliminate the time spent in the remaining parts. When implementation becomes much faster, review can occupy more of the remaining path to delivery. Volkov pairs the bottleneck observation with OpenAI and Anthropic careers pages: the organizations pushing generation hardest are still hiring humans. Their practices have not made human involvement disappear.

This is where Volkov corrects the continuum: the unit of classification is the task, not the engineer. The same person can delegate one change with little direct inspection and read every line of another. Different changes require different proof. Treating those choices as fixed identities hides the information that should determine them.

Look closely at Lopopolo's mechanism and it is not an instruction to abandon inspection. When a reviewer catches a mistake, encode what was learned in documentation, a linter, or instructions the reviewer will retain. Humans are unreliable at repeatedly recognizing the same class of error. A system that remembers the rule can catch its recurrence without requiring the original discovery each time. Attention moves from inspecting every line to inspecting and improving the system that produces and checks those lines.

Zechner supplies the complementary routing decision: let non-critical work proceed, but personally inspect critical code. Determining criticality itself requires understanding the implementation. Volkov adds that agents can help examine a large repository and identify critical areas, lines, and primitives. That analysis directs human attention; it does not make an agent's declaration of safety sufficient proof. The two endpoints agree more than the original caricature allowed.

Replace “Should I still read code?” with “What proof does this specific change need?” Volkov turns advice from other engineers into a routing table—the slide he wants people to take back to work on Monday. Its first rule is explicit: authentication, money movement, permissions, and irreversible data changes require line-by-line reading and personal inspection of critical paths.

The rest of the table addresses how evidence stays usable as output grows:

• Decompose. Split large changes into atomic, reviewable PRs. Agents can perform the decomposition, but an engineer still verifies the result. A giant diff that makes the reviewer's eyes glaze over defeats the purpose of requiring review.
• Verify. Use traces, evals, and shadow mode to examine behavior. Volkov names these as proof mechanisms without walking through a shadow-mode implementation.
• Separate. Do not give one agent sole responsibility for writing the implementation, inspecting its output, and writing its tests. Volkov compares that arrangement to writing an exam, taking it, and awarding yourself the grade.
• Engineer. Build guardrails, observability, and rollback into the surrounding system. Reading spends attention on one occurrence; engineering lets the system retain what that attention discovered.

A small TypeScript policy can make the critical-change rule explicit. This illustrative change concerns permission checks; the result is a requirement for human reading, not an assertion that review has occurred:

type Change = {
  id: string;
  authentication: boolean;
  moneyMovement: boolean;
  permissions: boolean;
  irreversibleData: boolean;
};

function requiresLineByLineReview(change: Change): boolean {
  return (
    change.authentication ||
    change.moneyMovement ||
    change.permissions ||
    change.irreversibleData
  );
}

const change: Change = {
  id: "restrict-project-deletion",
  authentication: false,
  moneyMovement: false,
  permissions: true,
  irreversibleData: false,
};

const reviewRequirement = {
  changeId: change.id,
  humanLineReviewRequired: requiresLineByLineReview(change),
  status: "pending",
};

The boolean is deliberately not a merge decision. A change outside these categories still needs appropriate verification and review; a change inside them needs additional human attention. Likewise, encoding the categories does not automate the difficult work of accurately classifying a change.

What happens to this routing table when models become substantially more capable? Volkov says he coined the continuum only 82 days earlier, around the announcement of Mythos Preview, and now faces questions about Fable 5. The model announcement distinguishes April's Preview from June's Mythos 5; Preview access included selected external cyberdefenders and infrastructure providers, rather than being exclusively internal as the talk suggests. The relevant pressure on the continuum is the speed of capability change.

Volkov attributes a revealing distinction to Anthropic's Thariq Shihipar: with Fable 5, his checking shifts from whether Claude is doing the work correctly to whether it is doing the right work. Execution quality and task selection are different review targets. A model can produce a competent implementation while pursuing an unhelpful objective, so improved execution makes the choice of objective more consequential.

Volkov then invokes Andrej Karpathy's counterweight: the temptation to stop looking at code is stronger than ever, but production is not the place to abandon scrutiny. The capability-drift arrow on the continuum points toward greater delegation. Yesterday's attention might go to generated code, today's to task direction and the required proof, and tomorrow's to the loops that choose and execute work. Capability changes where proof belongs; it does not remove the requirement for proof.

Loops are the next candidate primitive. Volkov connects them to the conference's interest in token factories, then asks the audience to distinguish hearing about loops from actually running them. He credits Peter Steinberger, creator of OpenClaw and described in the talk as being at OpenAI, and Boris Cherny with bringing loops into the conversation within roughly two days of each other. The shift is from prompting an agent at every turn to designing the system that writes the prompts.

The economics affect how quickly others should copy that behavior. Volkov describes these lab engineers as having free tokens, unlike engineers who must bear the cost of repeated execution. Their workflows serve as a lighthouse: evidence of a possible direction, not an assumption that every enterprise already has the same operating conditions. His Gretzky analogy is about anticipating where the puck will be, rather than pretending it is already there.

In Volkov's compact description, a loop resembles a scheduled cron job with an agent inside it:

1. Discover a task.
2. Form a plan and generate the prompt for that task.
3. Execute the plan.
4. Check the result against the goal.
5. Retry if the result fails the check.

The reduction in human intervention comes from the system carrying the task through repeated attempts. But that makes the identity and quality of the checker central to the design.

If the builder grades itself, review has been hidden rather than eliminated. This is the earlier exam analogy operating continuously. A retry loop can repeatedly optimize against a weak judgment of success. Automating that judgment does not make it independent.

Volkov illustrates the risk with a warning attributed to Addy Osmani: imagine a bug appearing in Jira, a loop picking it up, and the agent fixing it without Osmani reviewing the code. Osmani expects his product quality to suffer under that arrangement, potentially sending him into a downward spiral of repairs. The example is a warning about a proposed workflow, not a reported execution trace. Loops increase the importance of deciding where judgment enters the process because the system can keep acting between human interventions.

The future does not provide a stable point on the continuum. Volkov describes Claude Code's rise to a billion-dollar product as an unexpected outcome, and coding agents and their harnesses as an unexpected route toward general-purpose agents. He names OpenAI's Codex, Grok Code, and Google's Antigravity as examples of the industry's pursuit of that direction. The lesson is to remain flexible as capabilities change, rather than commit permanently to either maximal delegation or exhaustive manual reading.

His invitation to follow ThursdAI News is an invitation to keep tracking that moving boundary. The closing slide pairs uncertainty about the future with rapidly advancing capabilities and a subscription QR code. The engineering responsibility persists through both: deciding which work matters, what evidence it requires, and whether the system producing that evidence deserves trust.

Not every line in 2026 needs your eyes. Every system still needs your judgment.