WEBVTT

00:00:00.000 --> 00:00:02.400
And all this stuff it happens that you

00:00:02.400 --> 00:00:04.280
you remember it just enough to to pass

00:00:04.280 --> 00:00:06.440
the certificates. That's why I'm

00:00:06.440 --> 00:00:08.480
personally I had this experience of

00:00:08.480 --> 00:00:11.120
getting or being required to get like

00:00:11.120 --> 00:00:13.480
five certificates in 3 months and then

00:00:13.480 --> 00:00:16.000
each of those certificates expected like

00:00:16.000 --> 00:00:18.840
3 to 6 years of experience and I was

00:00:18.840 --> 00:00:21.160
just an intern. Not an intern, I was

00:00:21.160 --> 00:00:23.440
just on probation and condition to pass

00:00:23.440 --> 00:00:25.680
probation was to pass. And so some

00:00:25.680 --> 00:00:27.080
people joined before me, they had

00:00:27.080 --> 00:00:29.480
prepared exam cram guides and downloaded

00:00:29.480 --> 00:00:31.480
a bunch and then on one of those

00:00:31.480 --> 00:00:34.160
certificates I got like a 100% like a

00:00:34.160 --> 00:00:36.480
complete passing score and I was like

00:00:36.480 --> 00:00:37.840
they're going to be revoked. They're

00:00:37.840 --> 00:00:38.645
going to

00:00:38.645 --> 00:00:39.240
>> [laughter]

00:00:39.240 --> 00:00:41.360
>> they're going to you know claim that I

00:00:41.360 --> 00:00:42.600
That was actually the most interesting

00:00:42.600 --> 00:00:45.400
one. It was Microsoft SQL Server 2005 uh

00:00:45.400 --> 00:00:46.960
certification.

00:00:46.960 --> 00:00:48.720
I remember now you're describing your

00:00:48.720 --> 00:00:51.000
past when you were like uh

00:00:51.000 --> 00:00:53.600
Yeah, and it's the same thing because to

00:00:53.600 --> 00:00:55.760
be a Microsoft gold partner you have to

00:00:55.760 --> 00:00:57.680
have a certain amount of people within

00:00:57.680 --> 00:00:58.920
the organization that have those

00:00:58.920 --> 00:01:02.200
certificates. Yeah. I mean it's 2026.

00:01:02.200 --> 00:01:04.879
It's the same with AWS. I'm pressurized

00:01:04.879 --> 00:01:06.840
to do the certificates anyway. I mean

00:01:06.840 --> 00:01:08.480
the problem I learned from that is that

00:01:08.480 --> 00:01:09.720
I never trust someone who has a

00:01:09.720 --> 00:01:12.280
certificate. Like if somebody on a CV

00:01:12.280 --> 00:01:15.120
puts certificates, I will usually if

00:01:15.120 --> 00:01:16.440
it's in something I'm knowledgeable

00:01:16.440 --> 00:01:18.280
about, I will make their life hard on

00:01:18.280 --> 00:01:21.760
those topics. Well, fair enough. I mean

00:01:21.760 --> 00:01:22.840
and it's

00:01:22.840 --> 00:01:25.400
On certificates I do think

00:01:25.400 --> 00:01:27.120
they're more useful than they're not

00:01:27.120 --> 00:01:29.120
useful. And

00:01:29.120 --> 00:01:31.160
and to be honest I I do encourage my

00:01:31.160 --> 00:01:32.480
colleagues to get it because you do

00:01:32.480 --> 00:01:34.280
learn things that you might not

00:01:34.280 --> 00:01:36.720
ordinarily know. Um it's a bit lame but

00:01:36.720 --> 00:01:38.840
I didn't even know about uh

00:01:38.840 --> 00:01:40.840
I didn't know about

00:01:40.840 --> 00:01:43.520
CloudTrail Lake until it was in the exam

00:01:43.520 --> 00:01:45.320
question. Yeah, I don't know about it

00:01:45.320 --> 00:01:47.800
also. But then what do you use it for?

00:01:47.800 --> 00:01:49.680
Is it like like a data lake for your

00:01:49.680 --> 00:01:51.560
audit events or is it like a Yeah,

00:01:51.560 --> 00:01:53.840
exactly. So you don't have to Previously

00:01:53.840 --> 00:01:55.720
I think you just used to dump everything

00:01:55.720 --> 00:01:57.640
in S3 and and try to make sense of it

00:01:57.640 --> 00:01:59.240
with Athena.

00:01:59.240 --> 00:02:01.280
Yeah, but night

00:02:01.280 --> 00:02:03.120
At one of my previous organizations,

00:02:03.120 --> 00:02:05.560
they set up a huge Elasticsearch cluster

00:02:05.560 --> 00:02:08.399
to ingest all of the security events

00:02:08.399 --> 00:02:10.520
data. And to be honest, they just took a

00:02:10.520 --> 00:02:13.520
off-the-shelf GitHub Python repo. It's

00:02:13.520 --> 00:02:15.080
funny because we were doing Terraform

00:02:15.080 --> 00:02:17.080
everywhere for 3 years, and then we

00:02:17.080 --> 00:02:18.680
hired two people to do security with a

00:02:18.680 --> 00:02:21.160
new CTO, and those people go off and

00:02:21.160 --> 00:02:23.160
they do absolutely everything on their

00:02:23.160 --> 00:02:25.320
own, completely in isolation. And they

00:02:25.320 --> 00:02:28.000
like under direct supervision of the CTO

00:02:28.000 --> 00:02:30.600
to build all these dashboards. And like

00:02:30.600 --> 00:02:33.240
well, that's okay, but then they do like

00:02:33.240 --> 00:02:35.240
integrate with our Terraform. So, they

00:02:35.240 --> 00:02:36.680
set up all this account, we need to set

00:02:36.680 --> 00:02:39.680
up a Kinesis stream endpoint to to, you

00:02:39.680 --> 00:02:41.480
know, route all the events. But, I mean,

00:02:41.480 --> 00:02:44.240
they they impressed me when I there was

00:02:44.240 --> 00:02:48.560
a an US East 1 login outage, and I went

00:02:48.560 --> 00:02:51.720
around the back to get like access via a

00:02:51.720 --> 00:02:53.680
I don't know, I I think I use an access

00:02:53.680 --> 00:02:55.880
key that is stored At the time, that was

00:02:55.880 --> 00:02:57.520
like more than 4 years ago, we still had

00:02:57.520 --> 00:02:59.959
some AWS access keys in some services,

00:02:59.959 --> 00:03:01.800
and I just went to the secret store,

00:03:01.800 --> 00:03:03.040
used the access key directly, and

00:03:03.040 --> 00:03:04.440
started doing my stuff there because I

00:03:04.440 --> 00:03:06.519
couldn't do IAM logins. And I

00:03:06.519 --> 00:03:09.120
immediately got a notification on Slack.

00:03:09.120 --> 00:03:10.720
Yo, Vincent, there's some unusual

00:03:10.720 --> 00:03:12.040
activity on this access key. Is this

00:03:12.040 --> 00:03:14.320
you? And I was like, oh, wow, nice. So,

00:03:14.320 --> 00:03:16.160
it worked. Yeah, yeah. I didn't really

00:03:16.160 --> 00:03:18.120
know about all the security tooling like

00:03:18.120 --> 00:03:21.160
Security GuardDuty, Security Hub. I do

00:03:21.160 --> 00:03:23.320
feel it would probably They have all

00:03:23.320 --> 00:03:25.400
these like like out of the box stuff

00:03:25.400 --> 00:03:26.800
that will help you catch that sort of

00:03:26.800 --> 00:03:27.320
stuff.

00:03:27.320 --> 00:03:28.920
>> And with

00:03:28.920 --> 00:03:30.760
Another thing I didn't quite know about

00:03:30.760 --> 00:03:32.200
was that, you know, when you have an

00:03:32.200 --> 00:03:34.720
organizational unit in your master root

00:03:34.720 --> 00:03:36.800
account, you can there's a command in

00:03:36.800 --> 00:03:38.760
AWS Organizations to delegate the

00:03:38.760 --> 00:03:40.959
account, so you can delegate

00:03:40.959 --> 00:03:43.840
the security account and the IAM

00:03:43.840 --> 00:03:44.480
account.

00:03:44.480 --> 00:03:46.720
>> Yeah. I didn't actually know about

00:03:46.720 --> 00:03:48.400
>> I know that people set up accounts to do

00:03:48.400 --> 00:03:51.000
that, but I didn't know that you can you

00:03:51.000 --> 00:03:53.040
can delegate it straight from the the

00:03:53.040 --> 00:03:55.280
root account and and and in that way.

00:03:55.280 --> 00:03:57.840
So, Yeah, we we have a few things like

00:03:57.840 --> 00:04:00.080
Like um we have a shared services

00:04:00.080 --> 00:04:02.440
account where we run all of our like uh

00:04:02.440 --> 00:04:05.200
workloads like Atlantis and and like

00:04:05.200 --> 00:04:07.000
even if you use CDK and you CDK

00:04:07.000 --> 00:04:09.320
pipelines, it will recommend you to have

00:04:09.320 --> 00:04:12.000
a DevOps like pipeline account and it

00:04:12.000 --> 00:04:14.560
will provision the CDK pipeline into

00:04:14.560 --> 00:04:16.040
that DevOps account and then it will

00:04:16.040 --> 00:04:18.640
create trust relationships uh into your

00:04:18.640 --> 00:04:19.799
across your other accounts and your

00:04:19.799 --> 00:04:21.519
regions. So, we have this shared service

00:04:21.519 --> 00:04:23.720
account and we have like some delegated

00:04:23.720 --> 00:04:25.680
for resource manager, I believe, and

00:04:25.680 --> 00:04:28.320
also to to aggregate some of data with

00:04:28.320 --> 00:04:30.560
control tower. Control tower does a lot

00:04:30.560 --> 00:04:33.000
of that out of the box. But yeah, I mean

00:04:33.000 --> 00:04:34.880
what you said, sometimes there's some

00:04:34.880 --> 00:04:36.400
services and if you keep them on the

00:04:36.400 --> 00:04:38.160
root like the management account, it's

00:04:38.160 --> 00:04:40.280
not a very good practice and it's much

00:04:40.280 --> 00:04:41.800
better like they actually recommend say,

00:04:41.800 --> 00:04:43.360
"Hey, you shouldn't do this in here. You

00:04:43.360 --> 00:04:44.600
probably need to delegate this to

00:04:44.600 --> 00:04:46.960
another account." Yeah. There's also a

00:04:46.960 --> 00:04:48.520
feature I didn't know about where you

00:04:48.520 --> 00:04:50.320
can basically

00:04:50.320 --> 00:04:53.880
stop the root root account access.

00:04:53.880 --> 00:04:55.919
And uh it forces you to do like a

00:04:55.919 --> 00:04:57.600
temporary root access. I I can't

00:04:57.600 --> 00:04:58.440
remember the name of the feature, but

00:04:58.440 --> 00:05:00.040
there's a there's a there's quite a few

00:05:00.040 --> 00:05:02.080
things. But that's accounts root, right?

00:05:02.080 --> 00:05:04.640
It's not management account from the AWS

00:05:04.640 --> 00:05:06.960
org. Yeah, but still like you don't want

00:05:06.960 --> 00:05:09.000
root account Yeah, but it's different,

00:05:09.000 --> 00:05:09.919
right?

00:05:09.919 --> 00:05:11.040
What do you mean when you say root

00:05:11.040 --> 00:05:13.280
account? Because in in AWS org, you have

00:05:13.280 --> 00:05:15.160
a management account which is the

00:05:15.160 --> 00:05:17.880
account that you use to manage your org

00:05:17.880 --> 00:05:21.040
and root, what is root account in an AWS

00:05:21.040 --> 00:05:24.240
org? Root is the like maybe um So, you

00:05:24.240 --> 00:05:26.080
mean the root user? When you set up a

00:05:26.080 --> 00:05:28.520
new account, you have like this master

00:05:28.520 --> 00:05:30.840
and Yeah, you should absolutely disable

00:05:30.840 --> 00:05:33.120
that. That's like like we have that

00:05:33.120 --> 00:05:35.600
disabled.

00:05:35.600 --> 00:05:37.520
I think it's probably AWS config rules

00:05:37.520 --> 00:05:39.040
that I I'm brushing up on all the

00:05:39.040 --> 00:05:41.720
security stuff because my next role is

00:05:41.720 --> 00:05:44.840
more security sec sec eng. So, my new

00:05:44.840 --> 00:05:46.880
role uh which I'll be starting next

00:05:46.880 --> 00:05:49.960
week. We'll be administering

00:05:49.960 --> 00:05:50.600
um

00:05:50.600 --> 00:05:53.720
security preventions, monitoring, and

00:05:53.720 --> 00:05:55.480
all that sort of stuff on a on a large

00:05:55.480 --> 00:05:57.800
organization, making sure that nothing

00:05:57.800 --> 00:06:00.280
untoward happens. With with a focus on

00:06:00.280 --> 00:06:02.440
AI tooling because

00:06:02.440 --> 00:06:04.480
they want That's why we

00:06:04.480 --> 00:06:05.800
That's why that I'm was kind of keen on

00:06:05.800 --> 00:06:08.040
the AI guardrail stuff. So, I probably

00:06:08.040 --> 00:06:10.400
will continue working on that. Although,

00:06:10.400 --> 00:06:12.280
and and that project is like the first

00:06:12.280 --> 00:06:14.680
project I've used Spekit on or Spectrum

00:06:14.680 --> 00:06:16.760
development. And yeah, I do as I

00:06:16.760 --> 00:06:18.640
mentioned over WhatsApp, I I have I have

00:06:18.640 --> 00:06:21.440
some questions or some concerns or like

00:06:21.440 --> 00:06:23.440
I'm a bit I shared I mean, I shared them

00:06:23.440 --> 00:06:25.160
with you, and I've also shared my

00:06:25.160 --> 00:06:27.200
Spectrum development questions with my

00:06:27.200 --> 00:06:29.320
colleagues. And I feel like I get the

00:06:29.320 --> 00:06:30.960
same answer from you than with my

00:06:30.960 --> 00:06:33.120
colleagues. Like, "Yeah, that's Spekit.

00:06:33.120 --> 00:06:36.160
Have you tried this other STD

00:06:36.160 --> 00:06:38.200
accelerator? Have you tried Be Mad? Have

00:06:38.200 --> 00:06:39.520
you tried Get Things Done?" It's like,

00:06:39.520 --> 00:06:41.000
"What?" I think generally it's the right

00:06:41.000 --> 00:06:43.320
advice. You should try many. And also,

00:06:43.320 --> 00:06:46.000
Spekit is has not been maintained. And

00:06:46.000 --> 00:06:47.720
then, some of the like information you

00:06:47.720 --> 00:06:49.720
share with me, it's clear that they are

00:06:49.720 --> 00:06:51.520
changing things in Spekit without

00:06:51.520 --> 00:06:53.200
updating the docs. So, the original

00:06:53.200 --> 00:06:55.320
person building it is no longer with

00:06:55.320 --> 00:06:57.120
Microsoft since like, I don't know,

00:06:57.120 --> 00:06:59.160
since November when he joined Anthropic

00:06:59.160 --> 00:07:01.600
to work on MCP specifically. And since

00:07:01.600 --> 00:07:03.320
then, it has been in limbo for like

