Specification is the Bottleneck Now

Coding agents write the code. Engineering agents run the pipeline. The implementation bit — the part we used to pay senior engineers six figures to do — is mostly solved. And yet the software still doesn’t build itself. Because knowing what to build, with what, how it should work, and how it should be used is its own discipline. Agents didn’t kill specification. They exposed it as the real bottleneck.


An engineer staring at a glowing blueprint of a custom system while code assembles itself in the background

The Part That Didn’t Go Away

Everyone is hypnotized by demo videos. “Describe an app, watch it build.” And yes — if the app is a to-do list, a CRUD dashboard, or a landing page, the agent nails it in minutes. Because the agent has seen ten million of them. The implementation is templated. The choices are obvious. The specification writes itself.

That is not most real software.

Real software is built for a specific team with specific constraints serving specific users under specific assumptions that nobody has written down. The moment you veer off the well-trodden path, the agent’s confidence plummets — not because it can’t code, but because it has no idea what you actually want.

Implementation is cheap. Intent is expensive.


What “Specification” Actually Means

People hear “spec” and imagine a Word document with numbered requirements. That’s not the bottleneck. The bottleneck is the set of decisions that precede any useful code:

  • WHAT to build. The shape of the thing. Its boundaries. What’s in. What’s out.
  • WITH WHAT. The stack. The data model. The third-party services. The constraints you’re willing to inherit.
  • HOW it should work. The flows. The failure modes. The edge cases. The defaults.
  • HOW it should be used. The user. The ritual. The moment of truth. The thing they’ll actually press.

None of these are implementation. All of them are prerequisites to implementation. An agent that writes perfect code against a vague spec produces perfect code for the wrong system.


The Replication Ceiling

Here’s the rule that’s become obvious after building with agents every day:

It’s trivial to replicate things that already exist. The more unique, different, or custom the solution, the more must be specified to build it.

Ask an agent for “a Twitter clone” and it ships. Ask for “a Twitter clone but optimized for async engineering teams where every post is a typed work atom with deadline semantics and a ledger of side effects” and you’re back to being an engineer — not a typing engineer, a thinking engineer.

The replication ceiling is the cheapest software there is. Below the ceiling, agents are magic. Above it, the work is all specification. Every unique decision is a sentence someone has to write.

Infographic: Replication Ceiling — below the line agents generate software for free, above the line each unique decision is a specification tax the human must pay


Why Agents Amplify the Problem

Before agents, bad specs were tolerated because implementation was so slow you had time to figure it out mid-build. Every PR was a forcing function. Every demo surfaced a misunderstanding. The glacial pace was a safety net.

Agents removed the safety net.

Now a vague spec produces a finished product in an afternoon — and the afternoon you saved gets spent arguing about whether that product is the right one. The cost of building the wrong thing crashed to near zero. The cost of deciding what the right thing is didn’t move at all.

The bottleneck didn’t shift because agents failed. It shifted because agents succeeded so completely that everything else around them is now the slow part.


Specification is the Work Now

The engineer of 2026 isn’t someone who types code faster. It’s someone who can compress a fuzzy ambition into a crisp, executable specification — complete enough that an agent can’t misinterpret it, tight enough that the agent doesn’t wander, opinionated enough that the output is this thing and not some other thing.

That skill has a new name depending on who you ask: prompt engineering, product engineering, AI-native PM, solution architecture. They all collapse into the same practice:

  • Seeing the system clearly before it exists.
  • Naming the constraints that matter.
  • Choosing the stack with intent.
  • Writing down the flows, the defaults, the failure modes, the user’s actual ritual.
  • Handing the agent a spec tight enough to execute.

Typing code was never the scarce resource. Deciding what code should exist always was. We just never noticed because typing was slow enough to hide it.


Agents solved implementation. That’s real, and it’s permanent. But the specification problem is alive and well — and for anything more ambitious than a template, it’s the only problem that matters. Get good at specification. That’s the job now.