Should AI Engineers Still Read Code in 2026? The Z/L Continuum — Alex Volkov, ThursdAI
Alex Volkov introduces the "Z/L Continuum," a framework for navigating the tension between rapid AI-generated code production and the critical need for human review. He argues that the key lies in understanding that the continuum applies to tasks, not individuals, and presents a pragmatic routing table for verifying changes based on their criticality, highlighting the shift towards engineering systems that build and verify code, rather than meticulously inspecting every line. The talk also touches on emerging capabilities like Fable and "loops" and the importance of flexibility and human judgment in the evolving AI engineering landscape.
The talk by Alex Volkov addresses a core conflict emerging in AI engineering: the tension between the rapidly increasing output of AI-generated code and the traditional necessity of human code review. This tension is encapsulated in what Volkov initially termed the “Desolation of Apollo Continuum,” later refined as the “Z/L Continuum.”
The Shifting Landscape of AI Engineering
Volkov highlights a significant shift since December 2025, where AI models began completing tasks that previously took engineers over 16 hours. This era, dubbed “wtfhappened2025.com” by Swyx, marks a departure from traditional coding. Engineers are no longer primarily hand-crafting code; instead, they are “babysitting agents.” A prime example is Boris, creator of Anthropic’s Claude Code, who now authors 100% of his code using Claude, effectively deleting his IDE. Anthropic itself reports that over 80% of its code is AI-written, a figure likely higher now. GitHub data further supports this trend, showing a 14x increase in commits year-over-year, largely driven by AI assistance.
The Core Conflict: “Code is Free” vs. “Read Every Line”
This new reality has led to divergent philosophies, vividly illustrated by two talks at AI Engineer Europe:
- Ryan Lopopolo (OpenAI) - “Code is Free”: Lopopolo argues that models are now capable enough to write isomorphic, high-quality code, making code production and refactoring trivial. He contends that humans should elevate their focus from implementation details to “the prompt and the guardrails.” He suggests that velocity hits might be necessary to refine agents but that concerns about “slop” can be addressed by the system, not by human review of every line.
- Mario Zechner (creator of libGDX) - “Read Every Effing Line”: Zechner vehemently opposes this view, stating that agents compound errors (“booboos”) with zero learning, leading to “delayed pain.” He warns that unread AI-generated code results in broken products and screaming users. His advice: for non-critical code, “let it rip,” but for critical code, “read every line.”
The Z/L Continuum: It’s About Tasks, Not People
Volkov initially framed the continuum as a choice between being a “Zechner” (reading every line) or a “Lopopolo” (YOLO-ing code). However, he admits this framing was wrong. His mea culpa is that the continuum is real, but it’s about the tasks, not the people. The same engineer might adopt a Lopopolo approach for certain pieces of code and a Zechner approach for others, depending on the task’s criticality.
Upon closer inspection, Lopopolo and Zechner’s views are not as opposed as they seem:
- Lopopolo’s Mechanism: He advocates moving attention up the layers. Instead of repeatedly catching the same mistakes, engineers should inspect the system (linters, documentation, reviewers) that catches these mistakes, thereby engineering reliability once.
- Zechner’s Mechanism: He advises routing by task. Non-critical code can be deployed with minimal review, while critical code demands meticulous inspection. He suggests using “clankers” (advanced static analysis tools) to identify critical sections of a codebase.
The Consequences of Unchecked Velocity
Despite the optimists’ claims about output, the data reveals concerning trends:
- “Acceleration Whiplash”: A Faros AI survey from April 2026 reported an 861% increase in code deletion per PR and Anthropic shipping 8x more code per quarter. While output is up, so are problems.
- Decreased Quality: Anthropic’s status page, which Volkov describes as looking “like a Christmas tree,” suggests issues with stability. The same study showed a 31% increase in PRs merged with no human or agentic review, and a 242% increase in incidents per PR. Bugs per developer are up 6x since 2025.
- Human Review as a Bottleneck: Anthropic’s Recursive Self-Improvement (RSI) essay notes that as code output explodes, human code review has become a new bottleneck, citing Amdahl’s Law. Even with AI, humans are not being removed; their role is shifting.
A Pragmatic Approach: Routing Changes and Building Systems
Volkov proposes a practical “routing table” for AI-driven software development, emphasizing that the question is “What proof does this specific change need?”
- Read Every Line: For highly critical areas like authentication, money movement, permissions, and irreversible data.
- Decompose PRs: Break down large, AI-generated code into atomic, reviewable pull requests. Agents are adept at this decomposition.
- Verify Relentlessly: Leverage traces, evaluations, and shadow mode (deploying changes to a subset of users or infrastructure without impacting production) to verify functionality.
- Separate Concerns: Crucially, do not allow the same agent that writes code to also inspect its outputs or write its tests. This separation prevents self-grading bias.
- Engineer the System: Build systems that build systems. Implement robust rails, observability, and rollback capabilities. The goal is to spend attention once on engineering the system that remembers and prevents issues, rather than repeatedly reviewing individual lines.
Emerging Capabilities: Fable, Mythos, and Loops
New tools like Anthropic’s Fable and Mythos are further pushing the boundaries. Jared S. Chipar from Anthropic stated, “We used to check if Claude is doing the work right? With Fable 5, I instead check if Claude is doing the right work.” This signifies a shift in the level of abstraction at which human review occurs.
Andrej Karpathy’s observation, “It’s never felt so tempting to stop looking at code at all. But don’t do this in production,” captures the ongoing tension. This highlights the concept of “capability drift,” where increasing AI capabilities shift where “proof” is required. If yesterday it was inspecting outputs, today it’s task direction, and tomorrow it might be inspecting “loops.”
Loops are presented as the next engineering primitive, moving from individual prompts to designing systems that generate prompts, plan, execute, and self-verify. While powerful, Volkov cautions that if the builder grades itself, “you didn’t remove the review, you hid it.” As Adi Olsmanyu noted, relying solely on automated loops for bug fixes without human oversight can lead to a “downward spiral” in product quality. Loops don’t remove judgment; they raise the stakes on where judgment is applied.
Future Outlook: Flexibility and Judgment
Model capabilities are advancing at an insane pace (OpenAI’s Codex, Elon’s Grok code, Google’s anti-gravity). Volkov concludes by emphasizing that flexibility is required to keep up with these trends. The ultimate takeaway: “Not every line in 2026 needs your eyes. Every system still needs your judgment.”