Episode 2: What is Spec-Driven Development?

Published: Tuesday, Oct 14, 2025 • Duration: 39 minutes • Season 1

What is Spec-Driven Development?

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!

Watch on YouTube

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.”

Slide 1

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.

Slide 2

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.

Slide 3

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.”

Slide 4

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.

Slide 5

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.

Slide 6

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.