Spec-driven development

Spec-driven development means writing down exactly what you are building before any code gets written: the problem, what is in and out of scope, a testable user story, every state the feature can be in (not just the happy path), the data model, and the surfaces it touches. The spec is the contract; the build follows it. Spec first, build second, prove it works third.

This matters far more in the AI era than it used to. An AI agent will happily build whatever you describe, so a vague request gets you a vague, half-right result, and the more capable the model the faster it runs in the wrong direction. A tight spec is the highest-leverage thing a founder can produce: it turns your thinking into something the model can execute correctly the first time, and it forces you to confront the hard cases (empty states, errors, the unhappy path) up front, where they are cheap, instead of discovering them in production.

In practice this is a habit you can build into your normal tools. Say you're scoping a new feature in Linear: you write the spec as the issue description before you hand it to an engineer or an agent, so the ticket itself is the contract rather than a one-line title. Say you're drafting the spec longer-form in Notion: you keep a reusable spec template with the user story and state matrix as headings, so you can never skip the awkward bits. And when you hand that finished spec to a build agent like Claude, the quality of what comes back is set almost entirely by how clear the spec was going in, garbage spec, garbage build.