The End of Software Engineering?

On June 4, 2026, Shenzhen-based researcher Miao Li posted a paper with a deliberately devastating title: “The End of Software Engineering.” Its central argument is that AI agents aren’t merely improving software development. They are replacing the paradigm on which the profession was built.

The paper describes three eras of software delivery: on-premise licensed software, software-as-a-service, and now agent-as-a-service. On-premise software transferred predefined logic to the user’s computer. SaaS transferred infrastructure and maintenance to the vendor. Agentic software goes further by transferring part of the decision-making process to an AI system operating at runtime.

After more than 12 years as a software engineer, I recognize the shift. I’m already dependent on LLMs for a large amount of my coding. Increasingly, I describe the result I want, let the model produce an implementation, and act as the reviewer rather than the primary author.

That experience makes the paper feel less speculative than its title suggests. But I don’t think software engineering is ending. What’s ending is our old definition of it.

The Paper Already Walked Back Its Own Title

The most revealing detail isn’t in the original paper. It’s in the revision history.

Six days after version 1 appeared, Li uploaded version 2 under a new title: “Agentic Software: How AI Agents Are Fundamentally Restructuring the Software Paradigm.” The revised abstract explicitly frames the change as an expansion of software engineering rather than its literal end.

That is more than cosmetic editing. The new title better reflects what the paper actually demonstrates.

The manuscript is primarily a conceptual argument. It proposes a framework for thinking about agentic software and draws on existing research, but it doesn’t present a new controlled experiment proving that software engineering has become obsolete. Its original title works as provocation, not as an evidence-backed conclusion.

Still, the underlying observation is important. Generative AI is changing where software behavior comes from, when implementation decisions are made, and which artifacts engineers must control.

Agentic Software Changes What the Artifact Is

Traditional software tries to encode human decisions before execution. Engineers define rules, write functions, connect components, test the implementation, and ship a relatively stable artifact.

The paper argues that agentic software reverses this relationship. Instead of encoding every decision ahead of time, developers construct an environment in which an AI agent can reason about a goal, select tools, generate actions, observe results, and adjust its approach.

Under this model, code may become temporary. An agent could generate a script, run it, inspect the output, and discard the script immediately. The useful product isn’t necessarily the generated code. It’s the completed task.

That is a meaningful change, especially for one-off data transformations, internal automation, migrations, testing, integration work, and other tasks where preserving every generated implementation provides little value.

But the statement that “the agent is the software” is too clean. An agentic system still consists of engineered artifacts:

• Model and provider selection
• System prompts and instruction hierarchies
• Tool definitions and API contracts
• Authentication and permissions
• Memory and retrieval systems
• Evaluation criteria
• Sandboxing and execution environments
• Logging, monitoring, and rollback mechanisms
• Deterministic services surrounding the model

The source code may become less visible to the user, but engineering hasn’t disappeared. It has moved into the environment that constrains, observes, and corrects the agent.

The most likely future is therefore hybrid. Probabilistic agents will make more runtime decisions, while deterministic software will enforce the boundaries within which those decisions are allowed.

Complexity Does Not Disappear; It Migrates

The paper’s complexity argument is easy to sympathize with. Human engineers have limited working memory. We struggle to hold large architectures, dependency graphs, business rules, and historical decisions in our heads simultaneously.

AI agents can search far more material than a human can actively remember. They can inspect files, query documentation, compare implementations, run tests, and explore several possible solutions without becoming tired or bored.

That doesn’t mean they scale without friction.

Agentic systems introduce their own forms of complexity: probabilistic behavior, context management, model drift, tool errors, prompt injection, latency, token costs, inconsistent reasoning, and failures that emerge only through interactions between multiple components. Multi-agent designs also create coordination problems. One agent’s incorrect assumption can become another agent’s trusted input.

Traditional complexity is visible in code and architecture. Agentic complexity is distributed across models, prompts, context, state, permissions, tools, and generated actions.

This distinction matters when something fails. If an agent generates and discards its implementation, engineers may need to reconstruct which model was used, what context it received, which tools it called, what code it produced, and why its evaluation loop accepted the result.

Ephemeral code is convenient only if the surrounding system preserves enough evidence to make its behavior reproducible and auditable. Otherwise, we have traded code maintenance for software forensics.

The Strongest Evidence Argues Against Full Autonomy

One of the paper’s strongest supporting ideas comes from research into continuous software evolution. Coding benchmarks often ask an agent to solve an isolated issue in a repository. Real development rarely works that way. Changes depend on earlier changes, undocumented assumptions, architectural boundaries, and existing technical debt.

The latest SWE-Milestone benchmark revision tests agents across 998 tasks organized into 46 dependent milestones from 20 repositories. Claude Opus 4.5 achieved roughly 75% when milestones were evaluated independently, but only about 38% when the agent had to work through them in dependency order. Errors accumulated, damaged the repository state, and made later work harder.

