Spec-Driven Development: 7 Habits Serious Vibe Coders Use
Short answer
Short answer: Spec-driven development means writing a clear specification before you prompt an AI coding platform, then treating that spec not the chat history - as the source of truth for what gets built, reviewed, and shipped. It isn't a rejection of vibe coding; it's the discipline layer serious teams are adding to it in 2026, backed by real tooling from GitHub, AWS, and well-funded startups like Tessl. Below are the 7 concrete habits behind it, in order of how a spec actually moves from idea to shipped code. In our own workflow at Greta.sh: we define the requirements upfront and use them as the reference point throughout the build instead of relying on a long chain of prompts to explain what we're building.
"Spec-driven development" sounds like a rebrand of something engineers have always done and in a sense, it is. What's new in 2026 is that the biggest names in AI coding have started shipping actual tooling for it: GitHub open-sourcedSpec Kit in September 2025, AWS launched a whole IDE called Kiro built around it in July 2025, and Tessl — founded by Snyk's Guy Podjarny raised $125 million on the bet that specs, not code, will become software's real source of truth. None of this is about typing more carefully. It's a specific, repeatable set of habits. Here are seven of them.
1. They write the spec before they touch the prompt box
The instinct in ordinary vibe coding is to describe what you want directly to the AI and see what comes back. GitHub's own explanation of why it built Spec Kit is blunt about why that instinct fails at any real scale: AI coding agents "are exceptional at pattern completion, but not at mind reading." A spec is what closes that gap - a written contract for how the software should behave that the AI works from, rather than working from a single, underspecified sentence. If you don't already have a lightweight way to do this,our PRD templates for AI app builders is a faster starting point than a blank page.
2. They commit a "constitution" before the first feature spec
Teams doing this seriously don't start with a feature spec - they start with a project-wide rules file (often literally named AGENTS.md or constitution.md) that locks in language choice, frameworks, testing conventions, and dependency rules once, so every later spec inherits them instead of re-litigating them. It's a small habit that prevents a very common failure mode in longer vibe-coding projects: one screen built in one style, the next in another, because nothing was ever written down. Our ownchecklist for scalable vibe coding projects covers the same ground from a slightly different angle.
3. They keep each spec short, scoped, and explicit about what's out of bounds
The practical advice circulating among 2026 spec-driven ai development teams is specific: keep an individual spec to one to three pages, organize specs by feature in their own folders, and critically, write down what's explicitly out of scope alongside what's in it. That last part matters more than it sounds. An AI coding platform with an unbounded spec will happily "helpfully" wander into territory you never asked it to touch. A boundary line in the spec is cheaper than a code review catching it later.
Build this with a prompt on Greta.sh — describe the app, Greta writes and deploys it.4. They write acceptance criteria in a format the AI can't misread
Loosely worded requirements ("the login should work smoothly") are exactly what causes the "looks right, but doesn't quite work" outcome GitHub describes. Teams doing spec-driven coding well are borrowing a structured format - often EARS-style statements (Ubiquitous, Event-driven, State-driven, Unwanted-behavior, Optional) so a requirement like "the system shall lock the account after 5 failed login attempts" reads identically to a human reviewer and an AI agent. This single habit is doing more to close the AI-generated-code trust gap than almost anything else on this list.
5. They phase-gate the build instead of going straight to code
The phase gate both major toolchains enforce
- SpecifyWrite what the software must do, and what is explicitly out of scope. One to three pages.
- PlanThe AI proposes a technical design. Review gate — a human signs off before anything is broken into work.
- TasksThe plan is decomposed into sequenced, individually reviewable units. Second review gate.
- ImplementOnly now does code get generated, task by task, each traceable back to the spec that authorised it.
Both of the two biggest named tools in this space encode the same shape. GitHub's Spec Kit runs Specify → Plan → Tasks → Implement. AWS Kiro runs requirement unpacking → technical design generation → sequenced, tested implementation. Neither lets you skip from an idea straight to generated code — each forces a review checkpoint at the plan stage and again at the task-breakdown stage, before a single line ships. This is arguably the single biggest departure from classic vibe coding, and it maps closely to howagentic coding platforms that plan, code, and test themselves are already structured.
6. They trace every commit back to the spec that authorized it
Practically, this means commit messages that reference the spec file directly — something like feat(auth): magic link, refs specs/004-magic-link/spec.md — so six months from now, nobody has to reverse-engineer why a feature exists or what it was supposed to do. For anyone managing a vibe-coded app across many files and contributors, this habit pairs directly withour guide to managing multi-file vibe coding apps — traceability is what makes a large, AI-assisted codebase auditable instead of archaeological.
7. They treat the spec as a living document, not a one-time brief
This is the habit that separates spec-driven development from just "writing better prompts." Tessl's own framing of the idea is direct: the spec "will be structured to enable bigger apps than today's prompt-based creators, and evolve as the application matures" — meaning the spec gets updated alongside the code for the life of the product, not written once and abandoned. Skipped, this is exactly how a vibe-coded MVP quietly accumulates the kind of debt we've written about inwhat happens to tech debt after a vibe-coded MVP takes off.
Old habit vs. the spec-driven replacement
| Ordinary vibe coding habit | Spec-driven replacement |
|---|---|
| Describe the goal in one prompt, iterate on what comes back | Write a spec first; the AI executes against it, not against a single message |
| Requirements stay in your head or in chat history | Requirements live in a versioned file, reviewed before code is written |
| "The login should work smoothly" | EARS-style acceptance criteria a human and an AI parse identically |
| One big prompt for the whole feature | Specify → Plan → Tasks → Implement, with a review gate at each phase |
| Commits explain themselves (or don't) | Commits reference the spec that authorized them |
| The spec (if one existed) is discarded after launch | The spec evolves alongside the app, for as long as it's maintained |
[Source: habits were drawn from GitHub's own Spec Kit documentation and launch post (September 2025), AWS's Kiro launch coverage (July 2025), Tessl's Series A announcement and public framing of specs-as-source-of-truth, and independent 2026 reporting on how teams are actually running these workflows day to day.]
Frequently Asked Questions
What is spec-driven development?
An approach to building software with AI where you write a clear specification - covering behavior, constraints, and acceptance criteria — before any code is generated, and treat that spec as the ongoing source of truth rather than the resulting code or the original prompt.
Want to try one of these? Start on Greta.sh — no setup, no boilerplate — just a prompt.How is spec-driven AI development different from vibe coding?
It isn't a replacement so much as an added discipline layer. Vibe coding describes building software by describing intent in plain language; spec-driven development adds a written, reviewable spec and phase-gated checkpoints before that intent becomes shipped code.
What tools support spec-driven coding in 2026?
Two of the most visible are GitHub's open-source Spec Kit, released in September 2025, and AWS's Kiro, a full IDE built around specification-driven workflows launched in July 2025. Well-funded startups, including Tessl, are building entire platforms around the same idea.
Is spec-driven development only for large teams?
No — the core habits (writing a short spec, defining explicit acceptance criteria, reviewing a plan before implementation) scale down to a solo builder using a single AI app builder just as well as they scale up to an engineering team, and they're increasingly considered standard vibe coding best practices regardless of team size.
Do I need to abandon my AI app builder to adopt these habits?
No. These are workflow habits, not a specific product requirement — you can write a spec, define acceptance criteria, and phase-gate your own review before prompting any platform, including a full-stack builder like greta.sh, without switching tools.
The habit that actually matters most
Of the seven, the one worth adopting first if you only pick one is \#1: write the spec before you touch the prompt box. Everything else — the constitution file, the phase gates, the traceable commits — is really just infrastructure built to support that first habit over the life of a real project. If you're building on greta.sh, none of this requires new tooling to start: a spec can be as simple as a short written brief you paste in before your first prompt, with acceptance criteria and an explicit "out of scope" line. The teams treating it that seriously in 2026 aren't doing it because vibe coding failed. They're doing it because the fast part was never the problem — the ambiguity was, and a spec is what removes it. For code-quality practices once that first version ships, greta.sh's owndeep dive on whether AI-generated code scales is a natural next read.
Last updated: August 24, 2026.
Pages that should link back to this post (add manually): prd-templates-ai-app-builders, vibe-coding-tech-debt-after-mvp-takes-off, and the previously drafted is-vibe-coding-dead post (it references spec-driven development directly in point 5) are the three best candidates to link back in.
