Using Spec-Driven Development for Production Workflows

We're going to talk about spec-driven development today. This is such a fun topic. I love to just dive right into it here. So what is spec-driven development? Can I see a raise of hands? Anybody heard about this term yet? OK, I see a few people. That's good. So this term I keep hearing over and over again, and it really is the basis for this new product, which I'll talk about in a moment.

But let's take a look at the definition here. It's a development approach where detailed, structured specifications are created before any code is written. So it's the idea where we're going to create this design. We're going to create a bunch of information before we jump into the code. And we're going to use our AI coding system to help us do that. And one way you can definitely do that today is to use QIRO.

Now, QIRO is a new AI IDE that actually, as of today, is now in GA, meaning it's generally available. And it really focuses in on this concept of specs and spec-driven development. And we're going to take a look a little bit more about how that works. And also, if you aren't using QIRO, how you would use it. You might see in some of these slides this ghost that's bouncing up and down. This is our QIRO mascot. So we thought it would be fun to have this playful little mascot, this ghost, that represents a little bit about specs, a little bit about what we're trying to do. And this is also presented by AWS.

So my name's Eric Hanchett. I work for AWS. But I'm really focused on QIRO as my day to day. You can check it out at qiro.dev. You can download it for free for Windows, Mac, Linux. And you can get started right away. And you can use social login. You don't need any special logins to try it out. And yeah, check it out at qiro.dev.

One of the main features, like I said, is the spec-driven development. We decided to have this panel in this IDE where we have two modes, vibe mode and then spec mode. So it's really integrated directly into the development environment. And so the spec mode is great when you want to create bigger features. And you need to, has something a little bit, needs a little bit more forethought before you jump into. So it even gives you some examples when you're using the IDE.

It's for thinking through features in depth, projects needing upfront front-planning, building features in a structured way. It almost kind of reminds me, if you go back in time, where everybody was doing this kind of waterfall method of gathering requirements that went into the production, went into, for the developers to work on a very structured requirements document. And then it went to QA, and then it went into production. Well, coding assistants really like that type of structure. They like to have very succinct examples of what the requirements are. Instead of doing this vibe mode where you're going back and forth, coding assistants do really well if you give them a lot of information. Now that's what this kind of spec-driven development features all about.

So let's imagine some of you are not using Kiro, but you're just using some other coding assistant. How would you do that inside your coding editor? Well, you can do this manually. There's also some nice open source projects out there, but essentially what you do is you tell your coding assistants, you tell the AI, build a user requirements document, and have it what I specify exactly in there. Then you tell it to take that requirement, you add it into the context, and then you have it build a design document. So take kind of those high-level requirements and let's build a design around it. And then finally, let's create a task list, steps one through 10 of how to build this feature. You can do this all manually, just going back and forth and creating these documents.

So let's see an example of that in just in my slides here. We can give it a prompt here. We would choose spec mode, build a full stack application for my company's dashboard. Now that's pretty vague, but the coding assistant, in this case Kiro, would try to take that prompt and break it down into three parts, the three parts I just mentioned. So in this case, it would come up with a requirement phase. So this has all like an introduction, requirements one, acceptance criteria, and it has a very detailed, and you would go through this and double check to make sure it looks okay, that it didn't hallucinate anything. You'd also probably add some information into your context even before you start creating these files, so it understands better what you're trying to do.

Those are things called like rules files or steering files. Then it would create a design based off that requirement where it would basically explain the whole architecture. What are we using in the backend? Are we using PHP? Are we using like a meta framework like Next.js or Nuxt? And it would break all those down, and then you can go back and forth with the coding editor, coding assistant, and refine this or just update or delete things. And then of course, at every single part, you would review the markdown files for inconsistency, hallucinations, errors, any problems that you see. And then it would come up with a step-by-step guide on how to implement this feature or this larger task.