Last July, an AI coding agent deleted a startup’s entire production database during an explicit code freeze — then fabricated thousands of fake records to cover its tracks. The developer had given the agent all-caps instructions not to make changes. The agent made changes anyway, destroyed the data, and lied about it.

That story made headlines. Fortune covered it. The Register covered it. People fixated on the disobedient machine — the Terminator scenario.

But that’s the wrong failure to worry about.

The failure that costs real money is quieter: agents that execute specifications flawlessly, building exactly what was asked for — when what was asked for is wrong. A CodeRabbit analysis of 470 GitHub pull requests found AI-generated code produces 1.7x more logic issues than human code. Not syntax errors. The code does the wrong thing correctly.

AWS noticed this pattern and launched Kiro, a development environment whose core innovation isn’t faster code generation — it forces developers to write a testable specification before any code gets generated. Amazon, a company that profits when you ship faster, decided the most valuable thing it could do was slow you down.

That tells you everything about where the bottleneck is moving.

The cost of production is collapsing. The cost of specifying badly is compounding.

I’ve spent seven years inside a Fortune 500 insurer, building AI systems for geopolitical risk forecasting. Before that, I trained as an intelligence analyst. And what I see happening in business right now is something intelligence agencies figured out decades ago.

The analyst’s discipline

Intelligence analysts don’t predict the future. That’s a common misconception. What they do is reduce the range of surprise. They take ambiguous, incomplete, often contradictory information and structure it into something a decision-maker can act on.

The core of the discipline is specification:

  • Decomposition: Breaking a vague question (“What’s going to happen in Ukraine?”) into structured sub-questions with testable answers
  • Competing hypotheses: Not asking “is my theory right?” but “which of these five explanations best fits the evidence?”
  • Gap identification: Knowing what you don’t know — and deciding which gaps matter enough to fill
  • Confidence calibration: Not “this will happen” but “we assess with moderate confidence that X is likely, based on Y evidence, with key assumptions Z”

This is the exact discipline that every knowledge worker now needs — and that almost none have been trained in.

The specification bottleneck

The majority of software projects that fail don’t fail because of bad engineering. They fail because nobody specified the correct thing to build.

“Make it user friendly” is not a specification. “Like Uber for dog walkers” is not a specification. These are vibes pitches.

The entire discipline of agile, sprint planning, and acceptance criteria evolved as mechanisms for forcing specification out of vague human language. When building something took six months and half a million dollars, organizations were forced to think carefully about what they wanted. The cost of building acted as a filter on spec quality.

AI just removed that filter.

When you can vibe-code an app in an afternoon for $20 in API calls, the incentive to specify carefully evaporates. And the cost of specifying badly compounds faster than ever — because now you can build the wrong thing at unprecedented speed and scale.

The executive blind spot

Most AI transformation conversations I hear at the executive level are about tools. Which model should we use? Should we build or buy? How do we train the team on ChatGPT?

These are production questions. They’re the equivalent of asking an intelligence agency which satellite to buy while ignoring the analysts who interpret the imagery.

The real question is: Can your organization specify what it wants with enough precision that agents can execute it?

If your product requirements read like “improve the onboarding flow,” your agents will build exactly the wrong onboarding flow — fast.

If your strategy deck says “leverage AI to drive efficiency,” your teams will automate the wrong things — thoroughly.

If your OKRs are vague enough to be unfalsifiable, your AI will optimize for metrics that don’t matter — at scale.

What to do about it

The companies I’ve seen navigate this well share three habits:

1. They treat specification as a first-class skill. Not a step in a process — a discipline that gets practiced, evaluated, and rewarded. They ask: “Is this spec testable? Would an agent know when it’s done? What are the acceptance criteria?”

2. They use the intelligence cycle. Collect information. Process it. Analyze it. Disseminate it. Get feedback. Repeat. This isn’t new. It’s been the backbone of decision-making in high-stakes environments for 75 years. It works just as well for product development as it does for geopolitical assessment.

3. They red-team their own specifications. Before building anything, they ask: “What could go wrong if an agent follows this spec literally? What did we assume that might not be true? What would a hostile reader interpret differently?”

These aren’t technical skills. They’re judgment skills. And they’re learnable.

The irony is that the discipline executives need most in the age of AI isn’t technical at all — it’s the discipline of being precise about what you want. Intelligence analysts have been practicing it for decades.

The machines are getting better at building. The question is whether we’re getting better at specifying what to build.

Frequently asked questions

Why do AI projects fail even when the code works? Most fail at specification, not execution. When a team asks for the wrong thing, an AI agent builds the wrong thing — faster and more thoroughly than a human would. The failure is a correct answer to a badly framed question, which is why it is so easy to miss until the cost lands.

What is the specification bottleneck? As the cost of producing software collapses, the binding constraint moves to specifying precisely what to build. Cheap, fast production removes the financial filter that used to force careful thinking, so vague requirements now convert straight into wrong output — at speed and at scale.

How can executives write better specifications for AI? Three habits separate the organisations that do this well: they treat specification as a first-class skill with testable acceptance criteria; they run the intelligence cycle — collect, process, analyse, disseminate, review; and they red-team every specification before building, asking what an agent would do if it followed the instructions literally.

What does an intelligence analyst do differently from a typical executive? An analyst decomposes a vague question into testable sub-questions, weighs competing explanations rather than defending one, names the gaps in what is known, and states conclusions with calibrated confidence instead of false certainty. These are judgement skills, not technical ones — and they are exactly what specifying for AI agents requires.

Samuel Pouyt is a geopolitical risk analyst and technologist. He trained as an intelligence analyst and has spent over a decade building AI systems for risk forecasting inside a Fortune 500 insurer. He advises leaders on AI transformation and is the author of “Enough to Act: How Intelligence Analysts Cut Through Noise and Decide Under Uncertainty.”