$Agentic Development Fallacies

In 1994, L. Peter Deutsch, then a Fellow at Sun Microsystems, wrote down seven assumptions that engineers new to distributed systems make without noticing: the network is reliable, latency is zero, bandwidth is infinite, and so on. The list has outlived the hardware it was written about. What kept it useful is that every item on it is true somewhere. Each assumption was a local truth carried into a scope where it stopped holding, and the abstraction in between hid the seam it crossed.

Agentic development has a similar shape. I describe intent, an agent produces work, I review it and steer. Two comparisons are available for reasoning about that, and both are partly right. The interface is conversation, which is how I work with a colleague, and the output is code, which is what a compiler consumes. The mistakes below are what happens when either comparison gets carried further than it holds.

1. “If the prompt is clear, the result will be correct.”

Clarity is a property of what the prompt says, and most of the risk sits in what it leaves out.

Real requirements carry assumptions, constraints, edge cases, architectural decisions, and organisational knowledge nobody wrote down.

2. “More autonomy means more productivity.”

Letting an agent touch twenty files instead of two multiplies the work it can do, and multiplies the wrong work by the same factor. The second number is the one nobody watches, because wrong work looks like right work until somebody reads it carefully.

3. “If the code works, the agent understood the problem.”

Passing tests say something about behaviour and nothing about understanding. An agent can reach a correct output through the wrong abstraction, reimplement a mechanism that already exists three directories away, break a convention that holds everywhere else in the codebase, or solve the specific instance rather than the class it belongs to.

4. “Plausible code is performant code.”

Models are exceptionally good at producing code that looks right. It compiles, reads idiomatically, passes surface-level unit tests, and survives a quick code review. But LLMs optimize for the statistical probability of tokens, not execution complexity.

5. “Agents remove the need to understand the codebase.”

Usually the opposite happens. When producing code gets cheap, the scarce resource becomes the judgement to evaluate it, and that judgement runs on context the agent does not have: what the system is for, what broke last time, which constraint is real and which is habit.

6. “A successful demo means the workflow scales.”

Agentic workflows look extraordinary on isolated tasks, which is precisely what a demo consists of: greenfield features, isolated bug fixes, or self-contained scripts. In production, however, complexity does not scale linearly; it compounds.

7. “More agents means more intelligence.”

Assigning specialized roles to different agents—a Planner, a Coder, a Reviewer, a Tester—is an appealing pattern because it mirrors human engineering teams. But human organizational charts primarily exist to manage human cognitive load and coordination overhead, not because splitting tasks intrinsically creates intelligence.

8. “Humans are the fallback.”

Human oversight is often framed as temporary scaffolding—necessary today while models are flawed, but removable once models reach a high enough benchmark score.

This framing assumes humans and agents are performing the same job at different quality tiers. They are not. Agents perform rapid synthesis, pattern matching, and boilerplate expansion across known code. Humans perform value alignment, constraint prioritization, domain risk evaluation, and accountability.

Cheaper implementation, costlier everything else

The misconception underneath all eight is that agentic development is programming, faster. It is closer to a change in which parts are expensive.

When implementation gets cheap, everything implementation used to pay for gets relatively more expensive: specification, architecture, evaluation, observability, performance work, verification, judgement. Deutsch’s list has the same structure underneath it. One part of a system got cheap enough that people stopped thinking about it, and the cost turned up somewhere they were not looking.

The workflows I would bet on are the ones that make a wrong assumption cheap to discover, rather than the ones that generate the most code.

The framing here is borrowed from the fallacies of distributed computing.