Spec-driven development: What it is and how to get started with Spec Kit + Kilo Code
AI coding has come a long way: 47.1% of people use AI tools daily, according to the 2025 Stack Overflow Developer Survey. 84% use or plan to use AI tools in their development process.
Popular, not trustworthy: Here’s the bad news. Software developers don’t think highly of AI. Only 22% had a “very favorable” sentiment toward AI, according to the same Stack Overflow survey. That survey states that positive sentiment about AI has also decreased from 70% in 2023 and 2024 to just 60% this year.
The reason software devs don’t trust AI: Accuracy issues and “vibe coding.” According to the survey, 46% of developers distrust the accuracy of AI tools.
And who can blame them? We’ve been pitched this whole idea of “vibe coding” and the promise that “AGI is coming soon,” and that we’ll be able to create a full-fledged, full-stack app from a single prompt.
That hasn’t been the case. There’s been a flood of memes making fun of vibe coding – how everyone loves to vibe code, but nobody really likes to “vibe debug” their AI-generated code.
As they say, “it’s funny because it’s true.”
Enter spec-driven development
Here’s one observation many people have about AI models: They are remarkably good at pattern recognition, but not so great at reading your mind.
Let’s say you have an app and want to add a photo-sharing feature to it.
Compare these 2 workflows:
The “vibe coding” workflow:
Prompt: “Add photo sharing to my app”
The result: You leave a lot of room for the AI model to guess. The model has to guess the flow, the tech stack, how it’ll integrate with your existing code. The results will probably be very different from what you expected.
The “spec-driven” workflow:
Prompt: “Add photo sharing to my app”
The result: The spec-driven toolkit will generate a series of specs to define the flow of the whole feature, how it’ll integrate with your existing app, then it’ll ask you about the tech stack and libraries you want to use. Once that’s done, you’ll get a list of specific to-dos with the planned changes. You’ll then review those changes and watch as the AI coding agent executes them one by one.
Which of these workflows do you think will result in an actual feature that works, and which one will resurrect a CoffeeScript image cropper from 2011, transpile it incorrectly to ES6 and define half the JavaScript variables as var?
Welcome to the brave new world of spec-driven development.
Spec-driven development vs. traditional development
Most of us write code first and document later. Spec-driven development inverts this approach
In traditional development, your code is the source of truth. Writing specs is something you do later (often as an afterthought).
Spec-driven development flips the script. Your spec becomes the source of truth, and you let AI handle the implementation details and write the code. This way, your specifications become executable, thanks to AI coding agents like Kilo.
Let’s see how this works in action.
Getting started with spec-driven development using Spec Kit
GitHub has recently released Spec Kit, an open-source toolkit that’s compatible with several AI coding agents, including Kilo Code.
Spec Kit went from a relatively unknown project to something that has taken the developer world by storm in the last month. Many of our users have been curious and asked how to use Spec Kit in Kilo Code.
In this section, I’ll try to explain that, while giving you a broader overview of spec-driven development in the process.
Step 0: Install the CLI tool
To use Spec Kit inside your own project, GitHub created a command line tool called Specify. To install Specify on your machine, GitHub recommends running this command in order to “install once and use everywhere”:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
Specify is written in Python and uses a package runner called uv. Think of uv like npx, just for Python. Here’s how to install uv if you don’t already have it on your machine.
Once you run the uv command above and add specify to your path (you’ll get the instructions for this as you install the tool), you should be able to run ‘specify’ from anywhere in your terminal.
Step 1: Prepare your project for spec-driven development
For this example, we’ll use our VS Code extension.
There are 2 main steps you need to follow to prepare your project for Spec Kit:
Initialize Git (if you don’t have it already): To use Spec Kit, you need Git in your project folder. Spec Kit creates a new Git branch for each specification you define (we’ll learn more about the reason for this later).
Set up Spec Kit in your project: To do this, go to your project folder and run:
specify init .
What this command does: It tells Specify to do the required actions to initialize Spec Kit for this project. You’ll be asked to choose your AI coding agent. Choose Kilo Code:
What happens after this: After you choose Kilo Code, Specify will create a few text files inside your project folder:
All of these files will be helpful when running our Spec Kit commands from within Kilo Code.
After creating all of the files above, Specify has finished its job. Everything we’ll do from this point on will be inside Kilo Code.
Step 2: The Spec Kit commands
Note: I’ll omit the prefixes when talking about the Spec Kit commands (so instead of /speckit.analyze, I’ll use /analyze)
From this point forward, we’re able to run Spec Kit commands from within Kilo Code.
To make it easier to find these commands, all of those commands are prefixed with “speckit”. So just type /speckit into Kilo Code and you should see this:
Using these commands is where it all begins.
IMPORTANT NOTE: Spec-driven development is a concept. GitHub’s Spec Kit library is just one way to implement this concept.
There are many up-and-coming libraries that do spec-driven development a bit differently. One of those libraries, for example, is OpenSpec (see this video showing how to use Kilo Code with OpenSpec). Spec Kit is (currently) the most popular open-source library for doing AI spec-driven development.
I’ve listed these commands in the order you execute them. It all starts with defining what you want, using /specify.
/specify = Here’s what you should do
Here, you tell Spec Kit what you want to do on a high level. You describe your specification.
Important: Don’t include technical implementation details here. That comes later. This is where you describe on a high level what you want (usually some feature).
Scope: In spec-driven programming, a specification is usually a feature. You don’t describe your whole application in a spec. Nor do you describe small implementation details (e.g., “I want this button to be red”)
Example:
/specify Add user authentication with email/password
What happens after running this command:
A new Git branch will be created, and you’ll be switched to that branch
A new “specs” folder will be created inside your project folder. Inside “specs”, there will be a new folder called “001-your-branch-name-here”, eg., “001-user-auth-email-password”. This is the folder where all files related to the spec will go: After /specify, you’ll run commands like /plan and /tasks, and the output (.md files) of those commands will go there.
You should see Kilo Code generate a new file “spec.md” inside your specs/[individual-spec-folder].
In theory, you could write spec.md manually. After all, this is just an .md file that follows a specific format.
In practice, it’s faster to use Kilo Code + your LLM of choice to do this.
At the end of the day, /spec just generates/modifies files using the “template” files that Specify created for us in step 1.
[Optional] Run /clarify after you’re done with /specify: If you run the /clarify command after Kilo Code generates a spec.md file, Kilo will go through that file and find any ambiguities in your specs. It’ll then ask you to resolve those ambiguities. For example:
Do you want password reset functionality?
Should there be a minimum password length requirement?
…etc.
/plan = Here are the technical details
Before doing this step, read the spec.md file that Kilo Code generated for you to verify the specs are correct
After we’re done with /specify, we’ll run the /plan command.
What it does: Here you specify technical implementation details: Frameworks, libraries, programming conventions, etc.
Example:
/plan Use the built-in authentication generator I have in this Ruby on Rails 8 project. Also use Tailwind for the CSS
What happens after running this command: Inside specs/[individual-spec-folder], Kilo Code will create another file named plan.md. This file will have a more concrete plan on how to implement your specs with your tech stack.
/tasks = Let’s turn all this into concrete tasks
What it does: After generating a plan, the next step is to turn everything into concrete steps that the Kilo Code can execute. This is what the /tasks command does.
Unlike with /spec and /plan, you don’t have to specify any arguments when running /tasks. Just run this command and wait for a few seconds.
What happens after running this command: Inside specs/[individual-spec-folder], Kilo Code will create another file named tasks.md. The file contains a list of ordered tasks the agent will go through in order to implement your spec + plan.
[Optional] Run /analyze after you’re done with /tasks: Here, Kilo Code will take everything it generated so far and analyze it. It’ll identify inconsistencies and issues, and report them back to us (sorted by severity/importance/etc.) The goal here is to make sure we’re absolutely ready before going to the final step
/implement = Let’s execute the tasks
What it does: This is the final step, where you tell Kilo to take tasks.md and turn it into code.
What happens after running this command: Kilo will go through your tasks, one by one, and create code, files and folders, execute commands, install the necessary dependencies, and so on.
By the time this finishes, you should have a (hopefully) working program.
How these commands work together
When I started learning about Spec Kit, I was confused by:
1. What all of those commands actually meant
2. How to invoke those commands in order to go from specs to code
I then realized that to understand them, I needed to remember the end goal: to go from specs to code. This is what we’re trying to achieve.
Once I reminded myself of that, everything started to fall into place:
We start by defining what we want conceptually with /spec
We then continue by defining what we want technically with /plan
We then turn the conceptual spec and technical plan into a series of concrete steps with /tasks
We then execute those tasks with /implement
This is how we get from “what we want” (starting from /specify) to actual code (after /implement is done).
When to use vibe coding instead
Spec Kit is better suited for production-ready code; it’s for when you want to make sure that the agent doesn’t go off the rails and you produce unwanted results.
This is useful when you have a bigger feature that you want to implement, with several steps, tests, and so on.
That said, Spec Kit might be overkill if you want to add a simple feature to your app. For example, adding a testimonials section to your static Hugo website.
So the answer to this question comes down to scope.
How to define any non-negotiable project conventions
Before starting with spec-driven development with Spec Kit, many people recommend defining any non-negotiable conventions your project has in a separate file.
How to do this: Run the /constitution command, followed by what you want the LLM to always stick to.
Example: /constitution use accessibility best practices on all HTML elements, stick to using Ruby on Rails 8’s built-in libraries as much as possible
What happens after running this command: Kilo Code will create/update the “constitution.md” file, located here: /specify/memory/constitution.md.
Spec Kit might be just the beginning
Spec-driven development is here to stay. The approaches for implementing it will keep evolving.
Kiro, Amazon’s coding agent, started the trend of “using agentic AI tools to implement spec-driven development.”
GitHub is trying to bring their own version to as many coding agents as possible:
We’re also seeing “forks” like OpenSpec gaining traction. We also have projects like Spec Workflow MCP with an entire approval workflow.
And then there are people who take parts of all those systems to fit their own workflows.
Kilo Code will keep supporting spec-driven development along with all popular methods that implement this concept.