What is engineering for?
the old regime one scarcity, the hands; review is cheap because the diff arrives compressed 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 pass trivially, or are deleted 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 tier set by the change, never by the author 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
Why engineering?
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. Regularization here includes operational constraints and standardization. Mathematical regularization, which restricts or penalizes candidate solutions, and an operating envelope, which states the scope of a claim, are related ideas rather than identical operations. A constraint can exclude a useful solution as well as a bad one.
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 or machinery used to produce and select them, and the expected consequences of mistakes during trials and after adoption. Agents can change all four. Each method has to pay the whole account. 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. We should allow that result, rather than rename every successful automated process engineering so that the profession wins by definition.
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. 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. To use it, we have to keep three quantities apart: uncertainty about a stated question, the length of a representation, and the work of acquiring usable understanding. They are related. They are not interchangeable units of one substance called complexity.
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? What should a second request do? How long must the system remember that the two requests concern one payment? These are different questions: a fact about the world, a decision about acceptable behavior, and a commitment the implementation must support. The specification gathers facts and makes decisions. It selects which distinctions the system must preserve: timing may vary; charging the customer twice may not. Programming the retry forces someone to say how those distinctions will be represented and preserved through a failure. That is an occasion for learning what the original sentence did not settle.
Start with the fact. Call \(X\) what the first request did. Before anyone looks, it has two values: the charge failed, or it succeeded and the reply was lost on the way back. The customer's card is in one state or the other; the uncertainty is ours. How much of it there is depends on what we already believe. If the logs say that nineteen timeouts in twenty were failures, the question is nearly settled before it is asked, and a retry that proceeds will usually be right. If the provider has been failing in both directions all afternoon, it is even odds, and the same retry is a coin toss with the customer's money. Nothing about the payment changed between those two descriptions. What changed is the model, and the model is where the number lives. The number has a shape. Shannon's measure of the uncertainty is a hill: its summit at even odds, its feet at certainty either way. The timeout, the logs, and the afternoon's weather move us along it. The card does not move.
For a stated uncertain quantity \(X\), and observations \(C\), Shannon's conditional entropy \(H(X\mid C)\) describes the average uncertainty remaining after those observations, under a specified probability model. The timeout is the first observation. A status query to the provider, keyed to the original request, is the second and the better one: if the provider answers promptly and truthfully, nothing remains to be uncertain about, and the distance between before and after is what the query was worth. The difference \(H(X) - H(X\mid C)\) is the mutual information between the state and the observation. On average an observation never increases uncertainty; a particular answer can, as when the provider replies "pending." If the provider's status lags its ledger by a few seconds, the query answers less than it seems to, and how long to wait before believing it becomes a design decision with a number in it. Without the alternatives and their probabilities, a claim about the system's entropy has no numerical content. And a low entropy is not a certificate of truth: a model can confidently exclude the event that breaks the business. Claude Shannon, A Mathematical Theory of Communication (1948). His theory separates the communication problem from semantic meaning. The engineering choice of which alternatives matter, and what loss follows from confusing them, has to be supplied separately. Our two-valued \(X\) left out a third state, in which the first request succeeded, the retry carried a different key because the key was minted from the clock, and the provider, seeing a new request, charged again. The model gave that event no probability. The world did not consult the model.
Now the decision, which is where the specification earns its name. Entropy measures uncertainty about a question; the specification states the question, and it states it by choosing which differences count. Charged once and charged twice must never be confused: the second costs a refund, a complaint, and a letter to a regulator. Charged at one second past the hour and charged at three may be confused without cost, because nothing downstream turns on it. A specification is a partition of the world's states into those the system must tell apart and those it may lump together, with a loss attached to each confusion. Refine the partition and the uncertainty grows, not because the world became less certain but because more has been asked of it: an audit rule that every attempt be recorded with its time makes timing a distinction the system must now preserve, and a question it must now answer.
The commitment follows. The usual design is an idempotency key: the client names the payment once, the same name travels with every attempt, and the provider promises that one name produces one outcome and returns the first result to any repeat. The key settles the fact by refusing to let it matter. Without it, the retry is a bet on what the first request did, worth making only when a failure is likely enough to outweigh the cost of charging twice; with it, there is no bet. Good designs often work this way: rather than resolve the uncertainty, they arrange for the outcome not to depend on it. The key enforces the decision by making the second request harmless, and it carries the commitment, because the provider must remember every key for as long as a retry can still arrive, which is a retention period someone has to choose and pay for. It also shows why the three quantities named above must be kept apart. The key is a hundred and twenty-eight bits long and resolves nothing by itself; it is a name, not an observation. The business wants one bit, charged or not, and would pay a great deal for it. The length of a representation and the uncertainty about a question are different magnitudes, set by different parties: the engineer chooses the first, and the world and the model fix the second. Knowing that the key must be derived from the order and never from the attempt is a third thing again. No count of bits records it. It is what the engineer understands after watching a retry mint a fresh key and charge a customer twice.
There is another boundary. A terminating deterministic program's output is fixed by its code and input even when finding that output would take a person a year. Having enough information to determine an answer does not mean having an affordable way to compute it, still less an explanation one can use. Our ledger and the provider's event log together determine whether any customer was charged twice last quarter. Learning the answer is a reconciliation that joins millions of rows and runs overnight, if someone has written it; and when it prints seventeen, the question has only moved. Seventeen why, and which change let it happen, is a sentence no join produces. A repository can contain the answer to a question while leaving the engineer unable to answer it.
0.3 Context and compression
An explanation can rely on 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. Here \(L\) denotes a length in a specified encoding. Applying the two-part picture to explanations of engineering changes is an analogy; it does not turn prose length into a measure of review effort. 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.
The savings are relative to the reader and the task. Shared abstractions can make human work cheap; automated evaluation and regeneration can make some of that human work unnecessary. The house vocabulary should compete on that basis. Making every generated implementation legible to a person is an expense to justify where that person needs to act on it.
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.
The complexity has been assigned a home. Its maintainers remain responsible for the hidden implementation; callers must understand the promises; changes to those promises require coordination. When a caller quietly depends on an internal detail, that information has crossed the boundary without appearing in the contract. A later local change can then impose learning and repair on people who had every reason to believe it was none of their concern. Architecture governs how far knowledge of a change must travel.
0.5 Verification and evidence
Once a claim is stated, verification asks what evidence supports it. A test exercises selected behavior. A type system rules out classes of programs under its rules. A proof establishes a specified property under assumptions. Production observations tell us what happened under conditions the system actually met. These answer different questions, and none supplies an omitted business requirement simply by succeeding.
For the payment, a test that reproduces the implementation's expectation about retries may preserve the same mistake twice. A stronger check begins with a separately justified requirement—one debit for one payment—and creates the timeout, duplicate request, or crash that could violate it. The checking may be automated; the expectation still needs a reason. An executable specification is valuable precisely because it makes that expectation available to many checks.
An evaluation process can establish enough about a result to make a human account of its implementation unnecessary. That is an outcome to seek where it meets the task's needs. Its cost and coverage belong in the comparison with reasoning and review; neither method gets to assume away its own omissions. A gap in the tests is a reason to improve the tests, obtain other evidence, or limit the use. It does not by itself establish that a human must read the code.
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. Naur calls this theory building: the programmer becomes able to connect the program to the affairs it handles, justify its design, and respond constructively when it must change. Peter Naur, Programming as Theory Building (1985). 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. 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. A locally reasonable change can violate another person's assumption. Engineering keeps these accounts 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.
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. Information theory does not assign this duty. The organization does. An explanation available somewhere in a repository and an owner prepared to 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.
Where human learning and checking remain necessary, the resulting learning queue can be accounted for in hours. Let \(B_t\) be unfinished work, \(W_t\) newly admitted work, and \(C_t\) the capacity available to complete it during a period. Holding scope and work estimates fixed, a simple bookkeeping model is
\[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. Better external checks, replaceable implementations, or abandoning an unnecessary feature can reduce the demand. The equation accounts for work 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. That is the case the rest of this essay examines. It begins with an occasion on which the code, its explanation, and the people able to carry it were being built at once. It should not be taken as a reason to recreate those costs where an experiment can replace them.
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 part of the work. 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 (Jul 2026) 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 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 replenishing the understanding his output consumes. Anyone can generate; the scarce skill is compression. I believed that sentence 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 it should have been written. 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. Two moves remain to him, to compile himself and to delegate the diff while keeping the decisions, and he must make both.
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 increasingly 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. Across 718 firms, the adoption of coding agents raised 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.
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, and what is left when it is produced alone 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.
The learning deficit accumulates in the review queue when someone refuses to wave the work through, or in the running system when someone does.
"Entropy" is my name for the resulting disorder relative to the people who must change the system; it is not thermodynamic entropy, and no physical constant prices a review. Maxwell's demon supplies an image, not a proof: 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." The analogy here concerns the keeper's limited attention, not the thermodynamic resolution of the thought experiment. 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 carries obligations: it must be operated, explained, and changed. Shared understanding makes 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. More code makes those arrangements more necessary.
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. This is the strongest answer to Naur: perhaps more of the theory can be made recoverable than his programmers could afford to record.
His test still applies to the recovery. A plausible reason inferred from the code may be useful, but it is not evidence that this was the reason for the choice; the rejected alternative and the business constraint may never have been recorded. 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. Generation is private; the engineer and his team produce the change, and the credit attaches to him. The cost of learning what changed lands on 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 replenish the understanding, 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). Knowledge is not depleted by being shared; the scarce resources here are attention and the work of keeping a shared account current. 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 above 65; 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.
The employment picture is consistent with the same danger. Payroll data covering millions of American workers show employment of 22- to 25-year-olds in the most AI-exposed occupations running 19% below their peers in less exposed ones as of mid-2026, a gap of 13% a year earlier and widening. 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 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 minimal ones remain hard, so minimality matters more as a signal, and a firm that rewards volume is paying a premium to erase its own ability to tell. Where the next seniors come from is the question I cannot answer. 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. Tao's conditions for letting an agent do all the work are five: 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. A visualization applet meets all five; a portfolio management system fails four. Most of what a firm builds fails at least one of them. A firm that still intends to have senior engineers in five years must pay particular attention to the fourth.
Agents write, agents read
There is a defense of my impatience, and of failing the fourth condition on purpose, 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. 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. It cannot settle which cut to make, what it forecloses, or whether this invariant is load-bearing. If we use it to avoid those arguments as well, 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 who prompted a change is a required reviewer, 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 the commitments before the change is relied on. A plan here means a page: 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.
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 firm must teach the judgment it asks its owners to exercise.
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 20 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.
Anthropic's own people, asked, could delegate fully only a fifth of their work or less and said 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 0–20% delegable and 27%-not-otherwise-done figures are from the December 2025 Anthropic study 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).
Engineering is measured by what you can specify, verify, and explain. All three can be assisted; none is discharged by generating an answer. 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 will answer without reaching for the machine; 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.
The work now is to rebuild the conditions under which review can be easy again: 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 code depends.