00:07:03.320 --> 00:07:05.160
several months. And I guess in the

00:07:05.160 --> 00:07:07.120
lately, like maybe in the last month or

00:07:07.120 --> 00:07:09.200
so, they started adding new stuff to it.

00:07:09.200 --> 00:07:10.760
Like, they rewrote all of the prompts

00:07:10.760 --> 00:07:12.960
into skills. I think that's a pretty

00:07:12.960 --> 00:07:14.560
interesting idea. I mean, all honestly,

00:07:14.560 --> 00:07:16.960
Anthropic says that the commands /

00:07:16.960 --> 00:07:18.400
commands and skills are kind of the same

00:07:18.400 --> 00:07:20.440
thing. And you see Spek ledger also

00:07:20.440 --> 00:07:22.880
Sorry, you see Opus or the agent shell

00:07:22.880 --> 00:07:25.480
loading prompts as if they are skills.

00:07:25.480 --> 00:07:27.560
>> commands are way more implicit. Like,

00:07:27.560 --> 00:07:29.640
you like this is what's happening.

00:07:29.640 --> 00:07:31.840
>> They've been completely If you go to the

00:07:31.840 --> 00:07:33.960
official Anthropic docs, commands and

00:07:33.960 --> 00:07:36.040
skills are the same thing. If you run a

00:07:36.040 --> 00:07:38.000
/command, it loads the the skill

00:07:38.000 --> 00:07:40.040
of that command. If you mention, we're

00:07:40.040 --> 00:07:42.320
going to run the Spek ledger inspect.

00:07:42.320 --> 00:07:44.280
>> Okay, so it's going to go and load it.

00:07:44.280 --> 00:07:46.000
>> You should it's the same. You just go

00:07:46.000 --> 00:07:48.240
slash okay, okay, fine. For the agent,

00:07:48.240 --> 00:07:49.680
the idea of slash command has been

00:07:49.680 --> 00:07:51.760
deprecated. It's no longer a thing.

00:07:51.760 --> 00:07:52.920
They're still available but

00:07:52.920 --> 00:07:55.920
>> I thought you were saying that that that

00:07:55.920 --> 00:07:57.000
the

00:07:57.000 --> 00:07:59.560
the steps in spec driven

00:07:59.560 --> 00:08:02.560
development specify the plans, the

00:08:02.560 --> 00:08:05.120
tasks, the implement is now skill in the

00:08:05.120 --> 00:08:06.680
sense that you don't actually have to

00:08:06.680 --> 00:08:09.280
explicitly type it, but it sounds like

00:08:09.280 --> 00:08:10.760
the command is just hooked up to the

00:08:10.760 --> 00:08:13.640
skill. Yeah, the agent sees the commands

00:08:13.640 --> 00:08:15.520
and can load the command on demand. And

00:08:15.520 --> 00:08:17.760
I I see this is very nice in in cloud

00:08:17.760 --> 00:08:19.840
code with spec ledger. I think the front

00:08:19.840 --> 00:08:21.960
matter of the command because the

00:08:21.960 --> 00:08:23.400
implementation of Claude Code and the

00:08:23.400 --> 00:08:26.080
implementation of GitHub co-pilot, they

00:08:26.080 --> 00:08:27.800
at the very tail end of spec it, they

00:08:27.800 --> 00:08:29.760
added this idea of like handoffs between

00:08:29.760 --> 00:08:32.000
agents. And they even have this concept

00:08:32.000 --> 00:08:33.919
of like in the because I watched the

00:08:33.919 --> 00:08:35.919
videos of how he uses it with within VS

00:08:35.919 --> 00:08:38.039
code with co-pilot and he has the chat

00:08:38.039 --> 00:08:39.680
interface and it's very easy for him to

00:08:39.680 --> 00:08:41.479
say, "Now I want to hand off to this

00:08:41.479 --> 00:08:43.440
next command." And at the front matter

00:08:43.440 --> 00:08:44.839
you have like if you run this command

00:08:44.839 --> 00:08:46.520
then the handoff it next is that that

00:08:46.520 --> 00:08:49.080
next step that you need to do. And I

00:08:49.080 --> 00:08:51.320
just copy that over and when I ask cloud

00:08:51.320 --> 00:08:52.839
code, you know, with the onboarding

00:08:52.839 --> 00:08:54.160
actually with spec ledger, which is a

00:08:54.160 --> 00:08:56.839
skill that we added when you in it a

00:08:56.839 --> 00:08:58.839
repo, if it's a new repo, it

00:08:58.839 --> 00:09:00.280
automatically triggers the onboarding

00:09:00.280 --> 00:09:02.400
skill. If it's a existing repo, the

00:09:02.400 --> 00:09:04.360
onboarding skill does an exploration and

00:09:04.360 --> 00:09:06.600
then suggests the principle for you. It

00:09:06.600 --> 00:09:07.839
will look at your code in the way that

00:09:07.839 --> 00:09:10.000
you organize things and then it will say

00:09:10.000 --> 00:09:12.120
based on like you know, don't repeat

00:09:12.120 --> 00:09:14.160
yourself or write everything twice and

00:09:14.160 --> 00:09:16.360
you're you're like it will it will take

00:09:16.360 --> 00:09:18.680
a couple of those patterns that it sees

00:09:18.680 --> 00:09:20.400
and it will say, "The principles that

00:09:20.400 --> 00:09:22.640
you might be aligned with are these."

00:09:22.640 --> 00:09:24.000
And that's the onboarding flow of spec

00:09:24.000 --> 00:09:25.800
ledger that that spec it doesn't have.

00:09:25.800 --> 00:09:27.839
But the same with in it, the in it

00:09:27.839 --> 00:09:29.560
onboarding flow because of these

00:09:29.560 --> 00:09:31.440
handovers between the prompts and

00:09:31.440 --> 00:09:33.720
because if you use with Opus 1 million

00:09:33.720 --> 00:09:35.240
token context with spec ledger, you get

00:09:35.240 --> 00:09:37.560
this very smooth like, "Okay, we've set

00:09:37.560 --> 00:09:39.440
up the constitution. Do you want to

00:09:39.440 --> 00:09:41.320
build a new What do you want to work on

00:09:41.320 --> 00:09:42.520
first?

00:09:42.520 --> 00:09:45.040
The point of a handoff is to refresh the

00:09:45.040 --> 00:09:46.960
context, right? To clear, right? So that

00:09:46.960 --> 00:09:49.240
you have But not necessarily. It's It's

00:09:49.240 --> 00:09:51.080
more like what's the next step, right?

00:09:51.080 --> 00:09:53.200
We We We've done the constitution. We're

00:09:53.200 --> 00:09:54.840
going to work on our first feature,

00:09:54.840 --> 00:09:55.400
right?

00:09:55.400 --> 00:09:57.960
>> the handoff is is is the is the sort of

00:09:57.960 --> 00:10:00.120
line in the sand between a specify and a

00:10:00.120 --> 00:10:02.120
plan and a Do you Do you have the Do you

00:10:02.120 --> 00:10:04.120
have the same steps in Spec Ledger that

00:10:04.120 --> 00:10:06.880
the specify a plan? Yeah, it's pretty

00:10:06.880 --> 00:10:08.640
much the same except one person that

00:10:08.640 --> 00:10:10.440
like to use Open Spec renamed one or two

00:10:10.440 --> 00:10:12.040
things. Like instead of

00:10:12.040 --> 00:10:15.560
instead of analyze, it's

00:10:15.560 --> 00:10:16.200
or clarify.

00:10:16.200 --> 00:10:18.440
>> It's clarify. Yeah. Or clarify is the

00:10:18.440 --> 00:10:19.200
same thing.

00:10:19.200 --> 00:10:21.200
>> Spec It is clarify. Then there was

00:10:21.200 --> 00:10:23.080
something that was verify for a

00:10:23.080 --> 00:10:24.440
cross-check. I don't know. He renamed

00:10:24.440 --> 00:10:26.080
some of them, which I wasn't a huge fan

00:10:26.080 --> 00:10:27.440
of. I was like, but people come from

00:10:27.440 --> 00:10:29.480
Spec It. But I think more people use

00:10:29.480 --> 00:10:31.680
Open Spec. And it's funny because I I

00:10:31.680 --> 00:10:33.680
explained everything to a friend of mine

00:10:33.680 --> 00:10:36.040
and then he announced this to everyone,

00:10:36.040 --> 00:10:37.480
"Oh, I'm doing a workshop on how to do

00:10:37.480 --> 00:10:39.760
spec-driven development." And like he I

00:10:39.760 --> 00:10:41.320
was like Yeah, that was it.

00:10:41.320 --> 00:10:43.680
>> I was learning it.

00:10:43.680 --> 00:10:44.960
Exactly.

00:10:44.960 --> 00:10:45.320
Anyway.

00:10:45.320 --> 00:10:48.920
>> Yeah, I've seen things like that before.

00:10:48.920 --> 00:10:49.800
It's not the first time.

00:10:49.800 --> 00:10:52.040
>> Question Question Question time for you

00:10:52.040 --> 00:10:54.320
is like if you have like a if you're

00:10:54.320 --> 00:10:56.280
working on a spec-driven project and

00:10:56.280 --> 00:10:57.760
there's a small change that you need to

00:10:57.760 --> 00:11:00.120
make, do you go through all the steps?

00:11:00.120 --> 00:11:03.560
Because there was like a bug in my AI

00:11:03.560 --> 00:11:06.160
guardrail uh guardrail thing. It was

00:11:06.160 --> 00:11:08.320
quite simple to fix. I was like, I could

00:11:08.320 --> 00:11:10.000
even fix it by hand, like a cave man.

00:11:10.000 --> 00:11:11.280
>> Yeah, absolutely. I've said that many

00:11:11.280 --> 00:11:13.360
many times that I

00:11:13.360 --> 00:11:15.240
that I have two ways of working with the

00:11:15.240 --> 00:11:17.160
agent, right? Often because I'm working

00:11:17.160 --> 00:11:19.240
on Spec Ledger using Spec Ledgers, then

00:11:19.240 --> 00:11:20.680
while I'm working, I see, "Hey, this

00:11:20.680 --> 00:11:22.240
doesn't work well." And then I ask the

00:11:22.240 --> 00:11:24.960
agent, "Can you figure out why

00:11:24.960 --> 00:11:26.640
it didn't do this? I expect you that

00:11:26.640 --> 00:11:27.960
this would happen." And then the agent

00:11:27.960 --> 00:11:30.360
says, "Well, the prompt said this and my

00:11:30.360 --> 00:11:33.240
context has that. So that's why I didn't

00:11:33.240 --> 00:11:34.800
do it. And then I say, "Okay, go file a

00:11:34.800 --> 00:11:37.000
bug, right? Go file a bug. We're going

00:11:37.000 --> 00:11:38.920
to address that. Uh let's continue with

00:11:38.920 --> 00:11:41.040
the work that we're doing." And then I

00:11:41.040 --> 00:11:43.120
will often open a second cloud uh for

00:11:43.120 --> 00:11:44.400
what you just described, like there's a

00:11:44.400 --> 00:11:47.200
small little prompt template issue or

00:11:47.200 --> 00:11:49.200
the command isn't outputting something

00:11:49.200 --> 00:11:51.320
that confuses the agent, causing it to

00:11:51.320 --> 00:11:54.200
to do something unexpectedly. So, I just

00:11:54.200 --> 00:11:55.760
open a second cloud session. I say, "Go

00:11:55.760 --> 00:11:58.200
create a Git work tree and and then

00:11:58.200 --> 00:12:00.520
using the Git work tree tool, and then

00:12:00.520 --> 00:12:02.200
address this bug." That's the bug

00:12:02.200 --> 00:12:03.120
number. Okay.

00:12:03.120 --> 00:12:04.520
>> Just in plan mode. [clears throat] Just

00:12:04.520 --> 00:12:07.160
in plan mode. No specifier, no spectrum

00:12:07.160 --> 00:12:08.800
development. You do it in parallel.

00:12:08.800 --> 00:12:10.520
Yeah, cuz it's cuz that's the next thing

00:12:10.520 --> 00:12:13.560
I wanted to moan about was that going

00:12:13.560 --> 00:12:15.280
through spec uh

00:12:15.280 --> 00:12:18.240
spec it's but you know, specify, plan,

00:12:18.240 --> 00:12:21.040
God, clarify. It takes so long. It takes

00:12:21.040 --> 00:12:21.720
so

00:12:21.720 --> 00:12:22.520
long.

00:12:22.520 --> 00:12:24.680
>> I used to I used to tell it like even in

00:12:24.680 --> 00:12:27.120
plan mode, I would use to also indicate

00:12:27.120 --> 00:12:29.280
like, "Let's look at the impact." If the

00:12:29.280 --> 00:12:31.440
bug sometimes it looks superficial, but

00:12:31.440 --> 00:12:33.280
I ask it, "Go and investigate how much

00:12:33.280 --> 00:12:34.920
of the code base needs to be modified

00:12:34.920 --> 00:12:36.600
and what is the huge like how how big is

00:12:36.600 --> 00:12:39.680
the impact of this bug?" And then it um

00:12:39.680 --> 00:12:41.600
and then I might decide that this is

00:12:41.600 --> 00:12:43.520
quite big, and I actually might want

00:12:43.520 --> 00:12:45.960
this to be more of an STD flow. So, you

00:12:45.960 --> 00:12:48.560
can easily evolve like going from a bug

00:12:48.560 --> 00:12:50.320
planning phase and say, "No, I'm going

00:12:50.320 --> 00:12:52.640
to make a a branch for it. I'm going to

00:12:52.640 --> 00:12:54.680
create user stories and and get a larger

00:12:54.680 --> 00:12:57.160
buy-in." And and the And the reason for

00:12:57.160 --> 00:12:59.240
going for this bug workflow is for

00:12:59.240 --> 00:13:01.560
speed, right? Just to get it done.

00:13:01.560 --> 00:13:02.960
>> And then the one of the things I did was

00:13:02.960 --> 00:13:06.520
I used to specify work on the bugs 1 2 3

00:13:06.520 --> 00:13:08.200
4 5. And then it would create this

00:13:08.200 --> 00:13:10.200
massive fe- uh massive feature, like

00:13:10.200 --> 00:13:12.160
user stories, this bug needs to be fixed

00:13:12.160 --> 00:13:13.760
because as a user this and that, and it

00:13:13.760 --> 00:13:16.000
was this massive. And then I would it

00:13:16.000 --> 00:13:18.040
would never get done. Like I would ask

00:13:18.040 --> 00:13:19.440
other people, like, "Do you agree with

00:13:19.440 --> 00:13:21.280
the approach for these bugs?" But a lot

00:13:21.280 --> 00:13:23.360
of them were very straightforward. Like

00:13:23.360 --> 00:13:25.440
it's a very easy bug. Uh so, there's no

00:13:25.440 --> 00:13:27.000
need to get like a full alignment on

00:13:27.000 --> 00:13:28.840
that. So, so then I was like these

00:13:28.840 --> 00:13:31.040
branches affected too many areas, became

00:13:31.040 --> 00:13:32.920
too big. And I think that's the biggest

00:13:32.920 --> 00:13:35.320
danger with spectrum development is that

00:13:35.320 --> 00:13:37.600
you go in these long-lift massive

00:13:37.600 --> 00:13:39.520
feature branches. Which is great if

