Using Spec-Driven Development for Agentic Coding

Hi everyone. My name is Eric Hanton, and I'm excited today to talk to you about spec-driven development and how you can use it in your IDEs today. Now throughout this presentation, you might see this ghost bounce up and down in some of my slides. Don't worry, I'm going to talk more about that in the future, but it kind of goes in with how this spec-driven development works. So the first question you probably are thinking is, what is spec-driven development? Now it's not spec-der, like some of these ghosts that you see in my slides, but it's an important way of thinking of a way of creating specifications for your development environments and while you're coding. So let's take a look at the more formal definition of it. So you can see here, a development approach where detailed, structured specifications are created before any code is written.

So I don't know about you, if you're watching right now, have you ever had the issue, have you been around for a while, and have you heard of waterfall? So that was the idea where you had very specific requirements, this was a very specific thing you did with the software development life cycle, and then your developers would work on those very specific requirements, sometimes for many weeks, and nowadays we have moved on to agile methodologies and sprints, but having this very detailed requirements document is really good for IDEs, especially for AI IDEs out there, so it can understand exactly what you're trying to do and there's no ambiguity. So spec-driven development is really about trying to create that in your IDE, so that way your AI IDE, your agents understand what you're trying to do.

Now there is another definition I just want to clear up is what is specs. Now specs are the formal requirements, rules, and constraints that govern the creation and behavior of a system. So often times the software developers, I don't know about you, but I don't have time to write specs, I actually have other people that write requirements, and a lot of times the requirements I'm given aren't very detailed, but this spec-driven development actually helps solve that problem as well. So you don't have to have someone write really detailed requirements documents, we can actually have the AI do that for us. So let me show you exactly how that works.

So let me give you a little bit of a history lesson first. So at AWS we are very document-driven, we write a lot of docs any time we do anything, we have very long meetings and bar-raising meetings on anything we do, and we had this problem where we have lots and lots of documentation, but there was a problem, how do you get that documentation into our coding environments? And how do we use our AI coding agents in an intelligent way? So we actually came up with a few different ways, and we actually have a history of creating AI assistants. So the first being is Amazon Queue. So we have Amazon Queue, an IDE version, we have Amazon Queue CLI version, and so this allows you on the command line to ask it and prompt it to do things, and then it can go in and make changes to your code. And you can also script this, it's really powerful, you can add MCP services, but we kept on hearing back that we needed more ways to have better outcomes and results. Now you can vibe code with these tools like Amazon Queue CLI and Amazon Queue IDE, but you have problems where you're just going back and forth a lot, and a lot of times it isn't exactly what you want. So we saw this problem and we thought, what better way to fix it than with spec-driven development? So let me show you what happened there. So we introduced Qiro. Qiro is a new AI IDE coding assistant, and one of the major features of it is this spec-driven development, which I'm going to show you in a moment. So we wanted to have this internally, but also obviously it's externally available, and it has this nice cute mascot, this ghost, I call the Qiro ghost, and it's different than some of the other Amazon services or products you've seen. In fact, it's called Qiro, which is not Amazon Qiro or AWS Qiro, it's just Qiro. And so we really wanted to make sure that this was available for anyone that had the same problems that we saw, that wanted this kind of deeper way of creating software and have it be more reliable. Now we released a website, qiro.dev, you can go there right now. And what was really awesome when we released this in the wild, we had such positive reactions. I think this was something that many people were thinking about, as like, how can we make our agents, our AI even smarter? And we had so many downloads that we had to set up a wait list, and then people found a way around the wait list. So to this day, it is in wait list, and you can check it out at qiro.dev. And we are really proud of it, we're taking all the user feedback, making changes and updates. We actually have a Discord channel where you can even give your input and let us know. It's based off of Visual Studio Code, which I'm a huge fan of Visual Studio Code. I use that for everything. So it has that kind of environment that you know and love, especially as web developers, front end full stack developers. Although you're not limited to that you can use Java, you can use whatever else you like, of course. So I want to give a little shout out that if you are not using qiro, and if you're not, I wonder why not. But if you're not, you can do this spectrum development even without qiro itself. So there's a few ways of putting this together. And so I'll talk a little bit about it. First is you actually just need to be very specific to tell the ID exactly what you want. So you would include the following, you would tell it first, create a user requirements document and this user requirements document would have every single thing that you want inside of it. So you give it a prop and say create a user requirements document for XYZ feature and then maybe create it as a markdown. And then it would create it.

