Transcription
90% of AI coding fails because of one simple ingredient: structured context. Because it forces you to think about exactly what you are providing the model. So, it's no surprise that when the Kira IDE was released from Amazon, everyone was super stoked. The only problem was that unless you hopped on day one, you probably didn't get access to it. So sad.
But while everybody's fighting for Kira access, GitHub just released its own version for free. So in this video, I'm going to show you how to turn Cursor or Gemini CLI or Cloud Code into a production-grade development system in just under 15 minutes. We'll go through each of its three phases: specifying what to build, planning how to build it, and then tasking out the execution.
This video will be really good for you if you already code with those tools, but you still have those frustrating moments where you waste hours and hours with code that you end up having to throw away. Now, the third phase uses a hidden prompt structure that I think is the key to why this system works so well. So, make sure you stay tuned for that.
So, now we're going to get in and we're going to install this thing. Now, one of the biggest problems that vibe coders face is that they approach the project with like a stream of consciousness. But when you're trying to build high-quality software or something bigger, that approach causes a lot of problems because you start Frankensteining things together and you experience significant context loss. And you probably know the pain I'm talking about. The moment you clear the context or start a new chat with Gemini or Claude or Cursor, it starts suggesting patterns or building things that conflict with what you just built.
And so spec-driven development can help us overcome those problems because we flesh things out in detail and plan in layers, and then we refine that plan as we go along before we start building. In other words, instead of just guiding our implementations, the specifications become what the system actually follows. So specit has three core phases: we have the specify, plan, and then tasks. So first, we want to describe what we want to build on a high level, right? The what and the why. Then we want to refine that down into a plan, and then we chunk that plan down into tasks.
Now, the only prerequisite here is that you have to have UV downloaded. I will have a link to this down below. If you use Homebrew, you can install it pretty easily with their command here, but they have a lot of different options depending on the exact system that you prefer to download this with. So, this is the first thing: you need to have UV installed. From here, all you need to do is copy this command. And then we're going to hop into our terminal and we're going to initialize this thing. So the easiest way to do this is just go into the directory that you want to have this working with. Paste in that command. And then after the init type dash here, it's then going to take you through defining what is the AI assistant that you use. We can say Cloud Code. I'm going to choose bash for my scripting. And then it's going to go through and everything is going to be set up and configured. So let's go look at what we have.
And so what you're going to notice first inside of your file tree is that you have this directory now called specify, and then it also created three slash commands inside of Claude. Now, this system is really the secret sauce that makes this whole thing work because they're loading in templates of how to do these different pieces, scripts that the system can use to actually execute the different pieces. And then it keeps a running memory of important stuff about your project that you can come in and you can modify. And then all of this stuff gets actually executed through Claude commands, in this case, because we're using Claude. So we basically just installed a junior architect that will never forget your context. But now that it's actually connected, let's put it to work.
So going back and referencing this GitHub repository, the first thing we want to do is use this specify command. So, we want to tell it exactly what we want to build because without this specificity, we're relying on the interpretation, basically, of the language model to fill in those blanks for us. Which begs the question: is it us building the app, or are we just deferring all decision-making to a language model that's just going to do what it wants to do? Well, we really want to drive this system because if you don't do that, you're going to end up with a lot of outputs that you do not like because every ambiguous requirement is basically going to turn into 100, 200, 300 lines of ambiguous code that doesn't even do what you wanted it to do. So, if you skip this, you're going to end up rebuilding the same feature three, four, five times, and ain't nobody got time for that.
So, let's use this to add a feature to an existing app. So, here's a basic app that I have that I use for myself, and we're going to use this to add a new feature into our app because I've had a lot of you guys asking, "You seem to build everything from scratch each time. How can we just add existing features into apps with these tools?" So, that's what I'm going to show you. So, when I first built this, I had this idea that I would have a version history. Meaning, if I go in and I make changes to this prompt and then I'm using it and I want to see like which prompts are actually getting me the best results over time, I would be able to track that and then be able to revert back to previous versions of prompts that I use a lot. So, we're going to build out this version history feature.
So, I'm going to prompt it here with slashspecify and then I'm going to put in what it is that I'm intending to build. I want to add a feature into the app that tracks the version history of prompt changes, and a user should be able to view like a side-by-side diff of those changes. So I'm going to hit enter and run this. So once that thing finishes running, what you're going to notice is we have this new specs directory that got created, and then inside of it, we have this first feature specification called spec.markdown. Now, the thing that's really nice about this is it goes through, it looks at what you're intending to build, and then it leaves all of these areas that say "needs clarification." So, these are like specific questions that the system has for you that you need to fill in in order to have a really well-defined, fleshed-out feature that works the way you want it to out of the gate and doesn't have all these weird edge cases that aren't accounted for.
So this is a major win because it allows us, at this stage, to hash out all of that ambiguity and actually dial in the plan before we start going to the next planning phase. So what are some examples? Is the user able to actually revert to a previous version? What happens when a prompt is deleted? Do you delete all the version history of that, and it's like gone? Do you allow multiple users to edit the same file at the same time? Like, does there need to be a collaboration feature? What are the maximum number of versions that can actually be retained in this thing? All of these different questions that we need to answer. And then once we get down to the actual functional requirements, we have that same set of clarifications that we need to give the system. For example, how long should the version history actually be stored for? These are all things that we want to think about so that the system builds exactly what we want it to build.
So, I've gone through and I've reconciled all of the ambiguities. And so this is great because now we have this very specific list of requirements that need to be completed for us to consider this thing actually complete. And so again, this forces us to really think about what we're building and not waste time down the road. So by forcing yourself to think about the requirements upfront, you're basically becoming a product manager for your own projects. So this five-minute investment saves you five hours of refactoring down the line. And more importantly, it prevents that endless cycle of "meh, this isn't exactly what I was trying to build." Because that feeling is what really kills your momentum and ruins that starry-eyed dream you have of building something dope.
But once we have that, do we just jump straight into the tasks and the coding? No. We need to turn those specifications now into a real plan. So we have this list of requirements, but now we need to transition through to how we intend to actually implement them. Because for a seemingly simple feature, there's a lot of ways you could approach it, and there's a lot of research you should be doing to make sure you execute it right. So if you skip over this planning phase, you're going to code yourself into a corner that requires a complete rewrite. So this type of process is how real development teams prevent these architecture disasters. And hint: this is why a lot of real software developers flocked to Kira when it first came out, while vibe coders were kind of just sitting on their hands with it.
So now we're going to run this plan command, and here we can give it any specifics like text stacks or other architecture choices that you already have in mind. Now, for this project specifically, I am already using Supabase and Next.js and a bunch of other libraries, and so it's already there. So I'm just going to reference those things. But if you are building something that's going to require a new tech to be involved or be used, you can specify that here. And now you're going to notice once this step is done, we get a lot out of it.
So not only do we have this full planning file with a lot of details about how to actually implement this thing and the tech stack and where things integrate, but we get a lot of other stuff too. So we get this research document that talks about key architectural trade-offs or decisions that were made, why that decision was made, and what alternatives were considered. So this is really helpful to kind of go through and see the context of what it decided to do. We also get our data model out, meaning we're going to have a pretty clear understanding of what our data needs to look like in order to actually implement this type of feature for this version history and all the different definitions related to it.
Now, another really awesome thing we get out of this is called an API contract. Meaning, it's going to list out in detail all of the different endpoints in the API for this feature and the specific parameters that it accepts, as well as what it's going to respond back to on the front end. Now, the reason that this is really important is that this is going to become the source of truth for everything we build on the front end for this feature because we already know what the backend is going to have access to, what it expects to receive, and what it should be sending back.
So now, really the last stage of this is to generate the tasks for this plan. Now again, a lot of people skip this step and wonder why their code feels fragmented or janky. Meanwhile, we just got $5,000 worth of architecture consulting in a few minutes from GitHub SpecKit. But by doing this research properly and putting specifics into your architecture, you're setting your future self up for success. And so, this is the difference between building something that kind of works but breaks a lot versus something that's actually scalable.
So, we've got all of this great stuff: our plan, our research, our data model, our contracts, quick start guide, all of that type of stuff. The last thing we need to do is generate the tasks. And so the real hurdle here, and this is why I love this tool because it helps overcome this, is that we don't want task seven contradicting something that we did in task three. And so that's why I love this approach because our task lists have direct references to what we made in previous stages. And tasks without context are basically just sophisticated to-do lists that don't necessarily know what you already did. So the real value here is that we get a very true set of tasks based on the work we put in in those other stages.
So we just kicked this off inside of Cloud Code. Let's let it finish. Now we can see as this thing is going, it's pulling in all of the documentation that it had made. It's reading the plan. It's reading the data model. It's checking out the API contracts. It's understanding the quick start guide that it had. And now it's loading in its template for how it's going to make the tasks. And it's going through and actually building out that task file. And so here's what this task list looks like once it is finished. So it's a really clear phased approach with a lot of detail and specificity about where to find existing data, where certain files should be placed, how certain files should interact with one another. And so we can go from here and we can implement these tasks.
All right, guys. So this is what the final version of this looks like after that first pass. So we created this little version history tool. Let me actually just refresh the screen so you can see what it looks like. So if I were to come in here now and I were to edit this, let's just say I paste this in a bunch of times and I hit save. So now what we can do when we scroll down, we have this version history tracker. So I could say I want to compare version one to version four, for example, and hit compare. And then down here, we're going to get like this Git-style diff between the changes that we made between each of those different pieces. So, obviously, all the changes I made were up here. And so, that's why it's showing me that. So, pretty cool. And again, all of this done with this GitHub SpecKit. And the development on this, by the way, was actually pretty fast, relatively speaking, given how much detail is going into building this thing correctly the first time with all of like the tests that it does and all of that type of stuff.
So this context preservation means you're not starting from scratch every time you clear out the context and start building a new feature. Basically, you've created a repeatable system for taking ideas and turning them into something you can actually build with, which is the holy grail of AI-assisted development.
"You have chosen wisely."
So now that you have the reusable blueprint, tackle the next feature 10 times faster. So remember, guys: three phases, zero ambiguity, production-ready code every single time. This creates a system for repeatable success, which would be great if we had a lot more of that in our lives. Spec-driven development isn't about slowing down. It's about never going backwards again. So get on out there and use this system for yourself. For more actionable tutorials like this, make sure you subscribe to the channel so that you don't miss out on the next videos. But that's it. I will see you in the next.