00:13:39.520 --> 00:13:41.880
you're starting from scratch.

00:13:41.880 --> 00:13:44.480
Which is a little bit less great if you

00:13:44.480 --> 00:13:46.120
like if you're bootstrapping something,

00:13:46.120 --> 00:13:47.480
the first commit you have to set up the

00:13:47.480 --> 00:13:49.080
whole repo and you have to build out an

00:13:49.080 --> 00:13:51.120
MVP and you have to have a you basic

00:13:51.120 --> 00:13:53.680
testing. So, you can do this huge flow

00:13:53.680 --> 00:13:56.080
and the branch can be quite big. You can

00:13:56.080 --> 00:13:57.560
try and cut it down like, "Hey, I really

00:13:57.560 --> 00:13:59.200
want just to have the web app with the

00:13:59.200 --> 00:14:01.280
minimal interface and and and and all

00:14:01.280 --> 00:14:02.920
that." Sometimes just even I want the

00:14:02.920 --> 00:14:05.360
CLI with this input schema and then I'll

00:14:05.360 --> 00:14:07.560
work on the web app later. So, it's very

00:14:07.560 --> 00:14:09.320
dangerous to to go into these massive

00:14:09.320 --> 00:14:11.000
feature branches that never land.

00:14:11.000 --> 00:14:15.400
>> That leads me to my next issue is that

00:14:15.400 --> 00:14:17.480
yeah, it's easy for the branch to get

00:14:17.480 --> 00:14:20.000
quite big. And then, of course, the PR's

00:14:20.000 --> 00:14:22.480
going to become massive if you ever had

00:14:22.480 --> 00:14:25.200
to approve PR's in your in your in your

00:14:25.200 --> 00:14:28.160
project. So, how do you Is there like a

00:14:28.160 --> 00:14:31.200
clever way to say like

00:14:31.200 --> 00:14:33.040
what we're working on here can't be more

00:14:33.040 --> 00:14:34.280
than a thousand lines of code or

00:14:34.280 --> 00:14:36.280
something like that? Cuz at the moment

00:14:36.280 --> 00:14:39.240
AI agents This is your judgment and you

00:14:39.240 --> 00:14:41.080
I don't think you can You need to cut

00:14:41.080 --> 00:14:43.240
it. Like what I do, I tell the agent

00:14:43.240 --> 00:14:45.000
looking at the number of user stories if

00:14:45.000 --> 00:14:47.200
it's above five, I don't know. And then

00:14:47.200 --> 00:14:49.400
I say, "Let's scope these out." Like

00:14:49.400 --> 00:14:51.520
flag them as like um

00:14:51.520 --> 00:14:53.880
a wish list or later. And it will just

00:14:53.880 --> 00:14:56.560
put it like Again, I think we we have to

00:14:56.560 --> 00:14:59.400
not be stuck up on the process cuz if it

00:14:59.400 --> 00:15:01.200
feels like I mean, I understand on one

00:15:01.200 --> 00:15:02.680
way you want to guarantee quality and

00:15:02.680 --> 00:15:04.360
you want other people to follow a

00:15:04.360 --> 00:15:06.320
process and and then people get confused

00:15:06.320 --> 00:15:08.400
if the process isn't clear. But I think

00:15:08.400 --> 00:15:10.680
the mistake that you're making is you're

00:15:10.680 --> 00:15:12.880
getting so hung up on the process. Like,

00:15:12.880 --> 00:15:14.560
"But hey, but how do I do this?" Well,

00:15:14.560 --> 00:15:16.760
it's still an AI agent. You can still

00:15:16.760 --> 00:15:18.880
talk to it. And I think one thing we

00:15:18.880 --> 00:15:21.480
learned is that with these AI agents,

00:15:21.480 --> 00:15:24.200
you just ask them. You say like, "Hey,

00:15:24.200 --> 00:15:25.480
there's something wrong with your

00:15:25.480 --> 00:15:26.960
settings." And it goes and finds the

00:15:26.960 --> 00:15:28.240
setting and say, "Oh, you're right.

00:15:28.240 --> 00:15:30.280
There's a setting here that I can change

00:15:30.280 --> 00:15:31.680
and it will solve this problem."

00:15:31.680 --> 00:15:33.800
>> I I mean, we're debating here. I can see

00:15:33.800 --> 00:15:36.280
what you're saying, but though I do feel

00:15:36.280 --> 00:15:39.240
the process should have a lot of a lot

00:15:39.240 --> 00:15:41.200
of all like it should get you there

00:15:41.200 --> 00:15:43.440
without without it should get you to

00:15:43.440 --> 00:15:45.520
where you need to go to without too many

00:15:45.520 --> 00:15:47.840
problems. And I do feel as you mentioned

00:15:47.840 --> 00:15:49.720
the feature branch being too big is is

00:15:49.720 --> 00:15:52.160
very very easy to happen. I think like

00:15:52.160 --> 00:15:54.600
One thing that works for teams

00:15:54.600 --> 00:15:55.800
very disappointing

00:15:55.800 --> 00:15:57.840
>> you do it, you will get you will not

00:15:57.840 --> 00:15:59.880
have that problem. I don't think I mean,

00:15:59.880 --> 00:16:01.360
you could argue that yeah, but if

00:16:01.360 --> 00:16:02.920
somebody news comes, he's going to face

00:16:02.920 --> 00:16:06.240
these issues. But I I think you need to

00:16:06.240 --> 00:16:09.200
let people do pilots and and experience

00:16:09.200 --> 00:16:11.800
the problems and then walk back from it.

00:16:11.800 --> 00:16:13.640
>> I mean, I can only tell you 100 times

00:16:13.640 --> 00:16:15.840
Kai the same things that I've said on

00:16:15.840 --> 00:16:18.120
this show about these feature branches

00:16:18.120 --> 00:16:19.520
and scoping down.

00:16:19.520 --> 00:16:21.960
>> I know my it's a bit irritating to hear.

00:16:21.960 --> 00:16:24.720
My But the Okay, another thing that I

00:16:24.720 --> 00:16:26.880
was a bit disappointed by is that Spec

00:16:26.880 --> 00:16:30.839
Kit has this auto Git commit hook. And I

00:16:30.839 --> 00:16:32.720
was like, "Oh, cool. So, when I do this,

00:16:32.720 --> 00:16:34.560
it just Git commits." And then when I do

00:16:34.560 --> 00:16:36.320
that, it it just Git commits. So, I So,

00:16:36.320 --> 00:16:38.000
I can roll back. To be honest, I never

00:16:38.000 --> 00:16:39.760
rolled back. And then when I looked at

00:16:39.760 --> 00:16:41.920
the Git history, I was expecting to see

00:16:41.920 --> 00:16:44.720
like an amazing like step-by-step about

00:16:44.720 --> 00:16:47.000
all my genius prompts that I I was

00:16:47.000 --> 00:16:48.480
giving. The

00:16:48.480 --> 00:16:50.280
If you look at the Git history of the AI

00:16:50.280 --> 00:16:52.440
God Rolls project, link below, whatever.

00:16:52.440 --> 00:16:53.400
There's no

00:16:53.400 --> 00:16:55.960
the Git commit uh message is just like,

00:16:55.960 --> 00:16:58.040
uh you know, Spec Kit blah, Spec Kit

00:16:58.040 --> 00:17:00.120
that. There's no no information in the

00:17:00.120 --> 00:17:01.240
in the

00:17:01.240 --> 00:17:03.240
uh Git Maybe that's just a a problem

00:17:03.240 --> 00:17:03.440
with the

00:17:03.440 --> 00:17:04.959
>> like I said, the people that are working

00:17:04.959 --> 00:17:07.040
on Spec Kit right now, I think they are

00:17:07.040 --> 00:17:09.439
not very high quality because they made

00:17:09.439 --> 00:17:10.800
changes, but they didn't update the

00:17:10.800 --> 00:17:12.839
docs. Like they don't show that this

00:17:12.839 --> 00:17:14.520
There's a lot of documentation lagging

00:17:14.520 --> 00:17:16.880
behind. And to be honest, this commit

00:17:16.880 --> 00:17:19.240
hooks are are are something that didn't

00:17:19.240 --> 00:17:21.480
exist. And right now my commits are

00:17:21.480 --> 00:17:22.800
really nice.

00:17:22.800 --> 00:17:24.680
I really love the the commits that I'm

00:17:24.680 --> 00:17:26.400
getting, but I'm not using any hooks.

00:17:26.400 --> 00:17:28.800
Okay, well, okay, it's I've got to I've

00:17:28.800 --> 00:17:29.520
got to say something.

00:17:29.520 --> 00:17:31.280
>> times stop using spec drift, right? I

00:17:31.280 --> 00:17:32.800
mean, I've said I've said it like it's a

00:17:32.800 --> 00:17:33.840
good first starter.

00:17:33.840 --> 00:17:36.200
>> didn't use that one first, but okay, um

00:17:36.200 --> 00:17:37.840
No, yeah, you use it first. You do a

00:17:37.840 --> 00:17:39.960
small little demo and then you find all

00:17:39.960 --> 00:17:42.040
the pains and and when you ask me all

00:17:42.040 --> 00:17:43.560
these questions, I was like, I'm not

00:17:43.560 --> 00:17:45.160
going to answer those questions anymore

00:17:45.160 --> 00:17:47.440
until you try something else because

00:17:47.440 --> 00:17:49.640
And I did And for the record, I did try

00:17:49.640 --> 00:17:51.520
Kyra and that was a terrible experience.

00:17:51.520 --> 00:17:54.400
It was terrible. It was so slow and it

00:17:54.400 --> 00:17:55.840
it kept on like

00:17:55.840 --> 00:17:58.520
uh you know, timing out and you know,

00:17:58.520 --> 00:18:00.680
you kept on having to baby sit it. Not

00:18:00.680 --> 00:18:02.960
cool. Not cool. And then yeah, the the

00:18:02.960 --> 00:18:05.360
last note I have and I've talked to you

00:18:05.360 --> 00:18:06.760
about but it for and I'm sure you're

00:18:06.760 --> 00:18:08.760
going to tell me to do try another one

00:18:08.760 --> 00:18:10.800
is is the spec drift problem where the

00:18:10.800 --> 00:18:12.840
specs just become unaligned. But yeah, I

00:18:12.840 --> 00:18:14.600
will Okay, I'll I'm going to try another

00:18:14.600 --> 00:18:15.000
one.

00:18:15.000 --> 00:18:17.240
>> again, I already I I said this several

00:18:17.240 --> 00:18:19.280
times on this on these calls as well,

00:18:19.280 --> 00:18:21.400
that it is really up to you to say to

00:18:21.400 --> 00:18:23.800
the like let's say that the constitution

00:18:23.800 --> 00:18:25.320
is kind of and the same with Google

00:18:25.320 --> 00:18:26.920
Conductor, right? They all have these

00:18:26.920 --> 00:18:28.720
project principles a concept.

00:18:28.720 --> 00:18:30.600
>> forgot about Google's. Yeah, you tried

00:18:30.600 --> 00:18:32.000
Google Conductor and one of the things

00:18:32.000 --> 00:18:33.440
is it like it uses this JSON file at

00:18:33.440 --> 00:18:35.360
least back like maybe between four

00:18:35.360 --> 00:18:37.600
months ago and and it has this idea of

00:18:37.600 --> 00:18:39.360
like how do you want to define like how

00:18:39.360 --> 00:18:41.240
do you work with your team? And there's

00:18:41.240 --> 00:18:43.280
a constitution, right? And and this spec

00:18:43.280 --> 00:18:45.160
drift problem that you mentioned, like I

00:18:45.160 --> 00:18:46.480
can't explain it

00:18:46.480 --> 00:18:47.960
several times. I said like, you can

00:18:47.960 --> 00:18:50.160
really create a constitution rule and

00:18:50.160 --> 00:18:53.120
say that every spec plan includes

00:18:53.120 --> 00:18:55.120
maintaining

00:18:55.120 --> 00:18:56.280
um

00:18:56.280 --> 00:18:59.360
a centralized documentation library.

00:18:59.360 --> 00:19:01.840
Let's say that because again, the spec

00:19:01.840 --> 00:19:03.960
folders, they will contain a history of

00:19:03.960 --> 00:19:05.240
all of the specs that you've been

00:19:05.240 --> 00:19:07.000
adding, but they're changing. Like even

00:19:07.000 --> 00:19:09.800
if I scope something out in my five user

00:19:09.800 --> 00:19:12.200
story spec and I say, let's not do user

00:19:12.200 --> 00:19:14.680
story six and write it down." And then,

00:19:14.680 --> 00:19:16.760
when I come back to it once it's merged,

00:19:16.760 --> 00:19:18.280
I will often have changed my mind. I

00:19:18.280 --> 00:19:19.880
will look back at user story six and I

00:19:19.880 --> 00:19:21.400
see I realize that's not really what I

00:19:21.400 --> 00:19:22.800
want because now I have something in

00:19:22.800 --> 00:19:24.640
hand and I realize that actually it

00:19:24.640 --> 00:19:26.640
should be different. And so, thinking

00:19:26.640 --> 00:19:28.680
that those spec folders have any

00:19:28.680 --> 00:19:31.360
meaning, I think it is wrong. And what I

00:19:31.360 --> 00:19:34.120
do now is I tell in my constitution,

00:19:34.120 --> 00:19:36.920
when you build your plan and you layout

00:19:36.920 --> 00:19:39.440
your tasks, one of the final tasks is to

00:19:39.440 --> 00:19:41.760
go back and update the documentation.

00:19:41.760 --> 00:19:43.560
That's one way of doing it. The second

00:19:43.560 --> 00:19:46.400
way is like we discussed as well is I'm

00:19:46.400 --> 00:19:48.320
actually having a library of end-to-end

00:19:48.320 --> 00:19:50.920
tests. And the user stories, they impact

00:19:50.920 --> 00:19:53.280
it. I I ask it to write a quick start.

00:19:53.280 --> 00:19:54.440
And if you look at the spec later

00:19:54.440 --> 00:19:57.000
constitution, the CLI, it has a rule

00:19:57.000 --> 00:19:59.400
that says the quick start MD that gets

00:19:59.400 --> 00:20:03.520
generated has to match the E2E test

00:20:03.520 --> 00:20:06.200
suite. So, because it's a CLI, it's very

00:20:06.200 --> 00:20:07.960
easy to for it to write down when the

00:20:07.960 --> 00:20:10.040
user runs this command, then this is

00:20:10.040 --> 00:20:11.600
what needs to happen, right? And that's

00:20:11.600 --> 00:20:13.840
my quick quick start MD, which is like

00:20:13.840 --> 00:20:16.480
it shows you how the sub command looks.

00:20:16.480 --> 00:20:18.360
It shows you what the arguments are and

00:20:18.360 --> 00:20:20.760
the CLI, what's the UX a little bit. And

00:20:20.760 --> 00:20:22.960
it basically translate very cleanly to

00:20:22.960 --> 00:20:25.440
an end-to-end test on on on Go lang,

00:20:25.440 --> 00:20:27.640
where it's like it builds the binary and

00:20:27.640 --> 00:20:31.920
then it writes a test things

00:20:31.920 --> 00:20:34.000
like do the assertions. And so, my quick

00:20:34.000 --> 00:20:36.840
start.md per spec in those folders, each

00:20:36.840 --> 00:20:39.920
time results in another changes into the

