I've been deep in spec-driven development (SDD) lately, and I want to walk through what it actually is, then show you how I used it to build a game for Kiro's first birthday.
If you haven't run into spec-driven development, or SDD, don't worry, I got you. We'll cover what it is, where it helps, where it's overkill, and how I used it to make this game! Would you like to watch a video instead? Check it out!
SDD breaks down into three phases, and all of this happens before any code gets written.
First you create a requirements document. Then you have your AI editor turn that into a design document. Then, from the requirements and the design, you generate a list of tasks.
The most important part is that there's a human in the middle at every step. You check the requirements. You check the design. You review and edit the tasks that get created. Nothing gets built until you've signed off on the plan.
This isn't set in stone, though. Sometimes the requirements and design get combined into a single document. Other times you run it in a quick mode where all three happen at once. It depends on what you're trying to do. When I work on big features I create all three documents, when I'm trying to do something quick, like a demo, I might just use some sort of quick or plan mode.
Like anything else, SDD comes with trade-offs.
The thing I like most is the high first-pass success rate. If you actually do your job up front, writing a real requirements doc and a real design, the end product is a lot more likely to be what you wanted.
It's also easier to review. You're breaking a big, complex feature into smaller steps, so you can check each one instead, and push up multiple smaller PRs. And it helps prevent you from going in the wrong direction. Instead of letting the agent run off in a bunch of directions and finding out way too late, you're checking the code after every step or two.
The downside is the up front planning time. SDD takes more time before you see any code, so it's not meant for every task. For throwaway code or a small issue, it's not needed. On the other hand any features that takes more thought it does really well. You give up a little time at the start, and in return you get a more stable, better working app at the end.
Let me show you what I built. It's a rogue-like game where you walk around and explore a bunch of buildings. Each building represents a different point in time for Kiro, because this is part of our Kiro birthday celebration. Kiro is turning one. So one building covers when Kiro went generally available, another is the house we had at re:Invent, and so on. Visit all the houses and you unlock a bonus house/section. I thought it would be a fun way to tell Kiro's history.
Under the hood it's Phaser and TanStack Start. Phaser is the gaming library doing the 2D Final Fantasy style look, and TanStack Start is the web library wrapping it all. There's music in there too, which I'll get to.
I opened up Kiro and told it to use spec mode. You can do this right in the IDE, and as of v3 of the CLI you can use spec mode there as well. Either way, it creates those three documents: requirements, design, and tasks.
I gave it a prompt describing the game. Something like, I'm creating this 2D video game, Final Fantasy style, here are the different classes and names, here are the different buildings we're going to have. From that it generated the requirements in EARS format, which is the classic structure of a user story plus acceptance criteria. As I mentioned earlier, I double checked it at every stage to make sure the docs it created were correct.
From the requirements it built a design. You can skip this part if you'd rather keep everything in one doc, but I like having it. The design got into the technical details. Phaser as the TypeScript library for the front end, TanStack Start with useEffect all over the place, the high-level structure, the scenes, the boundaries, the game shell. Then came the task list, with every single task broken out. I told it to build an MVP first, so it took the full list and pulled the four most important tasks to the front. I went in and made sure that ordering made sense, had it implement those first four, looked at the output, and confirmed it held up before moving on.
A few things helped a lot here.
I used a couple of MCP servers. Context7 to grab the Phaser documentation, so the agent wasn't guessing at the API. And the Chrome browser MCP extension, so Kiro could open the app, look at it, and make sure it matched the requirements.
I also ran auto mode. I bounced between models, and while Claude 4.8 is great, it does chew through a lot of credits. Auto mode did really well, especially paired with SDD. That's one of the underrated parts of this approach. When everything is already written down in the spec, you don't need the greatest state-of-the-art model to get what you need. Auto mode was more than enough for most of this.
On top of that I used some skills. The AWS Agent Toolkit, plus the Amplify and serverless skills. I ran /aws-amplify
and it helped me get the game hosted on Amplify hosting. For the music I used ElevenLabs. I had a scripts folder wired up to a bunch of services, PixelLab for art, ElevenLabs for audio, even Hugging Face. All of it driven from inside Kiro, with a .env
file holding the keys, and it generated the assets for me too.
That's the basic version of my spec-driven development workflow. It's more planning up front, but for a real feature it pays off.
If you want to try the game, check it out! Do you use spec-driven development in your day-to-day? I'm curious what your experience has been. Take care, and thanks for reading.