Episode 2: What is Spec-Driven Development?
Published: Tuesday, Oct 14, 2025 • Duration: 39 minutes • Season 1
Download MP3 | Watch on YouTube
https://github.com/github/spec-kit
Spec-kitting an existing project: https://youtu.be/SGHIQTsPzuY?si=19uhEGXQv-leUh9J
https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
WDYT? Comments below!
summarize "https://youtu.be/q2KOAAtT-Qw" --timestamps --slides
This clip is a hands-on conversation and demo about using a spec-driven workflow to build and extend infrastructure code with large language model (LLM) tooling. The speaker walks through the motivations, the CLI-driven commands that scaffold a repo and a feature, the step-by-step spec → plan → task → implement loop, the ways this changes how you capture requirements, and the practical tradeoffs (time, tokens, and context management). Concrete numbers and timings are given for sessions, budgets, and how much time/token spend went into specification vs implementation. Two brief verbatim excerpts are included below that capture the speaker’s framing and a recurring problem the workflow addresses: “the code becomes more of like an after like an artifact” and “what’s data without a schema? You know what’s worse is data that used to have a schema but the schema is gone.”
Opening: why a spec-first workflow
The conversation starts with why the speaker switched toward a spec-driven process: LLMs accelerate work but also expose brittle, context-limited interactions that make adhoc code generation unreliable for larger projects. The host notes practical constraints: the cloud assistant runs sessions with fixed time/token budgets (a typical session described as five hours and a low-tier paid plan mentioned), so users must manage tokens and split work across models or sessions. Early remarks set up the need for a more structured, repeatable approach rather than jump-to-code prompts.
Tooling: a CLI-based spec scaffolder
The demo focuses on a repository scaffolded by a CLI-driven toolkit that adds a commands folder (slash-commands for the cloud IDE) and templates for spec files. The toolkit exposes prepared prompts as commands with arguments and installs into your repo so the cloud IDE shows them as slash-commands. The workflow is organized around a sequence of commands: constitution (project-level rules), specify (feature description), plan, taskify, implement and validate. The tool is IDE-agnostic: it uses the CLI under the hood and can target different LLM agents or plugins via configured prompts.
Specify: capture intent before tech
The first formal step is specify: write a functional spec about what you want and why, explicitly avoiding tech-stack details. The tool auto-generates personas, user scenarios and user stories from that input and creates a new git branch and a spec folder for the feature. This enforces treating specifications and test suites as primary artifacts—code becomes an output produced against those specs. The speaker frames the problem the workflow solves with the observation that unstructured notes and chat logs get lost and that structured specs help preserve reasoning and edge-case handling. “what’s data without a schema? You know what’s worse is data that used to have a schema but the schema is gone.”
Plan, research, taskify: heavy up-front work
Unlike free-form LLM generation, the toolkit emphasizes researching libraries, mapping functional requirements to data models, and turning the plan into small, self-contained tasks that include where and why a change will occur. For small utilities the quick, creative generation can work, but larger projects with multiple moving parts require careful upfront work to avoid divergent assumptions. The speaker reports spending multiple multi-hour sessions (described as two 2–5 hour sessions) to get specs, research, and task definitions into a state where automated implementation can be trusted.
Implementation, review, and IDE integration
Once specs and tasks are validated the workflow supports an interactive implementation phase where one model implements tasks and another reviews. The repo layout includes templates and a checklist command for validation to ensure edge cases are covered. The creator found that some LLMs follow the templates and prompts reliably while others diverge; the CLI arguments feature helps pass explicit user inputs into commands. The tool also creates a spec branch per feature, so each feature’s spec, tasks, and changes live alongside code in version control.
Source-of-truth, context limits, and costs
The recommended source-of-truth is the spec markdowns residing in the repo—these are the handover documents used when context windows start to saturate. The speaker warns that compacting or summarizing chat sessions can lose important research and reasoning, so writing explicit markdown handovers reduces drift. Practical costs were called out: spec generation and validations consumed a large fraction of weekly token/time budgets (the example given was roughly 40% of tokens on spec generation and validation, and ~30% on implementation). The workflow adds overhead up front but the speaker reports a successful run where two days of spec work plus overnight implementation produced a working feature the next day, demonstrating the tradeoff: more time invested up front, higher confidence and fewer integration surprises later.
Model: openai/gpt-5-mini
Transcript (auto-generated from YouTube captions)
Welcome everybody. It's it's Vincent and I just chatting about infrastructure and AI and uh what what what what's fun and cool I suppose. Um Vincent, you you wanted to show me something. I I know you've been itching. Straight on to the demo. Yeah, I can. Um give me a minute. I'll cut this out. >> Are you on Are you on Mac? cuz the >> Yeah, I am. >> Okay. >> It's It follows me. It >> You got center stage enabled. >> Yeah. I have no idea. It just works, right? >> Sorry, I have to uh plug some I have a pump. My AC pump. My AC is um in a funny position and it needs to pump the water out up. So, there's a pump, but the pump is a bit dodgy. >> What's your temperature there? It looks like you're sweaty. And >> yeah, I went to the gym this morning. So it is it is quite hot here. >> Yeah. Uh but I did so that's another that's a great thing about AI but and those budgets of AI by the way because I hit my budget like I have a 5 hour session and then I hit my budget maybe in two hours and so then I have 3 hours to go to the gym, right? I mean the amount of work I get done in two hours is is pretty much the same what I what I would do in a day. So it's pretty great. >> Yeah. Yeah, I I never thought about like that, but yeah, like I'm a big fan of like uh being careful with your time and you know the Pomodoro technique where you just jam in stuff. So if is >> So is the AI spend limit or Claude working the same way? Which plan are you on again? >> I'm on the like the lowest paid plan 20 bucks around Codex and Cloud. >> Sorry. Oh, and it and it basically works by by time. Like if you smashing your your token, >> the moment you send your first message, a 5 hour session starts >> and then you get a certain token budget within those 5 hours depending on your plan. And so it will remind you now they added like a nice usage command since they did Sonnet 4.5 last week and cloud code version two. So they added a lot more um context management and notifications about your usage um when and and also they added more I think they enforcing the weekly limits stronger and um basically within 5 hours you have a budget you keep track of how it's going so I can see like oh I'm at 50% let me maybe do a little bit more myself instead of just asking cloud to do it or or like um switch over to Codeex which often do. Um, so that >> I I tried Codeex I think after you talking about it and it is a lot better experience than I remember. >> Yeah, it has improved a lot but I don't use the CLI. Uh although that the CLI now recently has been updated as well. It's a little bit better. But the the IDE plugin, you know, lets you paste in images, reference well, you can reference files on both sides. But I find the I the IDE um plugin quite nice in uh in codeex because I can, you know, put it on full agent mode and it seems to use its tools and utility like better like when it needs to edit a file. >> Maybe you should show share the screen. show show it perhaps >> I think cuz that would be more interesting for people. Okay, so this is a project that I've been working on since the last time we talked where we talked about some of the events happening around Terraform states and state management open tacos announcement and I've talked to those people and I wanted to get some features in but I have not been able to reach them and so I started decided like it can't be that hard right I even commented on one guy like he posted like oh when you start a new project it's so exciting because you get to make a text tech decisions and then maybe you will regret those and I said like well cloud will oneshot it anyway so who cares so I I I thought if I I talk big like that let me try it right let me see if I can oneot this thing >> I'm I'm curious to see what's in your claw directory in your codeex which is just session management or something >> so this is what spec this is speckit um speckit gives you a command to bootstrap a repository to use speckit this kind of funny Now because Claude Code uh has announced plug-in marketplace so you can look at specit like a plug-in market sorry like a like a marketplace plug-in it comes with a bunch of commands basically prompt templates a bunch of scripts and um yeah that's pretty much it like it uses templates for some uh specification files that you may want to build. So, so this cloud folder here that has these commands, this is all prepared by specit. >> Oh, I see. So, it just So, what's a command then? It's like a it's like a prompt. >> I will try. Hold on. Um I I I want to open the the specit website. Yeah. So, um a command is like a prepared prompt. It can have arguments. So you can call those you know like when you do slash you can um call those like analyze. >> Yes. So then you all of your files that you put in here under the commands folder will show up as slashcomands in your Claude Code and you can also have arguments. >> Do do you use that a lot? I mean do you actually >> speckit is completely built around this workflow. So I've never used it until I use specit. So you basically I mean so you find yourself going analyze clarify constitution whatever that means in plan >> I don't know I've never used kro but the idea let me go spec kit let me open the website of spec kit the idea of specdriven development is to basically capture the reasoning behind code because they say rightfully so that the code itself is no long is never hold on I'm going to open this They have a website here somewhere. Uh anyway, where is the the ideology behind it? Hold on, let me find that spec driven development. >> Right. So, so the the whole idea behind specket which is the code was never really the secret sauce like before um basically people delivered code and the code is what represents the business logic documentation outdates becomes outdated very quickly but with LLM driven workflows the code becomes more of like an after like an artifact something that gets produced and you quickly like factor it or throw it away and what's more important is your specifications and the test suites built around Right. >> Specs and test suites. I I fully agree that sounds really good. >> So, so the power of inversion like this this this explanation is really good to read up front to understand really why it matters and why it is really worth it to do it that way. Definitely if you worked like like my previous workflow before speckit was I spend time with chipt on the web interface or in my phone when I'm in bed or when I'm walking around thinking about ideas and trying to understand how to use certain technology in some of my projects on on that note like um how do you capture your ideas that you have spontaneously like I to be honest I I try use voice recording and just cap try capture like me, you know, in the middle of the night saying do this workflow. Uh, and then I often forget about it like but do you have a better way of sort of capturing ideas and stuff? >> So, Chat GPT now has this feature where you can create folders. So, I've been working on this this well has probably been there for a while, but I've been using this feature to create folders more more aggressively. And yeah, sometimes I just tap the the dictate um and I just, you know, dictate what I'm thinking. >> Uh for example, >> that that works from the mobile, I guess you must do. >> Yeah. Yeah. But you can do it on on your laptop as well. I started using uh dictate on my my MacBook. Although that the transcription is not as good as if you use uh in the app because in the app I think it uses the LLM to trans transcribe. So um so here I was literally uh in my in my bedroom and I said what's data without a schema? You know what's worse is data that used to have a schema but the schema is gone. And here I'm talking about how my idea of like capturing the TypeScript um schema on top of the Terraform state gives you more of structured information about the actual Terraform infrastructure as code. Right? So, this was all spoken in and transcribed by the LLM and then it says like, okay, and I say, hey, help me create a launch uh site and it kind of captures like some of the hooks that we want to put on there, right? But as you can see, I have a lot of like ideas and chats and it's very hard for me to find back some of these ideas. Um, sometimes like I know I discussed something somewhere, it's somewhere in in one of these chats. The worst is after I've like done a drill down into >> So, you can't you can't search through them or something like that. You can you can search through this but I don't know it's I I still I I have discussed the same thing so many times because it becomes uh you know when you do a dictation you discuss something and maybe you're building on something that you had um discussed before uh but basically it's lost somewhere in these chats. So with specit um I feel like I do this in a much more structured way. So before speckit I had these chats I had to somehow capture all of these different responses from chatpt pick out the bits that I liked remove the bits that I didn't like and then create uh a document to to to basically track what I'm trying to do. So with specitate that starts with like a user description. So the first step is to to do specify the specify command is to to to kick off the workflow. So user a user description is that like a use case or is it something else? >> Yeah, that that's that's the hardest thing to to know about specit is like what do I exactly say in at each uh step of the way. So they do have a very good example on their readme. Um there's like a detailed walk through detailed process where um they go through like the first thing okay once you've initialized your repository and it is copied over your cloud commands into your git repository and it set everything up for you. You can choose codeex, you can choose cloud, you can use github copilot because this is a Microsoft product. And um they also changed like now now they have a prefix onto each slash command. Um I I have not talked about the constitution. >> Sorry Vincent you is this a Microsoft product? Did you say >> it's a GitHub right? GitHub is from Microsoft. >> Oh okay. Okay. >> Yes. So so so the first thing is in this example here like you need to do a functional specification not the the clarification you need to start on the actual spec project specification right. So that's the first thing you do you do specify um and that's after you've done constitution. So I will talk more about constitution later but first you have to come up with like a prompt of what we're going to develop. You ask me what is this thing that you're putting in. Uh be as explicit as possible about what you're trying to build and why. Don't talk about tech. Don't say like I want the Golang uh monolithic application or whatever. No, you're talking purely about what you're going to develop at that point. And so the great thing is once you've kicked off this this initial prompt um it's going to come up with a bunch of like what's the user scenario what are the usea like what are the personas um if when like user stories it basically follows a template um to >> so it creates the use cases for you what really >> yeah so the specify argument basically runs a script to create new feature which will then set up a new get branch. So when you use spec specify to to initialize your repo or your project folder, it will create a git repo and then you set up the constitution which I will talk about later and then you say I want to create a new feature. It sets up a new branch for that feature and prepares a spec folder. So everything is organized. It's like um ADR on on steroids or LLM driven ADR. Are you familiar with ADR? >> Uh yeah. Yeah. We I use them my work uh architecture uh decision record, right? >> Yes. uh it's architecture decision records the same thing you run a command and you create a decision record markdown and then you walk through it with your colleagues and then you lock it in right >> it's the same thing here um you're doing ADR but it's all driven through LLMs so the LLM is asked to run a script >> but this is but the uh vocabulary here is a feature right you call ADR is a feature here >> I guess so I I I I've only read about ADR I've always wanted to use it uh and then I started using speckit and I was like oh that's probably what ADR Well, I see ADR maybe I'm doing it wrong, but I see it more of a as a post activity like a like a documentation thing like you've worked some options uh and this is why you went with this option you know. >> Yeah. But when I tried to contribute to Atlantis, they uh they just adopted ADR and they asked me to before I started anything create the actual you know proposal of what I'm going to build like the feature what I'm going to build and and how I'm going to build it and where I'm going to make changes so that they could agree uh with me first if this was the way that they they wanted the project to evolve uh for my feature to get a better chance to get it uh accepted. Right. And I I think in open source that's kind of how you use ADR. Well, I always think the other way around like I I think you need to have code otherwise you don't have an ADR really. You need to have an implementation. You need to because because you know you can you can propose the moon on a stick but does it even work? You'll never know. >> I think you don't Yeah, sure. You you must have some type of credibility in in the changes that you're proposing. But for example, for me, I spend maybe a day or two reading the Atlantis source code and then identifying a couple of areas where I think the feature should impact and and then I can put my ADR in before I write the code to get like a a sanity check from the project maintainers, right? Like I'm saying I'm going to build this feature and I believe I need to change these code paths and they may very quickly flag well actually that code path kind of deprecated. um more of the of the logic that you're looking at lives there and and we can get that right first. Right. >> Okay. I I guess I guess to be honest it's it is a better attack cuz early early fast feedback is is a principle uh I also live by but uh if this project does it then then go for it I suppose. >> Yeah. So in my case with the Atlantic situation I was like great I get to create my first ADR. I'll do it next week. And then next week never happened. So um anyway with specit I I was very motivated with due to the recent events to to like really try out um how this could like work and without specit this is what I came up with like I come with the product requirement definition. I created like a V1 of what I want. I want the API to look like this and then a V2 a little bit updated after more chat GPT chats and then I asked uh cloud go ahead and and did it and and cloud was very enthusiastic. Um it always goes like perfect amazing the test pass everything's great but nothing worked like nothing worked together. >> Okay. So this is your this was your first way. Okay. Okay. >> Yeah. Yeah. This was my first way. So I went into chat uh did a bunch of chats tried to uh you know consolidate it into like a a product requirement document tried to capture all of the things that I wanted repository layout >> because I because I guess you went tech first here and maybe specitate is the other way. I I have so this is the the big thing I learned about speckit is like I I never really did proper product um development and I didn't have all of these users scenarios and all and edge cases thought out I this way like I can do it for very small things like I want to build a terapform provider I want to build a small binary I want to build a terminal user interface I can even terminal user interface start to get a little bit dodgy but like because cloud is so good at like being being creative it kind of works like oh great cloud came up with all this additional stuff that I never asked for, but because the project was small enough, it actually worked. It was able to complete it, for example. But once you start hitting like a big project where you have many moving parts that need to lift to like work together and and then you have assumptions on the left and assumptions on the right and nothing works together, >> right? >> So, so that's where specit is really great. Um because and I there was a thread earlier on on Reddit about that I just read earlier on Reddit um which was a way to capture the like in a monor repo to capture the meaning of each directory because when you want to make changes in a monor repo there's definitely responsibilities that live in certain parts and if you unleash an an LLM it will just like try to do everything in one area and then >> you know duplicate the logic. So this is I I mean I I like the owners uh paradigm. I mean to be honest I don't work on projects with that many owners to be honest. Uh but the the a the I like the um the agent markdown is is quite cool because you can sprinkle them in in your in your code hierarchy. Um >> okay. Yeah. So you could you could capture a bit more like don't do this here. If you need to change let's go over there. >> I suppose >> but it's tedious to maintain it right. So, so what is the approach here for for like >> okay so so so the Reddit thread was mentioning we they they iterate on an idea and then after 20 messages back and forth the context kind of grows and then over time the LLM when it actually starts implementing it to totally loses track of where things are supposed to go like you said you can like manually maintain agent files across your repository the way that specit approaches this is when you get down to the actual task generation it's very specific specific about where you're going to change what and why. So every single task that the LLM works on has very detailed like all self-contained information. Like that's at the very end and and I'm telling you specit takes me like easily two five hour sessions. So easily like two hours per session. So 4 hours at least to get it to the point before I even start to write code which is very frustrating when you start because you're so used to you know jump into cloud and have it generate a whole bunch of code and now you have to like go through all of these edge cases you know review the functional requirements you know do research and then align the plan and the research against those functional requirements and validate it and and and the first time my first feature which is like the start like bootstrap the mon repo and build some basic functionality it I totally like yes yes yes yes okay yes next on the first few steps because I also didn't even know what like most of those steps were meant to do um and and so I I ran up the the implementation part became very painful because specit divides it and you you specify the feature you you know start to formulate a plan where you actually define what is the text stack that you want to use that gets you know does some research to find out more about the libraries that you're interacting with and how they integrate with each Um and then once you've got the research, the plan, some data, models, then you start to generate the tasks and then you go through a couple of iterations of actually analyzing very very carefully how those functional requirements map back to those tasks and if everything is like covered in terms of like um requirements and and and >> and I did like like I said the first time I completely ignored that iteration and I went straight into implementation and halfway through I realized I made a big mistake. and like half of the code was actually not not quite right and I had to go back and try to make changes and I found it a bit hard to like uh adjust the course at that point because I hadn't done the a lot of the research up front and of course >> the idea is like how can I know that I've got everything right from the start right um you can't but >> um with this approach now with like really going into a lot of the edge cases the the feature that I did last time which was like adding um labels on terraform states literally I think two days to get the specs right and then I went to sleep at like 9:00 p.m. Ask cloud to start implementing maybe woke up around like midnight to ask codeex to review and continue the implementation and then by morning 7:00 a.m. kicked off another final implementation round and by lunch it was fully implemented and it hadn't encountered any issues and I went straight into the UI and it worked and it was like holy crazy. >> So this is really interesting. So >> what you said there where you got clawed to kick off the implementation. Um is is that like a specit thing to like you know specit implement? Okay. >> Yes. And then is it also a spec kit thing to like get codeex another model to review it? >> Uh not not explicitly but they do say that it's an interactive process. So they give you these starter commands to create those documents and you're they also say like don't expect this like >> um don't expect the first response to be what you want right you must actually validate and go through it. Um and then you know the first thing is after it went through this prompt it will then have a couple of needs clarification. It will generate edge cases like you may say here they talk about task taskify a team productivity platform should allow users to create projects and then it will create like um clarification questions like what if two users create this project with the same name like what what happens because you haven't clarified that right what if the user deletes a project that is um has a lot of tasks assigned to it how like is there a delete cascade in the background like how does that work so you have to go through a lot of these um details. >> Well, okay. So, this this sounds great. Absolutely great for like bootstrapping a project. But what what happens if you the uh just out of interest if there was an existing project like say you have an existing project and you want to specitify it? Is that possible? >> They do have a section about introducing it on existing projects. I have to say like this YouTube video here on the on the on the root p on the landing page or the root rate me it takes you to the channel of of one of the main advocates behind it and if you look at his posts from the like his YouTube videos from the like week last week and literally I think 3 days ago he did another update because they changed a couple of the commands they added new command into it which is a checklist command for your um validation so you can validate that you have really covered every area. Um, so, so these YouTube videos are amazing and he does talk about like how to go and use it into an existing project. Yeah, I think this is when I talk to people that use Ko, they say that this is very similar to Ko um but it's completely independent from like a specific IDE, right? You it works with multiple uh LLM agents. It uses the CLI under the hood. So, cloud is actually calling the cloud CLI to do some like summarizations and things like that under the hood. So when you mentioned Kira that that's uh sorry I I I not too sure what that means. >> Kirro is an AWS product that kind of launched the idea of specdriven development right they they really said like people are using Almstrong uh the specification is where you should start and they build a whole IDE around it. Ah, so Speckit and Kirro, how are they related? Just >> not at all. >> They're not related. Okay. >> Yeah. So, so, so Kira is a commercial product from AWS. It's an ID with a subscription with a subscription and they use Sonale as well. Um, but they provide you they have like nice little hooks inside the IDE. For example, if you have a task, there's a little green button that appears around it. So, you can click start implementing this task. and the LLM and start implementing it. That's kind of like you see that that's on the demo right now. >> Yeah. It's kind of like pretty cool. Yeah. >> Yeah. Because I mean Copilot has that, you know, you can like save and >> Yeah. Or >> I I think I think the specit with GitHub copilot does a similar thing, but I'm not using GitHub copilot. I'm just using the Claude Code with because I'm used to Claude Code. Yeah. >> Cool. Man, this is this is mind-blowing stuff, man. So, okay. So you got your speck kit, you got your task breakdown, you you kick it off overnight, you get codeex to review it. So how do you kick off codeex by the way? Is it is it just a like what you >> originally I always use the codeex ID on the side here? So I just install the the the plugin into in here. I need to update it I guess. Um so on one side I have copilot the GitHub you know provided. I have a seat uh provided by organization as well and then I have my personal codeex here. um that I have that I that is yeah that that's my codeex. >> Okay. >> I don't know what to say about it. >> So so your codeex is specified like how do you know that it's like >> yeah so so codeex only supported prompt arguments since last week. So the the speckit has this argument at the start here right the user input the user will provide some input. So when you kick off the command here um when you kick off specify yeah this is classic Claude Code doing the disco in the terminal um so when you say like we're we're we are going to revise the filtering library or something like that right I don't know that's actually not a good spec because it should not be related to the there's no functional requirement there's no that's just pure tech that's a really that spec actually. Okay, it should really be about like the user filtering experience is bad. Uh the perform like when a user clicks the filter it takes you know minutes before the result appears and then it will generate user stories and edge cases and like what are the benchmarks that we need to create what are the tests to validate that that it is implemented correctly and then we can go into the technical research like okay we find some hot pots we need to add some indexes into the database and do things like that. So that would be in the in the plan phase. So specify the first phase you say the functional requirement why do you need to do this what you want to do exactly. Then you do plan where it will kick off um several documents and and no actually before sorry before you go into plan um the specify will have generated edge cases and will have questions like what happens if uh if this or that right and then it will ask you clarification about how do you want to handle those like are you okay with this um and when you click up and for that also there's there's um an LLM prompt which will basically go through the document find any areas that needs clarification and then give you three or four options on how you may want to address this. So there's a question option A, B or C. So because we all use NLM ultimately to answer those questions, right? Yeah, I don't really I'm not really sure like what are some of the common ways that I could solve this and suspect it will give you like three or four uh clarification options there and then you can >> so but going back to codec soc. So you basically run some commands in claude and you run uh the same sort of commands in in codeex alternately. >> Yeah. So codec since last week has these arguments. So I I I started using the CLI and what I noticed is that the CLI in CEX never wants to execute the scripts. Maybe this is some training that OpenAI did to prevent like uh prompt injection attacks because there's been a few. So, so Codex even if the prompt says you will run this script, it doesn't run the script. So, so now I'm like confirm to me you will run this particular script and that works and it says yes I will run it and then actually when I say >> um I I I trigger the prompt. So you see the prompt was expanded here. So I call the prompt command and then it says user input is here. We need to identify actually I left the user input blank it looks like. Um I also noticed that if I put too much codeex will just lose half the prompt. I don't know. So maybe I stopped putting >> prompts. So on the subject of security, I'm not going to lie, when I use Claude, I sometimes specify, you know, skip dangerously skip permissions because I hate having to uh, you know, press enter. >> Yeah. >> So do you have a different approach to to security? >> Uh, depends on what repository I work on. If it's my own that I just bootstrapped, I'm okay with like most of it. Yeah. >> So you just skip all the permissions. >> I don't run MCPS or barely any because I believe that MCPS pollute the uh context window and the context window is scarce. So I try to keep as much of the context window free and so I only one MCP. Now >> on on the on the subject of context window like um I do think the interaction with MCP is quite good because it tells you when it runs the tool. It tells you what the input is and the output. Um, at least with Claude, it's quite clear to me, but like to me to me like a lot of these prompt prompting things, uh, I mean, they're quite verbose. I mean, like when you when you're running these commands, are you actually viewing all the input? Are you like like do you have a a finger on the whole context window or do you letting it do its thing? >> It depends. Like I used to be very hands-on with the implementation phase. Definitely when I wasn't going very detailed with like all the educations and functional requirements I started I realized I need to stop it to do the wrong thing. However like the last feature that I let it implement like literally I went to sleep. So I after I feel a lot more confident about the I ran the validate process like four times literally I think I use 50 I think at this point I use almost like 40% of my weekly token budget just on spec generation and and and like validation of the specs and then the actual implementation takes 30% or so. Yeah. >> Wow. So, and then your spec um what is the source of truth there? Like it's is it sitting in in a markdown file somewhere? >> Yeah. So, that's a that's a pattern I did before specit as well because cloud is great when you first start start using cloud. You go like let's go in plan mode and create a bunch of to-dos and then it ticks nicely through those to-dos. If you get stuck on something, you can like re like help it, you can nudge it along. You're following along and all that, right? But very quickly when the projects gets bigger, you you ident you realize that those to-dos like they're sometimes based on misconceptions or or you run out of context and then you need to compact and then the compact summary throws away a lot of the stuff that you originally was part of the reasons why the to-dos existed. So so those to-dos don't scale and so I started say asking cloud like okay check off the things that you've completed like when it started approaching context window limits and write it down for handover. I call it like we need to hand over to someone, right? So, write everything down into a markdown. Um, and then I would open a a new cloud session. Well, I didn't know how to use the clear comp um command properly, but I used a new cloud window and then I would just like read the handover document. Um, there's a couple of to-dos there. >> There's there's a command called compact, right? I think you >> Yes, but I found that the compact throws away like too many details. definitely some of the initial research that you've done and some of the reasoning why the to-dos exists and then if you you know halfway through are going down the wrong path and then the original you know logic is gone then the to-dos no longer makes sense and then cloud starts to be very creative and then it nothing works anymore. So that's why I already had this this experience um of of throwing away contexts easily and that's something that people say like >> you know your context is like a jewel you need to craft it very right to get it into the right you know data that you want and actually cloud added a lot of commands for you like the double escape if you are uh on cloud you can double double escape and you can rewind back to one of the previous like context snapshots or something like that >> I didn't know that >> res and you can even this one actually double escape is restore the code or conversation from a point before. This is something >> escape. Wow, I knew about I just learned about shift tab I think. I think is it shift tab? >> Yeah, shift tab. Shift tab is like the the amazing experience when you first start using Claude Code like because you actually get to you know determine the plan and the to-dos before you start writing down anything, right? But again like the plan mode hits it limit when you start building right large repositories. And so that's where, you know, writing things down into a markdown for handover really helps. And then specit um really formalizes that workflow because it really puts in like first we're going to get the functional requirements, then we're going to go through it and we're going to eliminate anything that needs clarification. It's literally one of the checkboxes. If you try to run the plan command or the plan prompt, normally cloud will see the instruction that if there's anything that still needs clarification, abort straight back to the user. You need to go clarify. Wow. Yeah, >> but the funny thing is it's LLMs, right? So, so when I do this with codecs, sometimes it sees this and just goes like, "Yeah, whatever." And just keeps going. It's like, "Come on, man. There's It's right there. Don't continue if there's still items to be clarified." >> Sorry if I asked you this question before, but how did you come across Spec Kit? >> Um, how did I come across it? >> Like hacker news or something? >> No, I'm I'm I'm on like a lot of Reddits. I'm on Claude Code Reddit, on entropic, on the OpenAI Reddit, like the subreddits, I mean, and I think it was posted there. I definitely saw all of the like on the AWS subreddit about Ko. I read a lot about specri development. I didn't I was building something at the time with Claude Code and I was quite happy the way it was going. But it definitely resonated with me because I was doing already those handover documents basically define what needs to be developed. I just didn't realize how how detailed the process was. Um >> because yeah so so what what you asked me earlier is like how does this actually work on an existing project and when you need to like adopt things I I don't know >> okay >> because I I started from scratch but I am using it on a large project right now and it is able to add in new features quite >> I think we're bouncing around a bit like I I still don't actually understand where your your specs live. They just live in the specs folder there. >> Okay. So, so the first step is you specify what you're trying to build, why you're trying to build it, and then it will when you kick off that pro prompt, it will create a branch and it will create a folder in the specs directory. And so then you're working on a branch on that specific feature, right? So this is one of the things people mention on Reddit is like how does this scale across a team like how do you keep track of like multiple people and their spec branches? So I also don't know that like this is a question that my colleague asked me when I I showed it to him. um like how will this like do you have everyone working on their own spec branches and so on? How do you collaborate on these branches? >> Um because it's going to be >> I can't answer those questions. >> If it's a fastmoving project, it might be a real pain to to merge, right? >> There might be a lot of different uh so so I think that's one important thing. Aside from the agents, there's the constellation uh which is part of the memory. So it creates a dot. So on one side it creates your commands under your cloud or your agent. So it has the prepared prompts there. Then it creates a special specify folder where it has the templates. For example, when it needs to write a new spec, it it has a very detailed plan template. So again, this is kind of like one shot or nshot LLM usage where you tell it like look at this and now replicate it. Now look at this then followed my example. Follow my example. Right? So it say read this then do this. Read this then do this. Right? So it it follows cloud is great. It follows this structure really really well. Codeex sometimes gives you a completely different template like completely nothing like it and sometimes chip 5 just >> what do you mean >> very nicely follows it. >> It like it doesn't read >> it doesn't follow it. I don't know why Sona is doing a great job but uh that's why that's why I have very dedicated like if I want >> so so what is doing a good job? Sonai >> Sonnet son um is a French way to say Sonnet uh >> Sonnet means a tune or doesn't it or like a >> it's a it's a type of pros I think like if you write >> son >> okay yeah >> so I'm going to I'm going to be I'm going to say this is a French word originally right >> yeah just like >> proson >> uh so you're using four you're using 4.5 I mean when it comes to model choices is are you quite are you picky about it? Do you go son for the 4.5? So this is the thing right these things change so fast um that's why I also avoid MCPS and other stuff like I trust them to provide the best working environment I cannot keep up with it so when they say use Sony 4.5 I'll be okay and they and uh and and that's the thing where a lot of people last week were very upset and because they are kind of telling people not to use opus and they make you blow your budget if you use opus they charge it double right they really want people to use Sonnet and people are like oh Son is not as good as Opus blah blah blah but >> they really craft code and the context and the tooling everything around the model and they're saying really don't use don't use sorry don't use opus so >> that's good to hear because like I had like some FOMO that I'm just not using making >> the right choices but I it has it has to be auto going forward I mean it's >> I agree like it's it's a full-time job like I watch some YouTube channels like go coder who very frequently breaks down he has his own benchmark um where he says okay I've tested Quen I've tested GLM I've tested JGPT OSS uh for local LLMs um and and he goes into great detail and I used to like wait until made a video to actually figure out is there like an improvement is there a significant improvement in his benchmark that would justify me to spend time to play with it and and I've actually started um I mean at some point you just want to get the worked on. You don't have the time to just keep reading about all the LLMs and >> cuz cuz every time there's like, oh, actually you need to use XML now. Yeah, you you should pro you write your prom. Oh, actually YAML is much better. Oh, no, no, JSON is the way. >> I'm sure you're making some crazy examples there. Anyway, I I think >> No, no, that's real. That's real like Reddit posts about this is my JSON >> formatted. Yes. No, it's not a >> that's like that's like a virus. Like you start using XML and then uh headache. Yeah. >> Um Oh, I think you g I think you gave me at least a very good overview of uh spec kit there. So maybe maybe we should we should go back to to uh the value add on Terraform.





