0:02 Think about the last time you asked an
0:05 AI tool to write code. It probably gave
0:07 you something that looked correct but
0:09 didn't quite work. That's where vibe
0:12 coding falls short. But it might not be
0:13 a problem with the particular model
0:16 you're using. It's most likely because
0:18 of lack of specification clarity. That
0:21 is where specdriven development comes to
0:23 rescue. GitHub just released a new
0:26 open-source toolkit called SpecKit,
0:28 which completely changes the game. Today
0:30 we're going to look at SpecKit, see how
0:32 it works, and I will show you a little
0:35 demo how to use it, and we'll find out
0:40 if this is really the future of coding.
0:41 In traditional development, you write
0:44 code, then document what it does. In
0:47 specdriven development, you do the
0:49 opposite. You write a specification, a
0:52 living executable artifact, and that
0:54 spec defines what you intend to build.
0:57 From there, all stakeholders and AI
0:59 tools align around the same source of
1:01 truth. This approach closes the gaps
1:04 between intent and implementation and
1:06 leads to cleaner, safer, and more
1:09 reliable code. The main idea is that
1:11 language models are great at patterns,
1:14 but not so great at reading your mind.
1:16 Broad prompts like, "Add photo sharing
1:19 to my app," leaves the AI guessing
1:21 thousands of details, most of which
1:24 never match your real intent. Specdriven
1:26 development eliminates that guesswork.
1:29 It gives AI clear structured guidance so
1:31 it builds exactly what you want. Few
1:34 months ago, Amazon launched Kira, which
1:36 was the first framework to really focus
1:38 on specdriven development. And James did
1:40 an excellent deep dive on that in a
1:41 separate video if you want to check it
1:43 out here. But now there's a new player
1:46 in town, SpecKit. It is GitHub's
1:48 open-source toolkit for specd driven
1:51 development with AI coding agents. It
1:55 features a CLI tool, templates, and
1:57 steering prompts designed to work with
1:59 tools like GitHub Code Pilot, Claude
2:02 Code, and Gemini CLI. It aims to
2:05 transform your ad hoc prompting into a
2:06 structured, verifiable development
2:09 workflow. Here's how it works. Specit
2:11 organizes your development into four
2:14 gated phases, each with a validation
2:16 checkpoint before moving forward. The
2:18 first phase is specify. This is where
2:20 you describe what you want to build and
2:23 why focusing on user journeys and
2:26 outcomes. The AI agent uses that to
2:28 generate a detailed spec which also
2:31 evolves as your understanding grows. The
2:33 second phase is plan. This phase defines
2:36 the stack and architectural constraints.
2:38 You tell the agent your specifications
2:40 and it constructs a technical plan that
2:43 honors those constraints. Third phase is
2:46 tasks. This is where the spec and plan
2:48 is broken down into small actionable
2:50 tasks. This gives you manageable
2:52 testable units that AI can implement one
2:54 by one. And the fourth phase is
2:57 implement. This is where AI tackles
3:00 tasks incrementally. You can review each
3:02 change before implementation instead of
3:04 running bulky code dumps. That way the
3:07 model knows what to build, how to build
3:09 it, and where to focus. You can verify
3:12 and refine this at each step. It gives
3:14 you total granular control over
3:16 execution. This toolkit was born out of
3:18 frustration with the coding models
3:20 behaving like a search engine instead of
3:23 a literal-minded pair programmer. At its
3:26 core, it's a shift towards intent as the
3:29 source of truth. Instead of code, the
3:31 spec becomes the authorative artifact
3:34 and the models constantly circle back to
3:36 the spec document for guidance on how to
3:38 proceed. So now I'm going to show you
3:40 with a little project how we can use
3:42 specit in our own projects. To kick
3:44 things off, you just need to run this
3:46 command in your terminal specifying your
3:49 project name and then choose which
3:51 agentic framework to use. In this demo,
3:54 I will be using GitHub copilot. The kit
3:56 will initialize all the necessary files
3:57 for your project and then you can
4:00 proceed to open the workspace in your
4:01 code editor. The first thing you will
4:03 see when you open the code editor is
4:05 that specit has created this script
4:08 folder and templates folder. And these
4:10 are just boilerplate spec templates
4:12 which are used to generate your actual
4:14 spec files. And the scripts are the ones
4:16 that execute and prepare those
4:17 documents. We don't have to change
4:19 anything here. We can just go ahead and
4:22 prepare our project by typing specify
4:24 followed by our prompt. This initial
4:26 prompt should be an overall description
4:28 of your project. what the goal is, what
4:30 the basic features are, and maybe even
4:32 describe what a simple user journey
4:34 looks like. In this example, I will be
4:37 creating a simple Pokedex team builder
4:39 where I can search for Pokemon and add
4:41 them to my team. I will also be using
4:44 Gro Code Fast one as the base model for
4:46 this project. So, let's go ahead and run
4:48 the command. And once that's done, you
4:51 will see that specit has created a new
4:53 branch for this development and it has
4:56 also created a spec markdown file. In
4:58 this file, we see that the model has
5:00 successfully understood the assignment
5:03 and created a primary user story along
5:06 with acceptance scenarios. I also like
5:08 that it thinks about edge cases as well
5:10 and other potential roadblocks. And
5:12 whenever the model comes to a situation
5:15 where it can't decide on a path forward,
5:17 it will add this block titled needs
5:20 clarification. So you can specify the
5:22 requirements yourself. And we can also
5:23 see here that it has crafted some
5:26 functional requirements and key entities
5:28 as well. Honestly, this is super cool
5:30 because I would be too lazy to write out
5:32 all these specifics for the model to
5:35 follow. So, it's good that spec kit is
5:37 able to guide the model to craft all of
5:40 this for us. And remember, if you ever
5:42 need to change something here or decide
5:44 on a totally different direction to
5:46 take, this is the file where you can
5:48 make those edits. But if we're happy
5:50 with the spec file, next we can proceed
5:52 to the plan phase. And here we should
5:54 more concretely describe the tech stack
5:56 of our application along with other
5:59 details that we deem necessary. Here I
6:01 just pasted in some basic technical
6:03 requirements for the project along with
6:06 some other helpful commands like using a
6:08 debounce on the Pokemon search endpoint
6:10 so we don't overwhelm the API. And once
6:12 you're happy with all of that, let's
6:14 execute the plan command. And you can
6:17 see here that specit gets more detailed.
6:19 It adds a data model and a research
6:22 document as well as contracts for the
6:25 object types which is super cool. And in
6:28 the data model file, it even crafted a
6:30 zod schema object. But I really love the
6:32 research document because here we can
6:35 see the ration behind the model choosing
6:38 specific frameworks and it also gives us
6:40 explanations about its reasoning along
6:42 with other considerations for
6:44 alternative solutions and it also
6:47 respects the text stack choices you give
6:49 it plus it tries to think of other
6:51 necessities which you might not have
6:54 considered as well. So that is really
6:56 powerful. So then we move on to the plan
6:58 file which has laid out all the
7:00 development phases in concrete steps and
7:03 it has also ticked the ones that are
7:05 already completed. This all looks very
7:07 good to me. So now we can move on to the
7:10 next phase, the task execution phase.
7:12 Now we already have the spec and plan in
7:14 place. So for the tasks command, we can
7:16 just start by asking the model to create
7:19 an MVP version of our project. And this
7:22 is where the magic happens. SpecKit will
7:25 now create a very detailed tasks list
7:27 which outlines step by step what we need
7:30 to do to get to our development goal.
7:32 Let's open up the tasks list. And we can
7:34 see here that it has given every task a
7:37 unique number. And that keeps everything
7:39 well and organized. So you can execute
7:42 tasks in order and review them as you
7:44 go. I see here that tasks one to four
7:46 are dedicated to setting up the
7:48 environment. So let's go ahead and ask
7:51 the model to execute those. There is no
7:53 slash command for this phase, but as I
7:55 understand the recommended way to
7:58 proceed is to write implement followed
8:00 by the task numbers to tell the model
8:02 which tasks to execute at the specific
8:04 given command. So first let's run the
8:06 setup tasks so you can also keep track
8:08 of the progress. So from here on out
8:11 it's a very free flow approach of just
8:13 asking the model which tasks to
8:15 implement and then just following along,
8:17 seeing the progress and iterating on the
8:20 process. And once they're done, we can
8:22 see that the model has also ticked them
8:24 as completed. I noticed that in this
8:26 particular template that they have, it
8:28 very much likes the test-driven
8:30 development approach where it writes the
8:32 tests first and then implements the
8:33 features. You can probably change that
8:36 in the spec or the plan if you want to
8:38 go for a different development approach.
8:40 So after a few commands and iterations,
8:42 my model has finished implementing all
8:45 of the tasks. And here's the result. As
8:47 you can see, we have a nice little
8:49 functioning Pokedex where I can search
8:52 for any Pokemon and add them to my team.
8:54 The API seems to be working perfectly.
8:57 And the project also looks very clean.
9:00 It uses Chats and UI elements as I
9:02 prompted it to do. And by the looks of
9:04 everything, it's very well and
9:06 functional. So, there you have it. We
9:08 just vibecoded a nice little web project
9:11 using SpecKit. I hope by now you see how
9:14 this meticulous specdriven development
9:16 approach can help improve the AI model's
9:19 ability to craft a cleaner, more refined
9:21 code. It also gives you more precision
9:24 to steer the model in the direction you
9:26 want to go. And I do have to mention
9:28 that although SpecKit is designed to
9:30 work with most of the coding models, the
9:33 choice of the coding model still makes a
9:35 difference. While testing out this tool,
9:37 I also tried scaffolding a project using GPT4.1
9:39 GPT4.1
9:41 and it didn't give me as good of a
9:43 result as when I used the Grock model.
9:45 So, choosing the right coding model is
9:47 still necessary to achieve the best
9:49 results. It's clear that specdriven
9:51 development is a paradigm we'll be
9:53 seeing much more of in the future of
9:55 coding. But what are your thoughts about
9:58 specit? Are you using specdriven
10:00 development in your coding practices?
10:02 Let us know in the comments down below.
10:04 And folks, if you like these types of
10:06 technical breakdowns, let us know by
10:08 smashing that like button underneath the
10:10 video. And also, don't forget to
10:12 subscribe to our channel for more videos
10:14 like this one. This has been Andress
10:16 from Better Stack, and I will see you in
Chrome Extension