Is Agentic Software the End of Software Engineering?

AI agents change what software engineering has to engineer. As decisions move into runtime, the object of control moves with them, and governance has to reach the same surface.

By Tahir Mahmood, Co-founder & CTO, OpenBox  ·  Last updated 2 September 2026

Agentic software does not end software engineering. It moves the object of the discipline. When AI agents reason through tasks, generate implementation on the fly, call tools, and revise their own work, the durable engineering problem shifts from writing every line of static code toward specifying intent, constraining agent behaviour, and controlling what happens at runtime.

That shift pulls the governance problem with it. Consequential decisions increasingly happen while the system is running, and controls designed around static artefacts cannot, on their own, reach behaviour that is generated or selected dynamically. This piece works through what actually changes, what remains, and where the new control surface sits.

What the "end of software engineering" argument actually says

The sharpest version of the claim comes from a June 2026 paper by Zhenfeng Cao. As of version 2 (last revised 10 June 2026), the paper is titled "Agentic Software: How AI Agents Are Restructuring the Software Paradigm". The earlier v1 (4 June 2026) was titled "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm"; the softer title reflects the v2 revision. Cao formalises a distinction: in traditional deterministic software, code carries pre-written decision logic; in agentic software, the agent itself is the software, and its decision logic is generated at runtime (arXiv:2606.05608).

The paper also proposes a historical arc from licensed software to Software-as-a-Service to what it calls Agent-as-a-Service, arguing that each shift transfers additional complexity away from the end user, with the agentic step transferring decision-making complexity itself. It introduces "Agentic Engineering" as a proposed expansion of the software engineering discipline, and frames the developer role as "intent architect". These are the paper's framings, not settled industry positions.

A separate line of work reaches a related, more measured conclusion. Hassan et al. (arXiv:2509.06216, v3 revised 24 June 2026) describe "Agentic Software Engineering (SE 3.0)" and argue for a duality of "SE for Humans" and "SE for Agents", introducing structured workbenches (an Agent Command Environment and an Agent Execution Environment) for human-agent collaboration. The two papers agree that the object of engineering is changing. Neither establishes that engineering is going away.

What changes when the agent is part of the software

The architectural shift is real but narrower than the headline suggests. In a conventional model, human intent is compiled into persistent code, tested, deployed, and executed. In an agentic model, intent is passed to an agent that plans, invokes tools, produces intermediate implementation, executes, receives feedback, and revises. The table below captures the contrast at a coarse level.

Two cautions matter. First, "the agent is the software" is a useful analytical framing for architectures where an LLM drives runtime behaviour end to end. It should not be universalised across every system that embeds an AI feature. Second, an agentic architecture does not eliminate persistent software. System instructions, orchestration, tools and APIs, data stores, permissions, evaluation harnesses, observability, and application components around the agent all remain durable and, arguably, more consequential than before.

Code may become less durable, engineering does not

The simplistic conclusion is that if the model writes the code, there is less engineering to do. The more accurate observation is that engineering effort shifts. Time spent hand-writing implementation gives back time to intent specification, decomposition, tool and interface design, permissions, evaluation, runtime monitoring, failure handling, and intervention design. In many teams the total volume of engineering work does not shrink; it moves to a different set of surfaces.

Some observers propose new role descriptions such as "intent architect". Whether that particular label sticks is not the point. What appears more consistently across current literature is that the skills that scale, code generation, retrieval, and tool wiring, are the skills that get automated first, while the skills that remain scarce, precise specification, systems thinking, evaluation design, and control, are the ones agentic systems make more valuable.

The real shift: from writing decisions to governing decisions

The clearest way to describe what has changed is this. Traditional software engineering encodes decisions ahead of time in source code, and controls apply to that code. Agentic software makes many consequential decisions at execution time, and controls need to apply to those decisions.

That reframes the questions engineers and governance teams have to answer. What is the agent authorised to do? Which tools can it invoke, and on which data? Which actions require a human to approve them before they run? What happens when a plan or an action falls outside expected patterns? What evidence exists, after the fact, that a control operated? These are not compliance ornaments. They are the runtime equivalents of the questions that access control, code review, and deployment approval used to answer at build time.

What happens to traditional engineering controls

Static controls do not stop working. They stop being sufficient on their own. Code review still catches implementation defects. CI/CD still gates deploys. Tests still guard regressions. What changes is the fraction of consequential behaviour those controls actually cover, because much of the behaviour is now selected dynamically rather than written in advance.

The pattern is consistent: a control designed around a static artefact cannot, by itself, control behaviour that is generated or selected at runtime. Something has to sit at the point of action.

Why runtime becomes the new control surface

Runtime matters because several of the things agent behaviour depends on are inherently dependent on execution: the model's output, the retrieved context, the evolving state of the session, and prior steps in the current plan. Others, such as the available tool catalogue, active permissions, and system configuration, can be established in advance, but the specific selections an agent makes among them cannot. That is where two distinctions become load-bearing.

Monitoring is not enforcement. A dashboard that shows what an agent did is not the same as a control that decides whether an action may proceed. Both matter; they are different jobs.

