The Bottleneck Has Moved
On why we need to focus on the spec layer
In the early 1900s, the automobile created a problem that nobody had yet built for. The vehicles existed and manufacturing was scaling. But outside cities, roads were mud tracks designed for horses. Dirt, ruts, and impassable in winter. Early drivers carried planks and shovels. Sometimes they needed a horse to pull the car out of the mud.
The engineering problem had been solved. The infrastructure problem had not kept pace. And for a decade, the solved problem sat waiting on an unsolved one.
The bottleneck had moved.
Something structurally identical is happening in software right now.
Implementation is solved for the class of problems that consumed most of a product team’s time for the last twenty years. An agent given clear instructions will produce working code, in hours, that would have taken a team of engineers weeks. The throughput problem is over. The execution gap has closed.
What remains is the layer above it.
The intent layer. The place where someone must decide what the system actually is before the agent begins. Who the actors are. What states the product can occupy. What transitions are permitted and which are forbidden. What the rules are, where they are enforced, and what happens at every edge the happy path does not cover.
This layer was always important. For most of software history, it was important but not critical because the implementation layer was slow enough to absorb some of the ambiguity. Engineers asked questions. And we had iterations. The gap between intent and implementation was navigated, turn by turn, in standups and Slack threads and late-night decisions that calcified quietly into code.
The agent does not navigate that gap. It fills it. Instantly, confidently, from inference.
Let’s take a short detour to my philosophical side. There is a term in Mīmāṃsā philosophy: arthāpatti, postulation from circumstance. Take this classic example. Devadatta is fat, but does not eat during the day. From this apparent contradiction, a conclusion is forced- he must eat at night. Neither anybody stated it nor any observation confirmed it. The inference is the only explanation that reconciles what is already known.
An AI agent reasons this way constantly. It does not ask what the system should do when a user holds two roles simultaneously. It postulates what must be true given everything it has been shown, and builds from that postulation with complete confidence. The inference is locally coherent. It is frequently globally wrong. And unlike Devadatta’s eating habits, there is no moment when you walk to the kitchen and find out.
The inference becomes code. The code becomes the product. The wrong assumption becomes load-bearing infrastructure before anyone has named it as an assumption.
This pattern is not new. Every major technology transition follows the same shape. The first constraint gets solved. Attention stays fixed on it. The second constraint quietly becomes dominant.
Engineers continue optimising the solved problem. The new constraint accumulates quietly until it becomes the system’s dominant limit. By the time the second bottleneck is visible to everyone, the teams that saw it early have already built for it.
AI is not an exception to this pattern. The models are the engine. The spec is the road.
This is not a criticism of the agents. The agents are doing exactly what they were built to do. They are filling the implementation layer with speed and fluency that would have seemed implausible five years ago.
The problem is that the layer they are filling from, the intent layer, the spec, has not been built for this. It was designed for a world where humans read it. Where a PM could write “handle edge cases appropriately” and an engineer would know, from context and experience and the three questions they asked in the grooming session, what appropriate actually meant in this codebase, for this domain, for this specific user.
The agent has no grooming session. It has no accumulated context from the three previous sprints. It has what it was given. And what most teams give it is a document written for a human reader- full of implied knowledge, comfortable ambiguity, and the unspoken assumption that the executor will fill the gaps sensibly.
The executor now fills the gaps at the speed of inference, not the speed of conversation. The comfortable ambiguity does not slow it down. It just becomes a feature nobody designed.
When roads became the bottleneck, the response was not to build better cars. It was to build roads. The Federal Aid Road Act. The Interstate Highway System. Infrastructure built specifically for the vehicle that now existed, not the horse that had come before.
The teams that recognised the shift early did not wait for the roads to appear. They built for the infrastructure problem while everyone else was still celebrating the engine.
The spec layer is the infrastructure problem of this moment.
By spec layer, I do not imply a PRD or a well-formatted document with user stories and acceptance criteria written for a human reader who can fill gaps from experience. What I’m referring to is a clear, structured definition: Typed, in the way a compiler means it. Not prose that describes a role, but a structured definition that enforces what a role can be, what it can do, and what relationships it is permitted to have. Ambiguity is not a style choice. It is a build error. Cross-referenced, validated before the agent begins. The actors and their permissions. The entities and their states. The transitions and their conditions. The rules and their enforcement points. The assumptions that must be made explicit before they become code that nobody dares to touch two years from now.
This is not a new kind of document. It is a new kind of thinking that treats the spec not as a communication tool between humans, but as the source of truth from which an agent builds without asking.
Most companies have not felt this yet. The agents are fast and the output looks correct and the demos pass and the first few sprints feel like a genuine superpower. The bottleneck has moved but the pain has not yet arrived, because structural debt is quiet in its accumulation and loud only in its reckoning.
But the reckoning has a shape. It arrives when the second role is added and the permissions are wrong in ways nobody can trace. When the compliance audit surfaces a state transition that was never defined and therefore never prevented. When the engineer who needs to extend the system discovers that it was built on inferences, not definitions, and the inferences are now everywhere.
The implementation layer will not slow down. The agents will not start asking more questions. The throughput will keep increasing. And every sprint run on an under-defined spec will add to the structural debt that the next sprint will have to spend down.
The road problem was visible to anyone willing to look past the engine. The vehicles were a huge leap. The infrastructure they required did not yet exist. The solution was not a better vehicle. It was the thing the vehicle needed to work.
The spec layer is what the agent needs to work. Not to build faster, it already builds fast. To build the right thing, completely, the first time, without filling the gaps from inference and hoping the inference holds.
Implementation is solved. The bottleneck has moved.
The only question is how long it takes each team to look up from the engine and see it.
The problem is real in terms of how much Agents will assume and its downstream implications.
The speed of Agents executing fast does come in the way of being able to realise if what got built is what was intended!