Spec-driven development isn’t new. It has its own Wikipedia page and has been around longer than you might realize.

With the explosion of AI coding assistants, this approach has found new life and we now have a growing ecosystem of tools to support it.

The core idea is simple: instead of telling an AI “hey, build me a thing that does the boops and the beeps” then hoping it reads your mind, you front-load the thinking.

It’s kinda obvious, with it being in the name, but in case you are wondering, here is how it works.

The Spec-Driven Workflow

Here’s how it typically works:

1. Specify: Start with requirements. What do you want? How should it behave? What are the constraints?

2. Plan: Map out the technical approach. What’s the architecture? What “stack” will you use?

3. Task: Break the plan into atomic, actionable pieces. Create a dependency tree—this must happen before that. Define the order of operations. This is often done by the tool.

4. Implement: You work with whatever tool to build the software from your task list. The human is (or should be) responsible for deciding when a task is completed.

You are still a part of the process. It’s up to you to make the decisions at the beginning. It’s up to you to define the approach. And it’s up to you to decide you’re done.

So how do you get started?

The Tool Landscape

The problem we have now is there is not a unified standard. The tool makers are busy building the moats to take time to agree.

Standalone Frameworks:

• Spec-Kit - GitHub’s own toolkit that makes “specifications executable.” It supports multiple AI agents through slash commands and emphasizes intent-driven development.

• BMAD Method - Positions AI agents as “expert collaborators” rather than autonomous workers. Includes 21+ specialized agents for different roles like product management and architecture.

• GSD (Get Shit Done) - A lightweight system that solves “context rot” by giving each task a fresh context window. Designed for Claude Code and similar tools.

• OpenSpec - Adds a spec layer where humans and AI agree on requirements before coding. Each feature gets its own folder with proposals, specs, designs, and task lists.

• Autospec - A CLI tool that outputs YAML instead of markdown, enabling programmatic validation between stages. Claims up to 80% reduction in API costs through session isolation.

Built Into Your IDE:

The major AI coding tools have adopted this pattern too:

• Kiro - Amazon’s new IDE with native spec support
• Cursor - Has a dedicated plan mode
• Claude Code - Plan mode for safe code analysis
• VSCode Copilot - Chat planning features
• OpenCode - Multiple modes including planning
• JetBrains Junie - JetBrains' AI assistant
• Google Antigravity - Implementation planning docs
• Gemini Conductor - Orchestration for Gemini CLI

Memory Tools

• Beads - Use it to manage your tasks. Works very well with your Agents in Claude Code.

Why This Matters

When first getting started building with AI, you might dive right in and be like “go build thing”. You keep then just iterating on a task until it falls apart once you try to do anything substantial.

You end up playing a game of whack-a-mole, where you fix one thing and you break another. This probably sounds familiar to a lot of you from the olden times of 2 years ago when us puny humans did all the work. The point being, even the robots make mistakes.

Another thing that you come to realize is it’s not a mind reader. It’s a prediction engine. So be predictable.

What did we learn? With spec-driven development, you’re in charge. You are the architect. You decide. The AI just handles the details, the execution, but the AI needs structure, and so these are the method(s) to how we provide it.