Logs are not automatically evidence. An event stream that records what happened is useful telemetry, and logs can serve as audit evidence when they meet the required properties. Doing so takes more than retention: attribution, integrity, appropriate retention periods, and enough structure to support a specific compliance finding. Retention alone does not confer those properties, and different regimes require different combinations of them.

An adjacent distinction is worth naming. A signed, hash-chained record can show that a set of recorded events was not altered after signing. That is tamper-evidence, not proof that the underlying facts are true, that the record is complete, or that tampering was prevented. Precision here is not pedantic; it is the difference between a control that survives external review and one that does not.

The control surface should follow the decision surface

If the useful principle from the analysis above is one line, it is this: the control surface should follow the decision surface. When decisions moved into code, controls followed into the code review, the test suite, and the deployment pipeline. As decisions move into runtime agent behaviour, controls have to reach the runtime as well, alongside, not instead of, the pre-deployment controls that continue to matter.

OpenBox, an AI agent governance platform, is one concrete implementation of this idea. It wraps existing agents with a Trust Lifecycle of five phases documented as Assess, Authorize, Monitor, Verify, and Adapt (docs.openbox.ai/llms.txt). When an agent operation is evaluated, the platform returns one of four governance decisions, ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT, with precedence HALT > BLOCK > REQUIRE_APPROVAL > ALLOW (docs.openbox.ai/core-concepts/governance-decisions). REQUIRE_APPROVAL pauses the operation and routes it to a human reviewer before it can proceed; HALT terminates the entire agent session.

For evidence, OpenBox produces a per-session proof certificate. Per its attestation documentation, each governance event is hashed with SHA-256, combined into a Merkle tree using sorted-pair hashing, and the session root is signed with ECDSA NIST P-256 via AWS KMS by default, or via an external attestation endpoint for organisations using TEEs or their own signing infrastructure (docs.openbox.ai/administration/attestation-and-cryptographic-proof). The documentation describes the result as tamper-proof; in the more careful terminology adopted above, that is tamper-evidence of the recorded session, not a claim about the truth of what was recorded.

These are not the whole of governance. They are examples of what "controls at the runtime decision surface" looks like when it is built, and they are the ones that a hostile reviewer can inspect against a live source. For a broader treatment of the surrounding framework, see OpenBox's guide to AI agent governance, and, on the specific point that some agent actions cannot be rolled back, Reversibility Is a Governance Requirement.

What engineers and governance teams should now control

A useful way to organise the new work is by the dimension of the system it addresses. This is offered as an organising model, not as a settled taxonomy.

Two notes on this model. First, policies and behavioural rules are distinct constructs. In OpenBox, policies are stateless per-operation checks implemented as OPA/Rego; behavioural rules are stateful pattern detections across a session (docs.openbox.ai/trust-lifecycle/authorize). Treating them as one thing loses the control that comes from their difference. Second, the final authorisation decision should stay deterministic. Probabilistic signals from the model are useful inputs, not the last word.

What this means for the future of software engineering

The provocative claim is easy to state and hard to defend as stated. Agentic software does not end software engineering. It moves it. Less time on writing every implementation. More time on specifying intent, designing the surfaces the agent acts on, evaluating outcomes, and controlling what happens at runtime. The pre-deployment disciplines that the industry has spent decades building do not disappear. They stop covering the whole problem on their own.

The corollary, and the point that matters most for governance, is that engineering and governance are becoming harder to separate. When consequential decisions happened between deploys, governance could operate on artefacts and calendars. When consequential decisions happen inside a running session, governance has to operate there as well. Whether a given organisation calls that "runtime governance", "agent controls", or something else, the shape is the same: controls at the decision surface, with evidence that they operated.

Frequently asked questions

Is AI going to replace software engineers?

Current evidence shows substantial change in software-engineering tasks and workflows, but does not settle the long-term shape of the profession. Coding-agent benchmarks need to be read carefully: on 23 February 2026 OpenAI said it no longer reports SWE-bench Verified, citing test-design flaws and contamination, and now recommends SWE-bench Pro. Cao's June 2026 paper (arXiv:2606.05608) argues the object of engineering is shifting toward intent, agent design, and runtime control, not that the discipline disappears.

What is agentic software?

Agentic software describes systems where a language model serves as the primary reasoning engine and generates or selects implementation dynamically to accomplish a task, rather than executing decision logic pre-written by humans. Cao (arXiv:2606.05608) contrasts this with traditional deterministic software, where code is the carrier of pre-written decision logic.

Does agentic software make code review and CI/CD obsolete?

No. Code review, tests, and CI/CD continue to cover durable software: tools, prompts, policies, orchestration, and infrastructure. What weakens is their reach over behaviour that is generated or selected at runtime by an agent. Runtime controls complement these, they do not replace them.

Why does governance need to move to runtime for AI agents?

Because agent behaviour depends on inputs that only exist at execution time: the model's output, retrieved context, available tools, active permissions, and prior steps. A control designed around a static artefact cannot, on its own, control what an agent selects in that runtime context. Controls at the point of action address the gap.

What should an organisation actually control when agents can act autonomously?

At minimum: what the agent is authorised to do, which tools and data it may use, which actions require human approval, which runtime patterns should escalate or halt a session, and what evidence is retained afterwards. These map to policies, approvals, behavioural rules, and signed session records in a governance platform, or to their equivalents in an internal build.

Sources