Does code quality still matter?

Mark Seemann · rss · 2026-07-23 source ↗ Reader 🖥️

Agent-Oriented Programming Languages Code Quality Human-in-the-Loop Recursive Self-Improvement Technical Debt

Because code quality as currently understood is entirely reducible to the constraints of human cognition, Seemann argues that a hypothetical future in which LLMs alone write, read, and maintain code — in machine-optimized languages rather than human ones — could render today's code-quality concepts meaningless, yet some structurally analogous form of technical debt would likely still emerge from LLMs' own constraints, and only the LLMs' own accumulated experience (not humanity's software-engineering literature, which is inescapably about human cognition) could diagnose and correct it.

theoretical · personal essay / thought experiment — A speculative first-person essay that opens from a tweet and a long-running personal preoccupation, then works through a deliberately hypothetical scenario (a fully human-free coding future) rather than reporting on current practice. Seemann repeatedly flags his own uncertainty ('I honestly don't know') rather than asserting conclusions.

Structure

Part	Role
Opening: the tweet and the human-in-the-loop caveat	Frames the question via a tweet contrasting hand-YOLOed code with agentic YOLOed code, and states the load-bearing caveat that quality matters as long as humans are ultimately responsible for the code
Why code quality matters	Defines code quality as an intrinsic, cognition-relative property (structure, readability, changeability) distinct from software quality, and traces today's code-quality practice to human cognitive limits (citing his own book Code That Fits in Your Head)
Programming languages for LLMs	Extends the thought experiment: if no human ever reads code, existing programming languages (built for human ergonomics) lose their reason to exist, and a new machine-optimized language ('LLaMe') could emerge
Technical debt for LLMs	Argues that even within an LLM-native language, alternative code structures would still differ in how cheaply they can be changed, so a structural analogue of technical debt could still accumulate
Can LLMs prevent technical debt?	Argues that humanity's accumulated software-engineering wisdom is inapplicable to LLaMe because it is entangled with human cognition, so LLMs would have to develop their own best practices from their own experience
Acceleration	Speculates that LLMs could write and consume their own 'incident reports and think pieces,' training successive generations on prior-generation experience faster than humans absorb comparable lessons
Conclusion	Summarizes the three possible futures (debt never materializes; debt appears and gets solved; debt appears and is unsolvable because it lies beyond human comprehension) and lands on a hedge against AI optimism

Key terms

code quality Code Quality
An intrinsic, structural property of a code base — how it is structured, how readable it is, how easy it is to change — explicitly distinguished from 'software quality' and explicitly reducible, as currently practiced, to the constraints of human cognition
LLaMe
Seemann's coined name for a hypothesized single programming language that emerges once no humans read or write code — optimized for LLMs to consume, generate, and manipulate rather than for human ergonomics
YOLO (a code base)
Writing code with no attention to code quality — used both for humans doing it by hand and, by extension, for agentic code produced with no quality oversight
technical debt (in this essay's extended sense) Technical Debt
Generalized beyond human-authored code to any accumulation of structural choices — even within a hypothetical LLM-native language or at the level of machine-code register allocation — that make a system more expensive to change later

Propositions

explicitAs long as humans use LLMs as a tool to generate code they are ultimately responsible for, the quality of that code still matters, because humans must review it, work with it, and fix its bugs.conf: high
explicitCode quality is not the same as software quality: code quality is an intrinsic property of a code base — how it is structured, how readable it is, how easy it is to change.conf: high
explicitUntil now, all questions of code quality have ultimately been reducible to questions about human cognition, because humans wrote and edited the code.conf: high
explicitIf humans no longer work with code at all, the constraints related to human cognition (long methods, cyclomatic complexity, obscure names, tight coupling) become irrelevant, and some of these notions may not even remain meaningful.conf: high
extendsFragments: May 5 · p8 — Fowler leaves open whether internal code quality still matters in the agentic age; Seemann extends the question to its logical extreme — a future with no human coders at all — and argues the human-cognition-based notion of quality specifically would become irrelevant there, while a structural analogue might not.
explicitMachine code is the one existing exception to the rule that programming languages exist to make programming easier for humans, but Seemann does not expect LLMs to generate machine code directly, mainly because machine code is not portable.conf: high
explicitIf no humans ever look at code, new programming languages optimized for LLMs to consume, generate, and manipulate could emerge, potentially converging on a single such language (which Seemann names 'LLaMe' for the sake of argument).conf: medium
explicitIt is conceivable that technical debt could still accumulate in an LLM-native language, because even machine code involves structural choices (e.g. register allocation) that differ in downstream cost.conf: medium
extendsFragments: July 6 · p6 — Fowler notes that 'design quality reduces to ease of change' and flags whether that lesson carries over to agents as an open empirical question; Seemann's LLaMe thought experiment works through exactly this transfer, arguing ease-of-change-for-LLMs could survive even where human-readability-based quality does not.
explicitWell-structured LLaMe code would let LLMs add features and fix bugs quickly and inexpensively (possibly measured in tokens); badly-structured LLaMe code would take more time and be more expensive to improve.conf: medium
supportsFragments: July 6 · p7 — Fowler proposes token cost as a proxy for architectural quality; Seemann independently arrives at the same proxy ('more resources (tokens?) for LLMs to understand') when speculating about quality in a hypothetical LLM-native language.
explicitHumanity's accumulated software-engineering experience (books, talks, podcasts, blog posts about avoiding long methods, using descriptive names, minimizing coupling) is deeply entangled with human cognition and is unlikely to transfer to avoiding technical debt in LLaMe.conf: high
explicitLLMs would have to learn what constitutes good and bad LLaMe code from their own experience rather than from human software-engineering literature.conf: high
explicitLLMs could plausibly write and train on their own 'incidence reports and think pieces,' letting a next generation of coding LLMs absorb prior-generation lessons much faster than humans absorb comparable knowledge.conf: low
supportsFOD#151: Recursive Self-Learning: Why It Matters Now · p4 — Seemann's 'Acceleration' scenario (LLMs writing think-pieces to train successor models faster than humans absorb knowledge) is a concrete illustration of the kind of no-human-involved AI R&D loop that FOD#151 estimates at 60%+ probability by 2028.
supportsWhat OpenAI and Anthropic Think Happens Next With AI · p3 — Both describe recursive self-improvement (models/generations learning from prior generations' experience) as a live mechanism rather than pure science fiction; Seemann's LLM-to-LLM 'incident reports' idea is a specific coding-domain instance of the general pattern.
explicitIt is possible that LLaMe technical debt is a transitional issue that will be solved within a few years as LLMs converge on appropriate LLaMe coding practices.conf: low
explicitLLMs are unlikely to be constrained by the same limitations as human cognition, but may have their own machine-specific constraints that could give rise to a technical debt that slows LLMs down.conf: medium
explicitIf a machine-native form of technical debt emerges whose limitations lie beyond human cognition, humans may have no chance to troubleshoot it at all.conf: medium
explicitLetting LLMs produce software entirely without human oversight is going to be more complicated than most AI optimists suggest.conf: high
implicitIf today's code quality is entirely reducible to human cognitive constraints, then the question 'does code quality matter' is really a proxy question for 'will humans remain in the loop,' not a question about code itself.conf: medium

Arguments

In a hypothesized future where humans no longer write or read code at all, today's notion of 'code quality' (defined by readability, method length, naming, coupling) would become meaningless, but a structurally analogous form of technical debt could still emerge and would need to be diagnosed and solved by LLMs themselves rather than by applying human software-engineering wisdom.

Explicit premises:

Code quality, as currently practiced, is reducible to human cognitive constraints (readability, comprehensibility, ease of human change).
If humans no longer write or read code, the constraints related to human cognition become irrelevant, and some code-quality notions (e.g. 'long method') may not even remain meaningful.
If no humans look at code, new programming languages optimized for LLM consumption/generation could emerge (hypothesized as 'LLaMe'), replacing human-ergonomic languages.
Even fully machine-oriented code (machine code, register allocation) still involves structural choices that differ in downstream cost, so an LLM-native language would likely also admit better- and worse-structured code.
Humanity's accumulated software-engineering literature is entangled with human cognition and would not transfer to identifying good/bad structure in an LLM-native language.

Implicit premises:

Technical debt is best understood generally as 'cost of future change,' not specifically as 'cost of future human comprehension' — so the concept can survive even when its human-cognition-specific manifestations (readability, naming) do not.
A single dominant LLM-native language ('LLaMe') is a reasonable simplifying assumption for the thought experiment, even though in reality multiple such languages, formats, or representations (or none at all, if LLMs converge on existing languages) could emerge instead.
LLMs (or their successors) are capable of an analogue of 'learning from experience' across generations/training runs in a way that is functionally comparable to how human engineering culture transmits lessons — an assumption the essay flags as uncertain but still relies on for its 'Acceleration' resolution.
The fact that humans could no longer read or verify LLaMe code themselves does not by itself prevent technical debt from existing in it — i.e., 'debt' is defined by cost-to-change, not by whether a human observer can perceive the debt.
Present-day incentives and safety practices (human review, human responsibility for code) are not permanent features of software development — the thought experiment requires assuming today's human-in-the-loop norm could actually be abandoned.

Letting LLMs produce software entirely without human oversight is more complicated than most AI optimists suggest.