Using Spec-Driven Development for Production Workflows

Hey, everyone. My name is Eric Handshed, and today I want to tell you guys all about spec-driven development and how you might use it in your workflows today. So there's a couple of things we want to talk about. First, what is spec-driven development? And then how can it make you a better and faster coder? So we just don't want you to code faster, but we want you to actually create higher-quality code from it. And I think really spec-driven development helps you with this. And I'm going to explain why and how.

So let's take a look at a definition of spec-driven development. So basically, it's a structured specifications are created before any code is written. That's the definition of really the specs or the requirements of this spec-driven development. And it goes to the heart of what it is. So what we're doing is we are writing these markdown files, we're writing the specifications and the design document before any of the code is written. And this actually works really, really well with large language models and our coding assistants that we use. And I'm going to show you exactly how that works.

Now a question I sometimes get is why? Like why should we use this spec-driven development workflow? And then how can we do it? So to answer that why question, I kind of like to think about our coding assistants, our large language models that we're using every day as sort of like AI interns. You need to really prompt them. You really need to push them the right way. No pun intended with the prompting. So you really need to guide them because if you give them just a little bit of leeway, they will go off the rails. And really the spec-driven development helps guide them in the right direction.

I remember when I was an intern and one of my first jobs, we had a VP that would walk around and he would just come up with random ideas off the top of his head. And when he told me it, I would drop everything and work on it. And then later my boss would be like, Hey, Eric, why did you drop everything? Well, the VP said something. And then I learned about well, you got to take his information that he gives you, write it down, put it in your schedule, talk to my manager about it. So I was a little too eager. And this is what AI interns are basically these large language models do nowadays and we got to be careful about it. I didn't really give you too much of introduction. So I'll give it to you now. My name is Eric Hanchett. I'm a senior developer advocate at AWS. I have over 15 plus years of software development experience.

And if you want to connect with me, you can check out LinkedIn. That's probably the best place to go. Just look for Eric Hanchett and yeah, talk to me, follow me. I'd love to talk to you more about it.

Another question that people often ask me about spec-driven development is can't the latest frontier models just do everything for us already? Why do we need this? And while I do say that the models are getting better and better every year and every release, sometimes incrementally, sometimes by leaps and bounds, it's still not perfect.

Giving the large language model, these models, more context is actually really important because it does help guide it in the right direction. With our software always changing and with the requirements always changing, and with new paradigms, shifts, you always need to kind of guide it where it needs to go. So let's keep a few things in mind before we get too far. There is quite a lot of information out there. I have some opinions. These are my opinions.

I have some opinions. These are my opinions. Let me know. Connect with me on LinkedIn if you agree or disagree. But I think you need to keep these in mind before using spec-driven development or VibeCoding or anything in between. We have to, you have to be careful with context. Now I told you before that spec-driven development gives you a lot of context that gets fed into that large language model. But sometimes you have too much of a good thing. What you need to do is when you are working with these large language models, usually you create like an agents.md or a claw.md at the beginning with some information in it. I would be very careful not to put too much information or too little information in that. Kind of like that Goldilocks zone of information is what you need. So you just need to give it enough rules and guidelines that it knows what to do.

That's exactly what I was talking about, agents.md or steering. We call it steering docs in Kera, which I'll mention about in a minute, but you just got to be very careful what you put in those documents. I also highly recommend when you're using spec-driven development to use skills. Skills are like instruction files that you can give to your coding agents that are ran on demand. So usually they have keywords in them. And when the coding assistant sees those keywords, they'll activate the skill or you can do slash in the skill name and then run it. But this actually really helps when you're doing the spec-driven development process. You can actually add skills when it creates your design documents or whatever else. You can use those in parallel or with the spec-driven development or when you actually implement the tasks.

Just be careful about giving too much trust. Remember, everything in the spec-driven development flow is you, meaning that you are the human in the loop, so to speak. You need to be the code reviewer of all the code that's generated through this process. You need to be interactively looking at the design documents and the requirements documents that are created. Because at the end of the day, if something goes wrong, you are the person that are going to be blamed for it, not the agent. That's not to say that we don't use tools to help do code reviews. Someone once told me, are you saying you're the human in the loop, you do the code review, no one else? Of course, we might have multiple people doing code reviews. And definitely use your normal AI coding assistants and review tools to help you review any pull requests that you create. Or CRs.