And then you would say create a design document based on that user requirements document. So you would go in and say you would add these requirements document into the context and then you would have it create the design document. And then lastly you would have it create the implementation details or task list from that. So this can be done with basically any AI ID out there. However, I think it really lends itself really well to QIRO.

There's also templates out there that you can download that you can kind of use as starting points. If you look around, there's also even an open source project. I think it's called spec. It's a spec open source project that you can use to also add this features or something similar to this functionality. Now with QIRO it's actually built into the ID itself. It's one of our main features, but certainly you don't have to use that to tease this.

Now you're probably wondering how does this work in practice. So let me show you kind of what the steps are and what you need to do. So first inside QIRO, we're going to use that for the rest of the examples of this tutorial, but you can kind of get an idea if you're using your own ID. But you actually have this box that opens up inside QIRO and it gives you two options. Of course, vibe is common and you can use that and it works really well. You can go back and forth, but you can choose spec. And spec is a great way, especially if you're creating in-depth features, something that needs upfront planning, maybe creating a brand new project from scratch.

So this is a great way to start with. And I really think that small features, small bugs, vibe's good, specs are really good for bigger features and more planning that needs to be up front, something that needs a little bit more thought before you jump in.

Let's imagine we were going to create an MCP server. I don't know. MCP is really big. We'll talk about that in more a second. That scrapes my local movie website and deploys it to AWS. Now I use the example of AWS here, but certainly you can use any provider. I just thought that was a fun example.

I would click on that spec inside QIRO and then I would add this into the chat window. Now I cut the chat window out here, but there is a chat window at the bottom that you can prompt and go back and forth with. It also supports like multi-modality. You have a couple different... You can choose which model you're going to use, things like that.

And so after I entered that prompt in and hit enter, QIRO would start working in the background and it would create this requirements document. This document would include the introduction, user stories, basically everything you need to start off with. At this point, you may want to consult your product manager, update the requirements, and possibly use the refine button to further enhance it. It's crucial to double-check before proceeding to the next step.

QIRO is intelligent enough to generate a detailed document even if you don't have one ready. It will create a design document post the requirements phase and seek your confirmation. This design document might feature ASCII art or mermaid diagrams to provide a high-level overview. Spec-driven development allows for continuous validation of the AI's interpretation against your actual requirements, enabling back-and-forth adjustments.

Committing early and often, along with maintaining separate branches in your version control system, is advisable when working with IDEs, agents, or AI tools like QIRO. Ensuring consistency, error checking, and addressing any issues are essential steps before moving to the implementation phase. The implementation phase in QIRO displays individual tasks, allowing you to revisit requirements and designs, make modifications, and update tasks seamlessly. QIRO provides a user-friendly interface where you can manage tasks efficiently and even control the number of tasks generated.

It even gives you another set of explanations of what it's going to do. That's one thing that's really nice about the spec driven development. You're always like checking and rechecking if what the IDE thinks, the AI thinks is what you actually want. And you can go back and forth here.

Now I'll put this shout out here for reviewing. Whenever you're working with any sort of IDE and agents or AI, you always want to commit early, commit often, merge back to your branch. Just make sure that you keep this in separate branches. That way you can easily revert back. Now you can revert back of course in QIRO, but I think it's just easier if you keep this all isolated and you have your version control system to play around with this.

