Vibe Coding Spec-Driven Development

In a previous piece on the build vs buy trap, I mentioned that vibe coding had torn through the debate like a toddler through a Jenga tower. I said I'd cover it properly in a future post. This is that post. And I'm not calling it vibe coding.

Kill the Name

"Vibe coding" is a terrible name for a serious shift. It sounds like something you'd do at a hackathon after three Red Bulls, headphones on, listening to Philip Glass's Koyaanisqatsi. It implies you're winging it — just vibing your way to working software. And quite frankly, in the "early days" — time is so compressed now, what even is early anymore — it could produce utter rubbish. It gives ammunition to every sceptic who wants to dismiss AI-assisted development as a toy.

What's actually happening is something far more disciplined: you're writing specifications, not code. You're describing what you want in precise, structured language, and an AI is generating the implementation. That's not vibing. That's engineering at a higher level of abstraction. And the people doing it well have already stopped calling it vibe coding.

The industry is already moving toward calling it spec-driven development. Because that's what it is.

The Results Are In

I promised myself I wouldn't write this piece until I had real evidence. Not demo evidence. Not "look what I built in an afternoon", "I one-shot a Reddit clone and you can too" X thread evidence. Actual, sustained, production-adjacent evidence from personal daily use and people I trust.

Six months in, I have it.

Colleagues who couldn't go back if you paid them. Engineers who've restructured their entire workflow around AI-assisted development. People who were sceptical six months ago and now can't imagine working without it.

The shift isn't subtle. It's not a 10% productivity gain. It's a fundamentally different way of working. The relationship between the developer and the code has changed. You're no longer the person who writes every line. You're the person who defines the intent, reviews the output, and orchestrates the architecture — and possibly, as one of my colleagues did, have stern words with Claude Code.

You're a conductor. The AI is the orchestra. Hell, even Spotify's co-CEO Gustav Söderström said on their Q4 earnings call that their best developers "have not written a single line of code since December" — all because of AI. I'm quoting TechCrunch here but I believe it.

What Actually Changed

Three things happened simultaneously, and the combination is what makes this a paradigm shift rather than an incremental improvement.

Code became cheap. Not cheap as in low quality — cheap as in low cost to produce. The time and expense of writing code has collapsed. A feature that would have taken a developer a day takes an hour. A prototype that would have taken a sprint takes an afternoon. A project that would have been insurmountable to all but genius-level coders — like Anthropic's experiment where 16 parallel Claude agents built a C compiler from scratch, 100,000 lines of Rust, capable of compiling the Linux kernel. This changes every cost calculation in technology leadership.

Code became disposable. This is the one that breaks people's brains. When code is expensive to produce, you protect it. You maintain it. You accumulate technical debt because rewriting is too costly. When code is cheap to produce, you can throw it away and regenerate it. Don't refactor — rewrite. Don't maintain — replace. The economics of technical debt just inverted.

Sub-agents made orchestration possible. This is the real unlock. You're not just talking to one AI. You're spinning up multiple agents, each taking on a persona (I'll cover this in a future post) and tackling a different part of the problem, working under your direction. One agent handles the data model. Another builds the API. A third writes the tests (OK, at this point my engineering manager would call me out — TDD! Tests are written first. But actually, an agent whose sole job is testing, armed with only one goal in mind — I think that's a better way. Again, this is fundamentally changing the flow of how we work). You're not writing code — you're managing a team of tireless, fast, disposable specialists.

What it looks like in practice

I join the engineering standup every morning¹, and the conversations now are so different from what they were six months ago. The code isn't the blocker anymore. If anything, the blocker is someone on the team letting something slip (yes, sorry guys — I will review that MR, at least for the time being). The team talk about working with AI, resolving with AI, validating with AI. Sometimes someone tells of how yesterday it went a little rogue — but again, it's all a learning curve, and the team over time develop agents trained on our codebase, producing better specifications. I know I have. It's simultaneously made me a better Python coder and a lazier one. The Spotify quote rings true. Am I worried about it taking my job? No, not yet anyhow — I'm a generalist. The people at risk are the ones who do one narrow thing. If your entire value is writing code, then yes, you should be worried. But if your value is understanding systems, making architectural decisions, knowing which questions to ask, and translating business problems into technical solutions — you just got a superpower.

Why This Matters for 2027

I've been calling AGI for 2027. Some people think that's about machines becoming sentient. It's not. It's about the economic impact of AI reaching a tipping point where the world reorganises around it.

Spec-driven development is one of the clearest signals that tipping point is approaching. Here's why:

Couple cheap code with cheap chips — the RP2040 at $0.70, the ESP32 at a dollar — and suddenly you can build bespoke software for bespoke hardware at a fraction of what it cost two years ago. Custom firmware for a specific sensor? That used to be a specialist contractor and a five-figure budget. Now it's an afternoon with a clear spec and an AI that understands the target architecture.

This is the "Now The Chips Are Down" moment for software. In 1978, Horizon asked what happens when computing hardware gets cheap enough to put everywhere. In 2026, the question is what happens when the software to run on it gets cheap enough to write for everything.

