Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

The bottleneck moved

For thirty years the cost of software was the cost of writing it. That cost has collapsed. An agent will produce a feature, its tests, and a migration before you have finished describing the next one. If you still believe the constraint on your software is typing speed, you are optimising a bottleneck that left the building.

The new constraint is comprehension over time. Not "can we build it" but "in six months, will anyone — a teammate, a future you, the next model — be able to say what this was for, whether the code still does it, and how we would know if it stopped." Generation got cheap. Justified, durable generation did not. The faster the agents write, the faster the gap between intent and code widens, because nothing is forcing the two to move together.

The map and the territory

The code is the territory. It is the only artifact that is unambiguously real: it runs, it fails, it ships. Everything else we write about the software — the ticket, the design doc, the Slack thread where the actual decision was made — is a map. A description of the territory, made at one moment, by one person, for one purpose.

A map has exactly one virtue: that it stays true to the territory. The moment it drifts, it is worse than nothing, because it lies with the authority of having once been right. And here is the quiet catastrophe of how we keep our maps today:

  • The Jira ticket was closed eight months ago. Closed means archived means invisible. The promise it encoded is now folklore.
  • The REQUIREMENTS.md at the repo root was honest on the day it was committed. Forty merges later it describes three features that were cut and omits the two that pay the bills. Nobody updated it, because nothing broke when they didn't.
  • The Confluence page has page-level history and rich text. It cannot be diffed at the field level, it cannot be grepped, and it certainly cannot be compiled against the code it claims to describe.

Every one of these maps shares the same fatal property: it does not compile against the territory. There is no mechanism — none — that turns red when the description and the code disagree. Drift is not an accident in this world. Drift is the default, and silence is its accomplice.

What this does to an AI

A human carries a fuzzy, lossy, but living map in their head. They were in the meeting. They remember that "retry on failure" meant transient failures only, that the edge case was deliberately out of scope, that the weird helper exists because of an incident in March. That tacit map is what lets a senior engineer make a change without breaking the unstated contract.

An agent has none of that. It has the prompt you gave it and whatever it can read from the repository. If the only readable map is stale prose, the agent does the rational thing: it re-derives intent from the code itself. But the code is the territory, not the why — it tells you what happens, never what was supposed to happen. So the agent infers, plausibly and confidently, a justification that may never have been yours. It "fixes" a behaviour that was load-bearing. It satisfies the letter of a paragraph whose spirit died two quarters ago. Multiply that by a fleet of agents running in parallel, each re-guessing the terrain from scratch, and you do not get leverage. You get entropy at machine speed.

This is the failure mode the rest of the series is built to remove. Not by writing better prose — prose is the thing that rots — but by making the map an artifact of the same kind as the code: typed, in the repository, and forced to compile against the territory it describes. A map that cannot silently drift, because the build turns red the day it tries.

The next part names what that map actually models. It is not the business domain. It is something one level up — and it is the heart of the argument.

Part 02: DDD on the Why, Down to the Proof

⬇ Download