Everyone was sold the same promise: AI is the button that ships software faster. Press it, and the slow, expensive part — writing the code — gets cheap.

Half of that is true. The other half is where teams are quietly getting hurt.

Because when you remove the old bottleneck, you don't remove the bottleneck. You move it. And it has moved somewhere far less comfortable: to judgement.

The old bottleneck is gone

For years, execution was the expensive part. Turning a clear idea into working software took skilled people a lot of time, so that's where the cost, the planning, and the caution went.

AI collapsed that cost. Not to zero, and not without supervision — but enough that "how fast can we build it" is no longer the question that decides whether a project succeeds.

That should be good news. It is, if you notice what changed underneath.

The bottleneck moved to judgement

Once execution is cheap, the quality of what you build is decided almost entirely upstream — in the thinking, not the typing. There are four places where judgement now makes or breaks the outcome:

  • The foundation. If your data and architecture are wrong, AI doesn't fix them — it amplifies them, faster. A weak base used to fail slowly. Now it fails at scale.
  • The jump from proof-of-concept to production. A demo that works is not a system that works. Getting from "it ran once" to "it runs for real clients, every day" is the unglamorous majority of the work — and it still needs people who understand the whole picture.
  • Defining the product. The hardest question was never "can we build it." It's "should we, and what exactly — and what do we deliberately leave out." Knowing what not to build is now more valuable than knowing how to build it.
  • Cost, benefit, and ROI. To judge whether something is worth doing, you now have to hold business, technology, data, and AI in your head at the same time. AI didn't reduce the number of variables you need to understand. It increased it.

That's the part people miss. AI is a tool unlike the others — to use it well, you have to understand more perspectives, not fewer.

Amplification cuts both ways

Here's the trap. If you treat AI as pure speed and skip the specification work, you don't save time. You scale your mistakes. A badly framed problem, solved fast, is just a bigger badly framed problem — delivered sooner, with more confidence, and harder to unwind.

We learned this the hard way.

Early on, we had a project where we simply ran after what the client asked for. Every new request, we chased. No anchoring spec, no shared definition of "done" — just motion. It turned into a never-ending change spiral. Exhausting for everyone, and the thing we were building kept moving because we'd never pinned down what it actually needed to be.

That project taught us how not to build. Not by blaming the client — by realising we had skipped the one step that prevents the spiral: specifying the problem before racing at the solution.

How we work now

So we flipped it. At apeirum we now spend most of our time specifying — understanding the real problem, the constraints, the definition of done — and then apply AI to make the execution efficient. It's how we built Mola, our analytics product for dental clinics: the specification did the heavy lifting, and AI made the build cheap.

The counterintuitive part: the efficiency gain doesn't just make us faster. It buys us room. Because building is cheaper, we can spend more of our attention on the problem statement — and that's exactly where more meaningful solutions come from. We go slower where it counts, and end up faster overall.

And this is the part the headline promised: specification isn't just the new bottleneck, it's the new moat. Anyone can generate code now. What's hard to copy is the judgement to define the right thing — so that's where the durable advantage sits. The winners in this shift won't be the fastest typers. They'll be the sharpest specifiers.

If you're weighing an AI build and want the specification right before the code starts moving, that's exactly how we work.

FAQ

Does AI replace developers?

No. It moves the value. The expensive part is no longer writing code — it's the judgement to specify the right thing, design a sound foundation, and take a system from demo to production. Those still need experienced people.

Why not just use AI to ship faster?

Because amplification cuts both ways. AI speeds up whatever you feed it — including badly framed problems and weak architecture. Without a clear specification, you don't save time, you scale your mistakes faster.

What does spec-first development actually look like?

It means investing most of the effort upfront in understanding the real problem, the constraints, and a shared definition of "done" — before writing production code. Execution then becomes fast because the target stops moving.

Isn't specifying first slower?

Slower in the one place it should be, faster everywhere else. Time spent getting the problem right prevents the endless change spirals that quietly consume most of a project's budget.