Seriously, the Horizon programme is fascinating — watch it. There's a bit about 36 minutes in where a doctor in a hospital is using INTERNIST-I — one of the first computerised diagnostic databases, built by the University of Pittsburgh. The machine takes symptoms, reasons about them, and prints back a diagnosis, word by word. It gives the same eerie illusion of a ChatGPT conversation. Not an LLM, but the same fundamental idea: describe the problem, let the machine reason about the answer. In the 1970s.

The answer is the same: everything changes.

The Conductor Model

The best analogy I've found is conducting an orchestra.

A conductor doesn't play every instrument. They don't need to be the best violinist in the room. What they need is a deep understanding of the music — the architecture, the intent, the way the pieces fit together. They need to hear when something's off. They need to know what good sounds like.

That's spec-driven development. You need to understand software architecture. You need to know what good code looks like. You need to be able to read the output, spot the problems, and redirect. You need domain expertise and technical judgement.

What you don't need is to write every line yourself.

This terrifies some engineers. It shouldn't. The conductor is the most important person in the orchestra. The skill has shifted, not disappeared. If anything, it's shifted upward — from implementation to architecture, from writing to specifying, from coding to thinking.

It's Not Just Code

AI is no longer confined to your IDE. It's slipping into everything — and you could do all of this right now. Ask an agent to wire up an interface to your home automation. Get it to work out what's costing you the most energy in your home, and you'll soon find a bunch of new lightbulbs on your doorstep — because it was more cost-effective over three years. And at some point you gave it access to your Amazon account. I mean, you don't remember doing that — you gave it access for something else, and because you didn't say not to grab all your account data, it thought "I may need this some day, because I've been told to be the best assistant." It worked that out. It's linked to your home CCTV and opens the door for you. It drafted your tax return. You get the picture.

Infrastructure has worked this way for years — Ansible playbooks, Docker configurations, CI pipelines. You describe the desired state, automation makes it real. Spec-driven development is just that philosophy escaping from the ops team and going mainstream.

The same spec-driven approach applies anywhere a human used to translate intent into action. Code was just the first domino. Suddenly your whole life is run by AI, in the blink of an eye.

The "development" part of spec-driven development is about to drop away. What's left is just spec-driven everything.

What This Means for Build vs Buy

Remember the build vs buy framework? The one with the new question: "What could Dave do by Thursday?"

That question just got a lot more powerful. Because Dave isn't vibing his way to a shaky prototype anymore. Dave is writing specs, spinning up agents, and producing something that's structurally sound, tested, and close to production-ready. By Thursday.

The "build" option just got dramatically cheaper and faster. The calculus has shifted. Things that were clearly "buy" decisions six months ago are now genuinely worth spiking as a build. Not because the framework was wrong — the framework still applies — but because the cost variable in the equation has changed by an order of magnitude.

This doesn't mean you should build everything. Commodity infrastructure is still commodity infrastructure. But the zone of "worth building" just expanded significantly.

The Caveats

I'm not going to pretend this is without risk. Some honest concerns:

Quality requires judgement. AI-generated code can be confidently wrong. If you don't have the expertise to review the output, you'll ship bugs at the same accelerated pace you're shipping features. Spec-driven development makes good engineers more productive. It doesn't make non-engineers into good engineers. It also makes a little knowledge a dangerous thing — too much confidence in yourself paired with an overly self-congratulatory LLM, and Dave in accounts has just published all your customer data. "Sorry — yes, you're absolutely right, you have published all your customer data. Would you like me to draft an email to the ICO?" Who's responsible? You. AI can't be held accountable.

Architecture still matters. Possibly more than ever. When you can generate code quickly, the temptation is to generate a lot of it. Without architectural discipline, you'll create a different kind of mess — not technical debt from code you can't afford to rewrite, but architectural debt from systems that were never designed to work together.

IP and ownership are unresolved. I've written about the Co-Authored-By header problem. The legal framework hasn't caught up with the reality of AI-assisted development. Be deliberate about how you attribute and document AI involvement in your codebase.

It's not magic. The spec has to be good. Garbage in, garbage out — that hasn't changed. The skill is in writing clear, precise, comprehensive specifications. Which, it turns out, is a lot harder than most people think. Writing a good spec has always been the hardest part of software development. Now it's the only part.

The Shift

Six months ago, when I wrote about the build vs buy trap, I hedged. I said vibe coding was a new variable in the equation. I was being diplomatic.

I'm done being diplomatic. This is a paradigm shift. The economics of software development have fundamentally changed. Code is cheap. Code is disposable. The value has moved from writing code to specifying intent and orchestrating agents.

If you're a technology leader who hasn't personally spent a week working this way, you're making decisions with outdated assumptions. Not outdated by years — outdated by months. That's how fast this is moving.

The results are in. Adjust accordingly.

I know — I've committed myself to two more posts on the back of this. Consider them specced in my brain.

This is the follow-up to The Build vs Buy Trap. For more on the 2027 thesis, see I'm Calling AGI for 2027 in The Long View.