If you read one line: Vibe code the things you're willing to throw away; spec-drive the things you'll have to live with. The dividing line isn't taste — it's blast radius. The moment code touches a customer, a login, a payment, or a second maintainer, the fastest way to build it stops being the cheapest way to own it.

The $130M Series C that a vibe-coding platform just raised settled one argument and started another. Argument settled: describing software in plain language and letting an agent write it is now a real, funded, mainstream way to build. Argument started: when should you actually do it? Because the same founders praising a Tuesday-afternoon prototype are, three months later, staring at a 2,000-line file that neither they nor the model that wrote it can change without breaking something.

The two modes, honestly described#

Vibe coding is the loop you already know: you type an idea, the agent produces code, you run it, you describe what's wrong, it patches. The source of truth is the running code. Its superpower is time-to-first-working-thing — minutes, not hours. Its failure mode is that intent lives nowhere durable. It's in a chat you'll close, distributed across forty prompts, never written down. When you come back in a month, the why is gone; only the what remains, and the what is a wall of code.

Spec-driven development flips the order. You write the specification first — what the feature does, the constraints it must respect, the acceptance criteria that define "done" — and the agent generates code from that spec. The spec is the source of truth; the code is a downstream artifact. GitHub's open-source Spec Kit made the canonical version of this concrete, externalizing it into four steps you run as explicit commands: specify → plan → tasks → implement (Spec Kit docs). Requirements go in spec.md, the tech-stack plan in plan.md, the work breakdown in tasks.md, and only then does code get written. (Our walkthrough of that exact workflow has the commands.)

The tell that this is a real category and not a rebranded prompt: there are now three distinct production toolchains, and they disagree about how much spec you need. Spec Kit externalizes the workflow into files and commands. AWS Kiro bakes it into an IDE, generating EARS-notation requirements with requirement-to-task traceability. Tessl takes it furthest — spec-as-source, where the code is fully regenerable and you never hand-edit it, backed by Snyk founder Guy Podjarny and $125M. We line them up in Spec Kit vs Kiro vs Tessl.

The decision is about blast radius, not ideology#

Don't pick a religion. Pick per piece of work, and the variable is simple: how much does it cost to be wrong here?

If deleting it tomorrow would cost you nothing, vibe code it. If a stranger will maintain it, a customer will touch it, or it can move money — spec it.

Vibe code: prototypes you're building to learn something, spikes to de-risk a technical unknown, throwaway internal tools, demos, the fortieth iteration of a landing page. Anything where the value is the answer to a question, not the code itself. Speed is the entire point, and structure is pure tax.

Spec-drive: anything that survives contact with a customer. Auth flows. Payment logic. Anything that reads or writes user data. Any feature a second person — a contractor, a first hire, future-you-in-Q4 — will have to modify. The spec is what lets them change it without archaeology. This is the same lesson as our maintenance-and-security checklist for vibe-coded apps, pushed one step earlier: the cheapest time to write down what the code is supposed to do is before the code exists, not during the incident.

The trap isn't choosing wrong on any single feature. It's never switching modes — letting the Tuesday prototype slide into production because it "already works," and discovering in the next fundraise's due diligence that the only documentation of your core system is a deleted conversation.

What this changes for how you work this week#

Stop treating "AI coding" as one activity. It's two, and you should name which one you're doing before you start. A useful default for a solo founder: vibe to validate, spec to scale. Prototype fast and loose to find out whether the thing is worth building at all. The moment the answer is yes and real users are coming, stop, write the spec against the prototype you just proved out, and regenerate it properly.

The 2026 tooling is what makes that handoff cheap enough to actually do. Spec Kit is free and MIT-licensed and drops into Claude Code, Copilot, Cursor, and 30-plus other agents; you can adopt the spec discipline without adopting a platform. There's no longer a speed-versus-structure tradeoff to agonize over. There's just a question you answer one feature at a time: am I building to learn, or building to keep?