---
title: "The End of Software Engineering? Not Quite."
description: "A paper argues that agents turn code into ephemeral material. The idea matters, but its evidence points to a shift in the center of gravity—not an extinction."
language: en
translationKey: end-of-software-engineering
kind: single
canonical: "https://lucashenry.dev/en/notes/the-end-of-software-engineering/"
markdown: "https://lucashenry.dev/en/notes/the-end-of-software-engineering/index.md"
alternate: "https://lucashenry.dev/es/notas/el-fin-de-la-ingenieria-de-software/"
alternateMarkdown: "https://lucashenry.dev/es/notas/el-fin-de-la-ingenieria-de-software/index.md"
publishedAt: 2026-09-01
updatedAt: 2026-09-01
topics: ["agentic-systems","software-engineering","harness-engineering"]
tags: ["agents","software","artificial-intelligence","engineering"]
aiAssisted: true
---

# The End of Software Engineering? Not Quite.

> A paper argues that agents turn code into ephemeral material. The idea matters, but its evidence points to a shift in the center of gravity—not an extinction.

The title promises demolition: *the end of software engineering*. The actual thesis is more useful and less cinematic. Zhenfeng Cao argues that, in an agentic system, **code stops being the only place where decisions live**. A model can interpret a goal, select tools, generate code for one step, and discard it afterward. The product is no longer necessarily a program delivered to a user, but a system capable of pursuing outcomes. [arXiv:2606.05608, Abstract and §1](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — Abstract and §1")

> **The thesis, without the hype**
>
> This is not merely a move from “humans write code” to “AI writes code.” It is a move from fixing all behavior before execution to letting part of that behavior be decided during execution.

That does change the work. It does not remove engineering. It shifts engineering toward context, tools, permissions, memory, observability, evaluations, and guardrails that make an agent dependable. The distinction between **ephemeral code** and **durable infrastructure** is how we keep the paper's useful idea without taking its title literally.

## From recipe book to cook

Think of traditional software as an exhaustive recipe book. Before the restaurant opens, someone must anticipate every dish, exception, and valid order. When input arrives, the system follows rules that were already written.

An agent is closer to a cook with a goal, a pantry, and food-safety rules. It observes the request, decides what to do, uses a tool, inspects the result, and corrects course. The paper formalizes that difference with four parts: a reasoning model, executable tools, memory, and a policy that governs action selection. [arXiv:2606.05608, §2.3](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §2.3")

### Shift in the center of gravity

**Where do decisions live?**

![Comparison between traditional software with decisions fixed in code and an agent deciding inside an execution loop.](https://lucashenry.dev/images/notes/diagrams/end-of-software-engineering/center-of-gravity/en-922b290a612d.png)

> **Takeaway:** The paper's central shift: from executing pre-coded decisions to choosing the next step while the task is running.

```mermaid
---
config:
  look: handDrawn
  handDrawnSeed: 9579305
  theme: base
  markdownAutoWrap: true
  themeVariables:
    background: "#f3f0e8"
    primaryColor: "#fffdf7"
    primaryTextColor: "#171813"
    primaryBorderColor: "#92551d"
    secondaryColor: "#dce5d3"
    tertiaryColor: "#f0dcc2"
    lineColor: "#73583f"
    fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart LR
  %% Where do decisions live?
  traditional(["Traditional software<br/>Decisions are fixed in code before execution."]):::ink
  agentic(["Agentic system<br/>Part of the next action is chosen at runtime from goal, bounds, and state."]):::amber
  traditional ~~~ agentic
  classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
  classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
  classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
  classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
  classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
  linkStyle default stroke:#9a7654,stroke-width:2px
```

*The paper's central shift: from executing pre-coded decisions to choosing the next step while the task is running.*

Related claims: `claim-01`

The agent is not software-free. The model runs on software; the tools are software; so are its sandbox, connectors, memory, and tests. What changes is that some task-specific logic can appear *just in time* instead of remaining frozen inside an application.

That makes unenumerated cases approachable. It also creates hard-to-reproduce states, probabilistic decisions, and new failure modes. **More adaptability is not automatically more reliability.**

## What becomes ephemeral—and what does not

The paper's sharpest phrase describes code as an “ephemeral instrument of reasoning.” [arXiv:2606.05608, §1 and §3.3](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §1 and §3.3") Read quickly, it sounds like repositories and platforms will soon be unnecessary. Read carefully, it is narrower: scripts, queries, or transformations generated for one task can be discarded after the outcome is obtained and verified.

A durable substrate remains underneath:

- the model and its runtime;
- tools and API contracts;
- identity, permissions, and isolation;
- state, memory, and traces;
- tests, evaluators, and invariants;
- budgets, limits, and rollback;
- rules for human intervention.

### Two layers, two timescales

**What may be disposable, and what must last?**

![Layer diagram separating temporary task code from the durable infrastructure required to control it.](https://lucashenry.dev/images/notes/diagrams/end-of-software-engineering/ephemeral-and-durable/en-07dd7af76e19.png)

> **Takeaway:** Making some code disposable does not make the system that runs, observes, and governs it disposable.

```mermaid
---
config:
  look: handDrawn
  handDrawnSeed: 515450
  theme: base
  markdownAutoWrap: true
  themeVariables:
    background: "#f3f0e8"
    primaryColor: "#fffdf7"
    primaryTextColor: "#171813"
    primaryBorderColor: "#92551d"
    secondaryColor: "#dce5d3"
    tertiaryColor: "#f0dcc2"
    lineColor: "#73583f"
    fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart TB
  %% What may be disposable, and what must last?
  ephemeral{{"Ephemeral layer<br/>Scripts, queries, transformations, and plans generated for one task."}}:::amber
  durable{{"Durable substrate<br/>Runtime, tools, permissions, memory, traces, tests, and governance."}}:::ink
  ephemeral ==> durable
  classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
  classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
  classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
  classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
  classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
  linkStyle default stroke:#9a7654,stroke-width:2px
```

*Making some code disposable does not make the system that runs, observes, and governs it disposable.*

Related claims: `claim-01`

> **My take**
>
> The asset is neither the isolated prompt nor the code produced once. The asset is the **harness**: the environment that provides context, capabilities, feedback, and boundaries. If generation gets cheaper, designing evidence and control becomes more important, not less.

## From selling programs to selling outcomes

The paper draws a line from licensed software to Software-as-a-Service and then to **Agent-as-a-Service**. Each stage absorbs another layer of complexity. First users stopped installing and operating the program; next, under this proposal, they may stop learning an application's workflow and ask directly for a result. [arXiv:2606.05608, §3](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §3")

A conventional CRM gives you screens for managing leads. An agentic service receives something closer to: “find the ten customers most at risk, explain why, and prepare a retention plan within these policies.” The primary interface changes from a collection of operations to **intent plus constraints**.

“Agent-as-a-Service” is the author's proposed label, not a settled market category. It still captures a useful direction: value is judged less by available features and more by a verifiable outcome.

## The engineer moves up a level

The paper calls the emerging discipline *Agentic Engineering*. The human moves from authoring every instruction to architecting intent, coordinating agents, and auditing results. [arXiv:2606.05608, §4](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §4") In practice, the work concentrates around four questions:

1. **What outcome counts as correct?** An ambiguous goal yields an ambiguous evaluation.
2. **What may the agent touch?** Tools and permissions determine its blast radius.
3. **What evidence must it leave?** A persuasive narrative does not replace tests, artifacts, or traces.
4. **When must it stop?** Cost, uncertainty, and risk need explicit limits.

Programming remains useful for building those tools and understanding their failures. But writing every line is no longer a sufficient description of the job. The new design unit is a sociotechnical loop: human, model, context, tools, and verification.

## The evidence: strong for tasks, weak for extinctions

The paper is not entirely triumphalist. It reports that Lingma SWE-GPT 72B resolves 30.2% of SWE-bench Verified, close to the 31.8% it reports for GPT-4o. That is meaningful capability on bounded, real-world issues; it is not evidence of sustained autonomous maintenance. [arXiv:2606.05608, §5.1](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §5.1")

The more important signal is the contrast. Summarizing EvoClaw, the paper says success drops from above 80% on isolated evaluations to at most 38% under continuous software evolution, across twelve models and four frameworks. [arXiv:2606.05608, §5.2–5.3](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §5.2–5.3") A task can end with a plausible patch. Maintaining a system requires preserving invariants across many changes, recognizing technical debt, and recovering from earlier errors.

> **What the evidence does support**
>
> Agents can already complete a meaningful share of well-scoped engineering work. Their performance depends on the model, but also on the environment, tools, memory, and verification.

> **What it does not yet support**
>
> Those benchmarks do not establish safe autonomous operation over months, superior total economics, accountability without humans, or the disappearance of software engineering.

## The bottleneck moves to verification

Errors compound across a chain. If each independent step had a 95% chance of being correct, the illustrative probability that twenty steps were all correct would be `0.95^20`, roughly 36%. Independence rarely holds in a real agent, but the model is useful: **a per-step rate that looks excellent can still create a fragile trajectory**.

### Compounding reliability

**Why does a long chain remain fragile?**

![Illustrative curve where a chain of reliable steps loses total success probability as it becomes longer.](https://lucashenry.dev/images/notes/diagrams/end-of-software-engineering/compounding-reliability/en-9f4319029704.png)

> **Takeaway:** Illustrative model: at 95 percent success per step, twenty perfect steps together fall to roughly 36 percent.

```mermaid
---
config:
  look: handDrawn
  handDrawnSeed: 10437401
  theme: base
  markdownAutoWrap: true
  themeVariables:
    background: "#f3f0e8"
    primaryColor: "#fffdf7"
    primaryTextColor: "#171813"
    primaryBorderColor: "#92551d"
    secondaryColor: "#dce5d3"
    tertiaryColor: "#f0dcc2"
    lineColor: "#73583f"
    fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
xychart-beta
  %% Why does a long chain remain fragile?
  title "Compounding reliability"
  x-axis ["1 step", "5 steps", "10 steps", "15 steps", "20 steps"]
  y-axis 0 --> 100
  bar [95, 77, 60, 46, 36]
```

*Illustrative model: at 95 percent success per step, twenty perfect steps together fall to roughly 36 percent.*

Related claims: `claim-05`

When generating a solution is cheap, distinguishing the correct one from one that merely looks correct dominates the cost. Agentic systems need evaluations independent of the agent's confidence: executed tests, reproducible queries, invariant checks, security review, and human approval where potential harm is high.

## Four reasons not to buy the title

### 1. The mathematical argument does not prove inevitability

The paper states that interaction paths grow as `Θ(2^n)`, then explains this by counting every possible graph between component pairs, `2^(n choose 2)`—very different expressions. [arXiv:2606.05608, Proposition 2.1](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — Proposition 2.1") An upper bound on possible configurations also does not describe how many matter in a modular real-world system. Complexity is real; this derivation does not make agents inevitable.

### 2. The comparison favors the agent from the start

Treating human cognition as `O(1)` while model capability grows erases how humans use teams, documentation, abstractions, and tools. It also erases agent cost, latency, context limits, and error propagation. The fair comparison is between complete systems—not an isolated brain and an isolated model.

### 3. Different metrics answer different questions

Issue resolution measures issue resolution. A coordination pilot measures that pilot. Repository popularity measures interest. None alone establishes a new economic model or sustained production reliability. The paper assembles suggestive signals; the leap from those signals to an “end” remains an inference.

### 4. The roadmap is a bet

Its four stages move from tool augmentation (2023–2025), to autonomous tasks (2025–2027), multi-agent teams (2026–2029), and self-evolving ecosystems (2028+). The fourth explicitly lists its representative systems as “prospective.” [arXiv:2606.05608, §6, table 3](https://arxiv.org/html/2606.05608v1 "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm — §6, table 3") These dates describe a proposed trajectory, not experimental results.

### The paper's roadmap

**What is observed, and what remains a hypothesis?**

![Four-stage roadmap from copilots to self-evolving ecosystems with evidence decreasing toward the future.](https://lucashenry.dev/images/notes/diagrams/end-of-software-engineering/paper-roadmap/en-c4633ab0552b.png)

> **Takeaway:** The roadmap blends an observed present with a speculative future; read it as a hypothesis, not a calendar.

```mermaid
---
config:
  look: handDrawn
  handDrawnSeed: 12870458
  theme: base
  markdownAutoWrap: true
  themeVariables:
    background: "#f3f0e8"
    primaryColor: "#fffdf7"
    primaryTextColor: "#171813"
    primaryBorderColor: "#92551d"
    secondaryColor: "#dce5d3"
    tertiaryColor: "#f0dcc2"
    lineColor: "#73583f"
    fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart LR
  %% What is observed, and what remains a hypothesis?
  tools("2023–2025 · Augmented tool<br/>Copilots complete code and resolve issues."):::sage
  tasks("2025–2027 · Autonomous task<br/>From specification to pull request."):::amber
  teams("2026–2029 · Multi-agent teams<br/>Coordinated roles across the lifecycle."):::amber
  ecosystem("2028+ · Self-evolving ecosystem<br/>A speculative scenario, not a validated forecast."):::rust
  tools --> tasks
  tasks --> teams
  teams --> ecosystem
  classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
  classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
  classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
  classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
  classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
  linkStyle default stroke:#9a7654,stroke-width:2px
```

*The roadmap blends an observed present with a speculative future; read it as a hypothesis, not a calendar.*

Related claims: `claim-06`

## What I would do now

I would not wait for stage four. I would use the central idea to redesign work that already exists:

- define the outcome and its evidence before delegating;
- provide curated context, not an infinite document dump;
- grant minimal, observable, reversible tools;
- separate generation from verification;
- measure rework, cost, time, and escaped defects—not lines of code;
- reserve human judgment for ambiguity, high risk, and irreversible actions.

A good candidate has a verifiable goal, frequent feedback, and a controlled blast radius. A bad one combines severe consequences, tacit criteria, and ground truth that arrives much later.

> **Conclusion**
>
> We are not watching the end of software engineering. We are watching **the end of identifying it solely with writing code**. Some logic will move to runtime; some code will become temporary; and the center of gravity will shift toward designing intent, environment, evidence, and governance. The paper overstates the rupture, but it points in the right direction.

Five things to remember: an agent decides inside a loop; code may be temporary while its platform is not; today's benchmarks favor bounded tasks; reliability degrades across long trajectories; and human work shifts from producing instructions to specifying and auditing outcomes.

## Complete sources

1. **The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm** — Zhenfeng Cao. [arXiv:2606.05608 · v1](https://arxiv.org/html/2606.05608v1). Role: `primary`.

## Editorial transparency

> This article was researched and drafted with AI assistance. Lucas set the angle, verified the sources, and retains editorial responsibility.
