AI agents (for example, Claude Code) feel fundamentally different from traditional software. Most software is built around logic the developer has already fixed in place; users can only interact within those allowed flows. An AI agent, by contrast, decides and carries out the concrete steps to fulfill a request. The actual reasoning may be delegated to an LLM, but the fact that behavior is determined by that judgment marks a sharp break from earlier software.
You could say older software is mostly static logic, while AI agents are dynamic.
Who holds the reins
In that sense, control has shifted from the developer to the model—an inversion of control (IoC) that amounts to a paradigm change. That may be why it feels new even to people who have spent their careers building conventional software.
Put more plainly, traditional software behaves like a deterministic machine. The developer designs every branch with if-else; if input A does not yield result B, we call it a bug. Logic is fixed, so execution is fast and outcomes predictable.
An AI agent, on the other hand, runs a reasoning loop: it interprets the user’s intent, surveys the available tools, and decides that “in this situation, this tool is probably the best fit.” The striking part is that this logic is not hand-authored by the developer—it is produced dynamically.
How the developer’s role changes
As these agents improve, developers may step back from incidental work like coding and debugging (bittersweet as that sounds) and focus on specification—what to build and how. There is already a lot of discussion about how the developer’s role will evolve under this shift.
For example, mastering language syntax and accumulating framework best-practice experience may matter less as a differentiator. I suspect problem formulation will take that place. So will the ability to turn those problems into business requirements and to express them in precise, logical spec documents.
Software like a liquid
Pushing the idea one step further: I can imagine a world where latency in the LLM’s reasoning loop is driven so low it is negligible, or where software rewrites its own behavior at runtime.
To unpack that: software until now has been a solid. Once built and deployed, its shape stayed the same until someone changed the code and shipped again. New software might behave more like a liquid.
The logic you need could be generated just in time (JIT). When a request arrives, the system could assemble a one-off execution path tuned to that request, run it, and throw it away—and if that path keeps getting hit, it could be cached so the JIT path is skipped.
A system might also watch its own load and, when a bottleneck appears, redesign and restructure itself without a developer in the loop.
Loss of reproducibility and questions of responsibility
From a traditional software mindset, that is a bundle of problems. The same logic might work yesterday and fail today depending on system state—in other words, reproducibility fades.
There is also the accountability gap: who supervises dynamically generated logic? If a system handles requests and quietly stores personal data from them for resale, who would even know?
And yet
None of this feels purely fantastical because business logic can paper over many of those concerns. As models get lighter and on-device AI matures, inference cost per request could fall substantially.
Once cost is no longer the blocker, properties we treated as essential—reproducibility, fixed logic, explicit developer control—may become optional rather than mandatory. Software turning liquid may be a tide we cannot hold back.