A simple app that lets users add shopping items, mark items as purchased, delete items, and preserve the list across browser sessions using local storage.
Behind this: 13 build steps · 4 tools and how each is used · how to validate demand · 1 more real example · 7 things the video never answers.
Searchable transcript of Stop Vibe Coding: Build Better Apps with Spec Kit — IBM Developer (13:58). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by IBM Developer. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 Have you been vibe coding? If you've ever asked an AI coding agent to build something for you, you probably know the drill. You ask for something. You get something back. You ask for changes. You get something else back. You ask for more changes and, well, it just gets really, really tiresome to get an AI to understand exactly what you want it to build.
00:20 Well, I think there's a much better way. I'm going to show you how to use spec-driven development. Instead of just prompting an AI to make you an app, define rules for the project, a feature specification, an implementation plan, a task list, and then take all of those documents and use those to guide the AI, step by step. By the end of this video, you'll understand how spec-driven development works and how to use Spec Kit to build apps in a much more reliable way.
00:47 The big idea behind spec- driven development is really simple. Before the AI writes code, define exactly what should be built. That means that AI is not getting product requirements, inventing edge cases or making random architecture decisions. It's actually implementing a spec. And that's exactly where Spec Kit comes in. Spec Kit gives you a structure using something called a constitution, where you define your project rules; a spec, which defines the feature; a plan, which defines the implementation approach; and
01:18 tasks, which break the work into steps for the AI agent. In this video, I'll walk you through the full workflow using a small, simple app idea. The app we're going to build is a really, really simple shopping list. Users can add items, mark items as purchased, delete items, and keep the list saved in the browser with local storage. This is a really small project, but it makes it perfect for learning the Spec Kit workflow.
01:47 So the first thing I'm going to do is I'm going to create an empty project folder and open it inside IBM Bob, which is what you can see in front of you here. And once we've created that folder, we need to initiate the Spec Kit CLI within it. So I'm going to open up a terminal window and I'm going to type in specify init. And since it's going to be in this folder itself, I'm just going to press the enter button.
02:12 Now as you can see, Spec Kit then pops up and it asks me what my coding agent integration is. And I'm going to go through this and I'm going to select Bob. It then says to me, what script type do I want to use? So I'm going to use the POSIX shell. And as you can see now on the left-hand side, Spec Kit's gone and scaffolded a couple of folders as well as an agent's markdown file.
02:41 Now, from this point onwards, we can close this terminal window and we can actually open up IBM Bob. And the first thing I'm going to do now that Bob is open is I'm going to ask it to read the contents of this project. We want to make sure that IBM Bob realizes that this is a project that's being driven by, by, uh, Spec Kit. Ok great. So as you can see, it knows that the project's core shopping list, it's brand new and it's empty and it's been bootstrapped with Spec Kit, a spec-driven development framework.
03:18 No application code exists yet. OK. And if you want to, you can go through some of these folders and see what's in here. But in essence, there is a lot of, um, scripts and markdown files that we're going to be using with the AI agent. Bob is also telling us that there are specific commands for Spec Kit that we can call for creating a feature spec or an implementation plan, or to break down tasks or to implement them.
03:49 And as you can see, Bob is already telling me the next step would typically be to define the constitution and then run through the spec-driven workflow to build out the shopping list application. So let's do that, OK? So the way that we're going to do that is we are going to define our constitution. Now remember, the constitution defines the rules of the project.
04:18 It's not the actual, uh, scope of what the project does. So I'm going to put some things in here that I think are important for, uh, being in the constitution. So things like, keep it simple. Since this is a simple demo, I want to use vanilla HTML, CSS and JavaScript. Make this keyboard accessible, persist data with local storage, and we should probably say to avoid any unnecessary frameworks or abstractions.
05:13 We want to keep this really, really simple. OK. Now as you can see, Spec Kit is going off and it's updating various files here. OK? Let's approve that. And if we have a look in specified memory, there's a constitution file. So if we go into .specify and memory, here we have our constitution file, and I'm just going to move this over a little bit. So here we have it.
05:40 We have a constitution here based upon what I provided. Spec Kit. OK. Excellent. I'm happy with that. Now Bob itself is telling me the next step in the workflow would be to write a feature spec for the shopping list app. So let's do that. Let's trigger /speckit.specify and let's write the feature spec, which is basically explaining what the app does, what the goals are, what the nongoals are, functional requirements, acceptance criteria, that kind of thing, OK?
06:19 So, for this shopping list app, let's add some specifications. Users can add an item, mark item as purchased, delete it, keep data across sessions. We should also tell it what we don't want it to build. So, do not build authentication, no sharing, no sync across devices because we want this to be a really, really simple app that just works locally. And let's not even have any categories.
07:10 Now bear in mind that it's really, really important to not just put things into the specification that you want the AI to build, but also things that you don't want the AI to build. Because if you leave agent, AI agents unfettered, they love to overbuild. And you need to tell them where the boundary is. Now there's a new folder called specs, and we have specs 001.
07:35 OK, and here is our first feature specification. The status is Draft. Users can add an item mark it as purchased here. Yep, that's exactly what we asked for. And it's converted this into user stories. And it's really great how Spec Kit uses the Given - When - Then format. This really, really helps give us a testable definition of Done. OK. Now as you can see, the AI agent is now telling me it's ready for the next phase, which is to run /speckit.plan to create the technical implementation plan.
08:20 Now, given that we have a specification here with three user stories as well as some functional requirements as well as success criteria, for something as simple as, as this, I think I'm pretty confident to just run this. Can close that back down again. So what's going on with the AI agent right now is this specification. It tells us what to build, but it doesn't tell us how we're going to build it.
08:59 So the AI agent's now using this specification to actually come up with the plan to build it, and this is what the blank template looks like. And this is going to be updated shortly. And here we go. Here's our implementation plan. Now this step is really, really important because it prevents the AI from improvising architectural decisions and creating extra scope.
09:32 I'm going to just minimize the Bob chat window so we can look at it in more detail. And as you can see, the plan's being validated against our constitution. So this is great because now we've narrowed the space even further. The AI doesn't just know the requirements; it also knows the intended technical approach that we want it to take. So the last document that we probably want to build before implementation is our tasks, and as you can see, Bob is already prompting me, telling me it's ready for, ready to break this
09:58 implementation plan into tasks. So let's go for it. Now what's happening is by using that implementation plan and the constitution and the spec, um, the AI is breaking the work into small, concrete steps. And this is one of the biggest improvements over normal AI prompting, where you prompt for something, get something back, prompt again and get something back and get, prompt again and get something back.
10:31 OK, by giving the AI a smaller unit of work, we can review it face by face. Bear in mind that the only thing we've done so far in this demo is only create documentation. I'm waiting for a file called tasks.md show, to show up in the left-hand side. OK, there we go. There it is. So here's the small, concrete steps for the AI to follow now. And as you can see, it's done them in a logical order.
11:01 First we're going to do some scaffolding and setup, then do some foundational stuff and then work on the user stories. This dramatically is reducing the guesswork. And if we go back to Bob, Bob is now telling us that we're ready to start building. So let's do that now. And as you can see, the AI agent's reading all of our documentation. It's implemented Phase 1, which was the setup.
11:33 Now it's implementing Phase 2. OK, it looks like it's finished. So what did we end up with? A simple shopping list app where I can add milk and bread, mark one as purchased, delete another, refresh the page and see everything persist correctly. It's not a huge app, but that's the point. This is a clean example of the workflow. Because we wrote the spec first, the implementation is easier to review, easier to extend, and easier to trust.
12:02 So why is this better than vibe coding? Here's the difference. If I just prompt an AI with "Build me a shopping list app," I might get something workable, but I might also get extra features I didn't ask for. No handling for empty items. No persistence, weak accessibility, random architecture choices, or code that doesn't even actually match the actual product intent.
12:26 With Spec Kit, I define all of that first so the process becomes clarify, specify, plan, task, implement, validate. And that gives the AI a much better operating environment. The cool part is once you've got the structure, adding features gets easier. Let's say I wanted to add categories to the shopping list. I wouldn't just ask the AI, "Add categories."
12:46 I'd create a new spec. What categories are, how users assign them, where the filtering exists, what happens to uncategorized items and what the acceptance criteria are. Then I'd update the plan, write the tasks, and execute again. That's what makes this workflow scalable. So if you want your AI coding agents to work more effectively, Spec Kit gives you a much better workflow than one-shot prompting.
13:13 The core idea is the constitution defines the rules. The spec defines the behavior. The plan defines the technical approach. The tasks define the execution steps. And the AI agent implements from there. That's spec-driven development. And this shopping list app is a simple example, but the same workflow can be used for bigger features, APIs, internal tools, and full applications. I hope you found this video useful and I'll see you in the next one.