That result doesn’t show that agents are useless. It shows that generating a plausible local patch and maintaining a coherent system over time are different capabilities.

Research on developer productivity is similarly complicated. A 2025 randomized METR study found that 16 experienced open-source developers took 19% longer to complete 246 tasks when using early-2025 AI tools, even though they believed the tools had made them faster. The study was narrow, involving developers working in mature repositories they already knew well, but it exposed the hidden cost of prompting, waiting, correcting, and reviewing generated work.

By February 2026, METR’s follow-up analysis concluded that the original slowdown probably no longer generalized to newer tools. However, selection effects and limited usable data prevented the researchers from producing a firm updated estimate. Developers who expected large benefits were also more likely to agree to participate, which complicated the results.

AI coding capabilities are improving quickly. The evidence still doesn’t justify treating long-term architectural coherence, verification, and maintenance as solved problems.

My Job Is Already Moving From Author to Reviewer

My disagreement with the paper isn’t based on nostalgia for handwritten code.

I’ve experienced the dependency it describes firsthand. LLMs can produce implementations faster than I can type them, especially when the task involves familiar patterns, repetitive transformations, API integration, or navigating an unfamiliar part of a codebase.

The natural consequence is that I spend less time constructing each line and more time judging what the model constructed.

But “reviewer” can be a dangerously passive description. If my job becomes accepting or rejecting generated diffs, I’m still operating inside the model’s framing of the problem. The agent decides which implementation to propose, which files deserve attention, and which tradeoffs to make visible.

A capable engineer has to work one level above that process. The role includes:

• Defining the intended outcome and its boundaries
• Identifying invariants the system must preserve
• Designing tests that can reject plausible but incorrect work
• Restricting which data and tools an agent can access
• Deciding when deterministic logic is required
• Monitoring runtime behavior and unexpected side effects
• Preserving enough state to investigate failures
• Taking responsibility for what reaches production

“Intent architect” is a reasonable name for this role. It captures the move from manually expressing every instruction in code to designing systems that can interpret and execute higher-level goals.

The word architect shouldn’t imply distance from the implementation, though. Reviewing AI-generated code often requires more technical understanding, not less. A reviewer must recognize absent requirements, subtle security problems, incorrect abstractions, and assumptions that the model never made explicit.

You can outsource typing. You can’t safely outsource comprehension.

The Real Risk Is Losing the Learning Loop

There is another problem the paper barely addresses: how engineers will learn in a world where agents produce most of the implementation.

Writing software has always been part of how developers build intuition. By implementing features, making mistakes, debugging failures, and maintaining earlier decisions, engineers learn how systems behave under pressure.

If AI handles that work from the beginning of a developer’s career, we could end up asking people to review systems they never learned to build.

That creates an apprenticeship problem. Senior engineers may become highly productive reviewers because they already possess years of implementation experience. Junior engineers won’t automatically acquire the same mental models by reading polished AI-generated patches.

Development teams will need to preserve deliberate learning opportunities. Engineers should sometimes trace generated logic manually, predict failure cases before running tests, explain architectural decisions, and implement critical components without relying completely on an agent.

Dependency itself isn’t a failure. Engineers have always depended on compilers, frameworks, libraries, cloud platforms, and search engines. The danger begins when a tool removes both the work and the understanding that the work used to create.

What Ends First Is Syntax Production

The most vulnerable part of software engineering is the mechanical translation of well-defined requirements into conventional code.

If a ticket already contains an unambiguous specification, known architecture, clear acceptance criteria, and predictable implementation pattern, an AI agent may be able to complete most of it. The human contribution was already close to syntax production.

The harder work begins before and after that translation. Requirements conflict. Stakeholders omit constraints. Existing systems contain undocumented behavior. Security rules limit convenient solutions. A locally correct change causes a system-wide regression.

Software engineering exists because real-world intent is incomplete and systems have consequences. Generating more code doesn’t resolve either problem.

AI may reduce the economic value of manually writing routine implementations. It will increase the value of people who can define the right problem, distinguish correct behavior from convincing output, and take responsibility for an increasingly autonomous system.

Final Thoughts

“The End of Software Engineering” is wrong as a prediction but useful as a warning.

If we define software engineering as humans manually converting decisions into syntax, then yes, much of that profession is already being automated. I can see it in my own work. The cursor moves less because the model generates the first implementation, while my attention moves toward specifications, architecture, tests, and review.

But software engineering has never been valuable merely because typing code was difficult. Its value comes from creating dependable systems under incomplete requirements and real constraints.

Agentic software doesn’t remove that responsibility. It creates more behavior that no human explicitly wrote, which makes specification, verification, observability, and accountability more important. We may become intent architects, but we will still need to understand the structure, inspect the work, and answer for what happens when the agent gets it wrong.