Agentic Software: How AI Agents Are Restructuring the Software Paradigm
Paper review · Zhenfeng Cao · arXiv preprint, June 2026
Most articles about AI coding tools ask how much faster programmers can work. This paper asks something bigger: if an AI can decide what to do while it runs, is it still the kind of software we have known for fifty years? The answer is interesting, but the most useful part for our industry is a warning buried in the evidence. AI agents that do well on a single task become much less reliable when the work carries on over time, and ship systems stay in service for decades.
| Title | Agentic Software: How AI Agents Are Restructuring the Software Paradigm Version 1, shown here, was titled "The End of Software Engineering". |
| Author | Zhenfeng Cao, Lingxi Intelligent Investment (Shenzhen) Development Co., Ltd. |
| Status | arXiv preprint, cs.SE and cs.AI. Submitted 4 June 2026, revised 10 June 2026 (v2). 15 pages. |
| License | CC BY 4.0 |
| Source | arXiv:2606.05608 ↗ |
🔍 (1) The Big Idea in Plain Words
Think of traditional software as a procedure manual written ashore. Programmers think through the situations in advance and write down the rules, and the computer follows those rules exactly. If something happens that the manual does not cover, a person has to come back and rewrite it.
An AI agent works more like a duty officer who is given a goal and some equipment, then decides the next step as the situation unfolds. Technically, Zhenfeng Cao describes an agent as four parts working together: a large language model (the kind of AI behind today's chatbots) that does the reasoning, tools it can use, a memory, and a planner. It may even write a small piece of code to get a job done and then throw that code away.
That comparison with a manual and a duty officer is ours, not the author's, but it captures the paper's main point. In traditional software the code holds the decisions. In agentic software the decisions are made while the system is running, and code becomes something closer to a disposable tool. Cao argues that this is a change in what software is, and not merely a faster way of writing it. The paper proposes a name for the new field, "Agentic Engineering", a term the paper credits to LangChain, a company that builds tools for AI agents.
⚙️ (2) Why the Author Sees This Change as Unavoidable
The argument begins with complexity. Every time you add a component to a system, the number of ways the components can interact grows much faster than the number of components. The paper gives a mathematical upper limit for this. With only 10 components, there could in theory be 2 to the power of 45 different interaction patterns, which is more than 35 trillion. Human ability to understand a system, meanwhile, stays roughly the same. Cao's conclusion is that people will eventually hit a ceiling, while an AI's capacity can keep growing as more computing power goes into training it.
The paper then places this in a short history of how software reaches its users. First we bought licensed programs and ran them ourselves, so the user carried the burden of keeping them working. Then came online subscription services (SaaS), where the vendor took on that burden. Cao now sees a third step, called Agent-as-a-Service, where the agent itself does the work and the customer pays for the result. Each step moves more of the complexity away from the customer.
People do not disappear in this picture, but their job changes. Instead of writing every instruction, they explain clearly what they want, oversee the overall design, judge the quality of the result and take responsibility for the ethical decisions. In the paper's framing, the human states the intent, the agent does the work and the human audits it.
📊 (3) What the Evidence Really Says
This is the part of the paper most worth reading, because the results point in different directions. Note that these numbers come from other researchers' studies, which the paper brings together.
Start with the good news. In a pilot reported from LangChain, a team of cooperating agents was applied to more than 20 enterprise debugging workflows. The time needed to find the root cause of a problem fell by 93%, saving over 200 engineering hours in one month. That is impressive, but debugging is a clearly bounded job, and a pilot is not the same as an independent test.
Next comes a more modest result. SWE-bench Verified is a widely used test that checks whether AI systems can fix real software issues. The paper reports that one model, Lingma SWE-GPT 72B, solved 30.20% of them, close to GPT-4o at 31.80%. Progress is real, but about seven out of ten issues remained unsolved, even though each one is a separate task.
Then comes the sobering number. A study called EvoClaw looked at what happens when agents keep working on software over time, the way a real product is maintained, instead of handling one isolated task. Across 12 leading AI models and 4 agent frameworks, success fell from above 80% on isolated tasks to at most 38% in continuous work. An agent can look excellent in a demonstration and still struggle when asked to look after the same system month after month.
The paper gives four reasons for this drop. The first is that agents lose track as a codebase grows beyond what they can keep in view at once, which the paper calls context drift. The second is that a small mistake in one change can spread through later changes. The third is that agents do not think about the long-term cost of maintaining what they build. The fourth is perhaps the most worrying: an agent can pass all its tests while still introducing a subtle error in what the software actually means or does. Cao sees these as limits of today's memory and verification methods and not as permanent barriers, but also accepts that fully autonomous development is still several years of research away.
🧭 (4) Where the Author Thinks This Is Heading
Cao sketches four stages. In the first, from 2023 to 2025, AI is a helper that completes code and fixes single issues while the person remains the author. In the second, from 2025 to 2027, an agent can build a feature or debug a problem from start to finish, and the person becomes the one who sets the intent and checks the result. In the third, from 2026 to 2029, teams of agents cooperate across the whole life of a software product, and people act more like project managers, architects and auditors. In the fourth, from 2028 onward, agents discover, learn and modify themselves, while people set the goals and govern the ethics.
These dates deserve some caution. The paper says the roadmap is based on current capabilities and trends, and it labels the fourth stage as prospective. It is better read as a thoughtful guess about direction than as a schedule to plan a fleet's technology around.
🏆 (5) How Far Should We Trust It?
The paper's great strength is its clarity. It gives us simple language for the difference between rules fixed in advance and decisions made at runtime, and it reports the drop in continuous work openly when it could have shown only the best numbers.
Still, it should be read for what it is: a preprint by a single author, built as a conceptual argument on other people's studies. Preprints are shared publicly without having to pass peer review first, and the listing we checked shows no journal or conference. A theoretical limit on complexity does not prove that agents are required, because real systems never use every possible interaction. The paper also cites more than 179,000 GitHub stars for a project called Hermes Agent, but stars show popularity and say little about whether something works. Finally, it does not deal with safety-critical or regulated equipment, so its conclusions cannot simply be carried over to ships.
⚓ (6) What This Means for Ships
The paper never mentions ships, so what follows is this review's own reading. Even so, the four weaknesses above sound very familiar at sea. Sister vessels slowly drift apart in their configuration, so what an agent believes about "the system" may not match the ship in front of it. One flawed change, repeated as a template, could reach several integrated systems or a whole fleet. A shortcut taken at delivery can become the owner's burden for the rest of the vessel's life. And a passed test procedure does not prove that equipment will behave correctly in every operating condition.
For teams working under IACS UR E26 and E27, a cautious path follows. These are this review's suggestions, not requirements from the rules. The sensible place to begin is shore-side work with clear limits, such as helping to investigate a fault or preparing a first draft of a document. That is where the evidence above is strongest. Anyone using an agent to draft a Vessel Asset Inventory or a Zones and Conduit Diagram should still check it against the actual ship.
Agents should not be given direct write access to onboard operational systems. Whatever they propose should go through the existing management of change process, with a named person approving it. It also makes sense to keep a record of what the agent saw and did, because when decisions are made at runtime, that record may be the only evidence available to an audit or investigation. And since agents can pass tests while still being wrong, their changes need a person to review the intended behaviour as well as the test results.
🎯 (7) The Takeaway
The paper's title promises a new era of software, but the number to remember is the fall from above 80% to at most 38%. For an industry that keeps its systems running for decades, the real question is not whether an agent can finish a task. It is whether anyone can still trust the system after the hundredth change.
Senior Manager at a global consulting firm specializing in Maritime Cyber Security, AI, and Data Analytics. 17+ years spanning shipbuilding R&D, AI product development, and maritime cyber compliance. Specializes in IACS UR E26/E27, IMO MSC guidelines, and smart ship development. Founder of ShipPaulJobs.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment