Spec Driven Development is Slowing You Down: Here’s a Better Way Transcript, AI Summary & Key Points

Hey guys, welcome back. So this week saw an interesting release from the big boys GitHub in the form of Specify. So essentially it's a specd driven development tool. And in this video we're going to check out whether it's actually worth using or not. And what we're going to do to prove that out is we're actually just going to build an app. We're going to vibe code one and we're going to use spec mode in the other.

So originally my goal was to create a tutorial on how to use spec kit. But after running a few bills, I decided to do a completely different video. So, let me give you a little bit of context. So, Vibe coding took the world by storm when it allowed everyone, including 8-year-old girls on Twitter or X, to create apps without writing any code. And while this is a superpower, it kind of became obvious that you still need to understand how apps are built in general in order to make the most out of these tools.

Otherwise, you just end up in this kind of spaghetti code and lots of errors. So the answer to vibe coding to solve this spaghetti code was the idea of specd driven development. So this is creating a plan, a set of documents for agents to follow instead of just feeling around in the dark prompt by prompt. And this is a good idea, but I think the pendulum has swung too far the other way from vibe coding towards too much specification.

We've gone from vibing to being bogged down in spec files and frameworks that to be honest are really just chewing through a ton of tokens and not being used properly. So instead of a long tutorial on how to use spec kit, I'm going to quickly cover specit, show you how it works so you can try it out yourself, the pros and the cons of it, and I'm going to show you the outcome of a sideby-side test where I built the same app without spec kit, just vibe coding.

And then I'm going to give you my insights into where I think spec driven development fits versus vibe code and what I actually recommend as a middle ground based on my working with agents to develop apps over the last 2 years. So apologies if this is a departure from my usual video style. It's not going to be full of cuts and graphics and fancy things.

I'm just going to basically lay out my thoughts and hopefully that's valuable to you. So there are lots of different frameworks to help you with specd driven development. So, one of the more popular ones is BMAD. I covered that in my channel a few weeks ago. Highly recommend taking a look at that. I actually think it's a good implementation. I have my own version that I did back in February.

It's called the three experts approach. I'll link to that in the description as well. And then you have a spec mode that's built directly into the editor like Kira, which I also covered in the channel a few weeks back. So, now we've got a spec kit or specify or specify, whatever you want to call it, from GitHub owned by Microsoft. So, not a small company.

And this is their offering. And I actually think the implementation is quite good, but it has its pros and cons. So to check it out, go to spec kit. You can go to GitHub spec kit to get it. And you just run this command in whatever folder that you want to kick started. So you're going to need UV installed in order to get this to work. If you don't have that, just ask chatbt how to get that installed.

And then you just type this in with a nit project name. Now if you've already got the project set up like I normally do. So if I have Nex.js JS or something like that. Instead of putting in project name, just put in dash dash here and then it will actually set it up in that project folder. So you can see here, this is how I run it. I just hit return and then we're going to get this CLI that pops up and then you just follow the prompts.

It'll ask you if you're going to run this with GitHub Copilot, Gemini, or Claude Code. In this case, I picked Claude Code. Now, I have been using GPD5 a lot more recently because there have been some documented issues with claude code in terms of quality and Tropic just came out yesterday admitting to some issues. So, it'll be interesting to see if those are resolved over the coming weeks.

So, as I said, I was going to give you a full detailed tutorial, but I'm just going to give you the TLDDR or the most important parts I think you need to know. So, it goes and creates this.clude folder with your slash commands in here. And these three commands, plan, specify, and tasks are all that you really need to know in order to run this system.

Everything else is basically managed for you. So if I was to type in here slashsp specify, uh I would follow this prompt with an explanation of what it is I wanted to build in terms of an app, a feature, etc. So over the course of me playing with this, I developed out a dev tool comparison website, and I built this in a vibecoded version and the spec version.

And I'm going to show you those both in a second and what my process was like. But essentially, I just type in /sp specify and then put in my prompt in here and hit return. So that basically goes ahead and creates uh a set of folders here in terms of specs. The other cool thing it does is it runs a set of scripts. So let's say it wants to create a new feature.

What it does is will actually create a new feature branch for you in git. So it builds out this little spec folder then and then your specs are typically what we've seen before. You've got requirements um acceptance scenarios etc. Even building in edge cases and it's a very testdriven development orientated framework. So when you're finished with the specify step you then go and type /pl and what slash plan does is basically generates planning based on the specification that we put forward.

It comes up with a detailed plan and even a set of contracts around your API specifications and everything else. It really is quite in-depth and again very safety focused, very test-driven development focused. And so once these documents are produced, uh it's recommended that you read through them and check for any areas where it says need clarification.

So you need to kind of fill in the blanks on the document yourself. Um once you finish the plan step, then you go to the task step. And what that does then is it breaks it down into multiple different tasks that you can carry out. So let's take a look at a tasks MD file here. Here's one that I actually have carried out already. So it breaks it down into phases.

Setup, endpoint tests, component tests, integration tests, and then as it goes forward, you just say update the last task that we've done and move on to the next. And you can see it's actually filled in that it's completed that and it moves on. Now, while I really appreciated all this detail, this whole process, even just to get through the first feature took a long time and burned through a huge amount of credits.

So, I'm all for the test-driven development approach and this level of planning, but literally it took me three minutes from my first prompt to have the equivalent app running in the vibe coded version. And it took probably upwards of 40 minutes to get through this process. And to be honest, the outcome wasn't even anywhere near as good as the vibe coded equivalent.

and I ran out of tokens in my 5-hour clawed window pretty quickly running both of these projects. So, I didn't even get to a satisfactory level taking this approach. Now, what I do appreciate is just the level of detail and thinking and dotting all the eyes that we have in here. Everything that you could possibly think of in terms of a production level app.

But I think my problem is this is the best case perfect scenario for approaching software development when you have a great idea of what you want build. But the thing is in reality I find that I work very much iteratively in a prototyping sense. I'm going to develop a little bit move forward check my mind move forward again realize that I need to use a different library or I need to change something else in terms of my design.

It's kind of this constantly updating plan, but I feel like this approach for me is just a little bit too rigid and I think we need to scale it back a bit. So, I really like the implementation. I just think maybe we need to uh remove some of the overengineering here. So, what I aimed to get built in the time I had or at least the allowance that Claude was giving me for my 5hour window.

So, for context, I'm on the max plan with Claude. It gives you a certain amount of generation for 5 hours. I pretty much ran out of tokens in about an hour building both of these together before I had to wait for it to reset. So, this is how far I got in that period of time. So, what I wanted to do was create this um uh benchmark for comparing AI dev tools because it's a lot of what I do on my channel just so I can get a feel for what I like and what features are coming out.

Now, this is not any final data. This was just populated by the model itself. So don't take any of these inputs as my own. A very test-driven development approach. It put all the scaffolding in place. Put a huge amount of time into the setup of the application. But where we arrived at was it was still using dummy JSON via an API instead of an actual database.

And this wasn't the final design. I was actually quite broken. I had to do a little bit of work to get it um polished. So um what I have found with spectriven development is it does tend to lack a little bit on the design side. When you have the ability to jump in and prompt it yourself, the design ends up that little bit better. So I feel like a hybrid approach is definitely necessary.

So if we take a look at the vibecoded version, this is what I ended up with in exactly the same amount of time. So we have a much better looking website. um you have all the different tools listed, but then what's more than that is this is actually connected to a full-on database in the cloud. It's Neon DB. And so if I now want to click on any one of these different features, I get uh more details about that feature and then also the ability to submit an update.

So anyone as a user or somebody in the audience can basically say, "Oh, I've seen the clog code have now added this." and then upload a screenshot and share some details on it and submit it and then I or somebody else can review and then add it to the bench. And to be honest, my first oneshot prompt got me pretty much 90% of this functionality, not the database.

So I used Nex.js with Prisma, etc. Um, so in my case, and I know this isn't the most complex app, uh, there's just no comparison in how quickly I was able to vibe code compared to all the waiting, hanging around, and token usage I had to burn when I was in spec mode. So, in reality, I've been building apps using AI solely without writing code for about 2 years now.

Here is my take on when to use spec mode, when to use vibe code, and the kind of hybrid approach that I use in the middle. So again, we're talking about two different approaches here. We have the vibe code approach, and then we have the spec mode approach. So what I'm proposing is something more in the middle, something of a hybrid between both approaches.

So with the hybrid approach, instead of just doing a ton of planning via spec mode before you do any prompting or in the vibe code way that you just jump straight in, I suggest that you just have a conversation with uh chatbt or Claude or whoever your favorite model is in its consumer mode just to say, "Hey, this is what I'm thinking of. I want to build this kind of mobile app.

What kind of a tech stack should I use? Why should I use that?" Ask some questions. Think about the libraries that might be involved. You just want to have a conversation. Get the model to ask you questions about what you're good at. You know, if you like JavaScript, TypeScript, if you're better at Python, these kind of things all matter. Just have this conversation over and back.

Uh in a research phase that doesn't take too long. This can only be like four or five prompts. Or you can use the prompt template. Um I'll attach it down below that I use where I have a chat with three different experts. I'll chat with a UX designer, a product manager, and a software architect. And there's a set of questions they ask me to kind of get me in the right headsp space for what I want to build next.

So the next thing is actually start with a tech stack. So once I know what tech stack I want to use or typically if I build been building for a while, there's a stack that I use a lot that would be like Nex.js and shad CN. I'll input that if it's relevant and then I'll actually set that up in the repo before I do anything else. So my model actually starts with a context of how I like to build things and what it's going to use.

It's not going to suggest uh using VIT or using Django when I'm a TypeScript developer. And that just helps an awful lot in terms of context. So then I go into a design mode. So essentially what I do is I start to work only on the front end of the application. I tell the large language model only to use dummy JSON and I include that as a rule just to make sure that it keeps doing that when it goes to develop all the backend architecture all the things like Prisma and Postgres in the background.

It really slows down your progress and you get a lot more errors. I just want to figure out how the app is going to work where the screens are going to come from what the views are going to be like and that really gives me lots of ideas and then it helps me inform how the database might be built next or the model can figure that out for you. So I would go into a iterative design mode first and then I pick my MVP.

So one thing about specdriven development is it tends to just build out this huge application with all the frameworks and everything set up in place and that's probably overkill when I'm just trying to figure out what I want to build or move iteratively. I like to build the smallest viable thing possible to test out and then bring that to the market or bring it to a user group or even play around with it myself before I decide to go any further because I could decide I want to throw this out and it doesn't make any

sense. Um I don't want to have wasted a load of time in setting up projects, infrastructure, etc. So start with your smallest MVP and then kind of iterate from there. And I still use lightweight specs and rules. So, um I am for specs and I am for using rules. But what I've seen people do is they have really huge rules files, really huge specs. And that really can confuse a model that has even a large context window like a million tokens because when you're feeding it too much information, it still gets a little bit

confused as to what the priority is. So, I like to handpick my specs and my rules and build them over time and then just add them in as they are needed as the model moves forward. and it keeps it on track to the way I like to build software. And then once I'm in flow, how I work in my prompting cycle is I will get it to create the tasks first. So I'll basically have a conversation to say this is the feature I'm developing next.

Come up with a plan. Don't implement code and then I get it to generate maybe a task file. So it's just like task.md. I put it in a docs folder and it will generate what it wants to do next. I'll review that. I'll change what I think is important. Um, and then I then move into implementation mode and I get one of the models to actually run the implementation of the task list.

And you'll find that tools like KO, even claude code, cursor, they all have their kind of lightweight planning modes built in. So they will help with this as they built out each one of the tasks that you have as they as they run and they implement. So all in all, this is my hybrid method between being overly speced and overly vied. So after 2 years of building with large language models, this is the kind of approach that I feel works best for me.

I'd love to know in the comments what approaches you take. Are you more towards specri development? Are there certain frameworks that you really like to use? Or do you just like to vibe your way through, accept all changes, and just hope that everything works out. So I'm going to throw this up somewhere. I just haven't picked a domain name. So if you want to get notified when it's up and running, just drop your name in here and subscribe to the newsletter and I'll let everybody know when I have it launched.

Also, while you're in there, take a look at the course. It's got everything you need in order to learn how to build an app with AI. I also cover a lot of this stuff for free on the channel. Feel free to look through that. Uh, but if you want to accelerate yourself and get closer access to the community, I highly recommend checking it