Transcription
Look, we're living through this incredible moment right now where AI can actually write decent code for us and build entire applications in minutes. Yes, I'm talking about wide coding. Here are some videos that I did recently that show the power of these AI coding agents.
But here's what most developers are missing. While everyone's focusing on better prompts and flashier demos, the real difference is in writing great specifications for AI to write great code. That's where GitHub's new tool specit comes in. It's bringing specdriven development at the front and center of AI coding. Exactly what we need.
For decades, code has been king. Specifications were just scaffolding that we built and discarded once the real work of coding began. For the AI written code, we need more than just better prompting. We need specdriven development.
What is specdriven development? Well, your specifications become executable directly generating working implementations rather than just guiding. The spec isn't documentation anymore. It's the blueprint that builds your software.
If you're new here, I am Priyanka Vgardia, a cloud and AI expert with 15 plus years of experience at big tech. And in this channel, I talk about careers and tools in tech.
So, let's be honest, wide coding with AI can be a total mess. You have this brilliant idea. You throw a prompt at your AI assistant and what you get back is well, a code that almost works. Let me say something like, "Hey, Copilot, build me a React to-do app with drag and drop local storage and dark mode. Make it look professional." And you're like, "This is it. AI is amazing. It's generating code." And then you run it and oh well, sometimes it's all good. And the other times it just doesn't work. You fix the color. Now there's something else that's wrong.
And this is where it gets interesting, right? You start playing this weird game of prompt tennis with your AI. Add error boundaries. Fix the local storage. Each prompt feels like it's going to be the one that fixes everything. But here's what actually happens. You end up in this beautiful chaotic dance where you're basically debugging code that you didn't write, trying to explain to an AI coding agent what you think might be wrong based on error messages you're not entirely sure what they're trying to say. And after like 47 some prompts, you're sitting there thinking, I could have built this myself from scratch in half the time.
We have a solution for this now. spec kit by GitHub. I will show you a full demo in just a little bit. But if you want to jump to it, use the chapters below to do so.
So see, when you wide code, you're essentially asking an AI coding agent to be your mind reader. You give it this high-level idea and expect it to somehow know all the implementation details, right? The edge cases, your preferred architecture patterns, all of it. It's like walking into a coffee shop and saying, "I want something caffeinated that tastes good." And expecting the barista to nail your exact preferences for a medium roast oat milk cortado with a dash of cinnamon. The AI is incredible at following instructions, but terrible at filling in the gaps that we leave. And those gaps, they are massive. When we're talking about coding.
That's where specdriven development comes in. And honestly, this is exactly what we need for AI coding. So, GitHub just released this open-source toolkit called SpecKit that basically codifies this entire approach that I'm talking about. And when I say it eliminates the guesswork, I mean it literally prevents those 47-some prompts that I talked about, the debugging sessions from ever happening.
So here's how it works. Instead of throwing vague prompts at your AI coding agents and hoping for the best, SpecKit structures everything into four clear phases. Now, think of them as guard rails that keep both you and your AI on track.
That's where specdriven development comes in. And honestly, this is exactly what we need for AI coding.
Now, phase one is specify. This is where you describe not just what you want to build, but why you're building it and who it's for. The AI coding tools takes this and creates a detailed specification document that becomes your single source of truth. It's like finally giving that barista your complete coffee order plus your dietary restrictions plus how much caffeine you need based on how much sleep you got last night. This isn't about technical stacks or app design. It's about user journeys, the experiences that you want the user to have and what success looks like. Who will use this app? What problems does it solve for them? How will they interact with it? What outcomes matter? Think of it as mapping the user experience you want to create and letting the coding agent flesh out the details. Now crucially this becomes a living artifact that evolves as you learn more about your users and their needs.
Then comes phase two. Now you get technical. Here you define your tech stack, your architectural decisions and your data models. You're basically setting the rules of the game before the AI starts playing. If your company standardizes on certain technologies, this is where you say so. If you're integrating into legacy systems, have compliance requirements, or have performance targets that you need to hit, all of those go here. You can also ask for multiple plan variations to compare and contrast different approaches. If you make your internal docs available to the coding agent, it can integrate your architectural patterns and standards directly into the plan. After all, a coding agent really needs to understand the rules of the game before it starts playing the game, right?
So that brings me to phase three. Phase three breaks down tasks. Instead of one giant build me an app sort of prompt, you get a prioritized list of small testable specific tasks. Each task is focused enough that the AI can nail it in one shot and you would require less debugging sessions. The coding agent then takes the spec and the plan and breaks them down into actual work. It generates small reviewable chunks that each solve a specific piece of the puzzle and each task should be something you can implement and test in isolation. This is crucial because it gives the coding agent a way to validate its work and stay on track almost like a test-driven development process but for your AI agents. Now instead of build authentication, you get concrete tasks like create a user registration endpoint that validates your email format.
Now that brings me to number four. The phase four is where the magic happens, the actual implementation. The coding agent works through each task individually and you can review, test, and approve each piece before moving on. But here's what's different. Instead of reviewing thousands of lines of code dumps, you, the developer, reviews focused changes that solve specific problems. The coding agent knows what it's supposed to build because the specification told it to do so. It knows how to build it because the plan told it to do so. And it knows exactly what to work on because the task told it to do so. It's like having a really good junior developer who always asks clarifying questions and shows you their work before committing those changes.
Crucially, your role isn't just to steer, it's to verify. At each phase, you reflect and you redefine and you refine. Does the spec capture what you actually want to build? Does the plan account for real world constraints? Are there omissions or edge cases that AI has missed? The process built in explicit checkpoints for you to critique what's been generated, spot gaps, and course correct before moving forward. Now, the AI generates the artifacts. You ensure that they're right.
All right. Now that we know what specit is and what specdriven development means, let me show you exactly how it works. I'm going to start from a completely blank VS Code workspace and build a functional to-do app.
Okay, so the first thing we'll do is specify the project itself where we want to use spec kit. I've got four different coding agents that you can use this with at the time of my recording. GitHub Copilot, Claude Code, Gemini, and Cursor. I'm going to use it with GitHub Copilot for the purpose of this demo today. And I'm using PowerShell and it initializes the specified project for checking requirements, script types, and all sorts of different things that it will do. And then I'm already in the right repo and the directory. Um, so the second thing I can do is start using this right away. Specify task.
So I am back in my VS code where I've got the specify folder that it created on its own and I've got memory constitution MD which which is where all the specifications are defined. Um, and then it also has the scripts and the templates tab. I'm not reading through any of that yet. I go in and I want to first see what do I need to do. So I am doing slashsp specify and describing a personal to-do app and I have some description of the app here. What do I want to do with this app and what do I want the user experience to be like which is all the things that we discussed in the specify portion and it's starting to go off and put that in create new feature.asuchet file in the specify folder. There we go. It has created a spec.md file where it has all of the different descriptions of what needs to be specified for this application to be made.
Then I go in and add the plan. So slash plan takes me to the plan. And this is where I'm defining my architectural details and what I want the tools and the stack tech stack to look like. And that is going in to the setup-plan.sh file. It creates this file on its own. It creates the research, the data model, the plan, the contract, the storage.mmd, all of the different things that it needs, the quick start.md, the tasks that we will use in the next section. No errors were detected. Perfect. That's exactly what we want.
So, our specifications and our planning is done. Now we're going to go ahead and implement the tasks slashtasks takes me to the tasks and I just said follow the task file and create the tasks. So it goes off and checks the task prerequisites.sh sh file and starts creating the different tasks that are needed to implement the specifications and the plan.
Now I'm checking the task.md file. It has a few things in there, but that's where we expect a lot more to be added. This is exactly what's happening. It's updating the slashtask command is updating my task.md file with a much more detail in there. It created 13 tasks testable parallel groups file paths and command examples and um I'm checking there's storage there's implementation there is task context there's quick ad component different tasks.
Now I want to implement so I'm just asking it to implement task 001 to task ask 13. And just for the purpose of the demo, I you typically do it one at a time, but for the purpose of the demo, I just went ahead and asked it to do all and wanted to see how it does. So now it starts to get to work and implement these tasks. Creating package.json JSON index. HTML, the config file, the JSON, the front end file main. You're seeing all of the the file different files being generated on the left and in the right as it's doing them. And finally when it has done all the tasks it tells me the summary of what has happened. If you want I can run and install this.
And once it was done giving me all the tasks. I did not bother to go check what it did and how it did it. But um once it was done doing all the tasks, I wanted it to run the MVP version locally. And so I just gave that command and it's trying to run it in the terminal. npm install. There we have it. It's running on localhost 5173. And when I click on it, it shows me a personal to-do list, a quick task, and it's all set, right? It built an entire AI application. And just like that, we have a functional to-do app.
But let's talk about why the spectrum development approach actually succeeds where woding or just prompting fails. Well, it comes down to a fundamental truth about how language models work. They are exceptional at pattern completion but terrible at mind reading. When you throw a wig prompt like add photo sharing to my app at an AI coding agent, you're forcing it to guess at potentially thousands of unstated requirements. The AI will make reasonable assumptions and some of them will be wrong and you won't discover which ones until you're deep into implementation. But when you provide a clear specification, a technical plan, a focused task approach, you're giving the coding agent actual clarity instead of focusing it to guess. Instead of mindreading your intent, it knows what to build, how to build, and in what sequence.
This is why this approach works across different technology stacks. Whether you're building in Python, JavaScript, or Go, the fundamental challenge is the same. Translating your intent into working code.
Now, specdriven development is useful everywhere, but there are three main scenarios where it becomes absolutely game-changing.
Now, the first is green field projects. When you're starting something completely new, it's so tempting to just dive in and start coding, especially w coding right now. But spending just a little time creating a spec and plan upfront ensures the AI builds what you actually intend not just some generic solution based on common patterns that it has seen.
Now second is feature work in existing projects. Now this is honestly where specdriven development becomes more powerful. Adding features to a complex existing codebase is hard right? But by creating a spec for what new feature, you force clarity on how it should interact with everything else that's already there. The plan then encodes all of your architectural constraints, ensuring that your new code feels native to your project instead of just bolted on or band-aid. This makes ongoing development faster and way safer.
And the third use case is legacy modernization. When you need to rebuild a legacy system, the original intent is often completely lost to time. With specdriven development, you can capture the essential business logic in a modern spec. Design fresh architecture in the plan and let the AI rebuild the system from scratch without carrying forward all that inherited technical debt.
So, if you're tired of playing prompt roulette with your AI coding agent, definitely check out SpecKit on GitHub. It's completely open-source and ready to use right now. I will drop all the links in the description below so you can see the full specdriven development approach in action. And hey, if you build something cool with Speckit, definitely drop a comment below. I would love to see what you're doing. If you like this video, you will definitely enjoy my other video on GitHub Spark here. Until next time, happy coding.