So, let me give you a little bit of a history lesson of where we have been, especially at AWS. We saw this need, especially from our teams and our customers that they were vibe coding, they were using these coding assistants, but they weren't getting the outputs that they wanted. And what we saw is these customers were using this bespoke pattern of having the agents, the coding assistants, create these full down requirements documents and these design documents. And we decided to create an application to do this all for them.

So, we released Kiro late last year in a general availability. It's our new AI IDE coding assistant. We also have a command line interface or CLI version, which is just as popular. I think right now it's switching. Most people are starting to use CLIs more often than IDEs. So, if you like to do that, you can use the CLI. But what we really focused on with Kiro is, you can see in these screenshots, is this vibe and spec mode. So, we're going to jump into spec mode in a little bit.

But we really thought this really encompassed what we were hearing from our customers, that people wanted more ways to work with larger features and more complex projects. And they really needed the coding assistant to know exactly what their project was doing. We also released the website at kiro.dev. Feel free to, after this presentation, to go check it out. You can download our CLI, our IDE, and give it a whirl, because we're really proud of it. It's fun. When we released this, it actually went a little bit viral. We got tens of thousands of downloads. A lot of people were asking us about Kiro.

So, we were really happy to release this. And when we set it up in preview, we had so many downloads, we had to put a gate in front of it. And then people found around the gate, but now it is publicly available for everyone to try and give it a shot. But I don't want this to be a half hour pitch for Kiro. You can do this process spec-driven development without Kiro, and there's a few ways. One is that basically, you have to just... You could do this manually with anything. You could tell your assistant, your large language model, to include the following.

First is the user requirements. You would tell them, please, based on XYZ, create a whole set of user requirements. Now, you can feed it your own user requirements beforehand and say, okay, use this as a basis, or you can have the editor, the AI IDE, go ahead and create it for you. Then you look back and forth and make sure it's okay. Then you tell the assistant to create the design document, then you look back at that, and then you have it create the implementation details. These are the tasks lists, the tasks one by one, to actually implement it based on the requirements and the design document you created.

So you could do this kind of a manual way if you like. I will give a shout out to Speckit. This is GitHub's open source way of doing this process. You can install it in a variety of different coding assistants. Now, in Qro, you have this IDE version. We have plan mode inside the CLI, if you prefer the CLI. But in the IDE, you would choose spec, and then you would go ahead and give it a prompt. In this case, I can say, build a movie MCP server to keep track of movies I've watched, or build a movie website, whatever you want. Now, you're probably thinking, is this spec only good for greenfield brand new projects? I would say absolutely not. I've seen existing apps that are years old, have dozens and dozens of these different spec files in them. This example, it's kind of more of a greenfield, but you can definitely use it for existing legacy projects as well. It works very well. I would just say that these are really good for when you're doing in-depth features, when your project needs a little more upfront planning, and you just want to build things in a structured way. It definitely works really well with complex projects. We actually added a spec mode for bug fixes, too. You can use it for smaller things, though you may want to just kind of vibe code those things instead.

Here's what our requirements document looks like. In the first part, it creates this requirements phase, where it's in this ears format, and it gives you the introduction, like the requirements, the user stories. We also have a process where it asks you questions beforehand. We added in some extra question and answers. As you put your prompt in, it'll ask you some clarifying questions before it creates this requirements phase. You can also do this quick plan mode we just added, which will go ahead and just generate all these documents quickly for you based on the questions and answers you give. There's a lot of different ways you can do this.

You'll create a design document, which is a higher level design document. You can also start with the design document first. Some people take this design and requirements, combine them, but typically, with our spec-driven development flow, you can either start one or the other. Then you might have mermaid diagrams here, ASCII art with all the information. This is at the point I would highly recommend if you're trying this at home, to stop and go in and update it with your knowledge, expertise, and taste to exactly what you're looking for. It's only as good as what you put in, but you'll find out that even with a smaller prompt and with the clarifying questions, it does a pretty good job. Of course, you always want to review it for markdown. The markdown files for inconsistencies, elucidations, and errors.

