"The End of Software Engineering": will AI agents end the software profession, or just one way of building software?

For over half a century, the software industry has run on a nearly unchanged principle: humans analyze the problem, design the system, write the source code, test it and maintain it. A paper published in June 2026 by Zhenfeng Cao (Lingxi Intelligent Investment, Shenzhen) with the shocking title "The End of Software Engineering" argues that AI agents may not merely help programmers write code faster — they may change how software itself is created, operated and sold. This article summarizes the paper's thesis, and the limits it acknowledges itself.

Quick answer

• The paper's core thesis: in traditional software, code holds most of the decision logic; in agentic systems, the AI model becomes the reasoning engine, choosing actions itself and using code as a tool — even generating code, running it, and discarding it when the job is done.
• The shift it describes: from "AI → software → result" to "Agent → result", where users describe what they want and interact directly with an agent instead of a pre-built application designed for each question.
• Three software eras, per the author: Software 1.0 (installed software), Software 2.0 (SaaS — selling usage rights over the Internet) and Software 3.0 — Agent-as-a-Service (AaaS), where customers pay for work outcomes rather than seats or features.
• Engineers do not disappear; their center of gravity moves: from hand-writing code to designing agent systems, controlling access, evaluating results and ensuring reliability — an approach the paper calls Agentic Engineering.
• The biggest limit, stated by the paper itself: AI agents are not yet reliable enough to replace the whole enterprise software development process, with open problems in authorization, system integration, state and accountability when multiple agents cooperate.

The same mindset for over 50 years

Take a company that wants a sales management system. The traditional way: a technical team analyzes requirements, designs the database, builds the backend, builds the frontend, tests and deploys. When business requirements change, programmers edit the code, update the logic and ship a new version. The essence of this model is converting business decisions and rules into static code, which the software then executes exactly as programmed.

From Waterfall to Agile, Monolith to Microservices, manual deployment to CI/CD — tools and processes kept changing, but the human role at the center of designing and maintaining a relatively stable codebase remained. AI coding assistants, arriving later, only accelerated that process: fundamentally, we still build software the old way.

Agents change the model, not just the speed

The paper's most interesting distinction:

Aspect	Traditional software	Agentic systems
Where decision logic lives	In code hand-written in advance	In the AI model — a reasoning engine choosing actions toward a goal
The role of code	The central product, fixed for all situations	A tool the agent uses; can be generated, executed, then discarded after the task
How humans assign work	Analyze, design, program every processing step	Set the goal; the agent breaks down tasks, picks tools, calls APIs, processes data and evaluates results
When requirements change	Edit code, release a new version	The agent adapts to new requirements during execution

In other words: previously, humans wrote software to solve problems; in the new model, humans can hand the problem itself to an AI system that chooses how to solve it. The paper notes this does not mean all software can — or should — be replaced by agents; the fit is strongest for work whose requirements change continuously.

From "AI → Software → Result" to "Agent → Result"

The paper describes a shift in how value is delivered. Suppose a sales director wants to know why this month's revenue fell 15%:

• The traditional way: the company must build a dashboard, write data queries, design reports and maintain analytics features.
• The agentic way: the user asks directly — "analyze why revenue dropped, compare with the previous three months, identify the affected product groups and propose actions" — and the agent connects to the data sources it is authorized for, queries, analyzes the movement and produces the report.

Users do not actually need an application with dozens of features; they need an answer to a business problem. Yet behind every agent there must still be databases, APIs, authentication systems and reliable software components — so "Agent → Result" changes how value is delivered, not whether traditional software exists underneath.

After SaaS, an Agent-as-a-Service era?

The author reads the industry's history in three eras:

• Software 1.0 — traditional installed software: users buy software, install it and manage the operating environment themselves.
• Software 2.0 — Software-as-a-Service (SaaS): software delivered over the Internet; the vendor runs, updates and maintains the infrastructure.
• Software 3.0 — Agent-as-a-Service (AaaS): users pay not just to use software, but for an agent to perform work or produce outcomes — instead of buying reporting software, a company uses a data-analysis agent that prepares periodic reports by itself.

The notable consequence is commercial: as customers care more about final outcomes, pricing by seats, features or licenses may have to compete with pricing by task and delivered value. This remains a forecast, though — there is no basis yet to claim AaaS will replace all of SaaS.

