Every generation of software has been built on the accumulated judgment of the generation before it.
Unix begat C. C begat entire families of systems software. The web begat distributed applications. Distributed applications begat cloud computing, containers, orchestration platforms, and the modern infrastructure stack.
None of this appeared spontaneously.
It was created by engineers who spent decades discovering what worked, what failed, and why. They encountered race conditions, data corruption, cascading outages, security vulnerabilities, scaling limits, organizational bottlenecks, and architectures that looked elegant on a whiteboard but collapsed under real use.
They wrote code, but the code was only the visible residue of the work.
The real product was knowledge.
Today, some of the wealthiest people in technology are celebrating a future in which the people who produce that knowledge become unnecessary. Salesforce CEO Marc Benioff says the company hired zero new engineers in fiscal year 2026, crediting AI coding agents with the productivity that used to require hiring. Block CEO Jack Dorsey cut the company’s workforce by roughly 40 percent, telling shareholders a smaller team “using the tools we’re building, can do more and do it better.” Anthropic CEO Dario Amodei told Davos that AI could handle “most, maybe all” of what a software engineer does within six to twelve months, adding of his own work: “I don’t write any code anymore. I just let the model write the code, I edit it.” Each of them describes software development as though it were a manufacturing process: specifications go in, code comes out, and artificial intelligence will soon make the workers on the assembly line redundant.
They are mistaking an inheritance for a perpetual motion machine.
A companion piece on this site, “Engineering by Proxy,” has already covered what happens when harness-based development lets proxy metrics substitute for real verification in the present: tests that pass without proving correctness, specifications that stand in for understanding, an agent’s account of its own actions trusted because checking it takes time nobody has budgeted. This piece is about a slower version of the same problem. It is not about whether the code shipping today is correct. It is about whether anyone will still be capable of knowing, a decade from now, once the people who would have spent this decade learning how were never given the chance.
Large language models did not invent software engineering. They inherited it.
Every design pattern they reproduce, every debugging technique they suggest, every API convention they imitate, and every architectural style they recommend came from human engineers. The models are trained on the accumulated output of a profession that spent generations learning how to make complex systems work.
That inheritance is immense. It is also finite unless it is continually renewed.
Software engineering knowledge is not a static archive. It is a living tradition maintained through practice, apprenticeship, argument, failure, and revision. Engineers do not become engineers by reading finished code. They become engineers by confronting systems they do not yet understand, making mistakes, receiving criticism, and gradually developing judgment. That process takes years.
It begins with junior engineers doing work that looks routine: small features, bug fixes, unfamiliar code, reviews, watching experienced engineers reason about tradeoffs. Over time they learn that correctness is contextual, that requirements are often incomplete, and that the simplest-looking change can violate an invariant buried three systems away. Some eventually become the senior engineers who can sense something is wrong before they can fully explain why. That intuition is not magic. It is compressed experience.
This isn’t a hypothetical pipeline problem. It’s already showing up in the employment data: employment for software developers aged 22 to 25 has fallen nearly 20 percent since 2024, even as employment among developers in their thirties and forties has grown over the same period, according to Stanford’s 2026 AI Index Report. If entry-level work is automated away, fewer people gain the experience required to become senior engineers, and if senior engineers are then reduced to reviewing an ever-growing volume of machine-generated code, they have less time to teach, investigate, design, and learn.
The profession may continue producing software while gradually losing the ability to produce engineers. That’s the part the automation story leaves out.
Artificial intelligence can generate code because human beings already discovered the patterns. It can reproduce solutions because engineers already solved similar problems, and recommend architectures because generations of practitioners documented the ones they built.
But software does not stand still. New hardware appears, new attack surfaces emerge, systems grow beyond their original assumptions, regulations and organizations change, users behave in unexpected ways, and abstractions that looked reliable fail under conditions their designers never anticipated. Progress requires people who can recognize when the inherited patterns no longer apply.
A model can synthesize from what has been recorded. Engineering advances begin where the record becomes inadequate, with someone noticing that the accepted solution is wrong, someone who has usually spent years developing enough understanding to challenge the consensus. The breakthroughs that become tomorrow’s training data are created by people capable of going beyond today’s training data. If the industry replaces those people, the advances stop being cumulative.
At first, the decline will be difficult to see. Code production rises, features ship faster, pull requests multiply, and executives point to lines of code, deployment frequency, and reduced headcount as proof the new system works. The output looks like acceleration. But more code is not the same as more engineering.
Software is not manufactured the way cars or refrigerators are. In manufacturing, the design exists before the factory reproduces it. In software, every meaningful change alters the design itself. The code is not merely the product rolling off an assembly line. It is also the blueprint, the machinery, and part of the institution’s understanding of how the system works.
Generating more code therefore doesn’t simply increase production. It increases the size and complexity of the design that humans must understand. Every new line creates an obligation: it must be tested, secured, operated, debugged, maintained, and eventually modified or removed. Code is not only an asset. It is a liability an organization carries forward, and AI makes that liability extraordinarily cheap to create without making it any cheaper to understand.
That’s a fundamental imbalance. A model can generate thousands of lines in minutes; no human can responsibly comprehend thousands of lines in minutes. The bottleneck moves from writing code to reviewing, validating, and integrating it.
Organizations then face a choice. They can limit generation to the rate at which engineers can understand the result, in which case AI remains a useful tool but doesn’t eliminate the need for engineers. Or they can let generation exceed human comprehension, merging code because tests pass, the diff looks plausible, and the model appears confident. Many will choose the second option because it preserves the appearance of productivity.
The result is software that carries every visible sign of engineering without the substance engineering is supposed to provide: specifications, automated tests, pull requests, documentation, dashboards, and compliance checks, each artifact possibly generated from the same incomplete assumptions as the code itself. The system appears verified because every layer agrees with every other layer. It may still be wrong.
This is one reason skepticism toward LLM-generated code is not irrational resistance to change. There is no general reason to assume generated code is correct. Large language models are trained on enormous quantities of human-written software, and that corpus contains excellent work, but also bugs, vulnerabilities, abandoned experiments, obsolete techniques, cargo-cult implementations, and code that appears to work only because its failures haven’t been discovered yet. The model has no intrinsic ability to separate correct code from plausible code; it learns statistical relationships among examples, and can produce an implementation that is syntactically clean, idiomatic, well documented, thoroughly tested, and subtly wrong.
Fluency makes this worse. Bad human code often looks bad. Generated code can look polished enough to suppress suspicion, inviting the reviewer to accept coherence as evidence of correctness. But correctness doesn’t emerge from style. It emerges from a relationship between the implementation and the real system it’s meant to serve: its requirements, constraints, users, failure modes, security boundaries, operational environment, and hidden assumptions, things rarely captured completely in a prompt.
The deeper danger, then, is not simply that AI will produce buggy software. Human beings already produce buggy software. The danger is that the industry will gradually remove the people capable of recognizing why it’s buggy, and that creates a destructive cycle: AI reduces demand for junior engineers, fewer junior engineers develop deep experience, senior engineers are asked to supervise more generated output with less time for mentorship and design, institutional knowledge erodes, and generated code becomes increasingly common in the training corpus that future models learn from, systems fewer humans fully understand.
The appearance of progress continues while the source of progress is being depleted. This is technical stagnation disguised as accelerating output.
Benioff, Dorsey, and Amodei treat engineering knowledge as though it were a natural resource waiting to be extracted: once enough code has been ingested, they imagine, the models can generate software forever without the profession that created the corpus.
But engineering knowledge is not oil in the ground. It is closer to a cultivated ecosystem: it survives because people maintain it, question it, and pass it on. Remove the conditions that produce engineers and the knowledge doesn’t remain stable. It decays. Documentation goes outdated. Design decisions lose their context. Systems accumulate layers no one is willing to remove because no one understands why they exist. Failures get patched locally rather than understood structurally. The models keep producing answers, but the civilization around them grows less capable of telling whether those answers are good.
There will still be code, maybe more of it than ever. But code production was never the scarce resource. The scarce resource was judgment: the ability to distinguish a working implementation from a durable one, to see that the requirement itself is wrong, to remove code rather than add it, to understand a system deeply enough to change it without causing damage, to encounter a new problem and create a solution that didn’t already exist in the training set.
Those abilities aren’t produced by autocomplete. They’re produced by engineering practice.
The future of software shouldn’t require rejecting artificial intelligence. AI can help engineers explore unfamiliar code, generate routine scaffolding, compare approaches, write tests, and accelerate mechanical tasks, freeing people to spend more time on design and understanding. But that’s augmentation, not replacement. The distinction matters because a tool that supports engineers strengthens the profession, while a strategy designed to eliminate engineers consumes its accumulated knowledge without preserving the means to renew it.
Every generation inherits software from the last, and also inherits engineers from the last. The first inheritance survives only because of the second.
If we convince ourselves that software engineering is merely code production, we may discover too late that we did not automate the creation of engineering knowledge.
We automated its consumption.