Then finally, you get to the implementation phase. This will be a list of tasks. It also has something called property-based tests in them, which are tests that are against the requirements document and design document. If you can additionally have those created and ran, I would highly recommend it. That way, it makes sure that the tasks actually are implemented correctly. I usually also, quick tip here, once it creates this task list, I tell it, please take the top four tasks, put them at the top, and create an MVP for me first. That way, I can actually see it working. Then I'll implement them. I'll implement the MVP version first. Now, I love model context protocol. I'm not going to go into exactly all the details of it, but it's a way, essentially, for your model providers to connect to different data sources. In this case, I'm using Kiro, and maybe I'm using OpenAI or Anthropic. We want to connect to different data sources. We have this MCP protocol in the middle. It connects everything together for us, which is awesome.

Now, I get this question, isn't MCP six months old, and it's dead now? A lot of people on the internet have opinions that change every other day. Some were saying you can do a lot of stuff with MCP just with command line tools. MCP is still maturing with a long road ahead, especially in security. One main reason I like it is for spec-driven development flow, integrating with project management services for easier work.

You can have all your tickets and requirements pulled into spec-driven development flow. Product managers can provide requirements documents for integration. Additional rules can be set in steering or agents.md files to guide MCP. You can specify which MCP server to use or include it in the initial step when creating requirements. A quick demo with the latest QIRO IDE version showcases the creation of a movie database project from scratch, starting with design documents. Property tests using FastCheck ensure requirements satisfaction.

The generated requirements document simplifies user stories and steps. Task lists can be updated to create an MVP version for initial implementation. Property-based tests ensure correct implementation. The MVP includes specific features like a browsable movie grid, genre filtering, sorting, and a thematic design. Following the MVP creation, all requirements are implemented, demonstrating the effectiveness of the process with property-based tests for execution review.

I was in the spec mode here, I said, please create me a movie website, so what it did is it started with this design document, and in this case, I actually told it to start with design instead of requirements. There we go, and then this shows the actual preview of the markdown file, so you can see it created a bunch of different mermaid diagrams that show the architecture of it, gives you sequence diagrams, and so I went back and forth with this and updated and edited it, and it created this all for me.

If I scroll down to the bottom of this document it created, you can see here it created a bunch of property tests, and these are really special tests. It uses FastCheck in this TypeScript in the Node world to do these tests, which actually run dozens if not hundreds of times with different values to make sure that these requirements are satisfied correctly, which is really nice. Then it created this requirements document in, once again, this ears format, so it's really very simple with these user stories, requirements. Let me see if I can open it up again. Here's it in preview. Here's the requirements document. Requirements one, movie data loading. When the application initialized, the filter engine shall load. So it gives you, step by step, exactly what it's doing here.

And then when I went back and forth with this, I got to the task list, and I asked it, hey, in the task list, can we create like an MVP, so it went ahead and updated the task list and even says right here, tasks one through four deliver a working MVP, browsable movie grid with search, genre filtering, sorting, and a full 80s synthwave theme. So it actually redid all the requirements and to get this basically MVP up and running out of the door, which I really enjoyed. I went ahead and just implemented all of them after that, but you could see how it works. You can also see it created this property based tests, which are nice, which I can go back in and take a look at the execution. If I kind of hover over some of them, like I can look at the changes, so I can look at the changes and exactly what it did. Definitely very, very useful in what it's doing. You can also, let me see if I scroll to the bottom here, here it is. So if I just kind of hover, it shows like a little bit of information about the property based test. It's like, with property tests for genre filtering for any movie data set and the extracted genres list must contain exactly a sorted set of unique genres. So it tells me exactly what it did at this point. And then I can even look at the execution of what it did. Okay, let's go back to the demo, I only have one minute left.

So if you want to learn more, you can go to qro.dev or you can join our Discord at Discord.gg slash qro.dev. I highly recommend everyone watching, check it out. It's pretty amazing. I also, here's a QR code, take a snapshot of this, give me feedback on this presentation. Let me know. I'd love to hear about it. And then finally, I have one more QR code. If you want to go to my website at Program with Eric, I have these slides for you to download and take a look at. And make sure you connect with me on LinkedIn at erichandschat. Love to just connect with as many people as I can. And also on BlueSky at erichch or x. Thanks.