The Spec Is the Product

The cost of building just dropped by an order of magnitude. Everyone is talking about that. Almost nobody is talking about what it actually demands of us.

This is the first in a series about the skills that matter now. Not developer skills. Human skills. The ones that determine whether AI makes us more capable or just more productive at building the wrong thing.

We start with the most important one: specification. The ability to describe what you want clearly enough that something which cannot read your mind will build it correctly. Everything else depends on it.

The Most Expensive Confusion

A CodeRabbit analysis of 470 GitHub pull requests found that AI-generated code produces 1.7 times more logic issues than human-written code. Not syntax errors. Not formatting problems. The code does the wrong thing correctly. It builds exactly what was asked for, and what was asked for is wrong.

This is not an AI problem. This is a specification problem. And it is the most expensive confusion in the industry right now, because the cost of building dropped to nearly nothing while the cost of building the wrong thing stayed exactly where it was.

When execution was expensive, bad specs were survivable. The slow, iterative process of building software created natural checkpoints. You would describe something vaguely, a developer would interpret it, build a piece of it, show it to you, and you would say “no, not like that, like this.” The cost of that back-and-forth was hidden inside the cost of execution. Nobody noticed because nobody measured it separately.

AI removed the back-and-forth. It takes the spec and runs. It does not stop to ask if this is what you really meant. It does not notice that your spec contradicts itself in paragraph three. It builds, confidently and quickly, exactly what you described. And if what you described was wrong, you now have a beautifully engineered monument to your own ambiguity.

There is a hard ceiling that makes this concrete. Research suggests that frontier language models reliably follow about 150 to 200 instructions before adherence degrades. That is not many. A typical project brief, combined with system context and tool configurations, can easily exceed that budget. When it does, the model starts skipping the steps that matter most: the collaborative ones, the clarifying questions, the parts that would have caught the misalignment early. The specification does not just need to be clear. It needs to be concise enough to fit inside the attention budget of the system executing it.

The Tacit Knowledge Trap

Here is why this is so hard. Most of us do not actually know what we want until we see what we do not want.

For decades, organizations ran on tacit knowledge: the unwritten understanding of what “good” looks like that lives in the heads of experienced people. The senior product manager who looks at a spec and says “this won’t work” without being able to fully articulate why. The engineering lead who rejects an architecture because it “doesn’t feel right.” The designer who knows the layout is off before they can name the principle it violates.

This knowledge is real. It is valuable. And it is completely invisible to AI.

AI forces tacit knowledge into explicit standards. That is the shift, and it is genuinely painful, because most organizations have never had to articulate what they actually mean by “good.” They relied on experienced people to carry that understanding implicitly. Now the experienced people need to externalize it, turn instinct into language, turn “I know it when I see it” into something concrete enough to specify, test, and verify.

This is not a technical challenge. It is a thinking challenge. And it applies to everyone, not just developers.

This Is Not a Developer Skill

A product manager describing a feature to an AI agent needs the same skill as a developer writing a specification file. A marketing director briefing an AI content tool needs it. A founder explaining their vision to a team of AI-assisted builders needs it. An operations lead defining a workflow for an automated system needs it.

The skill is the same everywhere: can you describe the outcome you want clearly enough, completely enough, and precisely enough that something which cannot read your mind will produce it?

Most of us are worse at this than we think. We have spent careers in environments where the humans around us filled in the gaps. A colleague who understood the context. A team that shared tacit assumptions. A culture that carried unspoken standards. AI has none of that. It has exactly what you gave it, and it will execute on exactly that, no more and no less.

Microsoft tracked 300,000 employees using AI tools. Excitement peaked in the first three weeks. Then most people quietly stopped using them. The survivors were not the most technical. They were the ones who learned to articulate what they wanted with enough precision that the tool could actually deliver it.

The 80% who gave up were not lacking intelligence. They were lacking a skill nobody had ever asked them to develop: converting the thing in their head into a specification clear enough for a machine that takes everything literally.

The Good News

Specification is a learnable skill, and it improves faster than most people expect. The best specification, it turns out, is not the most detailed one. It is the one that leaves no room for the wrong interpretation.

Five things to remember:

1. Describe done first. Three sentences. Not the process. The outcome. If you cannot describe done, you are not ready to start.
2. Name your constraints. Every unstated assumption is a gap the machine will fill with its own judgment. Which is often plausible and wrong.
3. Specify what you do not want. “Do not reorganize the existing code” saves more time than most positive instructions. Humans infer boundaries. AI does not.
4. Test on a human first. If someone with no context cannot understand your spec without asking questions, it is not ready for AI.
5. Fix the spec, not the output. Every failed output is a mirror showing you what your specification was missing.

But the deeper shift is not a technique. It is a habit of mind: learning to notice the gap between what you meant and what you said. One team at HumanLayer developed what they call a “design discussion” artifact: a 200-line document where the AI externalizes everything it thinks you want, asks questions about things it does not know, and surfaces its assumptions before writing a single line of code. It is, in effect, brain surgery on the agent’s understanding before you let it proceed. The document is not code. It is alignment. And it catches bad decisions on a 200-line doc instead of discovering them after 1,000 lines of implementation.

That gap between what we meant and what we said has always existed. It just never mattered this much, because humans filled it in for us.

The Specification Economy

Here is the broader pattern. In the old economy, execution was the bottleneck and specification was free. Anyone could have an idea. The hard part was building it. In the new economy, execution is approaching free and specification is the bottleneck. Anyone can build. The hard part is knowing what to build, and describing it precisely enough that the building produces what you actually wanted.

This is why the job market is splitting into a K shape. The roles that rise are the ones that involve knowing what to build: product thinking, architectural judgment, problem framing, quality standards. The roles under the most pressure are the ones defined entirely by executing someone else’s specification. Not because the people in those roles lack talent, but because the economics of execution changed under them.

The skill that bridges the gap is specification. It is not glamorous. It will never trend on LinkedIn. But it is the single highest-leverage capability a person can develop right now, because it is the translation layer between human intent and machine execution. Get it right and AI multiplies everything you know. Get it wrong and AI is a very fast way to arrive at the wrong destination.

The tools are ready. The question is whether we can describe, with enough clarity and precision, what we actually want them to build.

This is the first in “The Hitchhiker’s Guide to the K-Shaped Economy,” a series on the human skills that matter most in the age of AI. Next: “The Taste Gap,” on judgment, evaluation, and knowing whether the output is actually good.