Episode 27: Distracted by AI

Published: Tuesday, Apr 7, 2026 • Duration: 70 minutes • Season 1

Distracted by AI

Download MP3 | Watch on YouTube

Show notes: https://docs.google.com/document/d/1zoc-0L1o1Cyxtgatb9fN_ZGBGbshZIb9BTzwEj0C4Gc/edit?usp=sharing

Watch on YouTube

summarize "https://youtu.be/oyGi8ahf4Og" --timestamps --slides

This episode (27) is a long, wide-ranging conversation between two engineers about practical pain points as AI tools get folded into docs, development workflows and platform ops. Main threads: converting Confluence to Markdown then letting AI rewrite huge doc sets (500 pages) created disagreement over the source of truth; agents vs persistent docs and the idea of ephemeral AI views; tools and patterns for agent orchestration and spec-driven development; platform-operational stories (data teams, Airflow on Kubernetes, Terraform tooling and testing); and an extended discussion of software supply-chain hardening (OIDC publishing, gating packages by age, CI security checks). The hosts trade concrete examples, versions and configs (for example a 4‑day / 5760‑minute package-age gate) and surface practical tradeoffs rather than evangelism. we couldn’t decide what the source of truth was this world is probably going to look pretty different in 2026 Slide 1

Converting docs exposed a new governance problem

They moved 500 pages from Confluence into Markdown to make docs agent-readable, then used AI to rewrite whole swathes; the rewrite quality was good but the team couldn’t sign off because the scale (hundreds of files) made review infeasible, so the project lost consensus about the canonical source. The hosts stress a core rule: keep a single source of truth and avoid many persistent derivative views; when AI generates fixes you must break changes into reviewable, small PRs and distribute review work so humans can approve incrementally. Slide 2

Agents for discovery, but humans still uneasy

Making docs queryable by agents seemed like the intended flow—ask an agent for ephemeral answers rather than maintain many rewritten views—but not everyone is comfortable trusting ephemeral agent outputs because of hallucination risk and review norms. The concrete governance suggestions: keep core docs authoritative; use agents to discover and create ephemeral views; if a derivative view must persist, make it a reviewed, human‑signed artifact; and break AI edits into small, reviewable commits so the whole team can approve changes. Slide 3

Agent tooling and spec‑driven development are exploding

They compare frameworks that keep agents running until tasks complete (spec‑driven kits) versus interactive, chat‑until‑done styles. One tool keeps an agent looping until spec completion, another uses adversarial agents (spawn reviewers that challenge outputs). Early adopters can move faster—one friend reached advanced agent orchestration in a week or two—while long‑time users risk being stuck in legacy habits. A concrete example: a junior engineer used an AI tool to find a memory leak in ~5 minutes where a seasoned engineer would have gone through traditional heat‑map workflows. Slide 4

Platform work: data teams, Airflow and production friction

A former data‑platform engineer describes handoffs where data engineers prototype in notebooks and platform engineers productionize poorly tested work thrown over the wall, creating heavy support load and stress. Airflow is discussed as a tricky shared infra piece: earlier patterns mounted huge DAG volumes and ran monolithic runners; by 2020 native Kubernetes job runners and per‑job secrets injection made deployments far smoother. The upshot: platforms must become much easier—possibly “AI‑easy”—because expecting product teams to read docs, create repos and run workflows is a big barrier. Slide 5

Infra tooling tradeoffs: Terraform, CDK, testing and local emulators

They debate Terraform’s limits (no automatic rollback, heavy module complexity) versus CDK’s higher‑level abstractions and shift‑left benefits. Testing stacks: use Terraform’s built‑in test command for fast in‑memory checks, and use teratest when you must provision and assert runtime contracts (AMI builds, network or NAT instance permutations). Local emulators (localstack alternatives) are useful for quick serverless work and take‑home coding tests, but licensing and CI restrictions can change the calculus. The hosts also discuss porting CDK L2 coverage to non‑native backends so you can use higher‑level patterns without the original service runtime. Slide 6

Supply‑chain hardening: OIDC, package age, CI gates and noisy scanners

Recent supply‑chain compromises drove practical mitigations: publish with OIDC short‑lived credentials to avoid long‑lived publisher keys, and gate dependency updates by age (example: require a package to be on the registry for 4 days = 5760 minutes before accepting it) so immediately pushed malicious patches get a window for detection and takedown. Also, gate automerge with CI security scans (npm audit or equivalent) rather than relying on unit tests alone. They warn about noisy scanners and config overload but point to concrete CI rules: run an audit-level scan and only auto‑merge when security jobs pass, use minimum‑release‑age tooling in dependency bots, and prefer package managers with good audit support; one practical config discussed was setting a minimum release age flag to four days and running an audit step before auto‑merge.

Model: openai/gpt-5-mini

