CTO 6 min

In the End There Is No Software Left

Gaylord Aulke

Software Was Always a Detour

Software exists because machines could not work out for themselves what to do. Somebody had to write it down beforehand, completely and precisely, in a form a machine could execute. We call the result of that writing-down software, and the discipline that does it software engineering.

That says everything about its purpose. Nobody wants to own software. People want an invoice to go out, a warehouse to be scheduled, a customer to get an answer. The detour through writing it all down was necessary because the machine did not understand the task.

A paper published in June describes fairly precisely what happens when that detour disappears. It then declines to draw the conclusion.

What the Paper Says

Agentic Software: How AI Agents Are Restructuring the Software Paradigm (arXiv:2606.05608) by Zhenfeng Cao advances a thesis without testing it experimentally, which is worth saying up front. Its central distinction is still the most useful thing I have read on this in a year.

Traditional software has static decision logic: every rule is written by a human before the system meets its first input. An agentic system generates its decision logic at runtime, with the model reasoning about the goal, writing code, running it, reading the result and adjusting.

Cao calls the code that appears along the way a “transient artifact, produced and discarded as needed.” The agent writes whatever a task requires, runs it and throws it away. If it later finds the code no longer fits, it writes new code. None of it needs maintaining, because none of it is meant to last.

The most important sentence in the paper sits almost casually inside a comparison table. There Cao lists the output unit of each world: “functioning software” for traditional engineering, “delivered outcomes” for agentic work. He writes down himself that the product stops being a program.

Where the Paper Flinches From Its Own Thesis

Follow that through and you arrive somewhere uncomfortable. If code only appears and disappears as a task demands, there is no artifact left for anyone to maintain, version, document and hand over. Software engineering as an occupation hangs on exactly that artifact. Without it, nothing remains that could be called a profession.

Cao does not take the step. He names the whole thing “Agentic Engineering,” states explicitly that it expands software engineering instead of replacing it, and closes by assuring the reader that the old discipline is not ending but growing into something larger. In his own Stage IV, the distinction between software and agent then dissolves entirely. Both of those cannot be true.

He wrote down the premise that abolishes his discipline and then promised it would survive. That is where I disagree, and it matters more than any argument about dates.

The Number Everyone Argues About for the Wrong Reason

The counter-argument currently in circulation appears in Cao’s paper too. EvoClaw (arXiv:2603.13428) tests what most agent benchmarks avoid: continuous software evolution. It measures sustained work across a whole commit history, where each change has to leave the system intact and mistakes accumulate. Twelve frontier models, four agent frameworks.

Isolated tasks run above 80%. In the continuous setting, at most 38%.

Agent success rates fall from above 80 percent on isolated tasks to at most 38 percent on continuous software evolution, a drop of more than half. Agents are strong at tasks and weak at maintenance 0%25%50%75%100% 82% 38% over half lost Isolated tasksContinuous evolution one issue, one fixsustained work across a commit history 12 frontier models across 4 agent frameworks. Source: Deng et al., EvoClaw, arXiv:2603.13428.
What is measured here is the upkeep of a durable artifact. Remove the artifact and the benchmark tests work that no longer exists.

That number gets passed around as reassurance, and it cannot carry the weight. It measures how well agents maintain a durable artifact over time, which is the central activity of the old world. When code appears and vanishes as the task requires, the benchmark is testing a job nobody does any more.

So the honest answer to how much of software engineering survives is: none of it. It was always an aid for organizing work and getting tasks done. Aids disappear once the task can be done directly.

Why This Arrives Faster Than the Paper Assumes

Cao gives the transition a timetable: multi-agent teams through 2029, self-evolving systems from 2028, full autonomy as “a multi-year research challenge.” Three developments are working on the very weakness that timetable rests on, and their effects multiply.

Methods. Memory is the most active frontier in agent research right now, and the pace is high. Multi-layer architectures separate working, episodic and semantic memory, temporal knowledge graphs are meant to hold the relational state no context window can, and several groups are pushing on each of those directions at once. Setbacks come with that: a Toronto group (arXiv:2608.28978) found its graph store retrieving worse than a flat vector baseline, because decomposing text into entities loses the wording. The same paper shows deliberate forgetting working as advertised, with 9.8% of the nodes dropping out of a 27,021-node store and no meaningful loss on any of four metrics. This is what a field looks like when it finds its dead ends quickly and leaves them just as quickly. When it also builds several measurement instruments for one weakness inside a year, among them SWE-Marathon and SlopCodeBench, it has committed to closing it, and the next jump could land in any quarter.