00:20:39.920 --> 00:20:42.120
E2E. And if I don't have the central

00:20:42.120 --> 00:20:43.360
docs of these are all the features and

00:20:43.360 --> 00:20:45.200
all the sub commands, I have a fully to

00:20:45.200 --> 00:20:46.480
E of all the features and sub commands

00:20:46.480 --> 00:20:48.160
that are officially supported, right?

00:20:48.160 --> 00:20:51.160
And if I run make E2E, it's going to run

00:20:51.160 --> 00:20:53.920
is the user still able to run SL, um,

00:20:53.920 --> 00:20:55.720
you know, in it. Is the user still able

00:20:55.720 --> 00:20:57.320
to run this and is this the in it

00:20:57.320 --> 00:20:59.560
behaving the way it is? And if I haven't

00:20:59.560 --> 00:21:01.200
if I have changed the behavior of my

00:21:01.200 --> 00:21:03.320
CLI, you know, because a new a new spec

00:21:03.320 --> 00:21:04.760
has landed that has changed the

00:21:04.760 --> 00:21:07.000
behavior, then any of those previous E2E

00:21:07.000 --> 00:21:08.360
tests will have failed, right? So,

00:21:08.360 --> 00:21:10.480
basically I have an executable Okay, so

00:21:10.480 --> 00:21:11.760
a specification.

00:21:11.760 --> 00:21:13.200
>> you essentially have a constitution to

00:21:13.200 --> 00:21:15.080
say like don't break the tests. The the

00:21:15.080 --> 00:21:16.960
tests are the source of truth. I say

00:21:16.960 --> 00:21:18.640
there's two ways. You can say like I

00:21:18.640 --> 00:21:20.200
have two in my in my constitution. I

00:21:20.200 --> 00:21:22.640
always say like when you write the when

00:21:22.640 --> 00:21:24.400
you do the research phase and and you

00:21:24.400 --> 00:21:26.640
basically convert the very

00:21:26.640 --> 00:21:28.840
product-oriented or user stories from

00:21:28.840 --> 00:21:30.880
the specification into an actual

00:21:30.880 --> 00:21:32.840
technical stack and down to the line

00:21:32.840 --> 00:21:35.680
what is the actual, you know, command

00:21:35.680 --> 00:21:37.760
that gets run, whether it be like I have

00:21:37.760 --> 00:21:39.640
a mono repo that is because I love spec

00:21:39.640 --> 00:21:41.360
kits in in mono repos or spec driven

00:21:41.360 --> 00:21:43.160
development because you go like we have

00:21:43.160 --> 00:21:45.040
the web, we have the CLI, we have the

00:21:45.040 --> 00:21:46.480
back end, and they're all interacting

00:21:46.480 --> 00:21:47.800
with each other. And so, the quick start

00:21:47.800 --> 00:21:50.480
is usually, you know, we we we run a a

00:21:50.480 --> 00:21:51.840
seeding script that set up the whole

00:21:51.840 --> 00:21:53.120
environment, and then we do this and

00:21:53.120 --> 00:21:55.080
that, and everything can be executed.

00:21:55.080 --> 00:21:56.840
So, that's one way. I have an executable

00:21:56.840 --> 00:21:59.600
kind of like centralized version away

00:21:59.600 --> 00:22:01.720
from the spec folders. Or the other side

00:22:01.720 --> 00:22:03.520
is I have a centralized docs because

00:22:03.520 --> 00:22:05.160
ultimately when you build a

00:22:05.160 --> 00:22:07.320
a solution, if it's a dev dev tool

00:22:07.320 --> 00:22:09.040
focused, you will usually have a docs

00:22:09.040 --> 00:22:10.440
website, right? Of like these are all

00:22:10.440 --> 00:22:12.000
the features and this is how this work.

00:22:12.000 --> 00:22:13.640
And so, part of the work that needs to

00:22:13.640 --> 00:22:15.640
be done is to go back and update all the

00:22:15.640 --> 00:22:18.160
docs accordingly, and then, you know,

00:22:18.160 --> 00:22:19.680
when that lands, it pushes that. That's

00:22:19.680 --> 00:22:21.320
why I think mono repos are great because

00:22:21.320 --> 00:22:22.480
you can have everything

00:22:22.480 --> 00:22:25.360
>> I'm totally team mono repo. I can't I

00:22:25.360 --> 00:22:27.880
was speaking to a colleague and he says

00:22:27.880 --> 00:22:29.880
that the on this enterprise project that

00:22:29.880 --> 00:22:32.840
he's on, they they practice hexagonal

00:22:32.840 --> 00:22:35.920
architecture. I had to look it up, but I

00:22:35.920 --> 00:22:37.400
know what it means like

00:22:37.400 --> 00:22:37.800
It's clean.

00:22:37.800 --> 00:22:40.040
>> things are split into domains. So, he

00:22:40.040 --> 00:22:41.680
was saying that like they're using spec

00:22:41.680 --> 00:22:43.760
kit driven development on on a on a

00:22:43.760 --> 00:22:46.360
project, and and for and for managers

00:22:46.360 --> 00:22:48.640
and BAs and stakeholders, they can

00:22:48.640 --> 00:22:52.040
generate user stories in a flash now

00:22:52.040 --> 00:22:54.120
thanks to spec kit. But the trouble is

00:22:54.120 --> 00:22:56.080
is that when you come to implement it in

00:22:56.080 --> 00:22:58.080
a hexagonal architecture, you

00:22:58.080 --> 00:23:00.160
essentially need to to cut like five or

00:23:00.160 --> 00:23:02.720
six PRs for for a feature that's

00:23:02.720 --> 00:23:03.920
crossing

00:23:03.920 --> 00:23:06.360
um, you know five or six domains.

00:23:06.360 --> 00:23:07.880
And as he says this is an absolute

00:23:07.880 --> 00:23:10.440
nightmare because spec

00:23:10.440 --> 00:23:12.880
STD doesn't help you there.

00:23:12.880 --> 00:23:14.000
Yeah.

00:23:14.000 --> 00:23:17.640
It's I've You should have an orc

00:23:17.640 --> 00:23:20.560
his hot take like what why isn't STD

00:23:20.560 --> 00:23:23.040
just called alignment driven development

00:23:23.040 --> 00:23:24.600
or something because that's all it

00:23:24.600 --> 00:23:26.160
really gives you right?

00:23:26.160 --> 00:23:28.800
>> Alignment between AI and you and then

00:23:28.800 --> 00:23:31.040
more multiplayer with other people. Yeah

00:23:31.040 --> 00:23:33.000
it's like a more multi like multiplayer

00:23:33.000 --> 00:23:35.200
driven development. To go back to your

00:23:35.200 --> 00:23:37.080
previous point like when I have a a poly

00:23:37.080 --> 00:23:39.840
repo I do actually in my work folder

00:23:39.840 --> 00:23:42.400
where I launch cloud I clone multiple

00:23:42.400 --> 00:23:44.840
repos. So I have my work directory. Yeah

00:23:44.840 --> 00:23:46.840
and then cloud has access to all of them

00:23:46.840 --> 00:23:48.240
and that's where some people like you

00:23:48.240 --> 00:23:50.800
you create a like a spec driven repo and

00:23:50.800 --> 00:23:53.320
then I'm not doing get submodules but

00:23:53.320 --> 00:23:55.440
it's close to it right? It's like this

00:23:55.440 --> 00:23:57.120
massive integration repo with modules

00:23:57.120 --> 00:23:58.040
sub

00:23:58.040 --> 00:24:00.120
In VS code you can use this workspace

00:24:00.120 --> 00:24:02.160
feature which was a lifesaver in the in

00:24:02.160 --> 00:24:04.160
a previous life. Because I used

00:24:04.160 --> 00:24:06.440
workspaces and it's a different thing

00:24:06.440 --> 00:24:08.960
though. Like I used it for well I used

00:24:08.960 --> 00:24:10.240
it for a different purpose I guess. You

00:24:10.240 --> 00:24:11.520
can have different checkouts and they

00:24:11.520 --> 00:24:13.680
both and they all and like in code

00:24:13.680 --> 00:24:15.720
spaces they come out in the workspaces

00:24:15.720 --> 00:24:17.680
folder and they and then you can see it

00:24:17.680 --> 00:24:20.720
nicely in your VS code. I mean it's not

00:24:20.720 --> 00:24:22.560
that much different to checking into it

00:24:22.560 --> 00:24:24.440
like one folder in a way. The one

00:24:24.440 --> 00:24:27.480
problem that I had was that a lot of the

00:24:27.480 --> 00:24:30.320
language servers of like typescript and

00:24:30.320 --> 00:24:33.000
node JS and the integration within VS

00:24:33.000 --> 00:24:35.800
code had issues with mono repos or I had

00:24:35.800 --> 00:24:37.560
some problems with my configuration. I

00:24:37.560 --> 00:24:39.160
remember one of the problems was the

00:24:39.160 --> 00:24:41.840
debugger like if I need to run just

00:24:41.840 --> 00:24:44.760
tests with a node JS debugger you could

00:24:44.760 --> 00:24:46.600
only configure the debugger at the root

00:24:46.600 --> 00:24:48.880
of the repo at the root of the project

00:24:48.880 --> 00:24:50.920
not root of the repo. So I had a mono

00:24:50.920 --> 00:24:53.520
repo with like five projects and then

00:24:53.520 --> 00:24:56.440
the debugger would like use the get root

00:24:56.440 --> 00:24:59.040
to find like to launch the the the and

00:24:59.040 --> 00:25:00.280
he couldn't. Actually, it wasn't get

00:25:00.280 --> 00:25:02.240
root, it was project root. So, that's

00:25:02.240 --> 00:25:04.520
where I had to use workspaces. So, every

00:25:04.520 --> 00:25:06.800
package had a different had a workspace,

00:25:06.800 --> 00:25:09.240
and then I could open in this project in

00:25:09.240 --> 00:25:11.560
workspaces, and then I could go to any

00:25:11.560 --> 00:25:13.880
of them and run debug this package, and

00:25:13.880 --> 00:25:15.440
then it would run the debugger attached

00:25:15.440 --> 00:25:17.880
to this Yeah, I'm glad you brought that

00:25:17.880 --> 00:25:19.400
up because like that's the typical thing

00:25:19.400 --> 00:25:20.960
if you don't use a mono repo, you have

00:25:20.960 --> 00:25:23.400
the different folders. And then does

00:25:23.400 --> 00:25:25.560
your bloody intellisense work? Does your

00:25:25.560 --> 00:25:27.520
code sense work between the different

00:25:27.520 --> 00:25:29.800
projects? Because often enough that

00:25:29.800 --> 00:25:31.440
someone's like saying, "I've got this

00:25:31.440 --> 00:25:33.920
work around." But like the you know, the

00:25:33.920 --> 00:25:35.360
typescript

00:25:35.360 --> 00:25:37.880
type checking or the or the python

00:25:37.880 --> 00:25:39.840
whatever it's called is broken.

00:25:39.840 --> 00:25:41.480
Interesting. Yeah, and

00:25:41.480 --> 00:25:43.080
Okay.

00:25:43.080 --> 00:25:44.720
Another thing before I forget cuz I I

00:25:44.720 --> 00:25:46.480
just made a note about it. Going back to

00:25:46.480 --> 00:25:49.000
speckid, on the topic of all the specs

00:25:49.000 --> 00:25:50.440
that you should look through, there

00:25:50.440 --> 00:25:52.080
there was a command. I didn't try it. I

00:25:52.080 --> 00:25:54.160
should have bloody tried it. And it was

00:25:54.160 --> 00:25:56.760
I think it called speckid archive. Have

00:25:56.760 --> 00:25:58.040
you Do you know what that command does?

00:25:58.040 --> 00:25:58.880
I

00:25:58.880 --> 00:26:00.840
I didn't have this yet. It's definitely

00:26:00.840 --> 00:26:03.520
one thing on spec ledger it's in the UI.

00:26:03.520 --> 00:26:05.240
But basically, the way it went, right? I

00:26:05.240 --> 00:26:07.240
use speckid. I added task management

00:26:07.240 --> 00:26:09.200
with with like um

00:26:09.200 --> 00:26:11.280
a task graph instead of a markdown

00:26:11.280 --> 00:26:12.840
because speckid was writing everything

00:26:12.840 --> 00:26:14.440
down in markdown and it was like trying

00:26:14.440 --> 00:26:15.680
to track dependencies and

00:26:15.680 --> 00:26:17.440
parallelization. That makes sense.

00:26:17.440 --> 00:26:19.120
>> I don't know that like like you have to

00:26:19.120 --> 00:26:20.640
do that.

00:26:20.640 --> 00:26:22.840
>> Does. Yeah, well well, I got rid of that

00:26:22.840 --> 00:26:25.560
by by telling all of my structure

00:26:25.560 --> 00:26:28.000
prompt. I noticed that well, they kept

00:26:28.000 --> 00:26:28.880
it.

00:26:28.880 --> 00:26:30.600
It's just an index. So, if you use spec

00:26:30.600 --> 00:26:32.800
ledger, please do instead of complaining

00:26:32.800 --> 00:26:34.440
and then never trying. Okay, I'm going

00:26:34.440 --> 00:26:36.280
to try spec ledger next with I'm going

00:26:36.280 --> 00:26:38.480
to I'm going to redo my projects in spec

00:26:38.480 --> 00:26:40.000
ledger and then I

00:26:40.000 --> 00:26:40.600
Yeah, so

00:26:40.600 --> 00:26:42.280
>> Do you really want me to do this? Okay,

00:26:42.280 --> 00:26:44.440
so if you use spec ledger, you download

00:26:44.440 --> 00:26:47.320
a single go lang CLI and it has all of

00:26:47.320 --> 00:26:49.560
the sub commands to do the spec info,

00:26:49.560 --> 00:26:51.800
create a branch, do all the things. It

00:26:51.800 --> 00:26:54.080
it up all of all your templates, and it

00:26:54.080 --> 00:26:55.480
can download and update the template.

00:26:55.480 --> 00:26:56.600
So, it's like a single thing. I don't

00:26:56.600 --> 00:26:58.200
know. Originally, with Speck Kit, it was

00:26:58.200 --> 00:27:00.560
like it created bash scripts. There was

00:27:00.560 --> 00:27:02.920
one Python command to do bootstrap. It

00:27:02.920 --> 00:27:05.080
was a bit bit messy. So, with with Speck

00:27:05.080 --> 00:27:07.040
Ledger, it will then if you init, it

00:27:07.040 --> 00:27:08.800
will ask you what agents that you use.

00:27:08.800 --> 00:27:10.840
And if you want, it will then launch

00:27:10.840 --> 00:27:13.360
Claude Code with a prompt, and it will it

00:27:13.360 --> 00:27:15.760
will trigger the um the onboarding

00:27:15.760 --> 00:27:18.360
process, which will launch an explore

00:27:18.360 --> 00:27:20.320
agent, or if you if you do it in a

00:27:20.320 --> 00:27:21.920
brownfield, it should launch an explore

00:27:21.920 --> 00:27:23.680
agent and then come up with a bunch of

00:27:23.680 --> 00:27:24.800
principles.

00:27:24.800 --> 00:27:27.680
>> I can just bring my code over. Okay. It

00:27:27.680 --> 00:27:29.880
should be. I'll try that. I forgot about