Of course you want to check for some obvious things, inconsistencies, hallucinations, errors, anything like that because it still can happen. Now finally it goes to this implementation phase, which I really like, which shows each individual task. At this point you still have time to go back to the requirements and design, make additional changes, then click the update task button and it will update the task. There's actually a button directly inside the IDE that does that. From here you can check each task and then either you can click that little start task button or you can tell inside chat, say start at task one and at task two and it'll start working.

I also like at this point maybe to reduce the number of tasks. QIRO, like many other AI IDEs, is like an eager intern. It wants to do everything for you and create a million tasks. I love that. I love that, but sometimes I might be like, you don't have to do this. I might remove a step, I might change things, but I get that flexibility at this point, which is really awesome.

Now I want to give a shout out to MCP because you probably during this conference have seen some other MCP information, but MCP of course is a way to connect your agents to different tools and a standard to do that came from our friends at Anthropic. Some people call it the USB-C of protocols, which is nice. You can actually use that with QIRO.

Let me give you a quick example of how this works. You have agents on the left-hand side, you have the MCP, and then you have the tooling. This actually opens up a lot of possibilities because although the models that we use in QIRO or whatever IDE you're using are pretty up-to-date, they're always missing things. It may not have the latest version of software. You can use MCP servers to catch up with that to have the latest information that you want. QIRO of course supports MCP, so that's not a problem to add any of those MCP servers in there.

QIRO of course supports MCP, so that's not a problem to add any of those MCP servers in there. What does this have to do with spec driven development? You can use MCP servers during your spec driven development to make it even smarter. The way I think about this is that you can create what we call steering documents or rules files, and rules files could say every time you go and create a new spec, make sure you check this MCP server for the latest information. An example of that is maybe use something like Context 7, so that way it has the latest documentation. Context 7 is an MCP server that connects to a lot of different documentation sites and has all that information.

You can also maybe even pull it to your user, your management system, like your JIRA or something that you have your task, your project management system. That it can maybe pull the information directly from your project management system as it's creating the requirements and as it's creating the design document. That could be even a really nice feature for it. Of course, yeah, grab technical details as you need it. You can even set additional rules set forth in your steering files, so you can have it pull sometimes or only pull in certain circumstances. You can really shape that whatever way you like.

I always use steering and files or rules files all the time in any sort of project I use because I have a very particular way I like to code, and it's nice to have that there. Let me show you a quick demo of what this looks like. Here's an application, just a sample application that I created earlier. It's using something called AgentCore, which is a service that AWS has to help you deploy agents, but I wanted to show you what JIRA looks like in here. On the right-hand side is this session. I can actually open up additional sessions if I want, and then I have vibe, and I have spec. I also have some other features of JIRA. First, let's just start it and just see what it looks like. Let's create an agent that scrapes my local movie website and the latest movies. I can come here, click here, and what it's going to do is going to start creating those specs.

I can also show you here's the agent steering files, which are used to give additional context to JIRA on what you want to do. You actually can have this automatically created. If you don't have any steering files, it'll have a button there to click and create the steering files. I had it do it beforehand. I also add some general rules to use the context of an MCP server when needed. It looks like it already created the requirements document, and here it is. I'm going to say move on to the design phase.

I just want to show you real quick that as it moves on to the design phase, it's going to use that MCP server to make sure it has all the correct information it needs as it creates that design. If this was in real life, I'd probably go in, or production, I'd probably go in and just read all this, double-check it and make sure it makes sense. It has that user story acceptance criteria format. You can see here it's calling the MCP tool as I'm doing this, which is really nice. I know for a fact that it's using it. I have all my MCP servers here. I have them mostly disabled right now, but you can use those. I have the context 71 in there, but I can add multiple MCP servers in.

Alright, so thank you for checking out my demo. If you want to learn more about Qiro or spec-driven development, just go to qiro.dev. You can also join our Discord at discord.gg/qiro.dev. Thank you.