Cost. Inference for a fixed capability level has fallen roughly a thousandfold in three years, because quantization, distillation and hardware generations each contribute two to four times and those factors compound. Cheap inference buys more attempts per task and more verification passes, which is why several EvoClaw failure modes turn out to be budget problems.

Research itself. Systems that generate hypotheses and run the experiments are now part of how this research gets done; the field’s own tooling is improving the field. The honest caveat: at least one 2026 study finds AI research agents narrow exploration instead of widening it, so this loop may run faster along fewer paths.

Then a number that is missing from Cao’s paper: the time horizon over which an agent works independently has been doubling roughly every seven months. Extrapolation is not proof, and any of these curves can bend. But three overlapping exponentials pointed at one weakness is not a situation where I would plan around that weakness persisting.

What It Looks Like When It Arrives

Cao’s picture of agent teams is today’s: an orchestrator, a handful of implementers under it, a reviewer alongside. That already runs in production, ours included, and it hits its ceiling right there, because the orchestrator’s bandwidth is the ceiling of the system.

What I expect is a different order of magnitude. I mean hundreds of thousands of agents, each responsible for one component, one aspect or one function, each with its own narrow knowledge, its own goal and its own responsibility. None of them holds the whole. They negotiate their cooperation continuously among themselves and keep changing as they do. Whatever code they need, they write for themselves and discard afterwards.

That sounds like science fiction and is partly built already. The scale is demonstrated: platforms like GenSim simulate up to 100,000 agents, OASIS runs into the millions. So is dropping the central planner: “Markets, Not Planners” (arXiv:2608.23867) builds AgentLance, a decentralized labor market for agents that keep their execution costs private, and names precisely the problem I mean, that today’s orchestration is centralized and one router decides.

The idea itself is old. Carl Hewitt’s actor model described systems of independent units in 1973, communicating only by message and able to create more of their own kind; Erlang built that into telephone exchanges running millions of concurrent processes. Negotiation arrived in 1980 with the Contract Net Protocol, task allocation by call-for-bids, now rebuilt for language models (arXiv:2608.12371). The structure was never what we lacked. What we lacked were components that think for themselves. What happens once they do is something we have written about elsewhere.

Where the Line Actually Sits

You can read the speed off one person. In March 2025, Dario Amodei told the Council on Foreign Relations that AI would be writing 90% of code within three to six months and essentially all of it within twelve. That was treated as salesmanship and is now ordinary working life in a lot of teams, ours included. In February 2026 he went further: within a year or two, models could do software engineering end to end, “setting technical direction, understanding the context of the problem,” and he was explicit that he meant all of it.

Which pushes the question up one level. The assumed refuge is defining requirements and goals. Except requirements do not fall from the sky: they derive from business goals, and those derive from market position, competition, customer behavior and problems somebody wants solved. All of that is data. So what exactly stops an AI from doing that derivation too?

I cannot find a technical answer. Every step in that chain is pattern-making over evidence, which is precisely what these systems do.

At the end of that chain stands somebody who wants something, and that is not a skill. Data says what is; what ought to be, it never says. Whether a company enters a market or leaves it, how much risk it carries, whether it gets sold at all: those get decided, and the consequences land on someone you can sue, fire and hold liable. That is where handing the job to a machine breaks down.

What remains is the role of the principal: wanting something, and answering for it. It cannot be trained and it cannot be improved, which leaves it short of being a profession. That line is in any case a legal and social one, and lines of that kind hold only until somebody moves them.

The Human as the Bottleneck

Not every company will go all the way down this road, and most will not want to. That changes little, because the arithmetic reappears at every level. Cao names the reason himself: wherever a human sits in the flow, the bottleneck sits with them. The human is the only component in the system that does not grow exponentially and is not available around the clock. Every point of intervention gets more expensive with each model generation, measured against what it holds up.

Which gives my actual thesis, and it is a claim about competition. A company that does not push AI as hard as it can, at every level, will find itself dealing with competitors who ship faster, try more and cost less. The clock for this runs in model generations, and those arrive monthly. In regulated markets, where trust grows more slowly than software, the gap opens more slowly. It still opens.

Why We Track This

We build with agents daily, in client systems, so this is not an abstraction for us.

Today the 38% names what a team must still own. Tomorrow the bar sits higher and the same team needs to be on the next rung. That is what a 100-day engagement is for, and why we measure what changed rather than which tools got installed.

Anyone waiting for this to settle is reading a schedule as a verdict.

AI Agentic Coding Engineering Culture

Written with AI assistance and editorially reviewed, see AI transparency.

Gaylord Aulke

Founder of 100 DAYS. 30+ years in software engineering, formerly Zend Technologies. Builds AI-powered dev organizations with teams: in 100-day cycles, with measurable outcomes. More about Gaylord →