00:27:29.880 --> 00:27:31.880
the brownfield. I'm living in such a

00:27:31.880 --> 00:27:34.360
rosy life. But, one thing that I would

00:27:34.360 --> 00:27:36.240
say, like the idea of Speck Ledger was

00:27:36.240 --> 00:27:38.320
that you use the use the GitHub app in

00:27:38.320 --> 00:27:40.640
the repo, and the moment you push, the

00:27:40.640 --> 00:27:43.520
GitHub app will publish the markdown and

00:27:43.520 --> 00:27:45.400
parse out the tasks and generate a

00:27:45.400 --> 00:27:47.560
Kanban and generate a task graph to

00:27:47.560 --> 00:27:49.520
visualize what the tasks are, and then

00:27:49.520 --> 00:27:50.800
show the status of them, and then you

00:27:50.800 --> 00:27:52.200
could click on them and see the details.

00:27:52.200 --> 00:27:53.680
You using Beats under the hood, right?

00:27:53.680 --> 00:27:56.840
Well, originally, yes. But, then we we

00:27:56.840 --> 00:27:58.760
got rid of it because it's really a

00:27:58.760 --> 00:27:59.840
pain. Like

00:27:59.840 --> 00:28:01.040
>> One of the things So, you're back with

00:28:01.040 --> 00:28:02.880
Beats. Yeah, so I'll explain it again.

00:28:02.880 --> 00:28:05.560
So, basically, Beats uses a a task list

00:28:05.560 --> 00:28:07.920
at the root of your repo, right? And

00:28:07.920 --> 00:28:09.360
originally, I thought that's pretty cool

00:28:09.360 --> 00:28:11.640
because that means that when I'm running

00:28:11.640 --> 00:28:14.680
the command, like the the task get the

00:28:14.680 --> 00:28:16.680
the list of tasks, even if I haven't

00:28:16.680 --> 00:28:18.840
closed all of them in the next feature,

00:28:18.840 --> 00:28:20.080
so the feature has been merged and I'm

00:28:20.080 --> 00:28:21.880
working on a new one, it can see all of

00:28:21.880 --> 00:28:23.680
the tasks because it's a shared central

00:28:23.680 --> 00:28:26.560
one in the repo, not a per spec task

00:28:26.560 --> 00:28:28.600
list. Well, that turned out to be really

00:28:28.600 --> 00:28:30.320
painful because then they would create

00:28:30.320 --> 00:28:32.680
merge conflicts. And I mean, Beats

00:28:32.680 --> 00:28:33.720
always had this issue.

00:28:33.720 --> 00:28:35.880
>> the way the branches work. Okay, yeah.

00:28:35.880 --> 00:28:37.160
Yeah, and but Beats always had this

00:28:37.160 --> 00:28:38.840
issue. It it it tried to work around

00:28:38.840 --> 00:28:41.680
this problem by creating a sync branch.

00:28:41.680 --> 00:28:43.160
So, every time you would commit, then

00:28:43.160 --> 00:28:45.400
Beats would pushed the CLI would be

00:28:45.400 --> 00:28:47.120
triggered via a

00:28:47.120 --> 00:28:49.760
to go and update a single branch for

00:28:49.760 --> 00:28:51.480
everyone every other branch to be

00:28:51.480 --> 00:28:53.680
synchronizing into a single branch. So

00:28:53.680 --> 00:28:55.880
they created this thing within beats

00:28:55.880 --> 00:28:57.040
and it happens behind the scenes if you

00:28:57.040 --> 00:28:59.200
don't pay attention and it keeps

00:28:59.200 --> 00:29:00.480
propagating and recreating those

00:29:00.480 --> 00:29:02.480
branches if you if you are not able to

00:29:02.480 --> 00:29:04.600
remove all of the traces of beats. So it

00:29:04.600 --> 00:29:06.000
was creating a lot of conflicts, it

00:29:06.000 --> 00:29:08.440
wasn't able to handle the conflicts well

00:29:08.440 --> 00:29:09.760
and so one of the people that was

00:29:09.760 --> 00:29:11.360
working on spec ledger was like I'm so

00:29:11.360 --> 00:29:14.120
tired of beats and I will just take the

00:29:14.120 --> 00:29:16.600
the the idea but without running a demon

00:29:16.600 --> 00:29:19.320
just JSON L keep a task task graph, you

00:29:19.320 --> 00:29:20.800
know, take the structs from beats like

00:29:20.800 --> 00:29:22.880
look at the beats source code and do it

00:29:22.880 --> 00:29:24.880
per spec. That means if you run spec

00:29:24.880 --> 00:29:26.840
ledger from the root, it will find

00:29:26.840 --> 00:29:28.800
across all of the spec folders all of

00:29:28.800 --> 00:29:30.600
the tasks. It can do that. You can see

00:29:30.600 --> 00:29:31.720
all of the tasks across all of the

00:29:31.720 --> 00:29:33.600
specs. But if you run it within this

00:29:33.600 --> 00:29:35.240
feature, then you will only get the

00:29:35.240 --> 00:29:37.120
feature specs like this the task for

00:29:37.120 --> 00:29:37.800
that feature spec.

00:29:37.800 --> 00:29:40.360
>> sounds bloody sensible. And then the

00:29:40.360 --> 00:29:43.120
JSON L task list is in the folder so it

00:29:43.120 --> 00:29:44.960
will not conflict between each other.

00:29:44.960 --> 00:29:46.560
Because they're all like contained

00:29:46.560 --> 00:29:48.360
within the features so they will not

00:29:48.360 --> 00:29:50.120
fight constantly. So it's way way

00:29:50.120 --> 00:29:52.160
better. So that's why it was written.

00:29:52.160 --> 00:29:54.160
I understand I I I I understand the

00:29:54.160 --> 00:29:56.080
drawbacks of beats. I also I find that

00:29:56.080 --> 00:29:57.840
like some people are comfortable using

00:29:57.840 --> 00:29:59.880
beats or something like beats and then

00:29:59.880 --> 00:30:01.120
some people are definitely more

00:30:01.120 --> 00:30:02.640
comfortable marked out but that's

00:30:02.640 --> 00:30:04.440
another that's another separate topic. I

00:30:04.440 --> 00:30:07.120
wanted to to to to check in with you

00:30:07.120 --> 00:30:08.280
with

00:30:08.280 --> 00:30:09.880
with the

00:30:09.880 --> 00:30:11.640
the multi player what what what is your

00:30:11.640 --> 00:30:13.960
vision when it comes to multi player

00:30:13.960 --> 00:30:15.440
development

00:30:15.440 --> 00:30:17.240
with spec ledger cuz that's the ultimate

00:30:17.240 --> 00:30:19.520
that's the ultimate

00:30:19.520 --> 00:30:21.960
underscore with spec

00:30:21.960 --> 00:30:24.200
spec driven development is how the multi

00:30:24.200 --> 00:30:26.640
player works. Yeah.

00:30:26.640 --> 00:30:29.440
I'm I'm struggling to see it myself but

00:30:29.440 --> 00:30:31.400
I've just obviously just did it in one

00:30:31.400 --> 00:30:34.440
my mono repo with mono

00:30:34.440 --> 00:30:35.520
Yeah, exactly. If you don't have other

00:30:35.520 --> 00:30:37.400
people to work with you cannot see it. I

00:30:37.400 --> 00:30:38.320
mean

00:30:38.320 --> 00:30:42.400
I I saw the vision and when we all three

00:30:42.400 --> 00:30:44.520
during the week like I was in Hanoi, one

00:30:44.520 --> 00:30:46.120
person was in Saigon, another person was

00:30:46.120 --> 00:30:48.600
in Singa in Singapore, we would do we

00:30:48.600 --> 00:30:50.560
would be on a shared group chat because

00:30:50.560 --> 00:30:53.080
we're not a company. And we would just

00:30:53.080 --> 00:30:55.680
constantly like, "Hey, I specked out

00:30:55.680 --> 00:30:57.040
this thing." And then during a meeting

00:30:57.040 --> 00:30:58.520
we would make some notes and then we

00:30:58.520 --> 00:31:00.000
would go off and you know, create the

00:31:00.000 --> 00:31:01.480
different features that we want to work

00:31:01.480 --> 00:31:03.120
on. And then we could share very

00:31:03.120 --> 00:31:06.720
quickly. Yo, I I just had with my agents

00:31:06.720 --> 00:31:08.000
and with the contacts I provided I

00:31:08.000 --> 00:31:09.560
generated these user stories. Is there

00:31:09.560 --> 00:31:11.280
any concern? Does this look like a good

00:31:11.280 --> 00:31:13.200
approach to you guys? And then we would

00:31:13.200 --> 00:31:14.760
just quickly go through, put some

00:31:14.760 --> 00:31:16.320
comments, and say, "Hey, I think you

00:31:16.320 --> 00:31:18.400
misunderstood." And and the great thing

00:31:18.400 --> 00:31:20.560
is like I mentioned this before, I would

00:31:20.560 --> 00:31:22.680
do a user stories and then somebody left

00:31:22.680 --> 00:31:25.120
a comment and I was like, "This comments

00:31:25.120 --> 00:31:27.480
makes no sense to me whatsoever." And I

00:31:27.480 --> 00:31:30.200
would I was I was about to reply like,

00:31:30.200 --> 00:31:32.400
"That makes no sense." And then instead

00:31:32.400 --> 00:31:35.600
I use the Spec Ledger CLI and it

00:31:35.600 --> 00:31:37.720
basically, you know that the Specket has

00:31:37.720 --> 00:31:39.880
this clarify where you you take all the

00:31:39.880 --> 00:31:41.200
user stories and there's always edge

00:31:41.200 --> 00:31:43.160
cases and then it will go like, "There's

00:31:43.160 --> 00:31:45.400
still unresolved questions. How do you

00:31:45.400 --> 00:31:46.560
like these are the different ways you

00:31:46.560 --> 00:31:48.200
could approach them, right?" So this

00:31:48.200 --> 00:31:50.520
clarify command, yeah, in Spec Ledger

00:31:50.520 --> 00:31:53.160
this clarify command, we actually push

00:31:53.160 --> 00:31:55.680
the commit with all of the edge cases

00:31:55.680 --> 00:31:57.800
and then we let people comment and the

00:31:57.800 --> 00:32:00.320
clarify command tells the agent, "Great,

00:32:00.320 --> 00:32:01.680
you've looked at the edge cases in the

00:32:01.680 --> 00:32:03.840
documents. Go and look if anyone left a

00:32:03.840 --> 00:32:06.040
comment on any of these artifacts." And

00:32:06.040 --> 00:32:08.720
then the SL CLI will pull all the

00:32:08.720 --> 00:32:10.920
comments that is in the web web app and

00:32:10.920 --> 00:32:12.760
then pull them down and then look at

00:32:12.760 --> 00:32:13.160
what's

00:32:13.160 --> 00:32:14.720
>> down from from GitHub? Where are the

00:32:14.720 --> 00:32:17.120
comments by the way? Metadata. That's

00:32:17.120 --> 00:32:19.000
that's the one thing that is not stored.

00:32:19.000 --> 00:32:21.400
It's like, okay, the way that I see Spec

00:32:21.400 --> 00:32:23.200
Ledger is like the pull request view of

00:32:23.200 --> 00:32:24.640
GitHub where you leave comments on the

00:32:24.640 --> 00:32:26.800
PR except the PR doesn't organize the

00:32:26.800 --> 00:32:28.880
files in a nice way. Spec Ledger

00:32:28.880 --> 00:32:31.080
organizes the files in a way that makes

00:32:31.080 --> 00:32:32.680
sense for Spec Ledger development.

00:32:32.680 --> 00:32:35.320
>> this sort of view of the branch and then

00:32:35.320 --> 00:32:38.320
people comment on it inside a SpecLedger

00:32:38.320 --> 00:32:38.840
web application.

00:32:38.840 --> 00:32:40.960
>> like I I basically looked at how Jira

00:32:40.960 --> 00:32:43.160
organized documents. If you look at Jira

00:32:43.160 --> 00:32:45.000
at the top, you have like these

00:32:45.000 --> 00:32:46.520
artifacts have been created within the

00:32:46.520 --> 00:32:48.960
spec phase or the these artifacts have

00:32:48.960 --> 00:32:51.120
been created during the planning phase.

00:32:51.120 --> 00:32:52.800
These artifacts have been created during

00:32:52.800 --> 00:32:54.640
the tasks phase. And if And Jira

00:32:54.640 --> 00:32:56.560
visualizes the process, it says you're

00:32:56.560 --> 00:32:58.040
in the spec phase, you have artifacts

00:32:58.040 --> 00:33:00.440
there. You did not do the plan and

00:33:00.440 --> 00:33:02.680
research yet. So So the SpecLedger took

00:33:02.680 --> 00:33:05.880
that idea and visualizes it on a web app

00:33:05.880 --> 00:33:07.040
share it with other people and other

00:33:07.040 --> 00:33:09.160
people can see, oh this feature branch

00:33:09.160 --> 00:33:10.920
is already at the task phase. It has

00:33:10.920 --> 00:33:12.280
already done the user stories. It has

00:33:12.280 --> 00:33:13.880
already generated the research and it

00:33:13.880 --> 00:33:16.240
has already generated the task graph.

00:33:16.240 --> 00:33:19.240
That feature branch from Kai is still in

00:33:19.240 --> 00:33:21.040
the specify phase. That means that there

00:33:21.040 --> 00:33:23.000
are only artifacts related to that phase

00:33:23.000 --> 00:33:25.160
inside this branch. There has been no no

00:33:25.160 --> 00:33:27.080
research. There has been no task

00:33:27.080 --> 00:33:29.200
generation yet. So that's the idea.

00:33:29.200 --> 00:33:31.440
Compared to a PR where you just see a

00:33:31.440 --> 00:33:33.600
list alphabetically organized where S

00:33:33.600 --> 00:33:36.040
become comes after What is it? Research

00:33:36.040 --> 00:33:38.360
or P Q R S? Yes. So you would see like

00:33:38.360 --> 00:33:40.280
research.md and then you would see

00:33:40.280 --> 00:33:42.560
spec.md and you'll be confused because

00:33:42.560 --> 00:33:44.080
in the PR flow, if you look at the

00:33:44.080 --> 00:33:46.280
GitHub pull request view, it doesn't

00:33:46.280 --> 00:33:48.000
tell you you should read the spec first

00:33:48.000 --> 00:33:49.280
you should go look at the research

00:33:49.280 --> 00:33:50.760
because the research follows from the

00:33:50.760 --> 00:33:52.640
spec, right? So that's the idea of

00:33:52.640 --> 00:33:55.000
SpecLedger. It tells you that we have

00:33:55.000 --> 00:33:57.000
done the specification and in here's the

00:33:57.000 --> 00:33:58.440
spec and it has a little star because

00:33:58.440 --> 00:34:00.400
that's the core artifact of this stage.

00:34:00.400 --> 00:34:01.920
And and and that's the one you should be

00:34:01.920 --> 00:34:04.120
looking at. You read the user stories.

00:34:04.120 --> 00:34:06.280
And then if you want to like

00:34:06.280 --> 00:34:08.040
I was looking for screenshots, but I

00:34:08.040 --> 00:34:10.520
guess the the app is evolving a lot.

00:34:10.520 --> 00:34:12.000
Yeah, I mean honestly this could be one

