In a large legacy system, writing a change may take a few hours. Finding where to make it, and proving that it won’t break anything, can take days or weeks. That difference explains almost everything the debate around AI agents tends to overlook.
The debate now has a reference text: Agentic Software: How AI Agents Are Restructuring the Software Paradigm. Its central thesis is clear. In traditional software, decision-making logic lives in the code. In agentic software, it lives in the agent, which generates code when it needs it. Code stops being the product and becomes a byproduct.
There is a lot of truth to that. Anyone who uses coding assistants sees it every day: increasingly, the value lies in expressing intent, in saying what you want to accomplish, and less in typing every line yourself. The paper is also honest about an important limitation: it acknowledges that agents perform very well on isolated tasks but still struggle with large projects, long-term maintenance, and systems that never stop changing.
Where it goes too far is in its tone. The title and several of its conclusions suggest something close to the end of software engineering. We have heard that promise before. Assembly to C. C to frameworks. Frameworks to low-code. Low-code to generative AI. Every new layer of abstraction was supposed to eliminate programmers, yet every time we still needed engineers. What changes is the level at which they work. Code does not disappear; it sinks one layer deeper, just as assembly is still there beneath everything we write in high-level languages.
So far, that is a reasonable and somewhat comfortable answer. The problem is that it treats “the industry” as if it were a single place.
Two Worlds with the Same Name
The prediction that in five years we will write far less code by hand sounds plausible. But it is plausible primarily for greenfield projects and startups. In a large enterprise, with massive legacy codebases spread across multiple platforms and technologies, and often poorly documented, there is still a great deal of manual interpretation to be done, along with plenty of code that still has to be written by hand.
Agents shine when a project starts from scratch, the architecture is simple or well documented, there are few external dependencies, and the requirements are clear. Now compare that with the typical landscape of a large enterprise. Millions of lines of code. .NET, Java, SAP, mainframes, Python, and JavaScript coexisting, not always peacefully. Business rules accumulated over decades. Incomplete or outdated documentation, which is sometimes worse than having none at all. Integrations with hundreds of systems. And, almost inevitably, behaviors that nobody fully understands but that the business depends on.
In that environment, the bottleneck is not writing. It is understanding.
Knowledge Engineering
When the main problem is figuring out what a system actually does and what will happen if you touch it, the work starts to look less like programming and more like investigation. It becomes knowledge engineering.
This is where AI does help, and quite a lot. It can explore code, explain modules, generate documentation, create tests, and suggest refactorings. All of that reduces the time engineers spend getting lost in someone else’s repository.
But there are things it still does not do well. It cannot reliably infer implicit business rules, the ones that were never written down because “everybody knew.” It cannot reconstruct historical decisions that nobody documented. It cannot assess organizational impact. And it cannot effectively navigate dependencies across dozens of teams, where the relevant question is often not technical but rather, “Who is this going to hurt?”
That is why automation moves faster in startups and new products than in organizations carrying decades of technical debt. It is not necessarily that large companies are slower to adopt new tools. It is that their most expensive work was never the work those tools accelerate.
What Actually Changes
None of this means the paper is describing a fantasy. The trend is real. In a few years, we will probably write far less code manually, even in large enterprises. What the paper conflates is the end of writing code by hand with the end of software engineering. Those are very different things.
What remains when code generation becomes automated is precisely what has always been difficult: architecture, systems design, security, governance, integration, product prioritization, and technical leadership. And there is another shift worth noticing. The more autonomous agents become, the more important it is to define objectives, constraints, and success metrics correctly. An agent that quickly executes a poorly framed instruction does not save work; it multiplies it.
In a legacy system, this matters even more. An agent may be able to write the change in minutes. What nobody can give it yet is the list of strange behaviors the business depends on, because that list does not exist in any file. It exists scattered across the minds of people who have been there for years, in old tickets, and in incidents someone vaguely remembers.
Code was always the easy part to explain. The hard part was, and still is, knowing what not to touch.