If code is no longer the center, what do engineers do?

If agents increasingly generate code, test, fix bugs and deploy by themselves, the value of hand-written code may decline in some job categories. But a set of new questions appears, and they do not vanish just because AI can write code:

• Who verifies that the thousands of lines an agent produces in minutes actually solve the right problem?
• Who is responsible when an agent accesses the wrong customer data?
• Who designs the controls that keep an agent from taking dangerous actions on its own?
• Who evaluates performance when several agents cooperate and reach inconsistent decisions?

Per the paper, the engineer's focus shifts to designing agent systems, building execution environments, controlling access, evaluating results and ensuring reliability — together forming a discipline it calls Agentic Engineering. The future engineer's advantage may lie less in how many lines of code they write than in designing systems that produce correct, safe and valuable results.

The biggest problem: agents are not reliable enough yet

The paper devotes a whole section to the downside. An AI system can ace programming benchmarks yet still struggle with real products, because enterprise software is not just code: it includes complex business requirements, historical data, integrated systems, security regulations and countless edge cases. An agent can write an API that works in a test environment but miss an authorization condition; fix a small bug while silently affecting other features; or complete a task exactly as worded while missing the business's real objective. When multiple agents cooperate, managing state, sharing context, controlling errors and assigning accountability become new engineering problems. Moving to agentic systems is therefore not simply "replacing programmers with an AI model" — it demands a whole new layer of infrastructure and engineering method to make systems trustworthy.

The end of the industry, or the end of a method?

Read closely, the paper does not actually claim programmers will vanish. It argues the industry's center may shift along four axes:

• From building fixed programs to designing adaptive systems.
• From programming every processing step to defining goals, constraints and evaluation methods.
• From selling software usage rights to providing the capability to get work done.
• From humans directly performing most technical operations to designing, orchestrating and controlling automated systems.

Technology's history shows that each time a layer of work is automated, human value tends to move to other layers. And the paper's biggest open question: if users only need to describe what they want while agents figure out how — do we still need to build software the way the IT industry has for over half a century? It bears repeating that this is one researcher's thesis and forecast, not a conclusion that software engineering has ended.

Frequently asked questions

Who wrote "The End of Software Engineering", and when?

Zhenfeng Cao of Lingxi Intelligent Investment (Shenzhen, China), under the full title "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm", published 5 June 2026. It should be read as one paper's argument and forecast, not an academic or industry consensus.

What is Agentic Engineering?

The engineering approach the paper proposes for the agent era: instead of focusing on hand-written code, engineers focus on designing, controlling and operating agent systems — including designing agent workflows, building execution environments, controlling access to data and tools, evaluating outputs and ensuring reliability when systems act autonomously.

How does Agent-as-a-Service (AaaS) differ from SaaS?

SaaS sells the right to use software: customers pay per seat or feature and operate the tool themselves to produce results. AaaS sells work outcomes: customers hand a job to an agent (data analysis, report preparation, market research...) and pay per task or per value delivered, instead of operating a tool themselves.

Will AI agents replace programmers?

According to the paper itself: not yet, at least not across the whole enterprise development process. Agents still lack reliability in authorization, system integration, exception handling and accountability when multiple agents cooperate. The scenario the paper sketches is a role shift — less manual coding, more designing, supervising and verifying agent systems.

Does "Agent → Result" mean traditional software disappears?

No. The paper notes it itself: behind every agent stand databases, APIs, authentication systems and reliable software infrastructure built by humans. What changes is the user-facing layer — from "open an app with pre-built functions" to "state a request and receive a result" — not the existence of the software underneath.

Conclusion

The title "The End of Software Engineering" is deliberately extreme, but the argument beneath it is more balanced: what may end is a way of making software that has lasted half a century — humans translating every business decision into static code — not the software engineering profession itself. If agents really do take over an increasing share of execution, the engineer's value will sit in defining goals, constraints, controls and evaluation: precisely the work that is hardest to automate. For IT practitioners, the practical question is not "will the job disappear", but "which layer of this shift am I standing in".

Source: an introduction and summary by the Hoi Dan IT Official page on Facebook (6 Nov 2026) of Zhenfeng Cao's paper "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm" (5 Jun 2026); edited and structured by Wotech Electronics. The views belong to the paper's author and are a thesis and forecast. Illustration: the paper's first page, attached to the original post.