90% of Claude Code was written by Claude Code itself. Three engineers at StrongDM built what would have required a 10-person team eighteen months ago. Cursor generates $16 million in revenue per employee.
The cost of producing software is collapsing toward zero. And yet — Google’s DORA report tracked a 9% climb in bug rates correlated with a 90% increase in AI adoption, alongside a 91% increase in code review time. The code ships faster, but it’s more often wrong, and it’s harder to catch.
AWS saw this pattern and built Kiro. Its core innovation isn’t faster code generation. It forces developers to write testable specifications before any code gets generated.
Amazon — a company that profits when you ship faster — decided the most valuable thing it could do was make you slow down and define what you want.
This is the specification bottleneck. And it’s not just a software problem. It’s an everything problem.
Your AI strategy is failing because production got cheap and specification didn’t. When the cost of building collapses, the binding constraint moves to defining precisely what to build — and most organizations have invested in tools while leaving that skill untrained.
The filter that disappeared
When building a product took six months and $500,000, organizations were forced to think carefully about what they wanted. The cost of building acted as a quality filter on specifications. Bad specs were expensive enough that people learned to write better ones — or they went out of business.
AI removed that filter.
A vibe-coded app can take an afternoon and $20 in API calls. If the spec is wrong, you didn’t save six months. You wasted an afternoon — and possibly launched something that harms customers, because the specification was never right.
The incentive to specify carefully just evaporated. But the cost of specifying badly is compounding faster than ever, because you can now build the wrong thing at unprecedented speed and scale.
This isn’t just about code
Every knowledge worker is hitting this same wall:
- The marketing team that prompts an AI to “write better ad copy” gets copy that sounds good but doesn’t convert — because nobody specified what “better” means, for whom, against which alternative
- The strategy consultant who asks AI to “analyze the competitive landscape” gets a plausible-sounding report that misses the only three things that actually matter — because the analysis wasn’t structured against testable hypotheses
- The product manager who writes “improve the onboarding flow” gets a redesigned flow that optimizes for the wrong metric — because the acceptance criteria were never defined
In each case, the AI executed flawlessly. The specification failed.
Two classes of knowledge worker
What I’m observing — inside a Fortune 500 company and across the broader market — is a bifurcation:
Class 1: High-value specifiers. They define precisely what needs to happen, architect the system, manage agent workflows, and evaluate whether the output matches the intent. They hold the entire problem in their heads — what it should do, who it serves, why the trade-offs are correct. One of them, with the right agent infrastructure, produces what a 20-person team produced two years ago. They command extraordinary pricing power.
Class 2: Production-mode workers. They do the same work they’ve always done, slightly faster, with AI assistance. They’re being commoditized. Entry-level job postings are down by two-thirds. New graduates represent 7% of hires — a historic low. 70% of hiring managers say AI can do the work of interns.
The gap between these two classes is widening every quarter, because agents force-multiply excellent specification. A 10x better spec doesn’t produce 10x better output — it produces 100x better output, because the agents execute it across every function simultaneously.
What makes a good specification
After years of building AI systems and studying intelligence analysis tradecraft, I’ve found that good specifications share five properties:
-
Testable. You can determine whether the spec was met or not. “Make it better” fails this test. “Reduce first-response time to under 2 minutes for priority-1 tickets” passes.
-
Decomposed. The vague goal is broken into concrete sub-tasks, each independently verifiable. Not “improve customer experience” but: “reduce checkout steps from 5 to 3,” “add progress indicator,” “show estimated delivery before payment.”
-
Bounded. The spec states what’s out of scope. Agents are literal. If you don’t exclude something, they’ll include it — and then you’ll spend time unwinding work you never wanted.
-
Assumption-explicit. Every spec relies on assumptions. Good specs surface them: “We assume the user has already authenticated. We assume the API returns within 200ms. We assume the data is clean.” When assumptions fail, you know where to look.
-
Escalation-aware. The spec defines what to do when uncertainty is too high: “If the customer’s intent is ambiguous, escalate to a human. Don’t guess.”
Intelligence analysts call this structured analytical technique. Product managers call it acceptance criteria. The name doesn’t matter. The discipline is the same — and it’s the single most valuable skill in the specification economy.
The organizational challenge
Individual specification skill isn’t enough. Organizations need specification culture:
- Playbooks over documents. A document requires someone to produce it quarterly. A playbook is a living, testable specification that humans and agents both follow and improve.
- Measurable outputs. If your team’s work can’t be evaluated against structured criteria, it can’t be improved or automated. The eye-rolling about OKRs was an early preview. Now we actually have to do it.
- Red-teaming specs. Before building anything, ask: what happens if an agent follows this literally? What assumption might be wrong? What would a hostile reader interpret differently?
The companies that figure this out are already operating at 10-20x the output of companies that haven’t. And the gap is accelerating.
The specification bottleneck is the most important constraint in business right now. And almost nobody is talking about it.
Frequently asked questions
What is the specification bottleneck? It’s the shift in where value gets created once AI makes production nearly free. When building software took six months and half a million dollars, the cost of building filtered out bad ideas; now that you can build in an afternoon for $20, the binding constraint becomes specifying precisely what to build. Vague requirements convert straight into wrong output, at speed and scale.
Why is my AI strategy not delivering results? Most AI strategies invest in tools — which model, build or buy, how to train the team — when the real gap is specification skill. If your requirements read like “improve onboarding” or “analyze the competitive landscape,” agents execute them flawlessly and build the wrong thing. The fix is treating specification as a first-class, testable discipline, not a model upgrade.
What makes a good specification for AI agents? Good specifications share five properties: testable (you can tell whether it was met), decomposed (broken into independently verifiable sub-tasks), bounded (states what’s out of scope), assumption-explicit (surfaces what it relies on), and escalation-aware (defines what to do when uncertainty is too high). Intelligence analysts call this structured analytical technique; product managers call it acceptance criteria.
Why are some workers becoming more valuable while others are commoditized? The market is bifurcating into high-value specifiers — who define what needs to happen, architect the system, and evaluate the output — and production-mode workers doing the same tasks slightly faster with AI assistance. Agents force-multiply excellent specification, so a 10x better spec produces far more than 10x the output, widening the gap between the two classes every quarter.
Samuel Pouyt is a geopolitical risk analyst and technologist. He writes about specification, judgment, and decision-making in the age of AI.