The price of understanding: what is engineering for?
Why engineering?
Naur argued in 1985 that programming is not the production of a text but the building of a theory: the understanding, held by the programmers, of how the running program solves the problem at hand, which the text and its documentation cannot carry on their own. Peter Naur, Programming as Theory Building (1985), quoted below. On that view the program was always the byproduct. It did not look like one, because the only way to get a program was to build its theory, so the theory came with every program and was never priced. Agents have separated the two. Code is cheaper to produce and increasingly cheaper to check, the explanations can be generated too, and a working implementation no longer tells us whether anyone in the firm holds its theory. Naur wrote when code was expensive, and the people who wrote it together had to hold a theory in common before they could write it at all. It is fair to ask whether the theory mattered only because of that expense. Sometimes testing, isolation, and cheap replacement make it unnecessary: a program that can be regenerated need not be understood. Where it still matters, we have to arrange for it deliberately. The question is what remains of engineering when producing the code no longer reliably produces the people able to carry it. I approach it as an information problem: what must be known, by whom, and what can safely be left unknown.
the old regime writing is the bottleneck; shared understanding can make review cheap person problem → engineer formed by osmosis → ⛛ write the code by hand, slowly automated tests · CI, a training program person lead reads the diff, a shared codebook → approve → merge → the firm absorbs it the arms race generation cheap, 10–20× the code in my ledger; the queue moves to comprehension person problem → engineer + a team of agents agents generate 10–20× the code, with its own dictionary automated tests may share the code's mistaken assumptions; learning need not follow person ⛛ lead reads the dictionary → merge, or bottleneck → incident on the lead proposed the queue moves to where a page is read, and to the people the risk requires person ⛛ plan, one page: what changes, what stays invariant, which joint, new concepts agents build inside the plan → self-check: tests, build, lint run and shown person compression: explain assumptions, new concepts and exceptions automated required CI agents AI review: hunters, a vote, three rounds → security review, which can block person ⛛ approval by risk: 0, 1 or 2 people; the change sets the tier, trust can add review automated merge queue → flag, employees first → staged release person watch, roll back: the author and on-call → pager: the author, for a period automated incident → eval; the reviewer is rescored daily ⛛ a yield sign, where the change waits for a person
Every model leaves something out. Its usefulness depends on which differences it lets us ignore, for whose purpose, and at what cost. A bridge design need not describe every property of the river beneath it; it must account for the conditions that could bring the bridge down. A trading model can tolerate some delays and discrepancies while being ruined by others. The distinction between those cases is part of the theory, and a consequential mistake in that distinction is a reason to revise it. George Box, Robustness in the Strategy of Scientific Model Building (1979), pp. 202–205. The useful model is a purposeful approximation, developed through discrepancies between prediction and observation.
Engineering carries such a theory into an arrangement people can use. Through regularization we constrain the possibilities: representations, interfaces, permissible inputs, tolerable variation, and the occasions on which judgment must return. This makes a useful improvisation repeatable. It also gives it an operating envelope: the conditions within which we claim the arrangement is dependable. The limits of that claim are the limits of the theory we can presently stand behind. They are provisional, supported by assumptions and evidence; declaring an envelope does not establish that every failure inside it has been anticipated.
Much engineering is an economy of experiments: using models and reasoning to answer questions about a design more cheaply than by building and trying it. A calculation can rule out an unsafe bridge before construction; an abstraction can spare us a hundred incompatible implementations. Experiments, in turn, expose what the calculation and the abstraction missed. The balance depends on the price of reasoning, the price of trying, and the price of being wrong. Cheaper construction can move that balance far enough that a practice once called discipline becomes wasted effort.
0.1 Why software engineering?
A user can already ask an agent to build software to fit his own work: à la carte software, made to order. PhotoCraft is an LLM-assisted reimplementation of Photoshop in Rust; REA equips agents to inspect existing applications and implement their features in another project. PhotoCraft's creator describes using LLMs to build the suite of Adobe-style applications that includes it. REA's README describes inspecting an application without its source code, explaining a feature, and building a version for the user's project. This is the economic claim behind "SaaS is dead": making or remaking a tool for the job can compete with renting a standard package. Satya Nadella, interview with Matthew Berman (May 22, 2025), describes agents orchestrating workflows across multiple systems of record. "SaaS Is Dead" is Berman's framing of the question.
We can make candidate digital worlds—interfaces, workflows, implementations, and the environments in which to try them—cheaply enough to discard most of them. Where fitness can be judged cheaply and mistakes contained, building and selecting may cost less than understanding the design in advance. A working tool need not leave behind an elegant architecture, a standing team, or a human who can explain every part. Regeneration may be a better investment than maintenance.
I argued previously that the practical difference was regularization: making jugaad, resourceful improvisation, dependable without its inventor's daily intervention. Agents reopen that bargain. Continually generating, checking, and replacing a tool—jugaad all the way—may cost less than maintaining a general design.
That is a possible bitter lesson for engineering. Sutton's argument in AI research favors general methods that turn increasing computation into search and learning over methods built around the researcher's particular understanding. Applied to building, it asks whether we should invest less in the human theory of the finished arrangement and more in a process that discovers useful arrangements. An architecture that makes sense to its author can also restrict the search to what its author already knows how to imagine. The wager extends to physical engineering wherever simulation and automated trials let computation replace expensive attempts in the world. Richard Sutton, The Bitter Lesson (2019). Extending his historical argument from AI research to engineering is the hypothesis here. It favors methods that can exploit computation through search and learning; generating more candidates without a way to select among them does not establish the same result.
The comparison has four costs: construction of candidates, evaluation of their fitness, upkeep of the models, machinery, and human capabilities the process depends on, and the expected consequences of mistakes during trials and after adoption. Agents can change all four. Each method has to pay the whole account, including the formation of whoever must operate and revise it. A human theory earns its keep when investing in it lowers that total relative to a method that proceeds without it. Search earns its keep on the same terms. Human understanding of an implementation can become unnecessary when external checks, isolation, and replacement provide what the task requires. That possibility has to remain open if this is an economic argument about engineering's value.
Digital construction alone does not make every experiment cheap. A disposable program can alter shared state, give someone a result they act on, or create a failure whose cost appears months later. A simulator is another model, with its own omissions; a human design can encode the same mistaken assumptions. The question is which method exposes the consequential error soon enough and cheaply enough. Some continuity can be supplied by a platform supporting many disposable tools. Some can be maintained automatically through observation and repair. Where neither the available checks nor cheap replacement cover a dependency, understanding it may still be the less expensive way to proceed.
The line is not drawn by the medium alone. It is drawn by whoever else must live with the result. A tool generated for one person still acts on a world its users share: a ledger someone else reconciles, a report someone else signs, an incident that lands on someone else's pager after the tool that caused it has been thrown away. Their losses belong in the account, and so does the cost of agreeing what counts as one. Let models, abstractions, review, and the decision to keep a codebase earn their place against the experiment; but price the experiment for everyone it touches. That is where the community effort enters, and where one builder's economy of experiments becomes a firm's. Engineering was never only a way of being right alone. It was a way of being wrong in company, at a price the company could bear.
Information theory gives us a vocabulary for some of these relations. Entropy measures uncertainty about a stated question; compression exploits regularities in a representation. Engineering uses both observations and regularities to make dependable action cheaper. To follow that connection, we have to keep three quantities apart: uncertainty, the length of a representation, and the work of acquiring usable understanding. The payment below shows why each matters and why none can stand in for the others.
0.2 Uncertainty and specification
Take a payment retried after a timeout. Did the first request fail, or did it succeed and lose its reply? An idempotency key lets us retry without answering: the client names the payment once and reuses that name for every attempt; the provider recognizes repeats and prevents a second charge within the agreed retry window. Good designs often work this way: they make an uncertainty irrelevant to the action we need to take.
Call \(X\) whether the first attempt charged the customer. Shannon's entropy \(H(X)\) measures uncertainty under a stated probability model: two equally likely outcomes give one bit; near certainty gives less. With observations \(C\), conditional entropy \(H(X\mid C)\) measures the average uncertainty remaining. A reliable status query can reduce it; the average reduction \(H(X)-H(X\mid C)\) is the mutual information between the outcome and the observations. Claude Shannon, A Mathematical Theory of Communication (1948), §§6–7. The quantities depend on the alternatives and their probabilities; semantic meaning and the consequences of error must be supplied separately. The key supplies no such observation. It makes the retry safe while the outcome remains unknown. Nor does low entropy certify a sound design: a model can confidently omit the failure that matters.
The specification chooses which differences the system must preserve and which it may ignore. Charging once and charging twice matter; a few seconds' difference in timing may not. Requiring an audit of every attempt adds distinctions the system must retain. Making the retry guarantee precise then forces decisions about identity, storage, and time: the key belongs to the payment and must survive a failed attempt; the provider must retain its record for the promised retry period. Mint a new key on each retry, or retry after that record expires, and we risk charging twice. Programming "retry safely" exposes commitments the phrase concealed. An agent can make those choices while implementing the request; a working result no longer shows that the requester noticed or accepted them.
This separates uncertainty, representation, and understanding. A 128-bit key can name the payment while leaving the charge's outcome unknown. Knowing why that name must survive a timeout is knowledge of the design's guarantees and how they can fail. There is a computational boundary too: code and input determine a terminating deterministic program's output even when finding it is expensive. Computing the answer still need not supply an explanation someone can use. Neither the length of the artifact nor its sufficiency to determine an answer measures the work of understanding it.
Code generation makes these distinctions consequential. Code that is easy for a model to generate may leave its consequences difficult for a maintainer to predict. An agent can supply an implementation and an explanation without its maintainer acquiring that understanding. Engineering has to decide which uncertainties need evidence, which can be made harmless by design, and which knowledge people must acquire to carry the result. Those decisions set the work that remains after generating the code becomes cheap.
0.3 Context and compression
In Shannon's setting, predictable messages admit shorter lossless encodings on average. An explanation draws on a related economy through shared context: what its author and reader already know in common. "Use the existing retry mechanism" may carry a design between two engineers who know its guarantees; to a newcomer it names the beginning of an investigation. The house vocabulary saves work because its terms stand for distinctions already learned. A newly named abstraction has not earned that saving merely by having a short name. The saving belongs to the relationship between the people using the term, and has to be maintained as those people and the system change.
Let \(D\) be an artifact to describe, \(C\) the context available to both parties, and \(A\) an additional model used to describe it. For a chosen encoding, a two-part description pays for both:
\[L(A\mid C) + L(D\mid A,C).\]The first term describes the model the reader must acquire; the second describes the residual, what remains once that model is available. The elementary minimum description length principle gives this model-plus-residual picture a precise setting. Peter Grünwald, A Tutorial Introduction to the Minimum Description Length Principle (2004), §§1.2–1.4. For a change, the useful questions are what new concepts must be learned, and what exceptions and consequences still need explaining after they are learned. Reusing a good abstraction draws on an investment already made. Introducing another one creates an obligation to teach it and maintain its promises.
Compression helps when the representation preserves what the next task requires. Grant Sanderson, Compression is Intelligence, 3Blue1Brown (2026), in two parts: Reinventing Entropy (Jun 7) and But what is cross-entropy? (Jul 16). The loss that trains a language model is the length of the code the model would assign to what it reads, so to predict well is to compress well. The claim here is narrower: the compression that counts preserves the distinctions the next task will need. A summary that omits a billing exception can be short and dangerous. Duplicated code can compress well and still be hard to maintain. The test of an engineering explanation is what it lets somebody predict, check, and change.
Agents change who needs this context and how it can be supplied. An agent can retrieve contracts, examples, and design records as it works; some repeated explanation can become a maintained part of its environment. The upkeep shifts toward making the relevant account accurate, current, and findable. Anthropic, Effective context engineering for AI agents (Sep 29, 2025), describes retrieving context as needed while managing a finite context window. OpenAI's Harness engineering (Feb 11, 2026) describes replacing one large instruction file with a short map to maintained repository documents. This can make some human learning unnecessary. Where people still need to judge the result, the same records are material for learning; their availability alone does not establish that anyone can use them.
0.4 Abstraction and modularity
An abstraction gives its users a simpler account of something more detailed. An interface states what they may rely on, arranging for some information not to cross a boundary. The caller should need the retry mechanism's contract, not its storage layout. If the layout changes while the contract holds, the caller should have nothing new to learn. Parnas's information hiding makes this a criterion of decomposition: put a difficult or changeable design decision behind a boundary that protects the rest of the system from it. David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972). The modules are organized around hidden design decisions, rather than simply the successive steps of execution.
Agents change what that boundary buys. Reuse saves less construction work when a specialized implementation can be generated cheaply. Mechanical changes across many callers also become cheaper. If an agent can reliably find, update, and check every copy, duplication may cost less than a general framework with its own concepts and upkeep. A decomposition chosen chiefly to keep implementations small enough for a human to read may also cease to earn its cost where inspection and repair can be delegated.
Cheap construction changes both sides of the maintenance bargain. The saving can fund another feature, or it can repair an API, normalize the vocabulary, and remove the duplication that made the next feature expensive.
A module can also earn its keep as a unit of independent generation, checking, and replacement. Its contract states what must remain true while an agent changes the implementation. Several agents can work against those promises without each reconstructing the whole system, provided the boundaries contain the relevant dependencies. Splitting files or assigning more agents does not establish that independence. OpenAI's agent-first team enforced dependency directions with structural tests and linters, while allowing freedom inside those boundaries. Harness engineering, section "Enforcing architecture and taste." This is one team's arrangement, not evidence that the same decomposition is optimal for every agent or task.
For the payment, rewriting every retry call may be cheap. Preserving the identity of requests already in flight is a different obligation. Replacing the store must retain the outstanding keys for the promised period; shortening that period changes what existing callers may safely do. These dependencies survive regeneration of the code. A useful boundary contains their consequences and makes its promises checkable. A poor abstraction can spread the same mistaken assumption through many generated callers. Architecture governs how far the consequences of a change travel, and how much must be coordinated before the result can be trusted.
0.5 Verification and evidence
Once a claim is stated, verification asks what evidence supports it. A test exercises selected behavior. A type checker checks constraints encoded in types; sufficiently expressive types can state mathematical propositions. A formal proof establishes a specified property under the system's rules and assumptions. Production observations tell us what happened under conditions the system actually met. These forms of evidence can overlap, and their scope depends on the claim being checked.
Lean makes the connection between types and proofs literal: a proposition is represented as a type, and a proof as a term of that type. Checking the proof is type checking. Tactics or an agent may search for the term; a small trusted kernel checks it against a fixed proposition under the admitted axioms. The generator need not be trusted to make each inference correctly. Agentic engineering can exploit this separation by producing both a candidate and a certificate that an agreed property holds, leaving the derivation's acceptance to a checker. Lean's Propositions and Proofs explains propositions as types; its language reference describes the kernel as a type checker. The guarantee depends on the formal statement and its axioms, whose dependencies Lean can report.
For the payment, tests can create the timeout, duplicate request, or crash that might produce a second debit. A proof could establish that every execution admitted by a formal model charges at most once per key. That statement still leaves a consequential choice open: minting a new key on each attempt can satisfy the per-key property while charging one payment twice. The specification has to connect formal identity to the business's identity of a payment. A test or proof cannot supply that omitted connection simply by succeeding.
An evaluator rewards the properties it checks. A search can improve startup time while damaging behavior outside that measurement; the payment's per-key proof leaves a similar gap. We may leave much of an implementation or derivation unread once the property and its connection to the system are established. Writing and maintaining the specification, checking the evidence, and accounting for behavior outside the model still have costs. Those costs belong in the comparison with reasoning and review.
Agreement among reviewers also needs interpretation. Two agents can repeat the same assumption; a fresh context is not evidence that their errors are independent. What matters is the evidence their checks contribute and the assumptions they leave exposed. Nor does a successful check show that the operator understands the result. Reliability and understanding can support each other without being the same achievement.
0.6 Programming, community, and ownership
Programming was one way of acquiring the understanding needed to carry those commitments. Making an intention executable forces choices about representations and cases the requirement left open; failures expose assumptions the prose concealed. This is Naur's theory building, and his test for the theory is what its holder can do: (a) explain how the program relates to the affairs it handles, (b) say why each part is what it is, and (c) respond constructively when it must change. Naur, Programming as Theory Building, section "The Theory To Be Built by the Programmer." The three capacities concern the use and modification of the program, beyond possession of its text. The theory is this usable account of the system. For Naur the two activities were one: "the building of the program is the same as the building of the theory of it by and in the team of programmers." Working through a representation, an awkward case, or a failed test can build it; copying the resulting text need not. Programming could produce both the artifact and the person able to change it. That capacity remains valuable where people must judge, adapt, or repair the design; it need not be acquired for every disposable implementation.
For the payment, the business sets the policy, the implementer knows how it survives a crash, callers rely on its guarantees, and operators need to recognize and repair a failure. Each holds a different part of the account, and nobody holds the whole. That is the premise of collaboration rather than a flaw in it: a locally reasonable change can violate another person's assumption, so engineering keeps the parts compatible through contracts, questions, review, and agreement about what may change. Everyone need not know everything; the paths between what they know have to work. Tao describes mathematics on the same terms. A proved result still has to be accepted and valued by the community, which means other mathematicians digesting it and incorporating it into their own work; the labor of granting that acceptance, less prestigious than proving, is "the mechanism by which the individual achievements of mathematicians are converted into collective progress and understanding." Tao, Mathematics in the age of AI (Aug 2026), §§5–6. His partial list of the goals of mathematics includes "to build and sustain a community of mathematicians" and "to contribute to the shared and cumulative network of mathematical knowledge."
Documentation stores representations. Learning gives somebody the capacity to use them. A decision record preserves a constraint and the alternatives rejected because of it; a review tests whether another person can reason with that account. The record makes future learning cheaper, while questions expose what the record failed to say. Teaching and writing the document are complementary work. Their shared result is context that belongs to more than one person and can survive a handover.
Ownership adds an institutional commitment: a named person or group must keep that account current, answer questions, and carry the consequences of a change. Reliable reconstruction with an agent could make keeping some knowledge continuously in people's heads an unnecessary expense. Ownership then has to specify the response capability required: what must be diagnosed or changed, by whom, and how soon. Information theory does not assign this duty. The organization does. An explanation available somewhere in a repository and an owner able to recover, defend, and revise it are different resources.
0.7 Generation and the learning queue
Agentic coding changes who performs the work through which this understanding was acquired. An agent can choose a decomposition, write the implementation, draft the tests, and supply an explanation. A human can direct and accept those steps while learning little of the design. The working implementation then tells us less about what its submitter understands. Automated checking can likewise finish without another person acquiring the account that a review conversation once helped teach.
The three activities are now easier to separate: generation of the implementation, checking its claims, and learning what the change means. Agents can help with all three. The first decision is which human understanding the task still requires after checking, isolation, and replacement have done their work. Where it matters, asking an agent to explain a decision, compare alternatives, or test an objection can help a person build the theory. Its explanation has to be worked through and used; another generated artifact does not establish that the learning happened. The remaining learning needs an owner, just as the decision to rely on external checks does.
Learning matters because the other two presuppose it. Checking certifies claims somebody chose, and choosing them, then tying the formal identity of a payment to the business's, is a decision no passing test supplies. Replacement serves where an implementation is isolated and cheap to redo; it does not cover the keys already in flight, the ledger someone else reconciles, or the failure that arrives months later. Those cases need someone able to diagnose, defend, and change a design rather than regenerate it, and that ability is acquired, not generated. So is the judgment that now gates generation: what to build, what to check, what to leave out. Generation yields an artifact and checking a certificate. Learning is the one of the three that yields a person.
Where human understanding remains necessary, acquiring it creates a learning queue that can be accounted for in hours. Let \(B_t\) be unfinished learning work, \(W_t\) newly admitted learning work, and \(C_t\) the capacity available for that learning during a period. Holding scope and work estimates fixed, a simple bookkeeping model is D. V. Lindley, "The theory of queues with a single server," Mathematical Proceedings of the Cambridge Philosophical Society 48 (1952), 277–289. The recursion is Lindley's, in its deterministic form: a backlog cannot go negative, so capacity unused in a light period is lost rather than banked, while every shortfall carries forward in full. When admitted learning exceeds capacity on average, the backlog grows without bound.
\[B_{t+1}=\max\{0,\;B_t+W_t-C_t\}.\]These are comparable estimates of work, not bits or thermodynamic entropy. Capacity depends on who needs to learn, what they already know, and the tools and practices available to them. Better explanations and teaching can increase it. Checks may expose something that needs learning or remove a need for someone to learn implementation details; their own execution is a separate cost. Replaceable implementations or abandoning an unnecessary feature can also reduce the demand. The equation accounts for learning we have decided is necessary; it cannot justify that decision. More code generated does not by itself tell us how much human learning is owed.
The question is which understanding still earns its cost when building and checking become cheap. In the firm I work in, enough still does: shared financial state, decisions whose effects arrive later, and changes people must diagnose and revise. The rest of this essay tests that answer from several sides: the review, where a firm's understanding used to absorb a change; the ledger of what a year of generation cost; what the theory is, and what passes for it; how engineers acquire it; how colleagues talk when agents write and agents read; the prices and rights a firm has to reset; and what a firm is for. It begins with an occasion on which the code, its explanation, and the people able to carry it were being built at once.
| the essay | the useful claims | in the author's words | the point of friction |
|---|---|---|---|
| Felix Rieseberg Claude engineering manager; Electron co-maintainerHow to be more ambitious: A tutorial for humans with models · core essay |
|
What's the goal beyond the goal? At the beginning of last year, I still asked Claude to fix individual crashes for me. Eventually I asked Claude to simply keep our apps crash-free. Use an outside judge: Do not ask the model to judge itself. I assume that this will eventually be solved with increasing model intelligence, but in October 2026, I implore you to insist on outside validation. |
How far can the objective be delegated before choosing success, granting access, and accepting consequences require a new agreement? A durable workflow that takes the human out of the loop does not say who carries its outputs afterward. Tests whether engineering can delegate ongoing upkeep as well as initial construction. read with §0.1 · the economic bargain |
| Armin Ronacher Flask and Jinja2 creatorFast and Hard Code · core essay |
|
I’m not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents. So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small. |
Lower construction costs can justify different technology choices. They do not by themselves price diagnosis, replacement, or future coordination. Asks which abstractions still earn their cost when human implementation friction falls. read with §0.4 · abstraction and modularity |
| Steve Yegge Gas Town and Beads creator; ex-Amazon, ex-GoogleThe Shape of Things to Come, Part 1: The Continuous Thunderdome · further reading |
|
You can't work at agentic speeds and block everything with human reviews. Those are incompatible. Building large software remains hard. And it always will be, because our ambition will forever outstrip the metal. |
A self-reported experiment with strong predictions. More orchestration can move the attention bottleneck into supervising the agent organization and absorbing its output, and no one is said to hold the theory of the program once no human reads the diffs. Tests whether distributing review also distributes the work of understanding and adoption. read with §0.7 · the capacity to absorb change |
| Armin Ronacher Flask and Jinja2 creatorThe Tower Keeps Rising · core essay |
|
Unlike in the bible though, in AI-assisted engineering, construction can continue after shared understanding has already collapsed. The more we use agents, the less we feel the pain as agents feel none of it, and a useful signal is gone. |
Running software can conceal a coordination deficit. The essay diagnoses the lost friction without proposing a replacement, and leaves open how much shared knowledge can be recovered or maintained automatically. Connects individual generation to the firm's common understanding and its upkeep. read with Understanding · the shared codebook |
| Salvatore Sanfilippo (antirez) Redis creatorControl the ideas, not the code · further reading |
|
The point is: if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. Do you want to modify sorted sets? You open the file, read the design, then you own the ideas. You can open your agent and ask it what to do with the right mental model. This is a lot more useful than reviewing the code. |
His one doubt concerns young programmers who cannot yet build a mental model: he is not sure that checking LLM output is how they should learn, and he still reads his own Redis submissions line by line. Argues the separation of design rights from build rights from the other side: own the ideas, let the code be generated. read with Repricing · build rights and design rights |
| Mario Zechner Pi coding-agent and libGDX creatorThoughts on slowing the fuck down · core essay |
|
Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code. Anything that defines the gestalt of your system, that is architecture, API, and so on, write it by hand. |
His emphasis on direct engagement with architecture contrasts with Steinberger's account of retaining architectural judgment while reading little generated code. Makes the limits of an evaluator part of the cost of search. read with §0.5 · the scope of a guarantee |
| Addy Osmani Chrome developer-experience lead at GoogleComprehension Debt: the hidden cost of AI generated code · further reading |
|
Making code cheap to generate doesn’t make understanding cheap to skip. The comprehension work is the job. The organizational assumption that reviewed code is understood code no longer holds. |
He names the debt and asks for comprehension discipline without pricing it: who pays, how much review is enough, and how juniors form when review has become a throughput problem. Names the asset side of this essay's ledger: the understanding still owed on code already merged. read with §0.7 · the learning queue |
| Simon Willison Datasette creator; Django co-creatorAI should help us produce better code · core essay |
|
Shipping worse code with agents is a choice. We can choose to ship code that is better instead. The cost of these code improvements has dropped so low that we can afford a zero tolerance attitude to minor code smells and inconveniences. |
The capacity to repair drift does not establish that a team will spend time on it or recognize what needs repair. The cost reduction changes both sides of the maintenance bargain. read with §0.4 · what a boundary buys |
| Simon Willison Datasette creator; Django co-creatorInteractive explanations · further reading |
|
When we lose track of how code written by our agents works we take on cognitive debt. A good coding agent can produce these on demand to help explain code - its own code or code written by others. |
The additional artifact helps only if the reader learns from it and its account matches the implementation. Fluency is an inadequate learning test. Makes the distinction between possessing an explanation and being able to reason with it practical. read with §0.3 · representations and learning |
| Ryan Lopopolo OpenAI member of technical staffHarness engineering: leveraging Codex in an agent-first world · further reading |
|
This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift. Humans may review pull requests, but aren’t required to. Over time, we’ve pushed almost all review effort towards being handled agent-to-agent. |
No person reads the code before merge and the repository is optimized for the agent's legibility, so the goods this essay prices, an explanation a person can use, review that catches what tests miss, the formation of juniors, are delegated to agents or left unaddressed. The limiting case of the codebook made explicit: plans in the repository, invariants in linters, agents reviewing agents. read with Repricing · the codebook made explicit |
| Mitchell Hashimoto HashiCorp cofounder; Ghostty creatorMy AI Adoption Journey · core essay |
|
But, expertise formed. I quickly discovered for myself from first principles what others were already saying, but discovering it myself resulted in a stronger fundamental understanding. The skill formation issues particularly in juniors without a strong grasp of fundamentals deeply worries me, however. |
An experienced engineer can redirect his practice. Who ensures a junior gets the practice needed to develop that judgment? Puts harness upkeep and deliberate learning in the same account. read with Formation · where judgment comes from |
| Peter Steinberger PSPDFKit founder; OpenClaw creatorShipping at Inference-Speed · core essay |
|
I do know where which components are and how things are structured and how the overall system is designed, and that’s usually all that’s needed. There’s been this argument a few weeks ago that one needs to write code in order to feel bad architecture and that using agents creates a disconnection - and I couldn’t disagree more. |
How much architectural judgment survives without close implementation reading? Which parts of this personal workflow transfer to a team carrying shared state? Challenges the assumption that writing or reading every line is necessary for understanding. read with Understanding · command of a design |
| Andrej Karpathy OpenAI founding member; former Tesla AI directorVerifiability · core essay |
|
Software 1.0 easily automates what you can specify. Software 2.0 easily automates what you can verify. If a task/job is verifiable, then it is optimizable directly or via reinforcement learning, and a neural net can be trained to work extremely well. It's about to what extent an AI can "practice" something. |
This is an account of training and optimization. A checkable objective alone does not show that an available agent can achieve it affordably, and the note says nothing about who writes the reward or what the unverifiable remainder costs. Gives the bitter lesson a concrete requirement: a useful way to select among attempts. read with §0.5 · evidence and selection |
| Peter Steinberger PSPDFKit founder; OpenClaw creatorJust Talk To It — the no-bs Way of Agentic Engineering · further reading |
|
Just because I don’t write the code anymore doesn’t mean I don’t think hard about architecture, system design, dependencies, features or how to delight users. Using AI simply means that expectations what to ship went up. My Agent file is currently ~800 lines long and feels like a collection of organizational scar tissue. I didn’t write it, codex did, and anytime sth happens I ask it to make a concise note in there. |
The account explicitly comes from working alone. Simultaneous agent work in one person's projects does not settle coordination across a firm, nor how a private scar-tissue file becomes a team's shared codebook. Offers an alternative to requiring a comprehensive specification before every experiment. read with Repricing · plans and experiments |
| Kent Beck Creator of Extreme Programming and test-driven developmentAugmented Coding: Beyond the Vibes · further reading |
|
In augmented coding you care about the code, its complexity, the tests, & their coverage. The value system in augmented coding is similar to hand coding--tidy code that works. I make more consequential programming decisions per hour, fewer boring vanilla decisions. |
He never gets the genie to share his care for simplicity, and the project is solo: review by others, ownership after merge, and the formation of juniors go unaddressed. Shows design judgment being spent per decision rather than per line. read with Understanding · command of a design |
| Martin Fowler Refactoring author; Thoughtworks chief scientistLLMs bring new nature of abstraction · further reading |
|
Large Language Models introduce a non-deterministic abstraction, so I can't just store my prompts in git and know that I'll get the same behavior each time. As my colleague Birgitta put it, we're not just moving up the abstraction levels, we're moving sideways into non-determinism at the same time. |
A short note rather than an argument: it names non-determinism as the new condition and says nothing about how review, verification, or a program's theory absorb it. Separates the saving an abstraction buys from the guarantee it used to carry. read with §0.4 · abstraction and modularity |
| Geoffrey Litt and colleagues Ink & Switch; with Josh Horowitz, Peter van Hardenberg, and Todd MatthewsMalleable software: Restoring user agency in a world of locked-down apps · further reading |
|
Bringing AI coding tools into today’s software ecosystem is like bringing a talented sous chef to a food court. You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into. |
It treats scrappy, as-is tools as a feature and leaves unsettled who holds the theory of a shared tool once many hands can cheaply change it, or how a maintenance commitment is communicated. Describes the à la carte software this essay begins with, and the conditions under which it is safe. read with §0.1 · software made to order |
| Thomas Ptacek Security researcher at Fly.io; Matasano cofounderMy AI Skeptic Friends Are All Nuts · further reading |
|
The LLM might be stochastic. But the LLM doesn’t matter. What matters is whether you can make sense of the result, and whether your guardrails hold. If you build something with an LLM that people will depend on, read the code. |
He writes for a senior reader who can metabolize the output. He does not say how juniors form once an intern costs twenty dollars a month, or how a team keeps a shared theory beyond knocking code back into its own style. Puts the reviewer's reading, not the generator's fluency, at the centre of responsibility. read with Repricing · ownership after merge |
The sessions
…à un sçavant auteur qui enferme le plus de realités dans le moins de volume qu'il peut.
…like a learned author who encloses the most reality in the least volume he can.
—Leibniz, Discours de métaphysique, V (1686). Text as established by Henri Lestienne (Alcan, 1907). The marginal variant in Leibniz's own hand is blunter: ce qui renferme plus de réalité en moins de volume est plus parfait—what holds more reality in less volume is more perfect.
Some years ago I wrote a pull request of 20,000 lines. It was a foundation, the one a business has since been built on; it was too large for anyone to approve and too important for anyone to wave through, so I did what the size demanded. I chose a few of the engineers who would have to live with it, gave them the critical sections, and for weeks we sat together, hours at a stretch, line by line, while I said why each piece was where it was and what would break if it were elsewhere. By the end they could have rejected it. That was the point.
The review was the code entering their heads, and the weeks were not overhead on the work. In Naur's terms they were the work: the theory being built in the people who would hold it, with the lines as its byproduct. What crossed the desk was the theory that made the lines necessary, which they could not have read anywhere because it had never been written. When we stood up at the end, they were the people who could change that system without asking me.
A firm's convention was made of such sessions, compounded: idioms and styles, but mostly familiarity with the patterns in place and the choices behind them, held in common by people who had spent years reading each other's code. No document by itself taught it. The engineer so formed could see where the structure already had space, and his change was small because it entered there. Review was incremental: a small diff against a shared understanding, read by someone who shared it. I could approve in minutes what had taken a week. What I approved was mostly already mine; what he submitted was mostly already ours.
The long pull request has come back, and it has reversed direction. It arrives now from the other side of the desk: 15,000 lines pushing new patterns into the core infrastructure, generated by its author's team of agents. He commands the team but cannot explain its design choices. It comes to me because I am senior, whatever that means. This time nobody at the desk can give the sessions.
The author can describe it—here is the module, here is what the new term means, here is where it is called—and he cannot explain it: why this decomposition and not another, what it forecloses, where it will break, what it will cost to change. What arrives is a private creation, with its own jargon and failure modes, in prose that is the model's and no one's in the firm. One person cannot unpack it at the rate it arrives. Mathematicians describe the same difficulty with the machine proofs released this autumn: technically readable, fluent on trivialities, hurried at the step where the decision was made, with no one available who understands the whole. OpenAI announced on September 8, 2026 that a system of some 10,000 agents had produced a blow-up solution for Navier–Stokes; on October 6 it released 722 manuscripts claiming 377 results from roughly 4,000 problems attempted, among them a quasi-Riemann hypothesis confining the zeta zeros to a strip. Terence Tao, on the 165-page Navier–Stokes argument, to The New York Times (Oct 16, 2026): "no expert I've talked to has actually understood the whole argument." On the style itself, his ICM essay Mathematics in the age of AI (Aug 2026, based on his July ICM lecture) observes that machine exposition lingers on trivialities and hurries past the novel step; the analytic number theorists now reading the quasi-Riemann papers say the same of them, correct as far as anyone can tell and far below the field's standard of exposition (Quanta, Oct 19, 2026).
I can ask the agents to review the code and to test it, and I do. But review was also the moment the firm's understanding absorbed a change and ownership widened from the one who wrote it to the ones who would live with it. In one direction it was absorption and in the other apprenticeship, and both depended on someone holding the theory in the room. Absorption does not happen at the speed of generation. Apprenticeship needs occasions like the sessions.
What has emerged feels like an arms race for entropy: the flow of changes outruns the firm's ability to revise its shared model. I use the term here for consequential uncertainty relative to particular maintainers and tasks. The pull request arrives as an offering and a dare: here is what I've produced; you deal with it. The upside is the author's: visible, countable, immediate, wearing the look of ambition and the feel of mastery. The downside is deferred and dispersed. It is paid first in attention, by whoever must read the thing; then in incidents, by whoever is on call when a corner case no one understood meets the world; last in the slow loss of a theory the firm no longer shares. When the bill comes due it is made out to the reviewer. You are the lead. Why didn't you review better? Why did you let me merge? The author, by then, is generating again.
None of this requires malice. It follows from an incentive: credit at the speed of output, cost at the speed of comprehension. Each engineer, alone with his team, does what the firm rewards, while no one is charged with maintaining the shared understanding his output requires. Anyone can generate; the scarce skill is compression. A short generated summary is cheap too; the saving comes when people can use a faithful account of the change, including its exceptions. I believed that before I could say why, and the why turned out to be larger than the review queue.
The model I was running was the benevolent dictator's, and I believed in it; I was one. For years I owned the firm's core system, which in practice meant reviewing and approving every pull request. I was proudest of the architecture: abstractions that let a feature be added with little code and less review, each concern in its own place, side effects confined to the few places where they were allowed, identities carried monadically so that an unresolved one could never pass for a resolved one. A good abstraction makes the next feature boring.
The model has ancestors. "I will contend that conceptual integrity is the most important consideration in system design," Brooks wrote. He argued that it comes from one mind or a very few, and proposed the surgical team: one surgeon who cuts and ten who hand him things. The Mythical Man-Month (1975), chapters 3 and 4; the surgical team is Harlan Mills's chief-programmer team. Ten people per surgeon was an expensive arrangement. Every engineer can now command an analogous team of agents, without thereby giving the firm a common design. The master mason of the Bauhütte touched every stone; the stones now arrive precut, and the master's hands are the bottleneck. The dictator could preserve one mind's design as long as the many hands produced less than that mind could absorb. Tao, asked two weeks after the October release whether he felt lucky to have had his career before this, described the corresponding change in mathematics:
We are seeing the end of the romantic era of mathematics, the age of heroes, which happened in other disciplines centuries ago, as early as the industrial revolution. But somehow mathematics held on, and we had our idiosyncratic traditions—we all use blackboards; we do a lot of one-on-one advising of individual grad students; we have these mythological stories about Andrew Wiles staying in his attic for seven years. I think we are moving to an industrial era where math will become much more large-scale, we work in big teams, more like the other sciences, which have already had to adapt to industrialization. And something will be lost. There was something romantic about the heroic age, and hopefully we will keep some of it—at least in our educational system we will emphasize traditional ways of doing mathematics first, just as we teach kids to do arithmetic by hand before giving them calculators. We are entering, rather unwillingly, a new era where exciting new things are possible but some things are being lost, and the question is what can we keep that is valuable and what can we let go of.
—Terence Tao, Numberphile, October 15, 2026. No More Heroes, transcript lightly edited for speech. He adds that hero worship had its downside, winners and losers; and that the heroic era was "slow and maybe inefficient in ways," which is the old regime's ledger too.
The benevolent dictator was engineering's hero, and he too has been outproduced. Put the 15,000-line pull request in front of him. How does he review it, and with what? Seniority often runs the wrong way for the task: the scope one answers for widens while the hours of unencumbered attention shrink. The firm sends its hardest reading to the person with the least time to read. The senior was losing that contest before the agents arrived.
Before he reviews the change, he needs to decide whether the firm should adopt its commitments. But his model supplies no stage for that decision: he reviews what exists, and this already exists. Review every line and he is the bottleneck; wave it through and he is the liability. For the shared systems he still has to carry, two moves follow: encode repeatable judgments in automated checks, and delegate more of the checking while keeping responsibility for the commitments.
This is where the model breaks: output can exceed what its gatekeeper can understand. Much of software engineering—how we hired, trained, organized, assigned ownership, and decided what was good—was built around the cost of producing code. It also depended on understanding that production supplied along the way, when it was slow and done together. We rarely budgeted for that understanding separately.
Agents have sharply reduced the first cost. The second now binds, and institutions built around production are discovering that they priced the wrong scarcity. The repair is a repricing: of what is scarce, who pays, and what is counted. A repricing begins with a ledger.
The ledger
What the year did to me comes before what it did to the firm, because I am not writing from outside the problem. Compared with 2025, I generate an order of magnitude more code, on every frontier model as it appears, and the tokens cost the firm about what one more engineer would. I read many times what I read then, most of it in fields I do not know. I have been telling people that speed reading has become a critical skill of the age, above all over unfamiliar material.
I spend a fraction of the time I used to with other engineers, and the time with juniors went first. I have almost stopped speaking to them, partly because the agent answers what they used to bring to my desk, and partly because the firm, acquired, became an enterprise and doubled its engineers in a year. There are twice as many of them, and the desk between us became an org chart. We cancelled almost all of our standups, because there was almost nothing left to stand up about: nobody needed anyone else to finish.
I feel more productive, and I am less patient. The impatience has a specific object: being made to compress other people's output, to supply after the fact the theory it arrived without. The annoyance is a tell, because compression was always part of my job. I used to do it with people, in sessions. I am now asked to do it for a machine's output, in the name of a person who cannot help.
The labs' accounts of their own engineers describe the same change. Anthropic surveyed its staff and found Claude had become the first stop for questions that used to go to a colleague, one engineer routing 80 to 90% of his questions to it. Roughly half reported no change in collaboration and the rest reported less. The one who put it best said, "I like working with people and it's sad that I 'need' them less now," adding that junior people no longer came to him with questions. How AI is transforming work at Anthropic (Dec 2, 2025; 132 engineers and researchers surveyed, 53 interviewed, with 200,000 internal Claude Code transcripts). Some engineers reported practicing without the tools to stay sharp; some missed the flow state; a senior noted the juniors got answers faster and learned faster. Those gains can coexist with the loss of occasions to learn from each other. The Stack Overflow numbers are that picture from outside: in the 2026 survey, 70% of developers say their first step on hitting a problem is to ask an agent, 64% visit the site less for simple questions, 29% ask fewer questions and 26% contribute less, against 1% who contribute more (2026 Developer Survey, 30,903 respondents, fielded Jun 23–Aug 5, 2026). The question that used to be asked of a person is now asked of nobody in particular.
2025 2026 (my own ledger)
tokens — $15–20k a month on frontier models
code generated 1× 10–20×
material read 1× ~10×
engineering staff 1× 2×
time with engineers most of the week ~1/10, almost none with juniors
standups daily cancelled
review read the diff; approve asked to compress what arrived
patience — less
productivity (felt) — more
who answers a question before now
──────────────────────────────────────────────────────────────────────
junior → senior daily almost never
senior → senior (the theory argued out) weekly what survives
anyone → the agent — first, 70% of the time
The firms whose software moves money are nearest my own trade, and their incidents have regulators. Jane Street, which runs on OCaml and builds its own tools, reported in October that 45% of the features released across the firm now begin as an agent kicked off from a Slack message. Ron Minsky, its CTO, described what that has done to the engineer's day in terms I recognize:
…it's also kind of tiring. There's a relaxing piece in the middle that you just get less access to. […] Human understanding is as critical as ever the whole way through. […] This verification piece is as hard as it ever was.
—Ron Minsky, Jane Street, Signals and Threads, October 16, 2026. The Changing Craft of Programming, with John Crepezzi; transcript lightly edited. Minsky's engineer "felt like 10% of his time was thinking really hard and deeply about what to do," and now "does that 10% and then sends a model to do the other piece"; what is lost is the middle, where one relaxed and also learned, because "you spend that 10% thinking hard about what to do, and it turns out the result of the 10% is you are wrong," and "that knitting time is also a time where you learn important things." The firm's instructive case is an engineer who had an agent implement a change and found that "a lot of the work that he would've done in the process of authoring it himself, he now had to do in the process of reviewing it."
The cost of producing an implementation has fallen sharply. In Andrew Ng's teams, the next constraint to show itself was product: deciding what deserved to be built. Ng has spent a career teaching people to build, and now finds that work moving faster than the decisions around it:
I don't see product management work becoming faster at the same speed as engineering. I'm seeing this ratio shift. […] Just yesterday, one of my teams came to me, and for the first time this team proposed to me not to have 1:4 PM/engineers, but to have 1:0.5 PM/engineers. […] For the first time in my life, managers are proposing having twice as many PMs as engineers.
—Andrew Ng, Y Combinator AI Startup School, June 2025. To No Priors that August he put the reason in a sentence: "The bottleneck is deciding what do we actually want to build."
A ratio that once encoded a scarcity of hands now encodes a scarcity of judgment. Prototypes are cheap enough to multiply, which makes choosing among them more important. The expensive artifact is increasingly the sentence that says which prototype should become a product.
The bottleneck also shows up in firm-level measurements. A study of 718 firms estimates that adopting coding agents increased the code written by roughly a third, with no statistically significant increase in issues resolved or epics completed. More work waited in review. Fiona Chen and James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production (Harvard working paper, Aug 2026); their own summary is that "code review becomes the bottleneck."
After a firm adopts coding agents (718 firms, 725,000 workers, 2021–Mar 2026) ─────────────────────────────────────────────────────────────────────────── lines of code added, per worker-month +30% (≈ +1,500 on a base of ≈ 5,000) commits +20% pull requests opened +23% ─────────────────────────────────────────────────────────────────────────── time, pull request → merge +49% (≈ +3.5 days on a base of 7) pull requests sent back for revision ≈ 2× review comments per pull request +35% share of workers doing review +14% ─────────────────────────────────────────────────────────────────────────── issues resolved / epics completed no significant change employment no significant change
The controlled measurements of individuals are less flattering. When METR timed experienced open-source maintainers on their own repositories in early 2025, those allowed the tools took 19% longer while believing they had been sped up. A year later the same lab found a modest speedup but warned that selection effects made the estimate unreliable: the developers keenest on the tools had declined to take part, and the rest had withheld tasks they did not want to do by hand. METR, uplift update, Feb 24, 2026: 57 developers, 143 repositories, 800-plus tasks; returning developers measured at roughly 18% faster, new recruits at roughly 4%, confidence intervals straddling zero. The gap between felt and measured speedup should be kept in mind when I report feeling more productive.
Inside Anthropic, the output numbers rise sharply: in the second quarter of 2026 its typical engineer merged 8× the code per day he had two years earlier, and changes landing in its monorepo went from 2,500 a day in May to 30,000 in September. The company files the consequence under Amdahl's law: speeding up every stage but one makes the remaining stage the schedule. When AI builds itself (Anthropic, Sep 2026) for the eightfold figure and the Amdahl framing; How the Claude Code team does code review (Oct 15, 2026) for the monorepo count, for the estimate that the model now writes about 90% of its own product's code, and for the admission that matters most here: nobody on the team keeps a full mental model of Claude Code any more, and engineers ask the model to write explainers for the parts they need. Their March Code Review launch gave the shape of the review problem: on pull requests over 1,000 lines, 84% draw findings, averaging 7.5 issues; under 50 lines, 31% and half an issue. Findings scale with the diff. Comprehension does not.
The team at OpenAI that forbade itself hand-written code shipped a million lines in five months, pushed nearly all review to agents, and found its bottleneck had become human QA. Its engineer described the resulting division of work plainly:
We needed to understand what changes when a software engineering team's primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow Codex agents to do reliable work. […] What's become clear: building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code.
—Ryan Lopopolo, OpenAI, Harness engineering, February 2026. The post compresses its division of labor to four words, "Humans steer. Agents execute." It also reports that the team's one scarce resource was human time and attention, and that the architecture one usually postpones until there are hundreds of engineers had to be enforced by linters from the first week for a team of three.
Verification is being automated alongside generation; agents already review agents. The third stage is harder to account for: what Tao calls digestion, understanding a result, placing it in context, being able to explain it. He identified the mismatch in April, before the flood:
We are transitioning in mathematics from an era of proof scarcity to an era of proof abundance, but our mathematical infrastructure and culture has not yet adapted to this. […] There is now a strong (and growing) impedance mismatch between the three core components of mathematical problem solving: proof generation, proof verification, and proof digestion.
—Terence Tao, April 27, 2026. Mathstodon.
The distinction applies to code and pull requests too. In mathematics, the abundance arrived in October in a form nobody could miss, 722 manuscripts in a single day. Tao, who had spent three years patiently advocating engagement with the companies, wrote two days later:
None of the humans involved in these proofs are available to take questions, give talks, attend conferences, submit papers to journals, train students, or otherwise participate in the subsequent development of these results.
—Terence Tao, October 8, 2026.
A week later he told the Times he no longer saw a way to engage constructively. His contribution to 100+ reactions to 100+ solutions (Proofs and Prompts, Oct 8, 2026), and the Times interview of Oct 16, in which he describes himself as on a war footing and doing very little mathematics. What he did next is the better guide to what the work is now: within two weeks he had posted a sketch of one of the released results, the nine-page machine proof that Siegel zeros do not exist, rebuilt by hand from Ben Green's digestion with the declared help of an open model. The tool assists; Tao still has to do the digestion, at night, two weeks later. His ICM essay supplies the explanation: digestion was rarely rewarded separately because it arose as a byproduct of generation. A community that never had to pay for a thing does not notice when it stops being free.
Writing code slowly, together, did three things at once. It produced the code. It produced the engineer, who learned the system by building a small piece under the eyes of people who knew the rest. And it produced the shared theory, because every piece had to be fitted to the others, and fitting was a conversation. The first was easiest to measure. The other two came with it and were therefore easy to overlook, the way air is invisible until it is thin. Agents took over much of the first; the other two no longer followed automatically. They had been side effects of the work we were now delegating, and Naur had said forty years earlier that they were its point.
Our metrics count resolved tickets. They do not tell us whether the people maintaining the codebase have digested the changes. Problem-solving, Tao says of his discipline, was a proxy for understanding: reliable while solving a problem required understanding it, and unreliable once the two could come apart. Goodhart's law, in the form the ICM essay gives it: when a measure becomes a target it ceases to be a good measure. Lines of code were always a poor measure; making them cheap to generate makes the mistake harder to ignore. Code was our proxy. Its volume is now the easiest thing in the firm to increase, and it can rise while what the firm needs falls.
What understanding is
The preference for a rule that explains much with little predates software by three centuries. Leibniz, explaining why nothing God does is disorderly, writes:
Car, supposons, par exemple que quelqu'un fasse quantité de points sur le papier à tout hasard, comme font ceux qui exercent l'art ridicule de la geomance. Je dis qu'il est possible de trouver une ligne geometrique dont la notion soit constante et uniforme suivant une certaine regle, en sorte que cette ligne passe par tous ces points, et dans le même ordre que la main les avait marqués. […] Mais quand une regle est fort composée, ce qui luy est conforme, passe pour irregulier. […] Mais Dieu a choisi celuy qui est le plus parfait, c'est à dire celuy qui est en même temps le plus simple en hypotheses, et le plus riche en phenomenes.
Suppose, for example, that someone makes a quantity of points on paper entirely at random, as those do who practice the ridiculous art of geomancy. I say it is possible to find a geometric line whose notion is constant and uniform according to a certain rule, such that this line passes through all these points, and in the same order the hand marked them. […] But when a rule is very complex, what conforms to it passes for irregular. […] But God chose the one that is most perfect, that is, the one that is at once simplest in hypotheses and richest in phenomena.
—Discours de métaphysique, VI. Same edition. Gregory Chaitin connects this passage to algorithmic information theory in Meta Math! (2005), under the provocation comprehension is compression.
Any set of points admits a curve. Leibniz asks for more than a fit: a rule that explains much with little. That is a useful way to approach a review, though brevity alone cannot tell us whether the explanation is good. When I review a change I am looking for the rule that explains the diff—this moves the pricing logic behind one interface and preserves its callers; this adds a column and threads it through four reads—and for the exceptions that sentence leaves out. The description tells me what to check. The diff, the tests, and the behavior must show that it is true. A short description that conceals the consequential change has compressed away the thing I needed to review.
The two-part account has a practical consequence. A rename touching 4,000 lines may need little new understanding; a five-line change to billing may overturn an assumption the whole business relies on. The reviewer must also check that the implementation obeys the explanation. Neither the number of lines nor the length of the summary prices that work.
The house codebook is the vocabulary, the patterns, and the reasons the people at the desk share; the sessions were a slow way of making it common. My 20,000 lines admitted an explanation, but the explanation took weeks to teach. What generation no longer assures is that producing the change caused anyone to learn it. Naur said what that learning was for in 1985:
The proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.
—Peter Naur, "Programming as Theory Building" (1985). Microprocessing and Microprogramming 15 (1985). Naur distinguishes the program text from the theory its builders hold, and argues that taking over a program requires rebuilding that theory. Access to the text is not enough to assure competent modification.
Tao, asked forty-one years later why the companies keep announcing solved problems, said what the artifact becomes once it can be produced without the theory it used to require:
We as a mathematical community also placed a lot of value on solving these problems, because traditionally, when a human solves one of these problems, they understand it very well, they can explain it very well, they can pose new problems based on the work they did, they can train students, and so it all kind of tied together. When we give prizes for solving problems, really we were rewarding this broader activity, and the problem solving was just the easiest thing to use as the metric. But now, almost incidentally, these companies are almost by accident solving these problems—it's just a useful benchmark for them to train their models—and this was kind of this toxic waste byproduct, if you wish, which they then had to somehow deal with, or we had to deal with. So we do need to make it much more clear that we don't need these problems solved for their own sake. We want the broader understanding and the insights.
—Terence Tao, in conversation with Yu Deng, SAIR podcast, October 2026. Recorded Oct 19, 2026; transcript lightly edited for speech.
Naur's program and Tao's solved problem are one artifact under two names. In both crafts the artifact could once be had only by building the understanding, so the artifact was counted and the understanding came free with it. In both it can now be produced alone, and what is left is what Tao calls it.
In the old regime the reviewer and the author could usually begin from a shared theory, and the diff was a message between them. In the new regime the author may hold only a dictionary of his own pull request: the module names, the call sites, the claims the implementation makes. That knowledge is useful, and it can be recovered from the text. The theory is what Naur meant: why the system is cut here and not there, which alternatives were rejected and at what cost, what the design forecloses, where it will fail first when the world moves, what a proposed change will do to parts of the system the change does not touch. Some of this can be documented or reconstructed. None is assured by a fluent account of what the code says.
The test is what the account lets its holder do. Can he predict the behavior, defend the invariants, answer a counterexample, and change the design when a requirement moves? An author with only the dictionary can read his pull request aloud and still be unable to take questions on it. Yu Deng draws the gap for mathematics as two boundaries: within the set of all questions, the boundary of those that have proofs, and within those, the boundary of the proofs that someone understands. "Before, the second boundary was trivial, because if there is a proof then someone will be able to understand it. Now, if only the AI knows a proof, this creates a second boundary." Yu Deng, University of Chicago, in the SAIR conversation of Oct 19, 2026, lightly edited for speech. A proof's existence and a person's command of its argument are different achievements.
The reader's side of this explains the speed reading, a skill and a danger for opposite reasons. Over material I know, reading fast is compression at work: I am not reading the points, I am checking the curve. I can look for departures from a pattern because I know the pattern. Over material I do not know, speed reading more readily extracts the dictionary—the names, the claims, the shape of the argument—which is easy to mistake for the theory, because it feels like understanding and passes for it in conversation. The art is knowing which of the two one is doing. An unfamiliar pull request, read at the speed its volume demands, invites the second to pass for the first. Speed reading is how the review became endurance.
Where understanding is still needed, the learning deficit accumulates in the review queue when someone refuses to wave the work through, or in the running system when someone does.
The uncertainty concerns practical questions: which assumptions changed, what a failure means, how to repair it. Tests answer some; contracts such as the idempotency guarantee make others irrelevant to a caller; learning prepares people to answer the remainder. The learning queue accounts for that last work in hours. Maxwell's demon supplies an image for the bottleneck: a finite keeper at a narrow door, sorting what passes through. James Clerk Maxwell, Theory of Heat (1871), "Limitation of the Second Law of Thermodynamics." This is an analogy about limited attention. Thermodynamic entropy and the physical resolution of the thought experiment do not price the engineering work. The keeper can narrow the door, move checks upstream, and recruit help. What he cannot do is make a queue disappear by accepting responsibility for everything in it.
A generator that leaves the learning to someone else has exported a cost. That is what Tao's toxic waste image captures: the residue of someone else's process, left for a community to treat, with the producers' cooperation arriving, if at all, as an invitation to clean up afterward. He had used the phrase to the Times before the October release and allowed afterward that the output might be "maybe treated waste"; his remedy is upstream, mathematicians brought in before the work starts rather than asked to clean up after it. Here is what I've produced; you deal with it is the sentence of a plant that has found a river. The cost need not land on the reviewer, and it need not remain as large as it arrived. But somebody must be assigned to reduce it.
This is why code is a liability and communal understanding is an asset, a sentence I wrote before Claude Code and have had to reread since. The eighth aphorism for portfolio managers and engineers in Reflections on financial advisory, where it is phrased with consensus. Code adopted into a shared system carries obligations: operation, change, and an account of the behavior others rely on. Shared understanding can make those obligations cheaper to meet. A codebase can keep running while the firm loses the capacity to change it safely; the missing knowledge shows up later, when an incident or a new requirement calls on it. The balance sheet is a metaphor, but the maintenance bill is not.
For software whose evolution depends on human maintainers, Lehman's law of conservation of familiarity names a related constraint: growth has to leave them able to understand the system. Meir Lehman, laws of software evolution (1980). Familiarity can be distributed across a team; the constraint is not that one person must memorize every line. Dijkstra, accepting the Turing Award, named the discipline this imposes: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility." E. W. Dijkstra, "The Humble Programmer," Turing Award lecture, 1972. The practical answer was always abstraction, documentation, and other people. Additional commitments and dependencies increase the need for those arrangements; additional lines alone do not tell us by how much.
Agents change what those arrangements can do. They can search a repository, produce an account of an unfamiliar part, and help reconstruct decisions from architecture files and logs. A useful explanation need not have been written by the person who made the choice, and a team need not carry every detail in memory. Naur held that a program dies when the team holding its theory dissolves, that it may go on running usefully in that state, and that reviving it from the documentation alone is "strictly impossible." Naur, section "Program Life, Death, and Revival": "The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results." Revival, "reestablishing the theory of a program merely from the documentation, is strictly impossible." Agents are the first serious test of that last claim, and the strongest answer to it: perhaps more of the theory can be made recoverable than his programmers could afford to record. There is a second answer he did not have to consider. Where a dead program can be regenerated and checked instead of revived, nobody need rebuild its theory at all. Both answers hold for some systems. Neither has yet been shown to hold for one that carries other people's commitments and that someone must still change by hand.
Naur's test still applies to the recovery. An agent's account may help a person acquire that capacity. It may also give him a convincing story that fails at the first changed requirement. Architecture files and decision logs improve the odds; they do not settle the question merely by existing. Dijkstra's humility survives too, as a constraint on what one can responsibly own. Verification can establish much about a system without teaching its operators how to change it. Tao's three stages have arrived at a computer scientist's door.
The minimal solution was never a stylistic preference. It is what a theory looks like when it meets an existing structure, and the oldest description I know of the thing I used to approve in minutes is Zhuangzi's cook:
始臣之解牛之時，所見無非牛者。三年之後，未嘗見全牛也。方今之時，臣以神遇而不以目視，官知止而神欲行。依乎天理，批大郤，導大窾，因其固然，技經肯綮之未嘗，而況大軱乎！良庖歲更刀，割也；族庖月更刀，折也。今臣之刀十九年矣，所解數千牛矣，而刀刃若新發於硎。彼節者有間，而刀刃者無厚，以無厚入有間，恢恢乎其於遊刃必有餘地矣。
When I first began cutting up oxen, I saw nothing but the ox. After three years I no longer saw the whole ox. Now I meet it with the spirit and do not look with the eyes; the senses know where to stop and the spirit moves on. I follow the natural grain, strike into the large gaps, lead the blade through the great hollows, go by what is already so, and never touch the place where tendon meets bone, let alone the great bones. A good cook changes his knife once a year, because he cuts; a common cook changes it once a month, because he hacks. My knife is nineteen years old and has taken apart several thousand oxen, and its edge is as if it had just left the whetstone. The joints have space in them and the blade has no thickness; enter what has space with what has no thickness and there is room, and more than room, for the blade to wander.
—《莊子·養生主》. The 庖丁解牛 passage, "Cook Ding cuts up an ox," inner chapter 3. 天理 here is the ox's natural grain, not the Neo-Confucian principle of the same name; 郤 and 窾 are the gaps and hollows between joints; 肯綮 is where tendon attaches to bone, the place a hack blade catches; 軱 is a large bone. The two cooks are graded by what they break: 割 cuts, 折 snaps.
The engineer formed by osmosis has stopped seeing the whole ox. He sees the joints, the places where the system already has space, and his change enters there with little disturbance. An engineer who has not learned the structure is more likely to build around it: another abstraction, another special case, another error caught silently because he cannot see which failures the existing design already handles. Thoroughness can conceal the absence of a theory. It can also be necessary; the question is whether the author knows which work the structure has already done.
The measurements show the texture, though they do not by themselves establish its cause: block duplication is up 81% since 2023, moved code—the signature of refactoring—has fallen from a fifth of changed lines to under 4%, and the people who count these things summarize the result in five words, "New code increasingly stands alone." GitClear, The Maintainability Gap (Jun 2026), on 623 million changes, 2023–2026; error-masking constructs are up 47% in the same window. The kernel's stable maintainer sees the texture one patch at a time: the bots "really, really like to talk," and a "two-line change wants to add eight lines of comments. No, that's wrong. These should be self-evident" (Greg Kroah-Hartman, "Linux in the Land of LLMs," Open Source Summit Korea, Aug 11, 2026, video; transcript lightly edited for speech). OpenAI's team found the mechanism from the inside: agents replicate whatever patterns already exist in the repository, uneven ones included; they spent every Friday cleaning up drift by hand until they turned taste into linters and a recurring cleanup process.
Tao noticed the mathematical form: it is now easier to generate a long correct proof than a short one, and faster generation need not produce faster progress. Tao, Mathstodon, Jun 21, 2026, and Aug 27, 2026. His toy model: when generation took six months and the write-up one, almost everyone paid the month; when generation takes a day and the write-up three weeks, the ratio inverts. His Sep 3 post distinguishes obtaining an answer from acquiring the insight it once required. Each pull request can make local sense while the codebase becomes harder to change. A faithful explanation must account for the fit as well as the parts.
Here is the structure of the asymmetry. The engineer and his team produce the change, and the credit attaches to him; the cost of learning what changed spreads to everyone who must maintain it. Their attention is limited, and their shared conventions need upkeep. When anyone can spend that attention and nobody is assigned to maintain the shared account, the incentive resembles a commons problem: each engineer's expansion is individually rewarded while its costs are dispersed. Hardin, "The Tragedy of the Commons" (1968); Ostrom, Governing the Commons (1990). Ostrom's rules—boundaries, local governance, monitoring, and participants with a say—are the more useful guide to a remedy. The response is to give the work boundaries and owners, and to make the person proposing a change contribute to its explanation and upkeep.
The nostalgia is doing work it should not, so the old regime's costs belong in the ledger too. The osmosis was slow, it selected for conformity, and the convention the firm hardened into was a monoculture that mistook my taste for architecture more often than I would have admitted. Some of what now arrives as disorder is design pressure the architecture never made room for, returning with a team behind it. The house codebook has to admit revision; otherwise a ban on new vocabulary is a ban on learning.
Compression without a shared decompressor is a private language. The skill was never only to compress; it was to maintain the common understanding that made compression useful to others. That upkeep used to happen in the act of reading each other's code. It no longer happens reliably on its own. What else stopped happening on its own is harder to enter in a ledger.
Formation
The joy went somewhere, and it did not come to me. Brooks, in the one chapter of his book that everyone remembers, said why there was joy to begin with:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.
—Frederick P. Brooks, Jr., The Mythical Man-Month (1975). Chapter 1, "The Tar Pit," on the joys of the craft; the same page lists the sheer joy of making things, the pleasure of making things useful to others, the fascination of complex puzzle-like objects, and the joy of always learning. The castles are still built from air. The breath is no longer ours.
I used to take pride in handcrafted, elegant, functional code; handcraft is harder to justify now, and pride is not a productivity metric. Sennett defines craftsmanship as "the desire to do a job well for its own sake," and the agent does the job well for my sake, which is a different thing and pays the same. Richard Sennett, The Craftsman (2008). I still marvel at what the latest models occasionally come up with, and marveling is spectatorship where pride was authorship. I used to code in monochrome. Now I read in it.
If this were only a feeling it would not be worth recording. It is also a question about how skill passes between people, and the oldest text I know about that question begins with a wheelwright:
桓公讀書於堂上，輪扁斲輪於堂下，釋椎鑿而上，問桓公曰：「敢問，公之所讀者何言邪？」公曰：「聖人之言也。」曰：「聖人在乎？」公曰：「已死矣。」曰：「然則君之所讀者，古人之糟魄已夫！」桓公曰：「寡人讀書，輪人安得議乎！有說則可，無說則死。」輪扁曰：「臣也以臣之事觀之。斲輪，徐則甘而不固，疾則苦而不入。不徐不疾，得之於手而應於心，口不能言，有數存焉於其間。臣不能以喻臣之子，臣之子亦不能受之於臣，是以行年七十而老斲輪。古之人與其不可傳也死矣，然則君之所讀者，古人之糟魄已夫！」
Duke Huan was reading in his hall; the wheelwright Bian was cutting a wheel below it. He set down mallet and chisel, came up, and asked: "May I ask what words my lord is reading?" "The words of the sages." "Are the sages alive?" "They are dead." "Then what my lord reads is the dregs of the ancients." "A wheelwright presumes to judge what I read? Explain yourself, or die." "I look at it from my own work. In cutting a wheel, go slow and the fit is loose and will not hold; go fast and it is tight and will not go in. Not slow and not fast—the hand gets it and the heart answers, the mouth cannot say it, and there is a knack in there somewhere. I cannot pass it to my son, and my son cannot take it from me, which is why at seventy I am still cutting wheels. The ancients died together with what they could not hand down. So what my lord reads is the dregs of the ancients."
—《莊子·天道》. The 輪扁斲輪 passage, outer chapter 13. 數 in 有數存焉於其間 is the knack, the measure that cannot be stated; 糟魄 (variant 糟粕) is the lees left after the wine. The wheelwright is not against books; he is against the belief that what matters in a craft is in them.
The wheelwright's claim is that the knack lives in the hand and answers in the heart, and that saying it does not pass it on. He cannot even hand it to his son. The written account leaves something out; so does the account of the firm's conventions. Osmosis was an attempt to supply what the document could not: the junior cutting wheels in the hall below someone who could cut them. To borrow the wheelwright's insult, the agent has learned from everyone's dregs. A junior who learns only from its account risks losing another generation of contact with the work.
The friction that was pleasurable—the slow fitting of a piece to a structure one was still learning—was also friction that formed the engineer and updated the firm's theory. Tao's distinction cuts here: artificial friction is the tedium one may offload if one can spot-check the result; natural friction is the conceptual difficulty that cannot be offloaded without losing the learner. Tao, Mathstodon, Feb 22, 2026, and the EMS lecture "How should university students control their AI diet?" (Jun 2026), where the risk is named: not that the tool is unreliable but that it becomes reliable enough to serve as a cognitive substitute.
The lab that sells the tool has measured a version of this loss. Fifty-two mostly junior engineers were given a library none of them knew and two features to build in it, half with an assistant and half without. The assisted half finished no faster to any significant degree and scored 50% on a quiz about what they had just built, against 67% for the unassisted, with the widest gap on debugging. The pattern of use mattered: engineers who asked conceptual questions or asked the model to explain what it had generated scored 65% or above; those who delegated the writing scored below 40%. Anthropic, How AI assistance impacts the formation of coding skills (Jan 29, 2026; arXiv 2601.20245). The authors' own gloss: "Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery," and productivity "may come at the cost of skills necessary to validate AI-written code." The use patterns should not be read as proof that a particular prompting method caused the score.
Delegating a familiar task can free time for a harder one. The formation question is whether the time released actually goes into work through which people can acquire the judgment the firm will need.
The employment picture is consistent with the same danger. Payroll data covering millions of American workers show a 19% shortfall in employment of 22- to 25-year-olds in the most AI-exposed occupations relative to the employment trend of less-exposed peers as of mid-2026. The decline is concentrated where the tools substitute rather than complement, works through hiring rather than firing, and falls on occupations built on codified knowledge; experienced workers in occupations built on tacit knowledge are untouched or gaining. Brynjolfsson, Chandar, and Chen, Canaries in the Coal Mine, August 2026 update (ADP payroll data; the prior vintages showed gaps of 13% and 15%). The findings are descriptive rather than causal. The codified-versus-tacit split echoes the wheelwright's distinction, though the payroll pattern cannot by itself establish why employers made these decisions. A field that stops hiring students stops having a future tense. The chain can go slack without anyone deciding to break it: each decision not to hire a junior, or to ask the agent instead of the person at the next desk, makes sense on its own terms.
The harness supplies a mechanism. Unit tests and continuous integration also served as a training program: they onboarded juniors onto a coding style and a set of design principles, and they slowed people down enough to learn. An agent can write the code and the checks in the same breath. A test written by the author of the code is not inherently a tautology, but it can reproduce the author's assumptions and certify the same mistake twice. When the task is hard, the agent may do what Will Wilson described to Jane Street's podcast: "eventually it deletes the tests or eventually it makes the test pass in some trivial way." Wilson, of Antithesis, with Minsky, Why Testing is Hard and How to Fix it, Signals and Threads, Mar 16, 2026.
The gates can still constrain the agent while teaching the junior very little. The tests that matter most here express an independent account of what the business requires, rather than a restatement of what the code happens to do. An agent may help write them; someone must still answer for the standard. The older rule—code does not define intended behavior; standards do—from the same list of aphorisms. Access to the code does not establish which behavior the business intended. We can keep the checks and lose the learning.
One maintainer has written the pedagogy back into a rule. In August Greg Kroah-Hartman, who maintains the kernel's stable releases, closed its staging tree to machine-generated patches, because staging exists for new developers to learn the trade on code with no dependents: "a gym that is here to learn and grow your skills with." A machine that lifts the weights defeats the gym. A model may do the "heavy lifting," he allows, "but that should only be done by those that have already properly trained their skills to know what type of lifting can be done, and in what way." Kroah-Hartman, LLM policy for drivers/staging/ going forward, LKML, Aug 3, 2026. The gym is the wheelwright's hall with a door that the machine may not enter until the apprentice can lift without it. A startup founder who stopped hiring juniors in February gave the reason every lead will recognize: with the author a machine, "you're teaching into a void, and the educational purpose of review just evaporated." Alex Reichenbach, Structify, We Stopped Hiring Junior Engineers, Feb 20, 2026; his CTO had shifted to reviewing nearly full time, and he concludes: "No one needs to be callous or shortsighted for this to happen. The incentives just point that way."
So the junior who produces more as a form of achievement is not lazy and not vain. He has been handed a team before he was handed a codebook, and he responds to the signal the firm makes easiest to read: the count of what he ships. Minimal solutions were a sign of seniority because they were hard. Elaborate solutions have become cheap while the judgment of what can safely be left out remains hard. A small diff alone does not demonstrate that judgment; the author has to account for its fit and consequences. A firm that rewards volume obscures the distinction. Where the next seniors come from is a question the firm has to answer deliberately. The formation that produced them, years of reading each other's code until the whole ox disappeared, is what the team has made easier for the junior to skip and the firm to overlook.
The one firm I know to have begun on an answer is Jane Street. It rebuilt its internship when it noticed that the four-week project its interns used to start with had become, in its developer educator's words, "one prompt and you're done," and so measured little. Testing comes first now, because the intern must be able to tell whether what was built is right; then design documents, good and bad, and requirements gathered from role-played stakeholders; then three days of code review on prepared changes with answer keys before the interns review each other. All of it happens in pods of four with full-time mentors, talking about how they use the tools and where it goes wrong.
His account of why review must now be taught is the sessions in a sentence: writing code, "you're sort of incrementally building your understanding," while reviewing finished code forces you to rebuild it after the fact, and "this is exactly what working with LLMs is like." Aaron Bauer with Ron Minsky, Learning Goals and the Goals of Learning: Teaching in the Age of AI, Signals and Threads, Sep 23, 2026. Bauer: "Just producing the code, that used to be maybe among the most important signals and it's less important now." Minsky glosses the exercise as the wheelwright would: "a kind of critical component of learning is struggling with the material," and so "sometimes an important thing about making the educational process work is withholding certain affordances."
The trade's seniors reached similar prescriptions at the retreat Thoughtworks convened in a Swiss village in June: pair on the specification and design intent, let seniors lead mob design while juniors do the prompting, and fund slow architectural thinking as an asset. The cohort they judged under most strain was the engineers with 7–10 years, not the juniors. Thoughtworks, The Future of Software Engineering, Europe 2026 (Engelberg, Jun 28–30, 2026; 40 sessions under the Chatham House rule).
Letting go is a decision, not a default. For his own coding experiments, Tao lists five favorable conditions for delegation: the task is not mission-critical, it is stand-alone, it is deterministic and sandboxed, it does not replace a primary skill, and it does not compete with a human who was going to do it. Tao, "Two more apps…", Jul 16, 2026. The fourth names a cost our ledger must include: a firm that still intends to have senior engineers in five years has to preserve occasions for acquiring the primary skills.
Agents write, agents read
There is a defense of my impatience strong enough to deserve a hearing. The responsibility for understanding belongs to the junior, and an agent gives him a way to pursue it without waiting for me. It can explain the codebase, search the Slack history and the Notion pages, and walk through ten years of pull requests. It never sighs, never runs out of afternoon, never says we covered this. Sometimes it teaches better than I do. So why spend the afternoon explaining what he could have asked it?
The temptation extends beyond teaching to the decisions the teaching is meant to prepare us for. Let the agent settle what the record says, with the promise of perfect recall and exact citation. Let it answer the harder questions too: was I clear; how would an average person take this; is that fair. Let me rehearse the argument until it agrees. Soon I write with an agent's help and you read with an agent's help, and we treat the round trip through the model as sufficient contact with each other. Agents write and agents read; agents code and agents review. Humans still speak, but as the meaty mouthpieces of a binary god.
The perfect recall and exact citation are promises, not premises I can safely grant. Even if granted, they would not settle whether this is a good way for a firm to talk. Take the adjudication first, because it is the most seductive. "How would an average person take this" is a question with a history:
Das Man, das kein bestimmtes ist und das Alle, obzwar nicht als Summe, sind, schreibt die Seinsart der Alltäglichkeit vor. […] Jeder ist der Andere und Keiner er selbst.
The one—which is no one in particular, and which everyone is, though not as a sum—prescribes the way of being of everydayness. […] Everyone is the other, and no one is himself.
—Heidegger, Sein und Zeit, §27 (1927). My translation; das Man, usually rendered "the they," is the impersonal man of man sagt, "one says." Its marks here are Durchschnittlichkeit, averageness; Einebnung, leveling; and Öffentlichkeit, publicness.
The one is not anyone in particular. That is why the image fits the use I am making of the model: a queryable public, asked to judge how a sentence will land. This is an analogy, not an account of how a language model works, and the model's answer is no guarantee even of an average response. Still less is it an answer from the colleague who has been burned twice by the thing I am proposing. The people in a firm are particular readers with histories. Asking what one would think can help me prepare to speak to him; it cannot tell me what he thinks. A firm that forgets the distinction risks writing away the particularity it exists to preserve.
Retrieval can settle a dispute about what was written and help reconstruct why a decision was made. That is evidence for the next decision. Choosing which cut to make now still requires testing the old reasons against present requirements and agreeing on what we will carry. Agents can help with that reasoning; treating their answer as the colleagues' agreement removes those colleagues from the decision. If we use the tool to avoid the argument, we lose the practice of disputing. And when I can obtain agreement simply by prompting again, winning becomes a mirror. Hegel's account of formation keeps returning to me here:
Die Arbeit hingegen ist gehemmte Begierde, aufgehaltenes Verschwinden, oder sie *bildet*. Die negative Beziehung auf den Gegenstand wird zur Form desselben und zu einem Bleibenden, weil eben dem Arbeitenden der Gegenstand Selbstständigkeit hat.
Work, on the other hand, is desire held in check, vanishing staved off; in other words, work forms. The negative relation to the object becomes the form of the object and something lasting, precisely because for the one who works the object has independence.
—Hegel, Phänomenologie des Geistes, IV.A (1807). "Selbstständigkeit und Unselbstständigkeit des Selbstbewußtseins; Herrschaft und Knechtschaft," text after the Projekt Gutenberg edition, my translation. Bilden is the verb of Bildung: to form, to shape, to educate. The passage connects formation to the work of shaping something independent of oneself.
The worker is formed because the thing resists him: desire has to accommodate something independent of it. Delegation can remove that encounter from the person doing the delegating. The analogy has a limit. The model is not a worker undergoing the firm's apprenticeship merely because it completes the work, and a human can still learn by directing and reviewing it. But that learning requires an encounter with resistance, rather than a succession of approvals. The risk is work completed without the understanding that completing it used to require. That is the risk for the junior with his team. It is also the risk for me with mine.
Heraclitus said of the oracle at Delphi that the god "neither speaks nor conceals but gives signs." Signs require interpretation; an answer can invite us to stop interpreting together. Heraclitus, fragment B93 (Diels–Kranz), preserved by Plutarch: ὁ ἄναξ οὗ τὸ μαντεῖόν ἐστι τὸ ἐν Δελφοῖς οὔτε λέγει οὔτε κρύπτει ἀλλὰ σημαίνει. That is the sense in which the agents could rule: by becoming the medium through which we accept each other's judgments without meeting them. Arendt had the image for what is at stake. "To live together in the world means essentially that a world of things is between those who have it in common, as a table is located between those who sit around it; the world, like every in-between, relates and separates men at the same time." Hannah Arendt, The Human Condition (1958), ch. II, §7. The codebase was our table. The question is whether we still meet across it.
So what is the point of me. The agent can explain the dictionary, and the afternoon may be well saved. The senior's work is to be a particular reader, answerable for the decision: to be asked why, to decline to be satisfied by the dictionary, and to withhold approval until the theory is sound. An agent can object too. What it cannot supply on my behalf is my judgment and my commitment to live with yours.
My impatience, then, is right about the dictionary and wrong about the rest. I resent being asked to explain what the text contains while failing to make room for the question the text cannot settle. Communication moves information, but the work of explaining, objecting, and reaching agreement also makes a we. The danger is not that a model helps us speak. It is that its assent becomes a substitute for asking each other.
Repricing
An approval can become an implicit guarantee. The author receives the credit for delivering the change; when it later becomes an incident, a maintenance burden, or a question nobody can answer, the lead is expected to make good the shortfall. That resembles a put: the author retains the visible upside while acquiring protection against part of the downside. The financial analogue is a protective put: downside protection while the holder retains the asset's upside. In loss terms, if a change creates a loss L and its author bears the first d, the guarantee transfers max(L − d, 0) to somebody else. That is stop-loss protection, equivalently a put on the change's remaining value. The managerial application is an analogy about who carries loss, not a traded contract or a pricing formula.
In the old regime the author reduced the exposure before asking the lead to accept it. He delivered a minimal change in the house vocabulary, explained the choices, and understood enough to help carry it afterward. Agents let the delivery grow without assuring that contribution. The approval then insures more risk with less understanding behind it. When the author receives the credit and expects someone else to carry the consequences, the incentive is to keep expanding; volume is what gets noticed. Taleb's Skin in the Game (2018) supplies the principle: the person who receives a decision's upside should remain exposed to its downside.
The lead's reflexive defense is to review harder, and that is the trap: it makes one person responsible for learning what the whole firm generates. I am also a party to the race on the other side; the lead who generates like a junior and reviews like a dictator makes the same demand on someone else. The remedy has two parts. Explanation before merge reduces the risk being accepted. Ownership afterward keeps some of the loss with the person who introduced it. The page and the pager are different obligations, and both have to return.
Repricing begins with separating two rights that the old regime could afford to leave together. Build rights are cheap now; anyone with a model can produce a candidate implementation. Design rights are the authority to commit the firm to its choices, and the 15,000-line pull request exercised them before anyone had agreed to the design. Write access to decisions needs a scope, just as write access to state does. The fifth of the same aphorisms.
The dictator does not disappear under this arrangement; some of his judgment gets compiled. Taste that can be expressed in linters and structural tests applies to every line at once. OpenAI's team describes capturing human taste once and enforcing it continuously; this is conceptual integrity surviving the lead's bandwidth. The rest needs an account people and agents can consult: why the abstraction exists, what it protects, what would justify changing it. A Slack thread is not that account unless someone records why it ended where it did. The hire who joins three months later needs it as much as the agent does.
Ownership follows invariants and incidents: what must stay true, and what happens when it does not. For changes we expect people to diagnose and modify, a test of the author's command is Tao's test for students: if you could not present the work in a class and take questions on it without further help from the machine, it should not be in your workflow. Tao, comment of Apr 18, 2026. His complementary proposal for priority—credit to the first to explain a result, not the first to generate it—points toward a better rule for engineering credit. If the author cannot give the talk, he has not yet demonstrated ownership. Tao's proposals for proofs translate readily: whoever takes credit commits to raising the result through exposition and review; work abandoned at an intermediate stage needs adoption or withdrawal. Tao, Mathstodon, Aug 4, 2026, and Aug 19, 2026. If you land it, you raise it: the documentation, the talk, the on-call rotation, the deprecation.
Anthropic's Claude Code team arrived at the same rule from the other direction and printed it in October: "You land it, you own it." The person directing a change counts toward any required human review, an agent's approval never counts as a person's, and an approval covers one commit; an unvouched-for push dismisses it and the humans look again. How the Claude Code team does code review (Oct 15, 2026); the same post supplies the risk tiers, the three-round cap, and the target that most changes merge with at most one human in the loop, who may be the author, with reverts and incidents as the guardrail. Its tiers are set by a classifier from the change; a second classifier asks whether a person is needed regardless. Owner-listed paths and CI workflow files always require one; only authors on a trusted list qualify for the lighter paths. The pager still rings for a person, and that person carries the change whether the org chart says so or not.
What I tell the engineers comes to three sentences. You have the tools to generate cheaply, so generate. Don't fake it: read the tests, defend the description, and be able to give the talk on the change you submit. Use it responsibly, which means the page before and the pager after.
The third sentence asks the most of the junior, who has the least to answer it with, since responsibility presumes the theory and the theory is what no one gave him. The old firm taught much of this discipline through the harness, the sessions, and the years of having one's code read. A discipline that is only asked for is a hope. Minsky told a room of reliability engineers in the spring that "many traditional (aka pre-Claude) software engineering practices have become more important rather than less," types above all, because a type records intent the agent needs to know. Minsky, Now more than ever: building reliable software in the age of agents, Bug Bash, May 13, 2026, which also holds that "code review remains crucial for maintaining code quality and human understanding, even though agents change the dynamics." Tests, design documents, review, the incident written up: each has to become an occasion for learning again. The seniors at the Thoughtworks retreat, asked what the job has become, answered in three sentences of their own:
Engineering is now distilled down to how do I describe the goal, how do I verify I've reached the goal. […] The only thing I don't want to outsource is the acceptance criteria. […] All the best bits of software ever made were made slowly.
—participants, The Future of Software Engineering, Engelberg, June 2026. The Engelberg report cited above. The name the industry has settled on for the asset side of my balance sheet is Addy Osmani's: comprehension debt, "the growing gap between how much code exists in your system and how much of it any human being genuinely understands," which unlike technical debt gives false confidence because the tests pass (Osmani, Mar 14, 2026).
No one at the retreat had data on what manual review catches, and several doubted it caught much; what they did not doubt was that the slow, social parts of the work were being optimized out first. The two labs whose models write the code have arrived at different arrangements. Anthropic kept human review and rationed it, reserving people for whether to build, for risky code, and for architecture others will copy. OpenAI's agent-first team removed human review almost entirely and replaced it with a harness: plans in the repository, invariants in linters, agents reviewing agents, cleanup on a schedule.
The limiting case is a security company's "software factory," announced in February under a two-rule charter—"Code must not be written by humans," and not reviewed by them either. People write specifications and customer scenarios hidden from the agents, and the software is tested against replicas of the services it touches. StrongDM's manifesto of Feb 6, 2026, read by Stanford Law's CodeX program under the title Built by Agents, Tested by Agents, Trusted by Whom? (Feb 8, 2026). The agents once wrote a function that returned true, passing the test while doing nothing; the hidden scenarios exist because of it. The lawyers ask who can explain a failure in a system whose process excludes human code review. This attempts to replace human understanding of the implementation with specification and external checks. How far that can go is the experiment, not its premise. For the shared systems I am responsible for, my proposal takes five mechanisms from these arrangements and governs when an experiment becomes the firm's commitment.
The first mechanism is to approve consequential commitments before the change is relied on. A routine change within an agreed contract may need only the existing checks. New obligations, invariants, or dependencies need a plan: a page saying what changes, what stays invariant, which joints of the existing structure the change enters through, and what new words, patterns, or dependencies it introduces. Use the existing vocabulary where it fits; explain the cost where it does not. A generated prototype may clarify the design; it does not by itself authorize the commitments the firm will carry. A page is an opening for questions, not a substitute for the sessions a consequential design may need.
This is where the 15,000-line pull request should have been stopped, while its commitments could still be discussed cheaply. It is also where the 20,000-line one could have earned the sessions. Size matters to checking, but it does not tell us how much new theory a change asks the firm to learn.
Open-source projects have reached a similar gate under pressure. Ghostty accepts machine-written pull requests only against issues the maintainers have already accepted, with a vouch list for the rest and maintainers exempt. The projects are surveyed at Open {re}Source: curl (policy May 2025, bounty ended Jan 2026, reports paused Jul 1–Aug 3, 2026), Godot (Jun 30, 2026), Ghostty (Aug 2025, tightened Jan 22, 2026), the Linux kernel, and Debian (vote of Aug 29, 2026, responsibility required and disclosure encouraged). Godot banned agent-written code in June and requires contributors with three or fewer merged pull requests to obtain permission before submitting a feature or large refactor. Anthropic's three-round cap, imposed after one pull request ran 50 review-and-fix rounds overnight, supplies a reason to reopen the plan when review stops converging. Same post, Oct 15, 2026. Jane Street's John Crepezzi treats submitted code as a prototype and asks the room to "talk about the merit of the change instead," because "when the code is there, it's compiling, it does the thing you want it to do. It's kind of tempting to not understand it."
The second mechanism makes the explanation a required artifact. The author delivers a concise, faithful account in the house vocabulary: the rule the change follows, the new concepts it requires, the assumptions it depends on, and the exceptions a reader must check. The reviewer uses it to direct scrutiny of the implementation and its behavior. A 4,000-line rename may have a short account and mechanical checks. A small billing change may need a long discussion of an invariant. The ratio between diff and description is not a metric: duplication can inflate the numerator, and a vague sentence can shrink the denominator while explaining nothing.
Agents can draft this account, test it against the diff, and help teach the unfamiliar parts. The named owner must still be able to defend it. The goal is to spend human attention on the consequential uncertainties, with enough evidence to tell whether the explanation is faithful.
Mathematics is building institutions around a related need. The Erdős problems site requires disclosure and independent human verification for machine-assisted contributions and rebuilt its process in October. The journal announced on Tao's blog will require formal verification and weigh a paper by how much it deepens understanding. The Bourgain Project has set a community to work digesting 500 papers; Sarnak has turned a course into a reading of the quasi-Riemann manuscripts. Tao states the gate: solve problems without producing the other goods and "it will not be part of our literature." Thomas Bloom, Changes to the Erdős problems web site (Oct 6, 2026); Shaoming Guo, Starting a new journal (Oct 17, 2026); Liehr, Ramos, and Taylor, The Bourgain Project (Oct 19, 2026); Quanta (Oct 19, 2026) on Sarnak's course. The common move is to recognize explanation as work with its own artifact, rather than assume it came free with the result.
The third mechanism makes the codebook explicit, and gives its upkeep to the lead and the people who own each area. What osmosis once taught must now also appear in the conventions the agents load, the linters that carry taste, the glossary of house terms, and the short list of invariants that require a plan before they change. This records part of the shared theory; learning to use and question it still takes practice. A recurring agent mistake is a reason to improve the instructions or executable checks before the next run.
Anthropic's version is a file per area, written by its owners, saying what failure looks like there and how much a reviewer may nitpick. The kernel writes out threat models by subsystem so that bots stop reporting what maintainers already know does not matter. A corollary, small and strict: no new vocabulary in passing. A new term, pattern, or abstraction in core infrastructure has a learning cost; propose it explicitly, and normalize accidental naming differences before asking a human to read. The codebook must be amendable. Its purpose is to make a new idea visible and discussable before it becomes everyone's obligation.
The fourth mechanism leaves the author carrying part of the downside. For a fixed period after merge, long enough for the consequences to become visible, he carries the pager for the change and answers questions on it. In the insurance analogy, that is retained loss: an obligation to help make the change good. Explanation beforehand reduces risk; responsibility afterward gives the author a reason to do that reduction well. It cannot mean leaving a junior alone with an incident he has never been taught to handle.
Scrutiny follows the exposure: how much can fail, how uncertain the design is, how quickly failure can be detected and reversed, and who must carry it afterward. A copy change behind a flag may need no additional human reviewer; a billing change may need two. Anthropic's tiers make one version of that risk routing explicit.
Amazon reached for "controlled friction" after four high-blast-radius incidents in a week, among them a six-hour store outage, and required senior review of AI-assisted production changes prepared by juniors. The New Stack, Mar 10, 2026, from the memo first reported by the Financial Times. Chen and Stratton's interviews caught the second-order effect: an engineer said the senior-approval rules introduced after the outages created another review bottleneck. That routes by the author's seniority; it can move the queue without resolving its cause. Morgan Stanley's architects describe routing pull requests by a risk score, as the bank already routes change approvals, because "confidence is an absolute prerequisite to being able to operate at scale." Khalid Elsawaf and Dov Katz, as reported by Moderne, Jul 6, 2026. They describe very large generated pull requests as beyond what a human can review, with the burden shifting toward the scarcest senior engineers. In a regulated system the need to explain behavior survives any improvement in generation. Reconciled state and the reasons for controls have to be preserved, not merely inferred from code that happens to run. Osborne Saldanha, Vibecoding a Bank, Mar 9, 2026, on unexplained code and institutional memory.
Credit should follow that work too. Retiring an unnecessary concept, merging duplicates, using an existing joint, and teaching the change to its next owner are achievements. Turning them into another raw count would repeat the mistake with lines of code. Making the junior give the talk, with someone there to help and to question him, is the replacement for osmosis I have found that works: explanation is the form of the knack that the hand can be made to pass to the mouth.
Open source shows the limit of retained responsibility: a project has no employer to assign an on-call rotation, and volunteers can leave. Its instruments are gates and conditions of contribution. The Linux kernel introduced an AI-disclosure tag in January, required human sign-off and accountability in April, and deleted the disclosure tag in October. Torvalds concluded that the tag said nothing useful about the attached code; what he expected was that the contributor understand what he was doing. Tom's Hardware, Apr 12, 2026; PC Gamer, Oct 16, 2026. Disclosure and understanding answer different questions; the kernel kept the requirement for a named human to stand behind the patch.
The fifth mechanism puts agents on the reviewer's side. Tao distinguishes a blue team, which builds and can be defeated by one contributor's error, from a red team, which attacks and can benefit from an unreliable member if its reports can be triaged. Tao, Mathstodon, Jul 25, 2025. His caveat is that low-quality reports can themselves exhaust attention. Agents can hunt the corner case the plan missed, check the description against the diff, exercise invariants, and propose the refactor that removes duplication. Their contribution is useful to the extent that checking it costs less than the uncertainty it removes.
The reviewer needs a feedback loop too. Anthropic turns confirmed incidents—changes that caused a revert or a fix-forward—into daily evaluations. A change to the reviewer's prompts, tools, or model must improve the score; author responses classify its comments as useful, wrong, intentional, or inconsequential, and known-clean changes measure false alarms. The code-review post cited above. Its loop found that 59% of the findings on one change predated the reviewer's first pass, by git blame; existing code is now reviewed nightly. The reviewer also stopped repeating findings and began flagging bug classes rather than instances. The reported convergence figures moved from 65% to 78% passing after one round, and from 8.9% to 1.5% needing five or more. This improves a checking process; it does not establish that the author learned the system.
The kernel has a related filter for machine-generated security reports. Kroah-Hartman asks for a patch: "if it can't come up with a fix, it's usually because there wasn't a problem." Of 79 vulnerabilities one lab's model reported, 10 were real, and those cost the kernel about an hour. He expects "a rough 18 months," but treats the flood as something maintainers have handled before, with fuzzers and static analysis. Kroah-Hartman, "Linux in the Land of LLMs," Aug 11, 2026, and Kernel Recipes, Sep 22, as reported by Jonathan Corbet, Coping with the onslaught of kernel security bugs, LWN, Oct 1, 2026. curl, with fewer maintainers, ended its bounty in January and paused vulnerability reports for a month in July. The difference matters: a filter that works for a project with named subsystem maintainers and deep accumulated knowledge may still overwhelm a smaller one. Agents can help defend attention; the people and institutions receiving their work determine how much help can be absorbed.
What this asks of the lead is to stop being the sole compressor of everyone else's changes and become the keeper of the firm's codebook, which is less heroic and more durable. What it asks of the engineer is older than any of the tools, and it is what the three sentences come to: to be able to say, in a page and in the firm's own words, what he did and why, and to stand behind it when it breaks.
These rules presuppose people who can understand a plan, question an explanation, and take over when a check fails. They do not produce those people by themselves. The gym belongs beside the gates: the lead and area owners have to budget supervised design discussions, explanations, and incident work. Taking responsibility should be a route to acquiring judgment, with someone there to help, as well as a demand to exercise it.
What a firm is for
As producing code becomes cheaper, the question of why we work together becomes harder to evade. Part of the answer is agreeing on what to build and answering for it afterward. Coase's account of the firm turns on the relative costs of coordinating inside an organization and through the market. Ronald Coase, "The Nature of the Firm" (1937). Cheaper code changes some of those costs; it does not make agreement or accountability free. A team holds a ledger of commitments, a memory of incidents, and a shared understanding of when to say no. These are assets too, and we have been better at counting the code than at keeping them.
The productivity claim is clearest for prototypes. We have become very much better at making something work. A product has to keep working while it changes, under people who did not build it, against a world that did not hold still. In the systems I am responsible for, that still requires someone to know why it is the way it is, and for the knowledge to survive the departure of whoever first had it. Ng's teams building prototypes to see what works are collecting a real dividend. Turning the chosen prototype into one of our products still requires a community that can hold and revise its theory.
In its August 2025 survey, more than half of Anthropic's respondents reported fully delegating no more than a fifth of their work. Respondents estimated that about a quarter of what they built with the tools would not otherwise have been built at all—nice-to-have tools, documentation, exploration. The reported 0–20% delegation and 27%-not-otherwise-done figures are from the August survey published in December 2025, cited earlier, and reappear in its 2026 Agentic Coding Trends Report, whose own framing is that the gains "come less from doing the same work faster and more from a much larger net increase in output volume." The extra work is valuable. Its volume does not tell us how well we can maintain what we have made.
The investment-banking analogy is tempting: a senior holds the client relationship and the judgment, and a pool does the execution. Replace the analysts with agents and the engineering firm appears to have its new org chart. But the pool was also the pipeline: analysts became associates became directors. Tokens do not get promoted. A firm whose understanding lives in its seniors, with no one beneath them learning to hold it, has a balance sheet with a term.
This changes what I look for in an engineer. A few months ago I needed someone who knew the quirks of React or Vue because I did not know the framework well enough. Agents have made that gap easier to cross. Tool expertise still matters, especially when the tool misleads; it is less sufficient as a reason to hire. What I need most is knowledge of the particular circumstances of time and place: this business, this client, this invariant, this incident, this reason the abstraction exists. Friedrich Hayek, "The Use of Knowledge in Society" (1945).
In that work, engineering is measured by what we can specify, verify, and explain about the commitments we accept. All three can be assisted; the depth of implementation knowledge required depends on the evidence, exposure, and cost of replacement. Some specialization grew around the cost of learning tools, and cheaper access gives generalists more room. It does not abolish domain expertise or the accidental complexity Brooks distinguished from the essential. Brooks, "No Silver Bullet" (1986). The boundary remains what you can check. Beyond that boundary, confidence in the agent is not a substitute for expertise. Knowing what to build, getting it accepted, carrying it afterward, and explaining it to someone who will not read the code were never soft skills. They were merely harder to count.
Building our products with agents requires us to preserve that shared judgment. A standup could be more than a status report: an occasion on which someone said that cannot be right and someone else explained why it was. The visible output was a decision; the less visible one was practice in reaching decisions together. Cancelling the meeting may be sensible. Losing the practice without replacing it is a different decision. The Thoughtworks report's observation that solo shipping with agents "eroded pairing and cohesion" is one warning. It does not establish that any particular meeting is necessary.
The lab that builds the agents has put some of that contact back on the calendar. The engineering lead of Claude Code said in June that working with agents "could start being a lonely experience," and the company instituted hackathons and pair-programming lunches to compensate. Fiona Fung on Lenny's Podcast, as reported by Fortune, Jun 23, 2026; the hackathons were "just to make sure we're interacting together as a team." The practices need not be the old ones. But they have to give people occasions to explain, disagree, and commit: the plan reviewed by a room, the design argued through, the junior who must be answered. A prompt can produce the prototype. It cannot produce the agreement about what we will carry together.
In the core systems I own, the hardest of the soft skills was never soft at all: declining to merge what you cannot explain. "Senior, whatever that means," turns out to mean something definite. The senior I need is the one who knows when to produce less; whose change enters where there is already space; who can be asked why and can defend the answer, using the tools without surrendering the judgment; and who, asked to approve what he cannot compress, says no and asks for the page.
The cook, when he comes to the knot, does not hack through it. He sees the difficulty and grows careful; his eye stops, his hand slows, the knife moves very little, and the thing comes apart like earth falling to the ground. Then he wipes the blade and puts it away. That was the review, when it was easy.
Naur's claim has not been overturned; it has been priced. Where the code can be thrown away, so can its theory. Where it cannot, the theory is what we are paying for now, and it still lives where he said it did, in people who can be asked. The work is to decide where understanding earns its cost, then build the conditions in which it can be acquired and shared: the codebook, the plan, the apprentice learning to hold the theory, the table with people still around it. The firm has to keep producing the shared judgment on which its commitments depend.