00:34:12.000 --> 00:34:14.639
of the If it is it was a monorepo, but

00:34:14.639 --> 00:34:15.960
the problem is that people I work with

00:34:15.960 --> 00:34:19.000
didn't make it a monorepo. Um I I I want

00:34:19.000 --> 00:34:20.840
to put everything under monorepo. Docs,

00:34:20.840 --> 00:34:23.320
landing page, backend, CLI, everything

00:34:23.320 --> 00:34:25.399
public. But um yeah, I

00:34:25.399 --> 00:34:27.240
I haven't had a lot of time. I've

00:34:27.240 --> 00:34:28.879
re-architected the thing because it's

00:34:28.879 --> 00:34:30.280
super big.

00:34:30.280 --> 00:34:33.480
>> architecture aside, I would love to um

00:34:33.480 --> 00:34:35.919
capture the um um

00:34:35.919 --> 00:34:38.080
What I'm looking to see is like an an

00:34:38.080 --> 00:34:39.960
essence of what the workflow looks like.

00:34:39.960 --> 00:34:42.200
You know, Vincent comes along, comes up

00:34:42.200 --> 00:34:44.840
with the user story, Bob comes along,

00:34:44.840 --> 00:34:47.800
has a comment here, Jane comes along,

00:34:47.800 --> 00:34:50.000
have we thought about this? And then

00:34:50.000 --> 00:34:52.280
these are this is great. I had like a

00:34:52.280 --> 00:34:55.440
mock-up on speclager.io/

00:34:55.440 --> 00:34:58.440
is it demo? Yeah. Yeah, that's very old.

00:34:58.440 --> 00:35:00.520
The very first time I actually you can

00:35:00.520 --> 00:35:01.840
click on that and that's the cool thing

00:35:01.840 --> 00:35:03.640
about like sharing a little mock-up at

00:35:03.640 --> 00:35:08.400
HTML. So basically we asked, okay

00:35:08.400 --> 00:35:11.480
We had Cloud build a little mock-up UI.

00:35:11.480 --> 00:35:14.120
This is all fake data, all JSON static,

00:35:14.120 --> 00:35:16.800
all served from S3 behind CloudFront.

00:35:16.800 --> 00:35:19.520
And this was the this was the design

00:35:19.520 --> 00:35:21.200
that I wanted. So you can see we have to

00:35:21.200 --> 00:35:23.200
specify phase, you can collapse that.

00:35:23.200 --> 00:35:25.120
You can click on the little issues tab

00:35:25.120 --> 00:35:26.440
at the top where you will see your

00:35:26.440 --> 00:35:28.640
combine and you can see the the the

00:35:28.640 --> 00:35:30.440
issues tab. You have artifacts and

00:35:30.440 --> 00:35:31.520
issues and changes.

00:35:31.520 --> 00:35:33.080
>> I'm sorry, sorry. I I was going

00:35:33.080 --> 00:35:34.160
>> Yeah, and then you can switch that over

00:35:34.160 --> 00:35:36.440
to tree view on the top on the top right

00:35:36.440 --> 00:35:38.600
tree view. And that's that's what you

00:35:38.600 --> 00:35:40.600
would see in beats or in if you would

00:35:40.600 --> 00:35:42.560
use pal. So this is the web view of

00:35:42.560 --> 00:35:44.840
that. And then the changes to be honest,

00:35:44.840 --> 00:35:46.720
I hate that. It needs to be part of the

00:35:46.720 --> 00:35:49.680
artifacts. You I want the Google Doc So

00:35:49.680 --> 00:35:51.520
this is just the get diff view which to

00:35:51.520 --> 00:35:53.360
me makes no sense. If you use Google

00:35:53.360 --> 00:35:54.720
Docs and you work collaborative on

00:35:54.720 --> 00:35:56.840
documents, you can click on you you can

00:35:56.840 --> 00:35:59.280
see the versions of what this document

00:35:59.280 --> 00:36:01.160
and you can compare two versions. And

00:36:01.160 --> 00:36:02.440
and this whole changes being on a

00:36:02.440 --> 00:36:04.160
completely different area is is really

00:36:04.160 --> 00:36:05.760
bad and and that's one of the things I

00:36:05.760 --> 00:36:07.240
will change when I finally get around to

00:36:07.240 --> 00:36:09.120
do redoing the UI.

00:36:09.120 --> 00:36:10.040
Um

00:36:10.040 --> 00:36:11.640
Yeah, and then if you click you see you

00:36:11.640 --> 00:36:13.160
have the two phases. As you see in this

00:36:13.160 --> 00:36:15.360
case the in the workflow you see specify

00:36:15.360 --> 00:36:17.040
and plan has been completed. Although

00:36:17.040 --> 00:36:19.240
that the visualization is pretty bad.

00:36:19.240 --> 00:36:20.960
Uh oh, you're okay, you're on a

00:36:20.960 --> 00:36:23.080
different branch as me.

00:36:23.080 --> 00:36:24.400
Um

00:36:24.400 --> 00:36:26.320
Yeah, so you can see at which stage each

00:36:26.320 --> 00:36:28.280
of them are. When you go to spec, you

00:36:28.280 --> 00:36:29.800
can see the comments on If you click on

00:36:29.800 --> 00:36:31.720
one of them, spec.md.

00:36:31.720 --> 00:36:34.200
Click on the spec.md. Then you can see

00:36:34.200 --> 00:36:35.280
you can select text.

00:36:35.280 --> 00:36:36.520
>> Ah.

00:36:36.520 --> 00:36:38.800
Select some text. Not there, not in the

00:36:38.800 --> 00:36:40.760
comments. Yeah, there. Select some text.

00:36:40.760 --> 00:36:42.280
And then you can click comment, and can

00:36:42.280 --> 00:36:45.080
leave a little comment, blah blah blah.

00:36:45.080 --> 00:36:46.560
>> And then all of those comments and they

00:36:46.560 --> 00:36:48.720
are also threaded.

00:36:48.720 --> 00:36:49.920
I'm sorry. I'm glad you're working on

00:36:49.920 --> 00:36:51.520
this I'm really happy that you're

00:36:51.520 --> 00:36:52.160
working on this.

00:36:52.160 --> 00:36:54.840
>> on it anymore. We working on it like at

00:36:54.840 --> 00:36:56.480
the start of the year. Now I want to

00:36:56.480 --> 00:36:58.360
rewrite it because

00:36:58.360 --> 00:37:00.080
>> what what what what why are you getting

00:37:00.080 --> 00:37:01.680
distracted like is it cuz you're trying

00:37:01.680 --> 00:37:04.720
to just take home some money? Mhm.

00:37:04.720 --> 00:37:06.560
Like I mean I want to open source this

00:37:06.560 --> 00:37:08.800
whole thing. It's a Next.js app backed

00:37:08.800 --> 00:37:11.680
by Supabase hosted on Vercel, but I am

00:37:11.680 --> 00:37:14.280
doing a full review of the Supabase. And

00:37:14.280 --> 00:37:16.960
I honestly spent like almost 2 days

00:37:16.960 --> 00:37:19.560
asking Claude to help me understand how

00:37:19.560 --> 00:37:22.920
to properly architecture a Supabase app

00:37:22.920 --> 00:37:23.720
because honestly

00:37:23.720 --> 00:37:25.720
>> it's like it's just Postgres, isn't it?

00:37:25.720 --> 00:37:28.080
Yeah, it's a tier It's like a two-tier.

00:37:28.080 --> 00:37:29.600
It's like go back to stored procedures

00:37:29.600 --> 00:37:31.240
type of thing. You know, it's back to

00:37:31.240 --> 00:37:33.960
the '90s. What? Why are you architecting

00:37:33.960 --> 00:37:35.920
it like that? It seems a bit bizarre.

00:37:35.920 --> 00:37:38.120
>> Because that's how Supabase works. I was

00:37:38.120 --> 00:37:39.880
asking like how do I

00:37:39.880 --> 00:37:41.840
>> not depend on Firebase?

00:37:41.840 --> 00:37:43.320
It's I mean if it's an open source

00:37:43.320 --> 00:37:45.000
project, you can't depend on that.

00:37:45.000 --> 00:37:47.120
>> What? I make it easily I want to I want

00:37:47.120 --> 00:37:49.840
it to be super easily hostable. And

00:37:49.840 --> 00:37:52.200
Supabase gives you like a CRUD back end

00:37:52.200 --> 00:37:53.880
very quickly. But then when you look

00:37:53.880 --> 00:37:56.440
into it, it actually sucks to be honest,

00:37:56.440 --> 00:37:59.120
but Okay. Well, anyway.

00:37:59.120 --> 00:38:02.080
Make it make it AWS hostable. I mean AWS

00:38:02.080 --> 00:38:03.640
has a lot of stuff out of the out of the

00:38:03.640 --> 00:38:05.520
box. The database stuff I think is

00:38:05.520 --> 00:38:07.360
cheaper than it used to be. I know it's

00:38:07.360 --> 00:38:10.120
not free. Yeah. But With Supabase you

00:38:10.120 --> 00:38:12.080
get a free setup easily and also you can

00:38:12.080 --> 00:38:13.960
self-host completely. You can you can

00:38:13.960 --> 00:38:16.160
run it on localhost compose stack. So I

00:38:16.160 --> 00:38:17.840
don't like Supabase and that's why I

00:38:17.840 --> 00:38:19.560
spent 2 days trying to understand why I

00:38:19.560 --> 00:38:20.920
should be using Supabase and why I

00:38:20.920 --> 00:38:22.360
should like it. It's It's been

00:38:22.360 --> 00:38:24.240
frustrating. Like the very first I did a

00:38:24.240 --> 00:38:25.880
hackathon and they introduced Superbase

00:38:25.880 --> 00:38:27.360
and I hated it. I was like, what is

00:38:27.360 --> 00:38:29.200
this? This is from from client to

00:38:29.200 --> 00:38:31.000
database directly. Where is the

00:38:31.000 --> 00:38:32.200
the backend?

00:38:32.200 --> 00:38:33.840
The application layer, where is the

00:38:33.840 --> 00:38:36.160
logic? And then they built this thing in

00:38:36.160 --> 00:38:38.320
Superbase because I I was like I had the

00:38:38.320 --> 00:38:40.240
idea, I had the mock-ups of the UI and

00:38:40.240 --> 00:38:43.080
then they spent like two people junior

00:38:43.080 --> 00:38:45.120
to build it and um

00:38:45.120 --> 00:38:46.280
and they use Superbase and I was like,

00:38:46.280 --> 00:38:49.080
okay, I'll I'll guess I can I can try to

00:38:49.080 --> 00:38:50.560
come up with that.

00:38:50.560 --> 00:38:52.600
But now we all know that you're that was

00:38:52.600 --> 00:38:54.480
not the best decision. But what is your

00:38:54.480 --> 00:38:57.000
opinion of SQLite? That's another one

00:38:57.000 --> 00:39:00.000
that I I like to use locally, but on the

00:39:00.000 --> 00:39:02.160
cloud it's a different story. So SQLite

00:39:02.160 --> 00:39:04.080
is super interesting, uh but it doesn't

00:39:04.080 --> 00:39:06.040
do any like proper types in the in the

00:39:06.040 --> 00:39:08.520
backend. When I build a Terraform state

00:39:08.520 --> 00:39:10.720
backend, I support SQLite for like

00:39:10.720 --> 00:39:12.520
having a single node backend, right? So

00:39:12.520 --> 00:39:13.680
you can just run the Go language web

00:39:13.680 --> 00:39:15.800
server backed by an SQLite, set up

00:39:15.800 --> 00:39:18.560
Lightstream to have the write-ahead logs

00:39:18.560 --> 00:39:20.600
streamed to S3 and have point-in-time

00:39:20.600 --> 00:39:22.520
recovery very easily without doing like

00:39:22.520 --> 00:39:24.240
daily backups. So you can do a lot of

00:39:24.240 --> 00:39:26.000
really cool stuff with SQLite.

00:39:26.000 --> 00:39:27.800
But the moment I started saying I'm also

00:39:27.800 --> 00:39:30.400
supporting RDS and Postgres, then I

00:39:30.400 --> 00:39:33.240
having so many issues because you can't

00:39:33.240 --> 00:39:35.520
do it in SQLite. Like I I built like a

00:39:35.520 --> 00:39:37.400
repository pattern and and then

00:39:37.400 --> 00:39:39.400
integration and there's so much like the

00:39:39.400 --> 00:39:41.880
database schemas I was using uh Boon

00:39:41.880 --> 00:39:44.160
ORM, which is a Go language ORM that

00:39:44.160 --> 00:39:46.400
supports SQLite and Postgres quite well.

00:39:46.400 --> 00:39:49.280
And there was so many problems with

00:39:49.280 --> 00:39:51.680
supporting it. The minute you you have

00:39:51.680 --> 00:39:53.760
that requirement of or you have that

00:39:53.760 --> 00:39:56.720
like support other databases problem and

00:39:56.720 --> 00:39:58.040
you should earlier like if you want to

00:39:58.040 --> 00:40:00.920
make it easily hostable, I mean

00:40:00.920 --> 00:40:02.960
the hosting companies lock you in for

00:40:02.960 --> 00:40:04.960
one reason or another. There's also

00:40:04.960 --> 00:40:08.000
Turso that that they because SQLite

00:40:08.000 --> 00:40:09.800
license is very strange. Like they give

00:40:09.800 --> 00:40:11.640
you the software for free, but they they

00:40:11.640 --> 00:40:13.520
charge you for the testing framework.

00:40:13.520 --> 00:40:16.120
And then Turso I think rewrote SQLite I

00:40:16.120 --> 00:40:19.520
think in Rust. I'm not sure.

00:40:19.520 --> 00:40:21.160
And then they have three rights to worry

00:40:21.160 --> 00:40:22.640
about.

00:40:22.640 --> 00:40:24.160
Re-implement

00:40:24.160 --> 00:40:25.720
or reverse engineer the test suite,

00:40:25.720 --> 00:40:28.160
which is not available. And they made a

00:40:28.160 --> 00:40:29.880
company and then they make like they

00:40:29.880 --> 00:40:32.120
call it like Turso is a database at the

00:40:32.120 --> 00:40:33.920
edge. So you can have like a distributed

00:40:33.920 --> 00:40:35.480
SQL Lite database at the edge.

00:40:35.480 --> 00:40:36.040
>> Mhm.

00:40:36.040 --> 00:40:37.400
And they have some really cool ideas

00:40:37.400 --> 00:40:40.000
there. It makes me think why didn't

00:40:40.000 --> 00:40:43.880
Steve Yegge consider SQL Lite for Beats?

00:40:43.880 --> 00:40:45.280
Because it is very

00:40:45.280 --> 00:40:47.120
>> migrated.

00:40:47.120 --> 00:40:48.280
They migrated to

00:40:48.280 --> 00:40:51.520
>> to Dolt or something.

00:40:51.520 --> 00:40:53.560
But which is Because because it solves

00:40:53.560 --> 00:40:55.480
all of their like distributed Git

00:40:55.480 --> 00:40:56.880
branches problem that we just talked

00:40:56.880 --> 00:40:58.840
about. He had his demon, he had this

00:40:58.840 --> 00:41:01.760
whole Git sync branch approach. And then

00:41:01.760 --> 00:41:03.160
when they migrated to Dolt, I think they

00:41:03.160 --> 00:41:04.960
solved a lot of those problems. But I