Transcript (auto-generated from YouTube captions)
Well, this is episode 27 of the AI
infrastructure podcast.
This is an intro coming from Cornwall, a
windy one.
And today I'm driving to London, to the
big city
for the AI engineer conference. So, if
you're there Wednesday, Thursday, Friday
in London,
do say hello.
Otherwise, I will be
uh reporting back from that event. I'm
sure it will be very interesting to meet
lots of
AI enthusiasts.
And um
enjoy the pod. I think
it was a bit of a
weird one where
I was talking about the documentation
problem again
that AI
presents.
And uh we were just rambling about other
things. So, hopefully enjoy it.
Um
if you didn't, comment below. If you
did,
like it and comment below.
Otherwise, please enjoy the pod.
Good morning, Vincent. Good morning.
And it's Good Friday. That's nice.
I didn't
>> You're on holi- You're on holiday? No.
No, I have to do some work. But it's
okay, I have to catch up on some work.
It's pretty interesting work, actually.
Okay. So, I I'm just editing the uh doc
that we share. I was adding some uh
things to talk about. Oh, let me just I
guess this will be edited out.
Uh so, perhaps I I
could we could start with a quick fire
questions for you.
I'm going to probe the depths of your
mind. Yeah. Um okay, the the
the first couple of bits are related to
work and which I might have uh delete,
but uh whatever. Uh sorry, um
Claude Code is blocked. I need to be
unblocked as soon as possible.
Sorry. Cloud com- Claude Code comes
first.
>> Just it asked me something. For local
compose test, so we should keep the test
for a secret command
being available, I believe.
Okay. Um yeah, sorry. Go ahead. We
talked about docs uh
last pod and you recommended keeping
documentation in the source code.
And you showcased some pretty cool
abilities. I just wanted to say that
like at work, we did manage to convert
all our Confluence to markdown, which
was great. But then, once it was in
markdown,
uh it was too tempting to to to to use
AI to basically improve the docs. And
then, of course,
Uh pardon?
And last time you mentioned that Yeah,
and then people created different copies
with different type of angles, right?
And Yeah, I wouldn't say co- We didn't
go down the route of copies, but we got
we got into almost
a worse situation in a way. Perhaps it
is the same as copies, but but since it
was rewritten, we couldn't decide what
the source of truth was because people
were were saying like, "Well, no one's
actually gone through all these 500 uh
files of rewritten documentation. So, we
can't like sign it off cuz it's just too
big of of a rewrite. Essentially, we
couldn't decide we couldn't like we
couldn't call it a a success because
because
so, I guess it maybe is a is a story to
to
to say around AI where maybe we should
just go slower or something like that
just to get the buy-in. But at the same
time, it's just so easy to to tell AI
uh rewrite all the docs in different
ways. And it works for one person, but
it doesn't work for a team is what I was
trying to say. Well, okay. Maybe you
don't have anything to say to that, but
I just wanted to
Why didn't it work for for for a team?
Because the team
the the Confluence or the documentation
that we have was was pretty extensive.
There's like 500 pages. Yeah. And no one
was going to
Most of the team were were not prepared
to like go through the documentation
and
and basically, you know, approve it.
They just did they felt uneasy. Approve
it because the changes were too too much
like it needed additional review and
approval of like the changes that were
introduced. Yeah, but
when you're in a big team like
effectively, the whole team had to get
behind the documentation cuz the
documentation sort of describes how to
use the platform, how to do this and
that and the other across all different
sort of aspects across a very large
landscape. So,
so basically, it wasn't because one
person needed to make a decision. It it
was like the whole team really needed to
get behind the rewrite and it was just
impossible.
>> Okay. No, because like there's this
couple of
interesting sharings that I read just
today one and then there's another one
that um I don't forgot forget the
context. Um but you mentioned something
about if you create like docs
all over your repo in markdown, they
become maybe harder to discover than
Confluence
if you just use Git as a as a as a
storage mechanism, which is something I
always say, right? You should have your
docs in Git. But also, people are saying
you need to have your docs available to
the agent because ultimately, the agents
are going through these faster than
humans.
>> Yeah,
I mean, step one was that we we did
manage to get our docs into markdown
um
available to the agent. But then,
that that was that was all done, you
know, that was done. But the second step
is like the
um the the generated docs,
we we just couldn't agree on it cuz
cuz
like what
um
Okay.
Let let me just flesh this out. You
know, like one way is that you could you
could like if you want uh to find info,
you could you could always ask uh the
the AI agent. Right. So, the core source
of truth should always remain, right?
There should not be like derivative
docs.
>> Yeah, but the trouble the trouble is the
docs they are quite expen- they're quite
extensive. There's 500 pages and there
are actually like mistakes in them. But
okay, that aside, the trouble with that
approach is that like um
not everyone is prepared
uh
is is is prepared to to read docs that
way. Okay, so what you're saying is you
moved them out of Confluence into
markdown, so they became available to
agents. You then had one approach of
asking agents to generate different
derivative docs, but that's not good. We
discussed it and you said we should keep
a single source of core docs. And then
you discover docs by asking agent. You
find the information by asking agent,
but not everyone agreed to that. Yeah.
And then with with the core docs, the
you know, huge temptation to let AI, you
know, fix things. And then um which you
did actually in and I I think it did a
sterling job. I couldn't actually find
any major issues. But then then the
issue is that not not everyone in the
team wanted to approve it. wanted to
approve it because it basically
uh
since
it touches like 500 files.
Yeah, but
>> That that sounds like Okay, because when
you said that earlier, it felt to me if
you're moving out of Confluence and
you're moving it under version control,
the migration should be a one-to-one.
There can be no argument about this is
not the same. It's exactly the same. And
then you need to decouple. And if you
say we're going to let AI fix things,
and if if there is this hard requirement
within the organization that any change
to these docs now needs to be approved,
um you have to be um and reviewed, you
have to break it down in in in
reviewable chunks, right? So, if you let
the agent makes the fixes, then you have
to ensure that the fixes remain um you
know, small PRs that are reviewable so
that you can get buy-in and maybe
distribute the review work across
different people
uh in a way. I I I'm just thinking. I
mean, I constantly have this problem
with AI that I keep blowing up the scope
and pulling in more changes. And it's
very hard to just say no. I mean, if
you're talking about code, we've come to
the conclusion that a lot of people say
we don't look at the code, right? Even
um Adam Jacob's talk at the config man
configuration camp Yeah. Yeah, I can't
believe you just watched that one. I I'm
sure I shared it with you 3 months ago.
>> went an hour When I watched it, it was
an hour on YouTube. So, Yeah, I I
included a timestamp.
No, it was an hour ago posted on YouTube
when I watched it. Was it on YouTube?
Yeah, it was. I don't know. I didn't
because when I watched it yesterday, I
can I should go check. I thought it was
not on YouTube before. Anyway, it
doesn't matter when or what I watched
it. Yeah, I Adam Adam's I love his
talks. Well, it's a very good opening
talk uh to to ex-
to um
convince people, to give people a
summary of where the world's been
headed. And it sounds like he's
basically spending 35 minutes convincing
the room that yes, AI is coming. Yes,
it's bigger than you think. And yes,
it's changing everything and the way you
think. But here are the things that I
learned the last 3 months using it. And
and it's great for that. But even though
it was recorded in January, so when you
watch it today, it's already outdated.
Um he draws
>> How?
he draws the boxes of what has
completely been dominated by AI agent.
And he shows like the human is in in
response for design. The human is
responsible for plan. And then the
agents are is responsible for
implementation, validate, testing, and
deployment, or whatever. I don't
remember the exact boxes, right? And I
just thought when I saw those boxes that
I haven't really me personally reviewed
a plan generated by an agent. I just ask
another agent like adversarial review
agent. So, you just give another agent
complete blank context. That that do the
cross reference.
And I posted it as a comment and he
agreed with me. He said like, "Yeah,
that's already a case for for for his
experience as well. They are not
reviewing the plans anymore. They're
doing adversarial agent reviews." And so
now we are just part of the design.
Yeah, adver- sorry. Adversarial, sorry.
Adversarial, I keep saying it wrong.
>> Adversarial What's the the whole phrase,
sorry? Adversarial agents or agent
reviews.
Here they talk about networks, but it's
it's definitely a
a hot keyword right now in in the AI
bubble. Yeah, I'm not I'm not 100% sure
I can get agree and get behind this yet
because I haven't managed to
uh
Like for example, I don't know if you
shared it with me um or I shared it with
you or I just found it by myself.
um
Oh, there's this thing called cook
and it it essentially makes it easy to
um
I can't find it now. It makes it easy to
to do this adversarial thing in the
sense that like spawn an agent that
reviews the other agent. And I used it
and I thought to myself that I wasn't
convinced because it it made the
solution more complicated if anything.
It It just It just
It didn't get to the
to the
to the solution that I wanted, but that
was just one anecdotal data point,
right? So, anyway, we were talking about
adversarial agents, why? Because things
are outdated, but okay, you're talking
about Adam Jackson's talk. Yeah, I was
also just wondering a minute ago how did
we get there, but because you were
talking about docs and breaking down
chunks into smaller reviews and I was
saying that that's one of the biggest
issues I have with scoping down the
amount of work that the agent submits
because because I then trailed off in
the thought that we all agree that we're
no longer reviewing the the implemented
like the code, but we we now supposedly
only review the plans generated by the
agent and I'm just saying we don't even
review that anymore.
Um so so basically, I think we got there
because we were talking about what needs
to be reviewed by humans, right? So, so
if you need to produce something with AI
that needs to be reviewed by humans, you
have to resist the temptation to let it
become a massive amount so that they
will have a you know, rejection because
it's too much. They have no time to
review it. Basically, that's the point I
was making.
>> Yeah, and
and to me that's like a trap. And to be
honest, I think we even went down that
way at work for this documentation. And
we were just saying like, "Hey, we got
this view. We got this view. We got this
view." You don't need to It's It's too
much to
>> Why are you talking about this view and
this view? Are you creating from the
same core docs different views? Because
we already agreed don't do that. Okay,
well, I'm just I'm using it as a as a as
a terrible example of like like I got to
a stage where you where where where we
wanted to say don't review and then and
then then we have a right mess,
basically. Okay, so it sounds like
because this is discussion we had last
time and I'm not sure if we still want
to go deep into this topic right now,
but we agreed that at the time that
there are a certain source truth core
documents that are the single source of
truth and then you said we we said we
should use agents to query the docs and
find and just basically create like
ephemeral views
that that gets caught thrown away and
then you said some people are not
confident because I can I can I can see
that, you know, why would you not assume
the agent is hallucinating in one of
those ephemeral views, right? Unless you
generate a more like
persistent view that is actually
reviewed by a human to confirm that it
is not any hallucination in there. And
then you would start creating
um other views that are persistent, but
it's not good. So, it's really um
Okay, make conundrum. Yeah, it is quite
a conundrum. uh And yes, the talk was
posted on YouTube a month ago. I just
checked. So, my mistake, not an hour.
And
here's the what I was trying to talk
about earlier. Here's this CLI that I
was using.
So,
when when you first set it up, you
basically say which which
which models you want to use like Claude
and Codex. I mean, all you know, OpenAI
and Claude. And then and then you ask it
something and then it has these little
like
uh tags or I don't know what you call
these little arguments where you can
basically instruct the three parts other
agent how to review the code or
or you know, go three times
or how to
what what the evaluator function is or
something.
I and I used it and it
works beautifully. But my friend's
observation was a lot of all of a lot of
these frameworks and he he started using
get done, GSD.
And he says it's very funny because it's
literally just a whole bunch of markdown
prompting and
thin little layer of JavaScript. Yeah,
and and a little loop you know, like
>> And a lot of the these things are like
that. Yeah, exactly. Exactly. I mean,
And he says like, "What are we doing?
Like what's the value add here?"
>> yeah, and mine
I mean, I love it in the sense that like
it's beautiful to see these agents
working in in concert.
>> Mhm. But the results
were not good, but maybe I need to give
it a a better try. And another
you know, feedback I I got because um my
friend
has been mostly using cursor or a little
bit of agentic in cursor and he's been
happy with it. And I've been asking him
like, "Hey, you know,
I'll use spec ledger with you and then
you'll get to experience what is spec
driven development and I will deliver
some feature that whatever you want gets
implemented." I told him. And he he
wanted to drive, so I said, "If you want
to drive, then you should have." And he
says, "But I want to use chat GPT
models. I'm not going to pay for
Anthropic. I have already chat GPT." And
I said, "Okay, then you should use open
code." "Why not Codex?" He says, "I am
not I don't support
Codex CLI. I only support open code
because it's more similar to Anthropic
Claude Code in terms of they are trying
to match the tool usage and stuff in the
agent realm.
>> Okay, okay. So so he then decided,
"Okay, forget it. I'll just use cloud
code then." And he's been using cloud
code for a week now with spec driven
development and he I think maybe he
might have used another one, but he was
frustrated, so he started using get
done. And he said like within 1 week 2
weeks, he was like, "This is amazing.
Like why didn't I do that before?" And
then he's he's already like running
agent he's using get work trees and sub
agents. And he also subscribed to the
Claude Code next plan and um So, he's
been red pilled.
Like and he's asking me now how do you
use like sub agents and work trees and
agent teams and review agents and I'm
like, "I'm not there."
>> [laughter]
>> I'm like heads deep in just the spec
driven development side of things. I
haven't really like I I have on purpose
avoided going into this whole agent team
orchestration because I believe that
there's so many people doing it that
soon enough it will be like, you know,
perfect and I just need to wait a
little.
Yeah, so get so get done is is like
that cook I was just sharing, right? Is
it like that? I mean, He says it's a
spec driven development toolkit that
that is more like proactively keeps the
agent running until the things are
completed. Cuz a lot of the like spec
driven development frameworks, they
aren't really like keeping the agents in
loop until it's done.
Uh and apparently get get done does
that more. Like you see, I've done spec
kit open spec, but get done is
actually delivering the results. I find
that a little bit difficult. I'm
definitely a a Peter Steinberger kind of
guy. I just chat with the with the AI
until it's done. This one seems to I
wouldn't refer to myself as Peter
Steinberger if I don't run if I don't
have five
you know, open code accounts and I'm
running you know, 20 terminals at the
same time. I wouldn't do you know,
because this guy is on another level.
Yeah, he he's obviously very good at
context switching. I mean, I I like to
think I'm pretty good at context
switching.
Like I can I can you know, spin three
plates, maybe not five or 10. Mhm. Um
well, I don't know what to say to this,
but
I guess I just need to give it a try.
But it doesn't seem quite the same as as
though that cook thing, but maybe maybe
it's worth looking. I mean, there's
I mean, this is the crazy thing why we
we need to talk every week because
there's a
bazillion projects, aren't there? Yeah,
it's moving really fast and and also
what I took away from my my friend's
experience is that even if you haven't
looked at this, it takes maybe a week or
two and you can be at the front, you
know, trying to use the latest of the
latest.
>> Yeah. And maybe it's a good thing
because if you've been using it for 8
months, you're like stuck in your old
behaviors and the models have moved on.
And if you come in a fresh, you're like
no idea where to start, but this is
looks like what what people are doing,
so I'm going to start doing this.
element of beginner's luck. It's not
like beginner Yeah, well, it's it's just
being able to shed your your legacy or
tribal knowledge and being able to cuz
even Boris Chef Ni, he says that he's
stuck in a lot of old ways when he's
doing troubleshooting. He always gives
this example where he says there was
this memory leak and and he he has to
avoid going into his habit of going
going into an heat map to identify the
memory leak and then somebody younger
who joined the team and has really
adopted Claude Code, you know, just went,
"Hey, you know, I just asked Claude and
within 5 minutes it found the memory
leak. Whereas you started going into
your heat map and you know, 20 minutes
later you still nowhere and Cloud
already fixed it. So it's it's really
part of and then Boris says it, it's
part of the models are so good. I
constantly have to remind myself to like
cut those old habits and just ask the
model.
Yeah. Speaking of Claude Code, I I think
I don't know if this is real but I did
see some comment that someone analyzed
the the source code drop and there was
some talk that there's a way more
powerful model in the in the works but I
guess that's always going to be true
really. But like I don't have my faults
or Metas.
Yeah, when the new model drops how is it
going to change things? I saw a
screenshot on Reddit which could be
completely fake but like the
improvements compared to Opus were
significant. I mean the way it was
discovered when I I heard about it
before the drop was because Anthropic
apparently left information in a public
database. It wasn't like a meta dot dot
dot database. It left some information
about this Metos project or Capybara or
something like that.
And and that's how I heard it was uh
But it says quite a lot of like first of
Anthropic like up time being such a
horrible
I heard a lot of people moved away from
Anthropic because they are not able to
deliver their reliability. Yeah. Yeah.
They had a huge
They had this huge
issue with
token caching so your usage would
drop significantly like people would
send one or two messages and they would
hit their 5-hour budget because um
there was a bug in the way that the two
the cache was working and it was also
happening when you restarted Cloud. So
people were like finding the bugs and
even when the short source code leaked
people started to debug those bugs.
There's a memory leak I'm going So not a
memory leak. It was two significant bugs
that the community highlighted and and
that they had to fix. So they have been
having a very hard time. Then all of
this like internal information leaking
about models being underway. So people
are like right now on Reddit it's very
annoying because every day there's three
or four posts of people saying you know
First of all weeks they complain about
the the token usage budgets depleting
too fast and now Anthropic has released
.90 and .91 fixing some of these issues
and now people are posting yeah that's
not fixed until you refund you need to
refund because we couldn't use it.
You're all in on Anthropic right still
with your max plan? I don't want to
support Open AI. I like to think I'm
being a bit balanced like I've been
moving between Open AI and Anthropic. I
still have ChatGPT. I canceled it they
give me one month free but I haven't
recanceled it. So you need to cancel it
then they give you one month free then
you if you Yeah, yeah. You need to
cancel it for real after one month and I
haven't canceled it because my wife
really likes using ChatGPT. Mhm. The I
think the voice mode is also Much better
than
Yeah. Um phone app. Okay, let's change
topic ever so slightly. I wanted to
ask you quickly if you've ever worked on
a data platform. I worked for some
engineering
I mean I
I think it's
>> Enough time has passed and I can talk
about my Gojek experience. Mhm.
I I worked briefly at Gojek and uh
it didn't work out to be honest at the
end of the day. Not going to lie. But
the
but when I when I worked there
uh
as a data plat I was a data platform
engineer. It was interesting um in the
sense I I don't know if you've ever seen
this sort of model like this. We we had
data engineers and about 5 or 6 7 years
ago data engineers was like like for
some reason like really popular. I'm in
fact I think you you still see it today
like you do these like boot camps and
then people learn how to become a data
engineer.
You know what I mean? Like it seems to
be a role unto itself.
Oh oh I can see you're distracted by the
Claude Code.
Now what what what would happen is that
the the data engineers would get some
data or get some task to to wield some
data. They would jump in the then
Jupiter notebooks and then they would
come up with a POC about how the data is
going to look or how it's going to be
end up or something like this.
And then and then that becomes a data
product. But the trouble is is that they
since the the these data engineers were
kind of like fresh grads mostly or they
were just not really uh I don't know
what the reason was exactly. Well they
they lack some skills to productionize
it. So so they they would hand over
their work essentially to data platform
engineers and then we would
productionize it. Have you ever seen
something like this before Vincent? I
mean I've never really worked inside of
data team. I have supported a data team
as a platform team um
for one of the data teams I worked with
I was managing their Airflow deployments
and also helping
them define how they would get secrets
to the jobs in Airflow and also That's
typical. It has secrets to I mean since
since Airflow is like a shared thing
I the Cloud Composer I think is is
basically Airflow. All right. Yeah,
essentially Airflow is quite an
infrastructure challenge because it's I
think it's got some horrible assumptions
that everything is run on a shared
instance and then of course when you
have lots of data products. Uh I was
running
So at Honestbee back in 2016 they were
using Airflow and the
or they adopted Airflow at least around
2017
and
they hired someone an ex-DevOps engineer
who wanted to go into data and he joined
the data team and they only give him one
job which was to deploy Airflow. So he
was pretty pissed.
But but he was used to run Mesosphere.
So he was running they I was running
Kubernetes for the the the product
which were like several big Ruby on
Rails applications and they approached
the the platform team for uh you some
type of job running framework and at the
time 2017 the job API like the resources
of for running jobs in Kubernetes were
like alpha or beta they were very
unstable. So I said yeah we can do jobs
but
and so they decided okay I'm just going
to go with what I know and rather than
to talk to us they just deployed
Mesosphere. I was like what you know why
you deploying a competing like another
container orchestration system. Anyway
they ended up with having this huge
Mesosphere cluster
that was mounting the file system.
>> to Airflow right to jobs? Yeah because
of Airflow. They was just because they
didn't run anything because they were
using That's that's a typical problem
like everyone is on the shared Airflow
instance and then they go like oh we
have secrets we have things data we need
to containerize it and then they come up
with some hodgepodge containerization
solution.
>> because I managed Airflow at another
company like four years later and it was
completely different. None of that what
we just mentioned. In Honestbee we had
what the problem that you just
mentioned. They had they basically
containerized Airflow by creating a
massive image and then mounting a file
system into it with all of the DAGs. So
the whole all of the DAGs was just one
massive volume. So the image was just
something like a shell Yeah. I don't
think that's that's a that's a good
idea. That's like containerizing
Kubernetes. And the only reason I know
is because and everything. The Yeah yeah
they they basically run Airflow which I
also thought like why do you need to run
a job runner on top of a job runner?
Like why do you need Mesosphere to run
Airflow? Okay, okay. Okay. So when I
inherited it but then I can tell you one
thing okay doesn't have to be that way
with Airflow because I deployed Airflow
in 2020 which was like
four years later and and at that time
Airflow had a native Kubernetes job
runner and it has a native Kubernetes
orchestrator. Cuz originally Airflow was
like using Redis to distribute jobs to
runners but with with
with the Kubernetes integration it was
using Kubernetes as a job runner
interface and it would talk to the
Kubernetes API to spin up a pod which
was like an Airflow worker node and then
you it would get the the DAGs
from I think we put them on S3. Yeah I
don't remember how we delivered the
DAGs.
But it was definitely not like a huge
massive like file system. So then
actually it was really manageable. It
was really very smooth and the secrets
was easy because we were using like um
secrets directly for jobs and they were
just getting injected when they needed
it. Not shared nothing like that. And
that was in 2020 so Okay. So
so sorry I I I was a little bit
distracted. So how did what was the
solution ended ended up being again?
Airflow supports Kubernetes as a as a
job Really? All right okay that's
interesting.
It has for a long time.
I actually need to investigate that. We
were just
like back then we're using the the
managed GCP version and then recently
I've been
running the AWS managed version called
managed workflow I don't know MWAA. But
it it's
Okay, that's something to look up. I
mean what what I wanted to sort of
perhaps tell you was perhaps
um not nothing AI related it's more to
do with organization. I mean as much as
I didn't I actually didn't really like
this model at all because the data in
there was so there was a lot of data
engineers and and the data platform
engineers which I was a part of we were
really like overloaded with work because
unfortunately we needed to know what
they were doing because sometimes they
would just throw over the wall
um some some code that just basically
didn't even work and we would have to
like fix it and own it from end to end.
So we were like basically working on new
products all the time and as well as
supporting old products. It was quite
stressful.
Yeah.
But nowadays I think I think back to
those five years ago and I think to
myself like a lot of the work that we
were doing wasn't so
like inventive. You know what I mean?
Like we we didn't come up with the the
products themselves. They That was kind
of part of the day data engineers
things. But we were part of like
productionizing it. And now with AI,
productionizing probably becomes
easier?
Debatable. I mean, I don't think AI's
super proven to ship, that isn't it? And
productionizing is about shipping. But I
still I still maintain that this world
is probably going to look pretty
different in 2026. That's for sure.
Um
And then And then also I just wanted to
contrast that with what I saw what I saw
kind of recently on a on a gig where
basically um
Yeah, basically people are expected to
to know a lot more to do the job.
Like it we created, you know, a proper
platform where they where they had you
know, had to create a Git repo and all
that sort of stuff. And to be honest, I
I think it was just too difficult for
for for people to do it that way. I
don't know if you've ever created a a
platform where
you know, there's a config YAML and
you know, product teams are are expected
to to deploy their own app.
I I think to I think to myself that
that's just too hard. It's too hard. You
They've got to like It's got to be a lot
easier for different in a big
enterprise. It's got to become really
really like AI easy for people to create
software or a solution for for their
particular problem. Can't expect people
to like read docs, set up GitHub repos,
run workflows. It's just too hard.
That's That's all I wanted to share. I
definitely have problems where the
platforms I create around Terraform
are for some people
too
um let's say niche. Yeah, yeah. That's a
typical one cuz like like we find
Terraform easy.
But I know I know like as soon as you
you tell
a data um a product team like, "Oh, you
have to deploy Terraform." Then mind
just explodes. Yeah, but the problem
with Terraform is that it's not a very
good product.
Like it has the Go lang mentality of
it's better to rewrite something or
duplicate it than to create coupling,
right? Um what we are doing often with
Terraform is we are creating
abstractions that then create coupling
between different parts because we're
trying to reduce the the boilerplate and
the repetitive repetitive
repetition. So this is kind of like
where it starts to then become
complicated for people because we create
these meta layers around Terraform. Mhm.
So Terraform in itself can be bad.
And modules Modules in Terraform also
just flummox people then they like don't
know what's going on inside them.
Terragrunt reached V1, by the way. What?
Thinking about layers that complicate
Terraform, Terragrunt was released
with an official V1 like stable thing.
>> But Terragrunt has been around for a
long time. Yeah, but they never did a
stable release. So they finally released
Terragrunt V1 and they included stacks,
um which But they've been working on
stacks. Well, I used But this isn't exa-
exactly an example of where Terraform is
meant to be simple and then it becomes
too unmanageable because of the amount
of config files and repetition that you
get. And then people build layers around
it like Terragrunt and it's a prime
example of creating complete like super
hard things to understand because of the
complexity it it allows you to do.
I don't know, they probably improved a
lot of it,
um but I used Terragrunt in in one
organization which was rather large. And
I feel it was very successful in the way
that it managed our infrastructure as
code, but I also feel it was a massive
blocker for anyone that wasn't platform
to then contribute to that
infrastructure as code. Yeah, I guess
that's a good example. And the same with
Terra mate and all the others. Anything
that's a Go lang CLI around Terraform is
like that. Yeah. And do you think I
mean, compared to CDK? Uh good.
Um because CDK gets rid of the Terraform
modules, which to me I think is the
biggest problem. Most of these
orchestration system try to work with
Terraform modules. But Terraform CDK or
AWS CDK completely gets rid of it by
creating a higher level abstraction
because it has it is not just like
a scripting library, something that can
do simple loops or things like that.
It's an actual complete programming
language language and it allows you to
create object-oriented things such as
extending an a base class, implementing
interfaces, it's allowing you to do
dependency injection by just making sure
that the constructor takes in the
something that implements the interface.
So you get a lot more capabilities than
what you can do with Terraform modules.
So we're there CDK is not stuck in this
like I just have to script around the
whole bunch of stupid Terraform
>> converted. I'm converted.
We talked about this. We talked
I think one
Terragrunt was comes in view because of
TerraTest. Do you have you ever used
TerraTest? I am a heavy user of
TerraTest. Really? Yeah. I just today
was walking through
We're having AMIs built. So I used
TerraTest mainly for I think TerraTest
is amazing. If you have home-cooked AMIs
that come with a
pairing paired module. Like for example,
you know that there's this thing called
FCK net, which is like a feasible cost
um
net gate like net instance. So instead
of running Let me Google this. FCK what?
>> net NAT,
network address translation. It's like a
10% cost of an AWS NAT gateways.
>> Oh, so it's just like a a NAT gateway
replacement.
>> AWS VPCs support NAT instances. So you
can set up your routing tables to route
all the traffic through one EC2
instance. You don't need a NAT gateway.
Mhm. So basically I I forked this AMI
because it's literally like a
50-line bash script delivered through a
systemd one-shot to set up your IP
routing tables and um I'm sure people
are not doing that. It's just IP tables
and it's just registering your ethernet
interface to act as a egress interface,
right?
>> Okay. So it's very very basic small
little thing and it's amazing.
Um and I have a it together with a
module. I have a Terraform module that
basically
deploys this in several configurations.
It can be a single NAT instance in one
subnet and then all the other subnets
routing tables are routed towards that
NAT instance and then you would do cross
AZ that way. Or it can be one NAT
instance per subnet. So the module has
many configurations and they need to be
tested because it's a contract that you
support. TerraTest is amazing. Yeah.
Um so so what
>> I I I was just trying to remember. So
TerraTest is basically te-
is testing your
your
what do you call it? Your deployed
infrastructure, right? So what TerraTest
is is nothing but a bunch of Go lang
modules.
And what it shines through is the Go
lang testing
capabilities. Go test? Yes, Go test
because Go test can run test in
parallel, it can, you know, do all kinds
of like subnets tests, table-driven
tests,
and you can defer so clean up functions
can be deferred. So Terra- TerraTest is
just leveraging Go lang test framework
and it's just a a whole bunch of like
AWS SDK API implementations so that you
can
you know, um
on one side it it does OS exec
Terraform, OS exec Packer to test your
Terraform module and your Packer build
script. And on the other side it has a
whole bunch of assertions that you can
do. Is the instance registered with SSM
>> in the past, but like I mean, the
landscape I'm using it. So since
Terraform has added Actually, I have a
presentation about this that I delivered
in a conference in in Singapore. I think
there's different layers of testing that
you can do with Terraform. And the first
one you should use is the built-in test
command, right? Mhm. Because the
built-in test command is pure in memory.
So compared to TerraTest, TerraTest is
going to provision everything inside a
file system and it's then going to run
Terraform in it and it's going to take a
while. Whereas if you use the Terraform
test command, it's going to create
everything in time. It's you used the
Terraform test command?
It spins resources up.
>> Yeah. So I use both. So I I used the
Terraform tests
files in my module for some basic cross
variable validation like does a variable
condition
is it triggered as expected? For
example, I have a module and you should
set one variable and not the other. And
if you set both, you should get an
error. So I have a test around that.
So do you
So you use TerraTest with your CDK
your Terraform CDK stuff? With my my
library that I built, basically porting
the AWS CDK L2s, I used TerraTest to
validate that the L2s work actually
deploying. Yeah. Really cool. You should
mention that on your CDK trends.
It is.
Uh not on CDK terrain, it's on
TerraConstructs. Okay, okay. Which is
the L2 porting on top of CDK terrain.
But
there's some really exciting like things
in the work around that. So soon
TerraConstructs will will be no longer
needed, hopefully, and we can have
something directly that is going to have
all of the coverage of AWS CDK. And
that's going to be amazing cuz then you
can use it with AWS CDK with OpenTofu
directly. No more CloudFormation. Okay.
Can you imagine that? That you can use
all of those AWS CDK L2s directly with
OpenTofu. That's it's going to be
amazing. Okay. Let's That sounds
interesting, but that's that's upcoming,
right? That's upcoming.
Well, I think it's it's it's actually
more realistic now to talk about it
because if you if you're aware, there's
this one guy Kanto. I think he's a Japan
based. He's a heavy contributor to AWS
CDK and he like writes a lot of blog
articles about how AWS CDK works and
some of the features within and he's
contributing a lot of really really big
features. And he just announced
something called AWS CDK direct. And
what he does is he lets you run AWS CDK
without CloudFormation. So it reads the
CloudFormation YAML file and then issues
AWS CLI commands. Like it just calls
Oh, I see. I see. Something like that.
Yeah, and he uses a state file as well.
I might be a CloudFormation
apologist here, but like CloudFormation
kind of works. I mean, do you really
want to replace it? CloudFormation? I
mean, they made a lot of improvements
allowing you to refactor and I think
we're in a broken record, but it's it's
pretty painful when you have to deal
with logical ideas. Well, maybe that's
no longer a problem because now you can
tell CloudFormation that some resource
has changed its identity, so it's not
really need to be deleted. But one of
the biggest issues is a crash loopback.
Not Oh, yeah. The update crash fallback.
Rollback. Yeah, that's been broken. But
how does how does Terraform Sorry, how
does Terraform doesn't have that. Just
because of the planning stage will catch
that or something. No, just because
Terraform cannot rollback. You cannot
rollback Terraform. Well, you you can
disable the rollback uh
you know, you can pass an argument to
CloudFormation so it doesn't rollback.
>> Maybe that's new. Not last time I used
it, which was like 2 years ago, I think.
Okay. Well, if if there is something
coming out, I guess it's worth
evaluating. Like I think someone asked
me the other day like so with CDK you
get more linting, you you get more shift
left, right? I mean, we can we can
because well, I guess you have the best
you have the best of both worlds, don't
you? I mean,
when I talk with Adam Jacobs and I told
him I don't know. I told him about
because he's he's basically saying we
don't have to live with legacy of
Terraform providers. We can just rewrite
the Terraform providers on demand with
AI whenever we need it with whatever we
need it.
>> As someone as someone who's developed a
Terraform provider, it's not easy. No,
but and I told him like why would you
need to do that? Like you're throwing
away the baby with the bathwater. And he
says, "No, the model is completely
wrong. We need to get rid of it." So I
was like, "Okay." I just said I don't
understand that reply. So maybe you
I'm not going to go further there.
Okay.
Um hold on. I want you to get on the
topic whereby
Sorry. What ecosystem gives you the max
sort of shift left ability? Like one
thing I
noticed Let me just share this. How do I
share my Like there's been a few local
stacks sort of replacement
>> Today there was like this mini stack.
Yeah, there's there's been a few.
I just noticed them popping up here,
there, and everywhere. Yeah, since
LocalStack is like changing their
pricing model.
>> called Flocky. Oh, yeah. I've seen that
one. Um and then
I noticed this this AWS developer I
follow and I noticed I think randomly on
GitHub. Sometimes GitHub can just show
you what people are working on.
And
um
hold on. What is my username? And I
noticed he was working on this thing
called
um yeah, this Eman Fatih.
Um he he This I mean, this this comes in
my opinion, since he works at AWS, this
comes out of AWS.
>> No. No. No. No.
You cannot.
I can I mean, can you imagine working at
a big old company then everything you
does gets associated with it? That would
be so annoying.
I would hate that.
>> Obviously he vibed it. I mean, you can
tell.
I was about to say and I like that
there's Gherkin in it. That's super
interesting. I want to have a look at
that. Yeah, so
um
Okay, let me get my thoughts together.
So
you you use you use CDK, use Terraform.
Okay, what is the best ecosystem that
gives you the fastest iterations and
before you even deploy on the cloud,
that gives you the max amount of, you
know, verification that what you built
works. So to me it's it's something like
using uh I guess in the past, since I
don't have that much CDK experience
except my last gig, I would use
Terraform and I've maybe used uh
LocalStack and and then I would just,
you know, iterate from there and then I
would deploy.
That would probably be the fastest shift
left way. But have you come across any
faster ways of doing it? And I I don't
know exactly what happened to
LocalStack. Did they just go really
pricey or something? No, they changed
the license for
um
Before you could download the Docker
images of the community edition and you
could just run them, but now they
removed those. They deprecated those
Docker images and they only support the
enterprise Docker images and you have to
give it a token. So they are tracking
your usage. And another thing that they
did is if it detects that it's running
inside GitHub Actions or in CI, it just
shuts down. So you can use it locally,
but you can't use it in CI at all. So
that's where I think people got upset.
One, you can't use it anymore without
creating an account and giving it a
token so that they can track you. Two,
you can't run it at all in CI anymore.
Okay, that's a good summary. Yeah.
Um
that sucks.
So what in your opinion is the fastest
shift left way of of doing it? I mean,
I've always been intrigued by LocalStack
and I actually like to use it for like
take-home assignments because it doesn't
require a candidate to have any account
and I give them like a very basic AWS
infra that allows them to um you know,
do everything within the challenge that
um
that doesn't require that works without
a LocalStack license or anything like
that, right? But I have never used it
for anything like
um
you know, [snorts] validating a large
serverless setup. I think LocalStack
only makes sense if you are really
heavily depending on like serverless
services, right? That you cannot Like
otherwise you would just spin up like a
compose environment or you would spin up
a
you know, the services
>> Well, it's also good for all the like
AWS native, you know, Kinesis and So I I
have I built like this the Terraform
provider that uses SQS and I wanted to
validate it really fast and you can you
can actually have like complete
emulators of of SQS. I'm not sure about
Kinesis, but I'm I would be surprised if
you don't have that. And the funny thing
is those are like dedicated projects,
which I think are better than going with
like a massive library that tries to
track everything. Yeah. Yeah. Yeah. I
know what you mean. Like there's a few
like DynamoDB type Yeah, and and and the
the one that I was using for SQS was um
Was it ask Yeah, it was SQS. Was the was
written in I think Elixir or or um
something like Java. It actually Yeah, I
think it was using the JVM under the
hood. Uh is it Scala? It was something
crazy. Like I would never use it. I was
like, "Ah, I can't use that
because I don't I don't
understand."
>> self-contained as well. Yeah, it was
absolutely like yeah, it didn't didn't
matter what it was written in.
>> of most of AWS is probably some insane
Java. Yeah, but I mean, this was a this
was like a a public thing that just um
exposes the same API endpoints. And I
had good success with it. I was very
happy. Like at least I was able to test
this one little thing that needed that
one little service. So I could run it
locally. Um
but that's why I never use something
like LocalStack uh except for like
candidate take-home assignments or
something like that. Mhm.
So it sounds like you haven't really
explored this shift shift shift left
north stuff that hard. I mean, to me
this sounds like the biggest problem to
solve, really.
Especially now with AI because you want
AI agents to be in a little Why don't
you just give them an AWS account? Cuz
I'm not insane. No, I mean, why don't
you just give a developer an AWS account
so and a sandbox so that he can, you
know, test it against the real AWS API
services? Why would you try to emulate
it? Like I don't get that.
>> Because of speed. Speed and
safety and
>> you mock your tests, you get mock
confidence. Yeah, I I
I still maintain that this needs to be a
bit explored a bit more further. I'll
I'm going to bolden it. Oh my gosh.
Okay, last topic.
Cuz I need to run out and buy some
bread. Orchestration
uh can I assume that you that you and
like most people nowadays just use
GitHub workflows when you want to
coordinate something or do you use
something fancier to coordinate? I'm
and you know, Is this the last topic? I
don't know. I want to change the topic.
>> [laughter]
>> Can I change the topic?
Sure. So you know, because I think
there's more interesting with the trivy
hacks and and basically the axios hack
that happened and axios being on the
registry with a infostealer for 2 3
hours before it was detected and
removed. So I think right now and and
actually it's funny because I just got a
DM from someone that we both are trying
to build something and I said I'm sorry,
but I've been busy. I I've not been
working on this because of other stuff,
but if you want to work me to focus on
this, I can like pick it back up. And he
replied,
"I've been really busy with these supply
chain attacks." And I think it's it's
actually a very interesting topic
because everyone needs to change
completely the way that we handle
CVE and patch and
you know, releases. So maybe I can give
some background, right?
The the established practice today to
handle
CVEs in the past was basically to adopt
those fixes as soon as possible. So, if
you use semantic versioning, you have
three numbers. The first one is the
major
release, the second one is the minor
release number, and the last one is the
patch release number.
Mhm.
>> And so, usually if there's a CVE, which
you're not introducing any new um
features or you're doing a bug fix, you
you bump that patch version number, the
last number, right? If you're
introducing new features, you do the
minor, and if it's a massive breaking
change, you do the the major uh release
bump. So,
the way that you use semantic versioning
as a consumer of dependencies is by
setting up some type of rules around or
constraints around the packages that you
accept, right? So, you can set up your
your project, and this is something that
people learned quickly when
um they didn't put any constraints on
the dependencies, and they just adopted
minor and major um versions, and then
they got hacked or they got uh impacted
by those. So, people very quickly
learned to put a constraint around
dependency that you only accept uh patch
releases or maybe sometimes minor
releases, but usually just patch because
minor release Well, not minor release
shouldn't break you, right? Yeah, yeah,
yeah, yeah, yeah. So, so the best
practice right now that has been
established long by Dependabot,
Renovate, and others is to basically
constantly check if any of your
dependencies has a patch release. And
then that usually indicates, because
there's a CVE, you should upgrade as
soon as possible. And so, Dependabot
detects it, creates a pull request, and
if you're really fancy, and I think a
lot of people are, definitely if you
manage many projects or open source
projects, they set up an auto merge if
all of the CICD pass, it immediately
merges, right? So, that means that as
soon as a patch release is published
>> not quite fancy, but yeah, I mean No,
all of the CDK, TN, all of the CDK,
Terrain is auto bumping like that.
>> I When I say fancy, I mean that's
actually quite mature, but yeah, carry
on. Yeah. Cool. So, you
is the established best practice until
today. Yeah. Because with the recent
supply chain attacks, and a lot of those
basically what happened is some projects
get compromised, and the attackers are
smart. They just push a patch release,
right? So, everyone that's running
Dependabot updates and pulls in this
this package from the registry. So, this
this best best practice works against
people. And in the age of AI, there's
been a lot more supply chain attacks, a
lot more info stealers, a lot more like
>> so there must be something to be said
for people who don't update, right? I'm
just looking at my notes.
>> because if you don't update, you're
still exposed to CVEs, which are also
being detected first faster thanks to
AI, because AI is analyzing codebases
and finding CVEs faster. So, there are
more patch releases. Yeah, it's between
a rock and a hard place, isn't it? So,
what you need to So, and so, I was
asking around, how do I protect my
project? Because we just forked, I don't
want to get like a supply chain attack,
and then all of the trust in the project
dies. How do I make sure that this
project is not on the newspaper? Maybe
good and any news is better than than no
news at all, right? I could just let it
get hacked and then say, "Ah, people
like Finally know there's a fork."
No such thing as a bad publicity. Yeah,
so anyway, I I don't intend to have it
in the publicity in that way. So, I was
asking around, and I really like how
we're trying to solve this problem. It's
an interesting thing to discuss as well.
Cuz basically, a lot of these package
managers, aside from you obviously
fixing your long-lived credentials so
that you they don't get stolen and using
OIDC publishers so you get a short-lived
credential to publish so that even if an
info stealer got that key, it's already
expired by the time it tries to use it.
Yeah. Uh aside from first of trying to
make sure that you don't get compromised
that way, switch everything to OIDC for
publishing. The other way is so that you
don't get compromised as a consumer of
these dependencies is to make sure that
you use the feature that they have
added, which is one, you can demand that
the
dependency must be older than X days or
seconds. So, you can say to Dependabot
or to the package manager, do not accept
any package that hasn't been on the
registry more than less than 3 days.
Yeah, that sounds like a a very good
approach, right? Because now if the
package gets compromised, then hopefully
it get discovered, and by the time you
run, either it's been deleted or, you
know, you shouldn't have it. Yeah, I
guess that's like the Debian stable
model, like it has to go through an
unstable phase before it drops down into
stability.
And then the second thing is because I
don't think that's enough, right? Maybe
it was detected, but it wasn't taken
down because of I don't know what
reason, but usually NPM, G, actually the
package registry managers will
immediately take it down. Mhm.
The second thing is you need to gate
your CI, because your CI is not your
unit test passing is not sufficient
anymore for an auto merge. You have to
run a security scan in your CI, right?
And I was asking
>> do that. A lot of people do that, but
like
>> Yeah, yeah. You were just saying it was
fancy.
Well, a a lot of people A lot of people
do, but like I I I mean, I'm so worn
down by Well, I'm not going to I'm going
to say the name, Snyk. Like so many
There's so many like noisy Snyk alerts
Well, actually, because they have an
open source supports option, I was
thinking about, but I don't want to
because we use it at work and I hate it.
I don't even want to use it for my own
source.
>> What what what What are you talking
about? Something What you just
mentioned.
>> Oh, okay, yeah. I don't I don't I don't
mean to cast shade, but like it's
probably like a user error, like we
didn't configure it correctly or someone
didn't configure it correctly. Some
organ-
inevitably org administrator applies it
to every repo. So, every time you look
at a repo, there's a bazillion security
errors. You can hardly
work through the mess. Okay. So, then
then what I asked around and people told
me is that actually NPM audit, in this
case because we're doing the TypeScript
projects, right? NPM audit is pretty
good. So, Yeah, it is It is a great
tool. So, when I talked about this auto
update system that automatically merges
the PR if everything's good, actually
that's all built into Projen. Like you
just have to enable a flag. You just
say, "Yes, I want weekly updates. Yes, I
want you to to make sure
>> Okay. Yeah, and and Projen even switched
from Yarn Classic because apparently
Yarn Classic is not maintained and
doesn't have any of those features. So,
if you're on Yarn Classic, get off it,
right? So, I'm moving everything from
this inherited project from from CDK,
TF, it's all using Yarn Classic. I'm
migrating everything over to PNPM. Uh
Projen migrated from Yarn Classic to
NPM. They said it's good enough, it has
everything we need, and it's less of a
another hurdle for people to learn if
they don't not familiar with it with
with Yarn, Berry, or PNPM. But I'm using
PNPM, I really like it. And Projen has
support for PNPM dev dependency flag.
So, you can just say like it must be
older than 3 days, and I want you to run
an NPM audit in the CI of that that job
before it auto merges. It sounds like
NPM in a way or no that that that
ecosystem has the best tooling, because
the the tooling in Python, I would say
there isn't like an NPM audit. And
that's what I was saying. Just that What
do you want those guys to do for
security?
>> Yeah, that goes back to me bemoaning the
data platform stuff. I mean, UV UV
Astral would probably have those things,
right?
>> No, it doesn't really. Like the whole
Astral update story is still a mess.
Okay. That's not good. That's not good.
So, yeah, I I think it was really cool
because it's like um a really like
really hot and and really interesting
really. Uh because now you get like to
play balance. But then, of course, the
comment the first idea that most people
have is like, "But if everything
everyone is waiting to adopt a package,
how are we even going to know if it's
compromised?" Yeah, yeah, yeah. Cuz now
everyone's going to wait 3 days before
they they download it, and then they're
only going to find
>> imagine that that the NPM What whatever
happens in NPM is going to be
the the
What is the the expression? It's like
necessity is the mother of invention.
The stuff that happens in NPM is on the
forefront, right? And then it will
trickle down to other ecosystems or the
supply chain mitigations. So, so I have
a lot of work to do in that aspect,
actually. Like I still have to switch I
have already enabled OIDC publishing on
all the on all the registries, but I
haven't switched over the actual
publishers, the GitHub runners, to use
OIDC. And Okay, you're like an NPM
publisher deluxe, then I suppose. No,
I'm like a NPM, NuGet, Maven, and PyPI
publisher all across the board now.
Yeah, that's That sounds kind of risky,
actually. Yeah. I think I think I've got
like
I've got a couple of PyPI packages, and
I've got a couple of NPM packages. I
haven't uploaded to them for a while,
but but yeah, I think they're both just
passwords that I've never updated.
Yeah. But then to to address the concern
of people saying like, "But now
everyone's waiting, so how are we going
to know it's compromised?" But I think
that that security companies have a real
incentive, because every time And now
they're like all over Reddit, like Step
Security, but there's a couple of them,
Roll Security. There's like a lot of
security companies, and every time this
happens, they're on Reddit posting,
"There was this massive supply chain
attack." They have an incentive to find
to scan the packages published and find
any info stealer, any type of
you know, in injected whatever they they
usually identify things like the package
is unusually larger than than before.
Yeah. The package has some base64
encoded like strings in there that are
weird. So, they do this this uh
heuristical scans to very quickly detect
them. So, I don't think we need to worry
about if everyone waits 3 days, it's not
going to make detection slower. And then
somebody said gave me an example, "What
about exit utils?" I think exit util is
is like a completely different scenario,
right? What was the example?
X XZ utils, which was a
Yeah, yeah, yeah. I mean that that got
that took months before it was detected
and only because some Microsoft
researchers saw his CPU spikes
>> maybe it's worth
maybe it's worth plotting this in a in
Excalidraw. Let me just
public searchable cuz I do you think
it's worth capturing? Which one? Like Z
utils or what we just discussed? What we
just discussed like um I'm just sharing
my screen. And now we I just want to
capture it.
I just wanted to capture some
roughness. So I thought it was really
cool, interesting. Aside from obviously
the Claude Code source code map leak,
which has been talked about for death.
Um
I think the the scenario the whole
situation around Trevi being a complete
Is it it's Aqua Security that's that was
completely compromised, no? Okay, so
doing forgot how to use this thing.
So the
Uh we started by saying that like
developers with uh you know, a password
can can get compromised. Since they
aren't using OIDC. So that that could
happen. So that's that's one angle of
of attack. I'm just I'm just wanted
since they aren't using short-lived
credentials. Yeah, yeah. It's not
necessarily just OIDC, right? Oh my god.
Aqua Security posted an update yesterday
as well on on Wednesday, 2 days ago. The
other angle is that people are not using
uh security scanners. Yeah, but if you
use Aqua Security scanner
you got compromised.
If you were using Trevi, you got
compromised.
Trevi is the exception.
I I just wanted to plot like the the
typical ways that supply chain I mean,
there's probably a better list somewhere
already.
Um at least the ones that we talked
about. Um and then there was a third
one. What
Sorry, I I lost I was too busy typing.
What's What is the third one? Well,
well, I guess what what you just said
like the NPM will will will take that
will will will catch it.
Uh
given you know, X Y X days of cool down
or something like that. You know, like
like the like the XC or something.
>> It's something called um
age. The package The age of the package
has to be above. Let me find I did a
pull request on the CDK terrain repo um
provider project's old one. All these
security companies have Has Has anyone
Have these security companies actually
said that we have stopped attacks on
NPM? I want I I mean, does NPM use a
security scanner? Yeah, I don't think
they do because I think
when when Microsoft owns NPM
Microsoft owns NPM. Oh, really? Yeah.
Let me check.
>> even know that. NPMGS I mean, like the
official registry owned by GitHub. So
yes, Microsoft.
You understand what I'm saying? Like
when I
maybe I have a bad memory, but when I
published NPM, it's like pretty much
instant. So that means there's no
there's no gate, right? It It They They
just publish it immediately. I think so,
yeah. So it makes makes me think is this
step two people are not using security
scanners?
Include does
does NPM do this? Something to look
into.
Anyway, it's a it is an interesting
space. It's a space So if you use PNPM,
the flag is config.minimum release age
and you have to provide the number in
minutes. So I've just set it up as 4
days.
Which is 5,760 minutes.
>> parameter called? Minimum Minimum like
config yeah, minimum-release-age.
Oh, cool. Not underscore, but dash, but
okay, don't matter. And then the second
thing is you can run NPM audit with
audit levels. Yeah, NPM audit is really
good. NPM audit. And the guy like who
maintains Projen told me he finds it
good enough. And And honestly, he's also
the guy I was talking to about doing
some something else and he says that he
hasn't been able to work on it because
and he's on AWS. He says because of
these supply chain attacks have been
taking all of his time. Projen is
heavily used within AWS as far as I
understand. The way that they maintain
all of their repository boilerplate is
with Projen. So all of these features
allow AWS to very quickly roll out like
these settings across all of their
repositories, right? You just update the
core project and then every repo adopts
it and and and reconfigures itself
accordingly. Which is a dream, by the
way. Like um even here with this CDK
terrain provider like with the CDK
terrain setup that I inherited from
HashiCorp, it's all managed by Projen
and Terraform for GitHub. So
>> The tooling that
The tooling is really good when I think
about it.
>> It is really nice. Because I tried to
roll out Projen within my organization
as well, but again it's niche, it's
complicated.
>> is a is is CDK ecosystem very very very
I mean, but Have we ever talked about
Projen? Projen's TypeScript or It's
written in TypeScript. Oh, it's
available for Go? What?
>> Yeah, because it uses JSII, right? Oh.
How is it You wouldn't You wouldn't want
to put it in a Go language project. How
can you say if you never tried? Yeah, I
I
I guess I should
>> It supports Python and they also support
you UV in it now. Like the good thing
about Projen is that it's that actually
quite a lot of people use it even though
not a lot of people know about it and
that means that it's been kept up to
date with like quite recent frameworks.
We haven't updated the CDK TF supporting
there yet. We have to switch Projen all
the way over to CDK terrain. Um but
it it really gives you like really good
um
Okay, so you know how GitHub has this
amazing feature of creating a template
repository, right?
>> Yeah. Absolutely hate it. What happens
after you create it?
>> say it's sarcastic uh [snorts]
amazing. Okay, carry on.
>> So So And And not just updated. Yeah,
and then and then people have to come up
with all kinds of workarounds to
>> Like at at my last workplace, there was
uh actually the the workaround that we
have was pretty good. It was like a pack
pack new inspired. I don't know if you
know Arch Linux.
But basically, we wrote files into
people's repositories with the suffix
dot new. Okay. So So but still, you need
a whole bunch of additional stuff,
right? Um because the biggest problem of
these scaffolding framework um libraries
and cookie cutter and all this is that
they will bootstrap a file system for
you once and then that's it, right? How
do you keep that updated? Most of them
don't take that into account. So Projen
is different in a way that it approaches
the file system exactly the same way as
it deals with like a construct tree in
uh AWS CDK. So every file is basically
an object in memory that you construct
up into a tree. And then finally, when
you have defined what the contents of
the file is to look you know, on that
particular path, when you when you
synthesize, it writes everything down to
disk, okay? So then it creates the whole
I'm I'm understanding like it keeps your
answers. It keeps your values. Yeah, and
it it you can even have a function to
lazily determine the contents of a file
at the very end during synthesis, right?
By you know, collecting all of the other
files that have been generated and then
generating the contents of that file. So
you're able to completely functionally
define the contents of your of your file
system. And and and what's good about it
is that you can also hook into the
process. Like with with CDK and AWS CDK
and CDK Terraform, you can before
synthesis do some activities go on fun
activities. No, but like what you can do
is you can programmatically control the
contents of the file, which also means
that the consumer can define patches on
top of the files. So he can go find a
certain file within the tree and then
add additional lines or do additional
things because he in his case
So that means that if the if the root
project or the root object that built
your construct your tree of objects has
changes they will all just be adopted
and regenerated your file system on disk
and then your patches get rerun on top
of it and get reapplied as well. As long
as those two don't conflict, you know,
it will just re-render the file system
with your patches applied. So you can
constantly keep updating the the source
and then roll it out and it's all
programmatic. So
>> Yeah. So that's I mean, this is this is
applicable for for a platform where
you're supporting lots of products, I
guess, right? I mean, that's the big
reason. Yeah, so so where Projen really
shines is in like a poly repo setup
because it has really good support for
like a single repo with just one package
in it that needs to be published. If you
start to deal with one repository and
you need to support publishing multiple
packages then it becomes a little bit
more complicated. They have built
support for that on top of Projen. But
to be honest, I I never managed to make
it work because this is the main reason
I was not able to roll it out at work is
because we we have a lot of repositories
that are publishing multiple packages
and so I had adopted Turbo repo. And you
know, it's easy to build your own
project type in Projen because you can
define your object, which is a project
type, and you can determine what are
what is it like and and it works with
add-ons. So yeah, you can create one
object, which is like I'm going to take
care of the GitHub workflows and I'm I'm
an object that's going to take care of
the I don't know, your your
package.json, your your YAML, like your
your your manifest for your package. So
So it support all of these in like
add-ons. So you can say now I have a
repo, a base project, and I'm going to
add on the GitHub actions object and
it's going to generate my actions.
That sounds really powerful. I mean, it
sounds really handy for publishers like
yourself who you know, CDK terrain. I
mean, you you must be maintaining quite
a few projects, right?
>> just one. Yeah, yeah, we are maintaining
a lot of projects, but we just have one
project type in Projen that manages all
of our providers. Yeah, yeah, yeah,
yeah, yeah. So, so we just define a
provider within the project is Yeah.
this. And it comes with like it go it
comes with jobs to go and check the
Terraform registry if there's a new
version of the provider, and then it
will if there's a a new version, it will
regenerate the bindings. I know my
internet just hiccuped, right? But um
>> It didn't my word. Yeah, but it will be
fine on the recording. Yeah, yeah, I got
to edit this. Cool, man. I I I got to
rush out and buy some bread before this
the baker sells out and enjoy a few days
offline, I think. That's my mission. Not
spend spend some more time with my kids
since they're not they're on holiday
now. Yeah. So, I'll I get back to you
next week. And next week did I I I
mentioned to you I'm going to this AI
engineer conference today? Yes, you
mentioned it.
>> I'll I'll have some I'll have a lot more
to say next week. Or the week after.
I'll send you a link.
We'll catch up then.
Okay, see you. All the best. Have a good
Easter. Yeps. Uh yeah, happy Easter.
Yeah, are you going to do anything? No?
No. You don't have Easter in Vietnam.
You have other things. Yeah, but I'm on
this very annoying contract where I
don't have any ability to take leave, so
I'm not taking any.
>> of all time. Exactly. See you, man. Bye.
Okay, bye.