A paper landed in my feed last week that argued software engineering as a discipline is ending. Not evolving, not shifting, ending. The End of Software Engineering (Cao, arXiv 2606.05608, June 2026) makes the case that agentic systems represent a paradigm break rather than an incremental improvement, and that the profession as we know it is about to be replaced by something structurally different.
I read it because the title triggered me. I ship AI products for a living. I have opinions about what agents can and cannot do, developed one incident at a time, and I wanted to see whether the paper matched the thing I actually experience when I open Claude Code on a Tuesday morning.
Here is what I found. What the paper gets right, what it underweights, and what my 2026 shipping log says about the timeline it proposes.
What the paper argues
A brief, fair summary before I disagree with any of it.
Cao formalises the shift in two models. Traditional software is a triplet: resources, decision rules, execution environment. The logic is static, written by humans in advance. An agentic system is a quadruplet: LLM, tools, memory, planning. The logic is generated at runtime by a model that serves as a reasoning engine.
The theoretical leverage: system complexity grows exponentially with the number of components, while human cognitive capacity is roughly constant. Agentic systems decouple problem-solving capacity from that human ceiling, because the model’s capacity grows with compute rather than with an engineer’s hours.
Three generations of software delivery follow: local software (client absorbs complexity), SaaS (provider absorbs it), and Agent-as-a-Service (the agent absorbs it, billed by outcome). Cao’s target model is “agent to outcome” rather than “AI to software to outcome,” on the grounds that keeping software in the middle preserves the human bottleneck the whole shift was supposed to remove.
The new discipline he calls Agentic Engineering has a different object (the system of agents, not source code), a different control layer (the LLM, not the engineer), and a different human role: articulating intent, supervising architecture, calibrating quality, governing ethics.
Timeline: augmented tooling now, single-task autonomy 2025-2027, multi-agent teams 2026-2029, self-evolving ecosystems 2028+.
I think roughly a third of this is correct, a third is directionally right but on the wrong timeline, and a third is under-specified in ways that matter more than the paper admits. Let me take them in that order.
What the paper gets right, from field experience
The abstraction ladder claim is real, and I have written about it from a different angle in What I Tell My Developers When They Ask if AI Will Replace Them. Every rung in the history of programming has been called the end of the profession, and every rung has moved the profession up a layer. Agentic systems are the next rung. Cao’s framing of the rung as a change in the object of engineering (the agent system rather than the source code) is a sharper version of what most practitioners already know intuitively.
The identification of the new human differentiators is also correct in shape. Intent articulation, architectural supervision, quality calibration. I recognise all three from the way I now spend my week when I ship an AI product. The typing has collapsed. The judgment has expanded. Any developer working with Claude Code seriously in 2026 will nod at this section of the paper.
The generational framing (Local to SaaS to AaaS) is a useful reference. The critique of the dominant “AI to software to outcome” pattern, where the human remains the bottleneck because software is the deliverable, is directionally sharp. The pattern is real, and it is producing a lot of AI-adjacent products in 2026 that look modern but preserve the old delivery loop.
That is where my agreement stops.
What the paper underweights, from field experience
The most interesting number in the entire paper is the one Cao introduces in his counter-evidence section and then does not dwell on. EvoClaw shows agent performance dropping from over 80% on isolated tasks to a maximum of 38% on continuous evolution scenarios. Four causes: context drift, cumulative error propagation, no technical debt modeling, and insufficient verification fidelity.
That number, and those four causes, are the entire story of my 2025-2026 shipping year.
Context drift is what I saw building payment infrastructure for a fintech at scale. The agent shipped clean code for a single transaction path. It could not hold the shape of the multi-operator, multi-country retry logic in its head across sessions. Every new feature required me to re-establish the context, or the agent would make locally correct choices that conflicted with the global invariant.
Cumulative error propagation is what I wrote about in Stop Delegating Your Thinking to AI as the debugging trap. The AI patches a surface symptom. Two weeks later the same class of bug returns in a different code path. The patches accumulate until the fifth one cannot be applied cleanly, and someone spends a week unwinding four surface fixes that were masking one root cause two layers below. This is not a hypothetical failure mode. It happens.
No technical debt modeling is what I called dark matter in Test Coverage Was Enough. Ownership Coverage Is What Matters Now. Agents ship code that works, passes review, runs in production, and has never entered any human’s mental model. That code is fine until the day it is not. The team then discovers, at 3am, that they own a service nobody can explain. The paper’s roadmap for 2028+ self-evolving ecosystems assumes this problem gets solved along the way. There is no plausible mechanism in the paper for how.
Insufficient verification fidelity is the one that scares me most, and the one Cao mentions almost in passing. An agent can pass every test and still introduce subtle semantic errors. In consumer fintech, in health apps, in legal tools, the cost of a subtle semantic error is not the cost of a red test. It is the cost of a customer refund, a regulator letter, a user’s lost trust. The gap between “passed the tests” and “actually correct” is where the entire debate about AaaS falls apart, and the paper does not have a proposal for closing it.
The pattern I would name differently
If I were writing the paper, I would name the bottleneck elsewhere. It sits in the human organisation’s ability to build and maintain evaluation infrastructure at the pace the agents are producing code.
An agent can generate a service in an afternoon. A team can barely define what “correct” means for that service in a week. The organisation that thought it had accelerated 10x by adopting agents has accelerated 10x on generation and 1x on evaluation. The ratio is where every failure mode Cao mentions lives.
This is a problem that generalises. Cao proposes we move from software delivery to outcome delivery (“agent to outcome”). Outcomes are legible only when we can measure them. In 2026, almost no team has evaluation infrastructure that is meaningfully more mature than test coverage plus a Sentry dashboard. That is not sufficient for outcome-based delivery. It might not be sufficient for AaaS at all, and I do not see how the industry closes the gap on the timeline the paper proposes.
The revised timeline I would defend
Cao’s roadmap says multi-agent teams 2026-2029, self-evolving ecosystems 2028+. I think the model capabilities may support that timeline. The organisational capabilities almost certainly will not.
Here is the version I would defend, from the ground:
2026-2028. The current phase extends. Augmented tooling (Claude Code, Cursor, CodeRabbit) becomes standard. Single-agent autonomy on scoped tasks becomes reliable. Multi-agent orchestration remains a research topic that occasionally produces impressive demos and rarely produces production systems. The organisations that pull ahead in this window are the ones that invest in evaluation infrastructure before they invest in more sophisticated orchestration.
2028-2031. Multi-agent teams become production-viable for teams with mature evaluation stacks. This is a small fraction of teams. The rest continue to struggle with the ratio described above: fast generation, slow evaluation, growing dark matter.
2031+. Self-evolving ecosystems, if they arrive, arrive first in narrow domains where the outcome is unambiguous (search relevance, ad targeting, some kinds of trading). They do not arrive as quickly in domains where the outcome is contested or where the cost of being wrong is asymmetric (health, legal, fintech, safety-critical). Those domains will run agentic components inside human-supervised systems for longer than the paper suggests.
I am prepared to be wrong on the model side. I would bet against being wrong on the organisational side.
What this means for a builder in 2026
If you are trying to figure out where to invest your time as an AI-native PM, engineer, or founder in 2026, the paper accidentally answers the question in its list of gaps. The scarce work is not multi-agent orchestration. The scarce work is evaluation infrastructure.
Concretely, over the next twelve to eighteen months:
Build the evaluation stack before you build the agentic stack. If you cannot answer “what is the pass/fail signal for this agent’s output,” you cannot deploy the agent. If you cannot answer it at scale, you cannot deploy the agent responsibly. Most teams underinvest here by an order of magnitude.
Instrument ownership coverage. The failure modes Cao names (dark matter, context drift, verification gaps) all reduce to a team’s inability to hold a mental model of what its agents produced. I wrote a full piece on this metric; it applies exactly to the failure profile Cao’s paper implies.
Keep the human in the loop where the outcome is asymmetric. The AaaS vision works in domains where the cost of failure is bounded and observable. It does not work, on the timeline the paper proposes, in the domains where a wrong answer costs more than a right one earns. Know which domain you are in.
Treat the paper’s optimism as a directional signal, not a schedule. The direction is right. The schedule is aggressive by a factor that depends entirely on how quickly the industry builds the evaluation infrastructure that Cao mentions once and then moves past.
Closing
Cao’s paper is the right paper for its moment. It names the shift, it formalises the models, it argues the direction. All of those things are useful, and I am glad someone with the academic rigor to do them has done them.
The paper is also missing the thing that a practitioner year in 2026 makes obvious: the limiting factor sits elsewhere, in the human organisation’s capacity to know when the model is wrong. The gap between generation and verification is where every failure I have shipped this year lives, and the paper’s timeline assumes that gap is closable at a pace nobody in the industry is currently pacing toward.
The end of software engineering, if it comes, will be delayed by the end of software evaluation not arriving. That is the essay I would like to see next.