00:41:04.960 --> 00:41:07.800
never like tried using it. Well, there's

00:41:07.800 --> 00:41:09.960
so many things to try. I guess I have a

00:41:09.960 --> 00:41:13.120
good a good problem. AI guardrails and I

00:41:13.120 --> 00:41:15.440
can I have the time to try different

00:41:15.440 --> 00:41:16.640
things. So I'm just going to try

00:41:16.640 --> 00:41:18.800
different things. I'm going to try more

00:41:18.800 --> 00:41:20.320
and more. Hey, did you want to talk

00:41:20.320 --> 00:41:21.920
about anything else? Did you want to

00:41:21.920 --> 00:41:24.720
talk about cuz got 10 minutes left. Did

00:41:24.720 --> 00:41:26.640
you want to talk about another security

00:41:26.640 --> 00:41:29.720
topic about the TanStack or because you

00:41:29.720 --> 00:41:31.240
mentioned it and I didn't really

00:41:31.240 --> 00:41:33.200
understand what the the problem was cuz

00:41:33.200 --> 00:41:35.760
I cuz in my mind you educated me on the

00:41:35.760 --> 00:41:38.920
PNPM supply security stuff.

00:41:38.920 --> 00:41:41.480
Oh, I got educated by someone yesterday.

00:41:41.480 --> 00:41:42.080
Oh no, two days

00:41:42.080 --> 00:41:43.960
>> And I thought to myself, if you use PNPM

00:41:43.960 --> 00:41:46.520
you're fine. No, but like

00:41:46.520 --> 00:41:47.960
Actually very interesting feedback I

00:41:47.960 --> 00:41:48.960
got.

00:41:48.960 --> 00:41:50.960
Okay, what was the feedback?

00:41:50.960 --> 00:41:52.680
Okay, so first off, of course it's been

00:41:52.680 --> 00:41:54.240
a a roller coaster ride, you know,

00:41:54.240 --> 00:41:55.800
because I don't know if we covered this,

00:41:55.800 --> 00:41:58.400
but we had the copy fail local privilege

00:41:58.400 --> 00:42:01.080
escalation Linux kernel bug.

00:42:01.080 --> 00:42:03.640
>> That was allowing people to assume root

00:42:03.640 --> 00:42:05.200
permissions if they

00:42:05.200 --> 00:42:08.760
access. So local then somebody some

00:42:08.760 --> 00:42:10.840
somebody reported a but a

00:42:10.840 --> 00:42:13.240
bug called copy Sorry,

00:42:13.240 --> 00:42:16.080
dirty frag, which researchers started

00:42:16.080 --> 00:42:18.960
patching up on an open source repo, so

00:42:18.960 --> 00:42:21.040
on an open branch. And an independent

00:42:21.040 --> 00:42:23.000
researcher saw the branch, and the

00:42:23.000 --> 00:42:25.360
branch name was like in the class of

00:42:25.360 --> 00:42:27.640
copy fail. So, that drew his attention,

00:42:27.640 --> 00:42:29.480
like what is this copy fail category

00:42:29.480 --> 00:42:31.480
branch? Like is that another local

00:42:31.480 --> 00:42:33.960
privilege escalation bug? And so, he

00:42:33.960 --> 00:42:36.880
independently wrote a Python exploit

00:42:36.880 --> 00:42:38.960
script based on the changes that he saw,

00:42:38.960 --> 00:42:41.720
and then he published it. And then then

00:42:41.720 --> 00:42:43.640
everyone suddenly was like, "Holy, this

00:42:43.640 --> 00:42:45.760
is breaking the embargo. There has been

00:42:45.760 --> 00:42:47.680
no fixes released. Like the kernel

00:42:47.680 --> 00:42:49.880
hasn't been released. The distributions

00:42:49.880 --> 00:42:51.800
haven't been able to patch anything. And

00:42:51.800 --> 00:42:53.800
now there's a live exploit, which is a

00:42:53.800 --> 00:42:56.120
zero day, that people can abuse." So,

00:42:56.120 --> 00:42:57.440
initially the reaction was like,

00:42:57.440 --> 00:42:59.880
"Embargo has been broken by somebody."

00:42:59.880 --> 00:43:02.000
Uh but then he clarified on the mailing

00:43:02.000 --> 00:43:04.080
list, "Sorry, guys. I just saw this

00:43:04.080 --> 00:43:05.760
branch. It drew my attention. It didn't

00:43:05.760 --> 00:43:08.280
know it was like It wasn't my intention

00:43:08.280 --> 00:43:10.720
to create a zero day exploit." And for

00:43:10.720 --> 00:43:12.080
me there was like, "I just finished

00:43:12.080 --> 00:43:14.800
rolling out new AMIs, cuz I do immutable

00:43:14.800 --> 00:43:16.160
infrastructure with the new kernel

00:43:16.160 --> 00:43:18.320
build, and now I have to do it all over

00:43:18.320 --> 00:43:20.560
again. And worse, there were no kernel

00:43:20.560 --> 00:43:22.120
patches yet." So, that's where I think

00:43:22.120 --> 00:43:23.720
we had this discussion. People started

00:43:23.720 --> 00:43:26.160
releasing remediation instructions,

00:43:26.160 --> 00:43:28.800
which is like you have to go and and

00:43:28.800 --> 00:43:30.400
inside the Linux kernel disable these

00:43:30.400 --> 00:43:32.520
modules if you don't use it, because

00:43:32.520 --> 00:43:34.840
that's your right now your protection

00:43:34.840 --> 00:43:37.160
against the LP. And the funny thing is

00:43:37.160 --> 00:43:38.760
that What What is Sorry, what is LP?

00:43:38.760 --> 00:43:41.480
>> Local privileges escalation.

00:43:41.480 --> 00:43:42.000
>> Okay.

00:43:42.000 --> 00:43:44.120
>> So, so the The funny thing is that the

00:43:44.120 --> 00:43:45.880
these remediation instructions are being

00:43:45.880 --> 00:43:48.280
distributed like agent prompts, right?

00:43:48.280 --> 00:43:50.560
>> Yeah. Because like you don't need to

00:43:50.560 --> 00:43:52.520
tell you don't need to like step one do

00:43:52.520 --> 00:43:54.600
this, step two do this. No, you you can

00:43:54.600 --> 00:43:56.920
just say give this prompt to your agent

00:43:56.920 --> 00:43:59.120
and ask it to go and fix things. So,

00:43:59.120 --> 00:44:01.000
originally when I was I was looking at

00:44:01.000 --> 00:44:04.120
fixing the issue, I have AWS SSM, so all

00:44:04.120 --> 00:44:05.960
of my Linux instances are available in

00:44:05.960 --> 00:44:08.720
an inventory, and I can give the agent

00:44:08.720 --> 00:44:10.520
access to it, and I say, "Find out all

00:44:10.520 --> 00:44:12.200
the Linux instance or find out all the

00:44:12.200 --> 00:44:14.520
instances that are running the AMI that

00:44:14.520 --> 00:44:16.080
we need to go patch." And then it goes

00:44:16.080 --> 00:44:19.160
and SSH into and and patches it up. Are

00:44:19.160 --> 00:44:21.240
you using AWS Inspector to sort of

00:44:21.240 --> 00:44:24.080
highlight the vulnerability or

00:44:24.080 --> 00:44:27.320
We have Wiz.io to to

00:44:27.320 --> 00:44:30.280
you know, inspect the runtime. It's kind

00:44:30.280 --> 00:44:31.880
of like intrusion detection and

00:44:31.880 --> 00:44:33.520
prevention.

00:44:33.520 --> 00:44:33.800
Okay.

00:44:33.800 --> 00:44:34.840
>> agents

00:44:34.840 --> 00:44:36.760
So, they Wiz gives us like a graph.

00:44:36.760 --> 00:44:39.720
Yeah. Okay. And does it know about

00:44:39.720 --> 00:44:42.160
these copy fails and these It does. It

00:44:42.160 --> 00:44:43.960
does. It It does highlight like Yeah, if

00:44:43.960 --> 00:44:46.520
I don't uh patch the the instance, then

00:44:46.520 --> 00:44:48.720
then we get an email, and we see a nice

00:44:48.720 --> 00:44:50.960
graph of why and the the the risk

00:44:50.960 --> 00:44:52.520
because if this is a Linux instance with

00:44:52.520 --> 00:44:53.760
no public endpoints, and it's in a

00:44:53.760 --> 00:44:55.840
private subnet, and it's usually fine. I

00:44:55.840 --> 00:44:58.880
mean, like it's a lower risk factor.

00:44:58.880 --> 00:45:00.960
I mean, do you have local users with

00:45:00.960 --> 00:45:02.720
shell access to

00:45:02.720 --> 00:45:03.400
>> No.

00:45:03.400 --> 00:45:05.400
So, that's why also we are a lot So, the

00:45:05.400 --> 00:45:07.320
risk is bloody low for you, isn't it?

00:45:07.320 --> 00:45:09.880
Yeah. Yeah, the risk is much lower, but

00:45:09.880 --> 00:45:11.440
but you want to patch these things

00:45:11.440 --> 00:45:12.760
because

00:45:12.760 --> 00:45:14.480
they do show up in

00:45:14.480 --> 00:45:16.680
in those tools. And for example, my

00:45:16.680 --> 00:45:18.760
Atlantis instance has a public IP that

00:45:18.760 --> 00:45:21.240
is reachable by GitHub webhooks. So, it

00:45:21.240 --> 00:45:23.760
will usually find and and highlight that

00:45:23.760 --> 00:45:25.600
one because it says, "Oh, this Atlantis

00:45:25.600 --> 00:45:27.680
instance is public IP like the EI

00:45:27.680 --> 00:45:29.880
because it shows the AWS resources, and

00:45:29.880 --> 00:45:31.480
it shows that there's an elastic IP

00:45:31.480 --> 00:45:33.320
publicly attached to it.

00:45:33.320 --> 00:45:36.280
>> if it's like a public IP running an

00:45:36.280 --> 00:45:38.600
endpoint, you can't run that sort of

00:45:38.600 --> 00:45:40.600
LPE, right? There's There's no way you

00:45:40.600 --> 00:45:42.600
can do it. I mean, like I do I do

00:45:42.600 --> 00:45:44.600
sometimes wonder like you were just

00:45:44.600 --> 00:45:46.080
saying that like, "Oh, I just patched

00:45:46.080 --> 00:45:47.720
AMIs, and then I have to do it all over

00:45:47.720 --> 00:45:49.440
again." I mean, you're doing a lot of

00:45:49.440 --> 00:45:51.800
work. No doubt. Actually, no, I'm not

00:45:51.800 --> 00:45:52.200
actually doing

00:45:52.200 --> 00:45:53.800
>> you I sometimes think it was like Do you

00:45:53.800 --> 00:45:55.800
Do you need to do it? You don't really

00:45:55.800 --> 00:45:57.400
need to do it, really, cuz there there's

00:45:57.400 --> 00:45:59.600
no risk, in a way. If the If you don't

00:45:59.600 --> 00:46:01.440
have This is defense in depth. This is

00:46:01.440 --> 00:46:03.800
in case there's an RCE, somebody gets

00:46:03.800 --> 00:46:05.240
like let's say that I had running an

00:46:05.240 --> 00:46:07.280
Engine-X and I'm using OpenResty with

00:46:07.280 --> 00:46:10.800
Lua scripts and there's an exploit for

00:46:10.800 --> 00:46:13.840
someone to get remote code execution on

00:46:13.840 --> 00:46:15.640
the host. But Engine-X no problem,

00:46:15.640 --> 00:46:16.960
right? Because I'm running it under the

00:46:16.960 --> 00:46:19.720
Engine-X web user in Linux and that user

00:46:19.720 --> 00:46:21.480
doesn't have any permissions. And then

00:46:21.480 --> 00:46:23.240
you have an LPE because you never put

00:46:23.240 --> 00:46:25.720
patch to copy fail. So then that that

00:46:25.720 --> 00:46:27.520
Engine-X user that has no permissions

00:46:27.520 --> 00:46:29.240
suddenly elevates the permission to

00:46:29.240 --> 00:46:32.240
become a root on that host and suddenly

00:46:32.240 --> 00:46:34.000
gets access to write to an EBS volume

00:46:34.000 --> 00:46:35.840
and and persist itself. Because I have

00:46:35.840 --> 00:46:38.200
like some nodes that like they're in

00:46:38.200 --> 00:46:39.960
ASGs and ephemeral, they get like

00:46:39.960 --> 00:46:42.480
rotated, but they do have like for

00:46:42.480 --> 00:46:44.400
example TLS certificates that are maybe

00:46:44.400 --> 00:46:46.240
with Let's Encrypt stored on the on the

00:46:46.240 --> 00:46:48.800
on a volume. And so the Engine-X web

00:46:48.800 --> 00:46:50.200
server doesn't have access to that

00:46:50.200 --> 00:46:52.040
volume. Well, if I'm using

00:46:52.040 --> 00:46:55.080
>> So I still I still think that I mean who

00:46:55.080 --> 00:46:57.480
uses Engine-X nowadays, but I still I

00:46:57.480 --> 00:46:59.280
still find that hard to imagine

00:46:59.280 --> 00:47:01.240
sometimes. Anyway, I'm not trying to say

00:47:01.240 --> 00:47:02.760
that there's no

00:47:02.760 --> 00:47:04.120
I'm not I'm not I'm not trying to say

00:47:04.120 --> 00:47:05.800
there's no risk, but I'm just

00:47:05.800 --> 00:47:07.600
>> you should look at the at the at the web

00:47:07.600 --> 00:47:09.880
report on how much of the web is served

00:47:09.880 --> 00:47:11.360
by Engine-X. I think it's still at like

00:47:11.360 --> 00:47:12.800
50%.

00:47:12.800 --> 00:47:13.760
Well,

00:47:13.760 --> 00:47:15.560
I still find it hard to imagine that you

00:47:15.560 --> 00:47:18.080
can get user access on an Engine-X

00:47:18.080 --> 00:47:21.720
server in a in a modern hosted system. I

00:47:21.720 --> 00:47:24.560
find it extremely hard to imagine, but I

00:47:24.560 --> 00:47:26.680
feel free I feel free to prove me wrong,

00:47:26.680 --> 00:47:30.040
listeners. I just I just hate how like

00:47:30.040 --> 00:47:32.720
every security chat group I'm on like

00:47:32.720 --> 00:47:34.360
hey, look at this copy fail thing.

00:47:34.360 --> 00:47:36.320
Screaming, you know,

00:47:36.320 --> 00:47:39.360
exasperated emojis. I like this is super

00:47:39.360 --> 00:47:40.240
interesting.

00:47:40.240 --> 00:47:43.000
>> dude, it's not going to be we don't

00:47:43.000 --> 00:47:44.640
really need to do that we don't need to

00:47:44.640 --> 00:47:47.600
drop everything and patch this because

00:47:47.600 --> 00:47:50.640
the risk is incredibly low. We don't

00:47:50.640 --> 00:47:53.200
have local users. You're forgetting

00:47:53.200 --> 00:47:55.400
You know the amount of products that I

00:47:55.400 --> 00:47:58.240
built that do not properly validate

00:47:58.240 --> 00:47:59.800
inputs. When you say you don't have

00:47:59.800 --> 00:48:01.920
local users, there's so many other

00:48:01.920 --> 00:48:04.960
things. Sorry, you're using? We use go.

00:48:04.960 --> 00:48:07.240
Okay, let's talk about the 10 stack 10

00:48:07.240 --> 00:48:09.800
stack a hack because it was very

00:48:09.800 --> 00:48:12.280
interesting that it it actually

00:48:12.280 --> 00:48:16.400
showed that um I know I forgot. Cuz I I

00:48:16.400 --> 00:48:18.640
said like one of the one of the things

00:48:18.640 --> 00:48:20.680
that came out of this is basically 10

00:48:20.680 --> 00:48:22.880
stack got published through the trusted

00:48:22.880 --> 00:48:25.560
OIDC and was published as a verified

00:48:25.560 --> 00:48:28.520
package. Meaning the package was built

00:48:28.520 --> 00:48:31.440
on hardware that was running in GitHub

00:48:31.440 --> 00:48:34.120
managed a software and it was signed and

00:48:34.120 --> 00:48:35.680
all of the verifications everything

00:48:35.680 --> 00:48:36.880
passed.

00:48:36.880 --> 00:48:38.960
It was published from official CICD

00:48:38.960 --> 00:48:41.800
pipelines from the project. Yeah, I mean

00:48:41.800 --> 00:48:43.200
package that's signed and has a

00:48:43.200 --> 00:48:44.520
vulnerability doesn't really surprise

00:48:44.520 --> 00:48:45.880
me, but carry on.

00:48:45.880 --> 00:48:47.880
No, but that's one of the more, you

00:48:47.880 --> 00:48:49.600
know, the whole

00:48:49.600 --> 00:48:51.160
security stance of a lot of these

00:48:51.160 --> 00:48:52.720
projects is like you don't use

00:48:52.720 --> 00:48:54.520
long-lived credentials because a lot of

00:48:54.520 --> 00:48:56.920
these attacks lately have been

00:48:56.920 --> 00:48:58.880
secret exfiltration, right? The Tree V

00:48:58.880 --> 00:49:01.800
hack, Aqua security, it was all about

00:49:01.800 --> 00:49:03.560
a package got executed, got access to

00:49:03.560 --> 00:49:05.920
secrets, and we got like tokens to

00:49:05.920 --> 00:49:07.160
publish. And I was like, why do you have

00:49:07.160 --> 00:49:08.440
tokens? Why do you have long-lived

00:49:08.440 --> 00:49:10.480
tokens? You should be using short-lived

00:49:10.480 --> 00:49:12.200
tokens that are only valid for the

00:49:12.200 --> 00:49:13.880
amount of time that you need to publish.

00:49:13.880 --> 00:49:15.840
So, if your whole approach to security

00:49:15.840 --> 00:49:18.320
was to adopt OIDC, that has now been

00:49:18.320 --> 00:49:20.120
subverted. I mean like not subverted,

00:49:20.120 --> 00:49:21.720
you always need to do defense in depth,

00:49:21.720 --> 00:49:23.760
right? So, one of the main things was

00:49:23.760 --> 00:49:25.760
that the 10 stack package was

00:49:25.760 --> 00:49:28.200
through OIDC, short-lived tokens,

00:49:28.200 --> 00:49:30.280
verified builders, signed package,

00:49:30.280 --> 00:49:32.760
published. So, So, that So, they had a

00:49:32.760 --> 00:49:34.960
good posture, but they still still got

00:49:34.960 --> 00:49:36.000
hit or something. Is that what you're

00:49:36.000 --> 00:49:36.320
saying?

00:49:36.320 --> 00:49:38.920
>> Yeah, they got hit because there was a

00:49:38.920 --> 00:49:42.760
way for somebody to do a PR, and so I

00:49:42.760 --> 00:49:44.960
think it's Team PCP, right? The what's

00:49:44.960 --> 00:49:48.360
it called? Hulut? Oh, yeah. Yeah. Mini

00:49:48.360 --> 00:49:51.720
Hulut from Team PCP, they were able to

00:49:51.720 --> 00:49:54.640
shy Hulut and mini shy who loot. So they

00:49:54.640 --> 00:49:58.680
were able to create a PR and the caching

00:49:58.680 --> 00:50:01.320
action of GitHub actions did not

00:50:01.320 --> 00:50:03.400
differentiate the branch that the cash

00:50:03.400 --> 00:50:06.320
came from. So they created another sort

00:50:06.320 --> 00:50:08.240
of get

00:50:08.240 --> 00:50:10.840
hack in a way through the cash thing or

00:50:10.840 --> 00:50:12.320
something. Yeah, and it's funny because

00:50:12.320 --> 00:50:14.440
lately somebody shared an article with

00:50:14.440 --> 00:50:16.720
we was like we are bad citizens if we

00:50:16.720 --> 00:50:18.640
are not using proper caching techniques

00:50:18.640 --> 00:50:20.920
because everyone just assumes that NPM

00:50:20.920 --> 00:50:23.960
GS and Python registries and Maven

00:50:23.960 --> 00:50:25.040
public registry all of this

00:50:25.040 --> 00:50:26.960
infrastructure is available for free,

00:50:26.960 --> 00:50:30.120
but it costs money. And so you are

00:50:30.120 --> 00:50:32.400
consuming a lot of compute whereas you

00:50:32.400 --> 00:50:34.640
should probably use a proper cash and

00:50:34.640 --> 00:50:36.120
don't redownload every package every

00:50:36.120 --> 00:50:37.720
time you need to do a run. And now

00:50:37.720 --> 00:50:40.320
caches are can be dangerous or it can be

00:50:40.320 --> 00:50:41.080
an attack vector.

00:50:41.080 --> 00:50:43.160
>> Well, if you do it again, all of these

00:50:43.160 --> 00:50:46.840
attacks are exploiting some very minor

00:50:46.840 --> 00:50:48.600
oversight in the way that things are set

00:50:48.600 --> 00:50:51.320
up, right? The option is there and you

00:50:51.320 --> 00:50:53.560
can use it, but if you do, there's a

00:50:53.560 --> 00:50:55.400
whole bunch of conditions that you need

00:50:55.400 --> 00:50:57.600
to do to protect yourself. In this case,

00:50:57.600 --> 00:51:00.160
if you're doing this type of caching,

00:51:00.160 --> 00:51:01.840
you need to make sure that the main

00:51:01.840 --> 00:51:04.680
release branch doesn't use the caches

00:51:04.680 --> 00:51:07.160
that are created and and and accessible

00:51:07.160 --> 00:51:09.640
to untrusted code. So they did they did

00:51:09.640 --> 00:51:11.880
a pull request from their code that they

00:51:11.880 --> 00:51:13.960
controlled and they were in the cash

00:51:13.960 --> 00:51:17.000
process part of the PR, it injected a

00:51:17.000 --> 00:51:19.840
poison package inside the cash. And so

00:51:19.840 --> 00:51:22.840
when the main release happened, the cash

00:51:22.840 --> 00:51:24.280
got pulled in and during the node

00:51:24.280 --> 00:51:26.600
install from the cash, node node modules

00:51:26.600 --> 00:51:28.480
installed from the cash, a hook was

00:51:28.480 --> 00:51:30.080
executed I think or something similar.

00:51:30.080 --> 00:51:32.280
I'm not sure exactly how they were able

00:51:32.280 --> 00:51:34.440
to trigger the poisoned package and that

00:51:34.440 --> 00:51:37.160
package then was able to do whatever it

00:51:37.160 --> 00:51:38.160
needed to do

00:51:38.160 --> 00:51:39.520
with full credentials.

00:51:39.520 --> 00:51:41.680
>> that to me, Vincent. Yeah, because

00:51:41.680 --> 00:51:43.760
that's in these cases people are like oh

00:51:43.760 --> 00:51:45.480
somebody of the maintainers had like a

00:51:45.480 --> 00:51:47.240
token or his account was not secure

00:51:47.240 --> 00:51:49.320
because this used to happen, right?

00:51:49.320 --> 00:51:51.400
People got hacked, they took their

00:51:51.400 --> 00:51:53.840
account got taken over or they were like

00:51:53.840 --> 00:51:55.760
how did somebody merge this? Like when

00:51:55.760 --> 00:51:58.800
when they talked about three V action,

00:51:58.800 --> 00:52:00.800
then somebody had approved a pull

00:52:00.800 --> 00:52:03.440
request that was pointing to a a commit

00:52:03.440 --> 00:52:04.880
that it was accessible from a fork

00:52:04.880 --> 00:52:07.640
repository. So so they were like why did

00:52:07.640 --> 00:52:09.440
they not like why did they approve this

00:52:09.440 --> 00:52:11.080
PR? And it's like usually because it's

00:52:11.080 --> 00:52:12.480
hidden between a bunch of other diffs

00:52:12.480 --> 00:52:14.400
and and things like that, right? So all

00:52:14.400 --> 00:52:15.920
of these are very interesting and and

00:52:15.920 --> 00:52:17.680
what they are trying to say is also that

00:52:17.680 --> 00:52:19.880
with these AIs studying these

00:52:19.880 --> 00:52:21.320
repositories and the way they are set

00:52:21.320 --> 00:52:22.560
up, they're finding these

00:52:22.560 --> 00:52:24.240
misconfigurations and these loopholes

00:52:24.240 --> 00:52:26.040
much faster than we have. Like some of

00:52:26.040 --> 00:52:27.440
these problems have been there for 20

00:52:27.440 --> 00:52:29.680
years but nobody saw. And now these AIs

00:52:29.680 --> 00:52:31.200
go through everything and they're like,

00:52:31.200 --> 00:52:33.480
"Hey, the cache is reused across

00:52:33.480 --> 00:52:35.440
branches. Exploit this." So a lot of

00:52:35.440 --> 00:52:37.400
this is now automated being found and

00:52:37.400 --> 00:52:39.360
then it's causing issues over and over

00:52:39.360 --> 00:52:40.600
again.

00:52:40.600 --> 00:52:42.880
Yeah, yeah, this is this is fascinating.

00:52:42.880 --> 00:52:44.600
Okay, but I need to take my kids to

00:52:44.600 --> 00:52:46.600
school. Thanks for your patience.

00:52:46.600 --> 00:52:48.600
>> There was one more thing about using

00:52:48.600 --> 00:52:51.160
package age. The package age like you

00:52:51.160 --> 00:52:53.320
said like if you use PNPM and you make

00:52:53.320 --> 00:52:54.800
sure that the package is over a certain

00:52:54.800 --> 00:52:57.440
amount of age should be sufficient to

00:52:57.440 --> 00:53:00.200
protect yourself. I got schooled on that

00:53:00.200 --> 00:53:01.920
two days ago but now I forgot. He says

00:53:01.920 --> 00:53:04.240
like I need to Wait, I I think I made a

00:53:04.240 --> 00:53:06.240
note. I tried to be really fast here. I

00:53:06.240 --> 00:53:08.120
hope I wrote it down. Well, or maybe

00:53:08.120 --> 00:53:10.800
we'll put it in the show notes in in the

00:53:10.800 --> 00:53:13.240
in the description how you got schooled

00:53:13.240 --> 00:53:15.560
with PNPM. You can't just rely on PNPM.

00:53:15.560 --> 00:53:17.880
Man, yeah. Well, I'm I'm I'm going to

00:53:17.880 --> 00:53:19.480
I'm actually looking forward to doing

00:53:19.480 --> 00:53:22.960
more security-related stuff. So I'm let

00:53:22.960 --> 00:53:23.560
I remember.

00:53:23.560 --> 00:53:25.600
>> I'm going to learn more. I saw the note.

00:53:25.600 --> 00:53:28.520
He said that if you set up your project

00:53:28.520 --> 00:53:30.040
to automatically update your

00:53:30.040 --> 00:53:33.080
dependencies even if you make those auto

00:53:33.080 --> 00:53:35.120
update flows make sure that they don't

00:53:35.120 --> 00:53:36.720
update until the package has more than a

00:53:36.720 --> 00:53:38.280
few days on the registry because then

00:53:38.280 --> 00:53:40.360
you hope it will have been detected, you

00:53:40.360 --> 00:53:43.520
will still be hacked. And the right way

00:53:43.520 --> 00:53:46.760
to do it is to use a GitHub secret a

00:53:46.760 --> 00:53:49.360
GitHub Dependabot feature, which through

00:53:49.360 --> 00:53:52.520
secret through security. So, Dependabot

00:53:52.520 --> 00:53:54.520
does a security scan on the packages.

00:53:54.520 --> 00:53:57.000
And then it will only say, "Hey, this

00:53:57.000 --> 00:53:58.680
package this dependency has a

00:53:58.680 --> 00:54:00.800
vulnerability." And only update those

00:54:00.800 --> 00:54:02.920
packages, not everything. So, a lot of

00:54:02.920 --> 00:54:04.840
these upgrade flows, they will just look

00:54:04.840 --> 00:54:07.160
is there a new package? Okay, upgrade.

00:54:07.160 --> 00:54:09.080
And then is an upgrade and all the tests

00:54:09.080 --> 00:54:11.400
pass? Okay, auto approve and merge. So,

00:54:11.400 --> 00:54:13.520
always our project is upgrading, always

00:54:13.520 --> 00:54:15.840
up to date. Your previous approach was

00:54:15.840 --> 00:54:17.240
missing that security scan which

00:54:17.240 --> 00:54:19.560
Dependabot gives you. Yeah, he's saying

00:54:19.560 --> 00:54:22.280
is is like never do that. Only upgrade

00:54:22.280 --> 00:54:24.480
if there's a CVE in a dependency and

00:54:24.480 --> 00:54:27.360
only or if you have really there's a a

00:54:27.360 --> 00:54:28.720
minor version patch that you need

00:54:28.720 --> 00:54:30.880
because of a new feature, right? So, use

00:54:30.880 --> 00:54:32.880
Dependabot, it will identify any

00:54:32.880 --> 00:54:34.840
dependencies that have a

00:54:34.840 --> 00:54:37.000
security vulnerability and it will

00:54:37.000 --> 00:54:39.400
update those. I've never heard someone

00:54:39.400 --> 00:54:41.240
advocating for Dependabot. Like usually

00:54:41.240 --> 00:54:43.440
everyone says use Renovate, use more

00:54:43.440 --> 00:54:46.040
advanced, you know, PNPM Because we're

00:54:46.040 --> 00:54:48.000
on a public repo and it's for free. So,

00:54:48.000 --> 00:54:49.720
he says, you know, you can get you get

00:54:49.720 --> 00:54:52.480
it for free. So, and it's like easy to

00:54:52.480 --> 00:54:52.880
set up.

00:54:52.880 --> 00:54:56.040
>> that that comes out of the box with uh

00:54:56.040 --> 00:54:57.320
with Dependabot or do you have to is

00:54:57.320 --> 00:54:59.320
that a feature that you need to enable?

00:54:59.320 --> 00:55:00.680
I think it's a feature. So, I did it's

00:55:00.680 --> 00:55:02.400
something he told me like we have a lot

00:55:02.400 --> 00:55:04.800
of those auto upgrade flows. Link to

00:55:04.800 --> 00:55:06.400
I need to run although my kids will be

00:55:06.400 --> 00:55:07.960
late. Thanks again, Vincent. We

00:55:07.960 --> 00:55:09.360
appreciate it. Boy,

00:55:09.360 --> 00:55:12.960
>> Okay. uh Bye-bye.