Episode 39: Decision Records for AI

You look professional, Vincent. I'm
I haven't seen this side to you.
>> Let's level up this podcast, yeah? Let's
start to draw diagrams directly on the
whiteboard. But, was it in in in mirror
for you, or was it like
not mirrored? Cuz for me it was
mirrored.
>> Sorry, I wasn't looking
like One topic I want to get to you is
tech One topic I want to get to you is
tech debt, right tech. Oh, yeah, it
looks great.
Bell.
>> Does it?
>> Yeah.
>> Okay.
>> Yeah.
>> Cool.
>> This is good.
>> If I can get this room, cuz I just
dropped into It's a pod. It's a working
pod.
>> Okay. So, maybe for the the context of
our avid fan base
>> of one.
>> [laughter]
>> Hello. Thank you for watching.
Hello, Fred.
>> It's been like a month since our last
one. So, what happened to you? You got a
you you got a you got a on-site job now.
Can you Can you describe what happened
to you, Vincent? Cuz for me nothing much
has changed, really.
>> No, I
I have an office that I can go to, and I
can meet people now, which I didn't have
for the last 6 years. So, maybe I'll be
less of a recluse. I'll I'll learn to
behave.
>> No, don't
Don't say that, cuz my my client has has
done one of those like return-to-office
type policies, and like
>> No, no. I said I didn't say I said I
have an office I can go to. It doesn't
mean I have to be here. Like a lot of
the colleagues right now are not here.
>> Yeah. But,
>> It's I'm usually there on Wednesday.
>> I guess
I maybe I I jumped the gun there,
though.
It's good to be in office to some
respect, right?
>> Exactly. That's what I was in alliance
with people. Yeah.
>> How's it going? Are you still in
probation period, and
>> Yeah. I'm just having fun, right?
Probation.
It's It's just the best time to have
fun, isn't it?
>> What What What is your What is your
role? Can you talk about your work, or
you can talk about other things?
>> My role is the most ridiculous. I see
myself Let's see Let's say how I saw
this
>> I see myself.
My title does not see me.
>> Well,
I'm not going to say much, but I see my
my role more as like focused on
approaching AI adoption from a platform
perspective. So, the the tricky bits is
that of course they already have a
massive platform team, even a dedicated
AI platform team. So, when I joined I
was quite
scared, but I saw gaps and I feel like I
can
I can address some of those gaps.
Let's see how long
my views survive.
>> So, which gap are you working on?
You can't say.
>> Trying to
highlight where agents struggle in
existing pipelines systems.
Like, you know, you have an established
It's It's a It's a highly
sensitive environment. So,
compliance requirements and so on. So,
there's a lot of of of blockers there
that are there for a good reason, right?
It's not a startup where, you know, you
want to deploy in S2 to production as
fast as possible. There's a very strict
chokehold that the platform team has for
good reasons. So, that's kind of like
the probably the most challenging part
being, you know, I wanted to be focused
on AI adoption. Even though lately a lot
of people are like
really anti-AI, more I feel like. I
don't know, maybe. Not not in this
company, but like generally I think the
people I think
>> I'm willing to accept that there
there there's certainly places where you
want a human in the loop. Though, at the
same time
like given an incident or given a
given a use case, you want you want the
agent to be unlocked to be able to
perform it in a reasonable
manner in a in a sense. So,
>> It's it's about signal versus noise. I
don't I never I never said that I want
to take humans out of the loop, right?
It's just where does I think Autopilot
is a great example. Autopilot was able
to reduce the signal the noise. We don't
just press enter prompt. It's able to
surface very clearly where your
attention is needed. Says like hold on,
you know, agent is doing something here.
That probably shouldn't be
>> Sorry, the signal wasn't that great
there.
Yeah.
Interesting.
Yeah, there there is pushback from AI
from from some people that I
I went to like an onsite the other day
and met my colleagues. So, it was
interesting to have beers with them
because, you know,
then you hear
people's hopes behind the scene.
Hopes and fears around AI, right?
>> Yeah.
So,
to to jump into one topic I was keen to
hear from you about
tech debt.
How do you Do you have any tips like I
remember using a
a SaaS service back with the Italian
client where where all the
vulnerabilities were like brought in.
But, I think Datadog can do this.
But, anyway, all the vulnerabilities
were all brought into one dashboard.
Single pane and we're able we were able
to like sort of accept the risk or you
know, prioritize which ones we're going
to do. I just had I just had to ask you
quickly if you had any experience of
using Datadog or something else to to a
whole bunch of vulnerabilities or or
tech debt.
But the since I'm in security, the the
tech debts are seems to be out of date
dependencies essentially.
>> I had quite a few discussions lately as
I'm in, you know, coming into this new
role and talking to people about the
business value and like
I think it's it the way that
the team the team I work with uh sees
tech debt is more of like
a ceiling of capabilities.
>> So, as you as you deliver work, you're
you're
you know, elevating the ceiling of
capabilities.
And until you hit the ceiling, you're
not forced to make changes on those.
Like the ceiling
maybe, you know, able to handle a
certain capacity. Cuz tech debt in
general is not just about security
vulnerabilities that are pending. It's
also about like, you know, where where
every week we have to reset the database
server because there's this background
job or we need to truncate the logs.
>> Yeah.
>> And and things like that are, you know,
generally not good but they are
>> of the ceiling.
The ceiling cuz I I'm assuming you can
use that as a as a metaphor to describe
that your team has
essentially too much toil, right? And
then you need you need to
you need to be able to lift that ceiling
by adding, I don't know, a new team
member or uh
addressing the tech debt. Otherwise,
you're you're you're over capacity or
something. I don't know.
If you
If I if I understood your analogy
correctly.
>> It's it's more of
of capabilities of the of the
architecture and the software, not not
just the team. So, when you
I'm I can't claim this the way of
looking at the at at the
at at software and software development,
that view is not mine. But I do like the
way that it reframes because the way
that like Google and SRE identify,
sorry, or did define tech that. It's
more about, you know, your error budget
and other things that trigger
refactoring or trigger different like
maybe a code freeze. Cuz cuz what is
tech that, right? I have a lot of
arguments in previous companies where I
go like, oh you know, this all of this
bash this massive bash script that runs
in our deployment is tech that. Like we
need to to get rid of this. We need to
split up the deployment pipeline. We
need to support parallel because it's a
microservice architecture we need to
support parallel deployments and things
like that. Yeah and and dependency like
a proper mono repo build tool and and
then they might might might team lead
would be like, no.
It works. It's not tech that, you know,
it's it's all of that what you mentioned
is nice to have.
>> Well well in my context it's it's like
a large organization,
lots of teams,
and what's happening is that we get
these alerts from different systems that
but that dependencies are out of date or
or vulnerable.
So that's that's that's my tech debt.
>> And that's just one, yeah. I mean that's
just
>> I work kind of roll my eyes because many
of these internal
dependencies many of these systems are
only internal and many of the the the
dependencies
are super low risk in my mind.
But they but they're flagged as high or
critical and uh
what I'm struggling to do is just
essentially I've done this before.
I feel
like an idiot for not remembering how I
did it. Is is just to essentially uh
manage them and and govern them and and
be able to sort of flag them as like
accepted.
>> Classify.
>> I'm disregarding this these ones because
it's you know, it's internal. It's like
a system or maybe I have to maybe I have
to be real and say like, hey, this team
doesn't exist anymore, I'm afraid to
say. And it's running like it is and we
just don't have the
the
capability to update this one.
You know what I mean? Like I'm I'm
looking for that sort of uh
governance tool more than anything else.
I mean
Yeah, I mean
I know what you're saying.
I mean
when we were looking at Twistlock
backend a long time ago when I was
setting up for a for the Singapore
government integration, like we were
start cuz
they have like this IM8 requirements.
What I wanted to get to is they have
like a IT standard that they're they
judge architecture upon and you must,
you know, be compliant. Uh for example,
have a three-tier architecture, have the
the limit the DMZ zone, only allow
ingress on your data layer on a
different You know, that's IM8 like
then.
And one of the requirements was with
Twistlock and an intrusion detection and
prevention. So, IDS and IDP. So, you
need to detect and but also
constantly scanning for like workloads
and vulnerabilities in those workloads.
And one of the most, you know,
advertised features of some of these
platforms I was looking at at the time,
Aqua Security, Twistlock,
>> I'm familiar with Twistlock, but what is
that?
>> Twistlock, they were acquired by
I forgot. They were acquired by a big
brand of but
they were an Israel security startup.
And there was another one, Falcon from
Sysdig. Yeah, Sysdig. Uh Falcon, those
are the ones that I was evaluating
because we were Kubernetes cloud native
platform. And so, one of the hardest
things is like, "Hey, Kubernetes, you
have this massive cluster that runs all
the workloads, batch jobs, and all. But
then IM8 is like very strict. You have
to have your ingress layer living on
completely separate nodes with like
natural access control lists." And if
you have a Kubernetes cluster, that's
hard. You know, even if you you you
taint ingress nodes so no other
workloads can live on it, how do you
ensure that nothing tolerates the taint
and runs on the on the ingress layer
anyway? So, you need to have some web
hook and admission hook and and all
kinds of enforcement. So, with Twistlock
we were able to to uh
achieve some of that.
What I was trying to get to was that the
security reports, like what you say.
We're running CoreOS, which was like
this super
you know, con- container OS.
Yeah, so so the kernel like it's a very
minimal host operating system.
>> Yeah, yeah.
>> And and a very up-to-date kernel cuz
it's like very aggressively upgrading
updating as well. It's very security
focused, right? CoreOS, I mean, the
company before they
>> Who didn't they join
>> No, they they were acquired by Red Hat
and then their Kubernetes uh yeah,
solution wasn't was basically replacing
Red Hat OpenShift. They replaced
Tectonic.
>> Yeah, I mean I mean I'm assuming when
you run Kubernetes on the cloud it does
the same thing as CoreOS, you know.
But CoreOS was cool cuz you could have
got got the same feeling on your own
machine.
>> CoreOS the the the biggest thing that
CoreOS did was immutable architecture
with dual dual boot. I think we talked
about this in a previous uh
>> Yeah, yeah, yeah.
>> But what I was getting to was the
security scanning and the reports and
the Twistlock vulnerability reports
exactly your problem, which is like
being able to to to flag certain
critical findings as you know, you have
to put the reason why it's not yet
addressed, right? Or you have to put it
in like a backlog and and a timeline
against when it's going to be addressed.
And we we we Twistlock helped you with
those things.
The big selling point of those
frameworks was to like, hey, you know,
most of these solutions, definitely if
you go open source, they just it's very
easy to get like a full scan of all of
the possible vulnerabilities and drop
and and and dumped at you. But then what
the differentiator is for the commercial
offerings is to basically help you with
exactly that. Like, that's where they
are, you know, making you pay.
>> Yeah.
Okay, I'll I had I have to do some
research. I was just I was just hoping
that you had a quick solution for me.
But I mean yeah, I'm sure I'm sure I get
there. Hey, I wanted to show you
change the topic to something that I
might have talked to you about
about decision-making in organization.
So maybe this is just me having a chip
on my shoulder as we say in English. I
don't know what you say in Belgium.
Though I'm often irritated
by it's not just my own employer, it's
like the different clients find it very
curious how they poorly communicate a
policy.
Right? Like you you were talking about
the public sector earlier where they had
like I am a I am a they had like a like
a good spec and I think Singapore yeah,
like
for the most part there was good
leadership and good leadership for me is
essentially
very boring and this
it's basically writing things down and
sharing what that that writing is and
making sure everyone's aligned on that
that piece of writing.
So the thing that I've noticed in many
in many of my gigs is that you might
have a town hall or you might have like
a social media post nowadays like like a
leader saying like, "Oh, we are changing
the policy on this. I hope you feel
comfortable this. If you have any
feedback but like you might not like you
know, since these different mediums like
you know, like a YouTube or a like a
Confluence and or Workvivo or they're
all they're all like kind of different
mediums difficult to to track a but but
they usually don't have a single source
of truth. They don't have like a
a URL like you know, company decisions.
dot
whatever.com/the
decision.
So this inspired me to to vibe code.
>> You You shared the link.
>> Yeah.
>> Right. I was just going to open it.
>> Yeah. So, this basically
inspired me to to vibe code something.
And
yeah, like I don't know. Do you think
I'm just making a mountain of a
molehill? Like I It's It's the same
thing like I'm
I'm sure you know what architecture
architecture decisions
But it's the same concept. Like
essentially, you make a decision.
You have a URL.
You You copy it around. And And of
course, in my mind, good communication
is repeating the message. Saying like
you
the same message all the time. But like,
"Hey, if you want to know more, check
out decisions. whatever."
And you will or follow this QR code and
you will get um
you will uh
see see exactly all all about it. So, I
I did get a little bit crazy. I did even
define a schema.
And make sure that And when I build it,
it sort of like validates it. You know,
you you can have like a like an RFC or a
W3C spec, you can have like
>> Does it Does it have an MCP?
>> No, it doesn't. But it It has an
endpoint and an LLM's text.
It generates LLM's text, dude.
>> Does it then have like an open API or
some other schema
to validate it?
>> Uh yeah, it's Well, it's It's just got a
YAML schema. So, when you when you
actually write a decision, you you mark
it up and it validates that
these fields are are are set. And that's
about it.
>> It's like ADR, but
uh
but then I guess
>> But this is what it's supposed to be
self-hosted.
Yeah, it's self-hosted. You can All need
to do is
well, ask Claude to build it or or run
this build.py or this makefile.
I I I mean
it's never mind the implementation, but
but do you often feel that communication
in a company is could be better or I
mean, have you seen better communication
than what I'm envisioning here?
>> I mean
I'm in an environment now where
I talk to many people. Like one of the
biggest issue is is is not just, you
know, tracking decision records, but
basically feeding context to agents
because ultimately the decision records
are
possibly some of the stuff you want to
to have agents access to, right? It's
It's disparate. It's completely
separate, you know, Confluence,
Bitbucket, uh sorry, GitHub code, like
uh it's all over the different
repositories. Maybe there's some in
Slack. So, what we're focused on is I
think one of the biggest issues is also
the same data is being represented in
different ways. And and and you know,
documents run out of out of sync. Like
the problem you had in the previous gig
where you say like we have a whole bunch
of Confluence articles and we want to
ingest them into like a Markdown
database managed by agents and agents
can generate multiple views
>> but but that same Markdown
>> And just for the context, we actually
unleashed unleashed did that migration,
but the trouble is that the the AI
agents sort of made the the content in
Markdown somehow repetitive
>> like the broken mirror of different
views.
>> Yeah, and it created more noise than
than what we almost had originally. I
mean
>> And that's a common problem, right?
It's a common problem. Even if you use
back-driven development, one of the
first issues you're going to face is
that you you write something down in
your specify like in your original user
stories given when then acceptance
criteria. And then when it comes down
to, you know, implementation, the
library, the technical, you know, the
the API routes, the data model.
>> Yeah.
>> And then when you go down all the way to
the implementation plan, the phases,
that's the same information.
>> Yeah.
>> That points back to like this task needs
to be implemented because of this this
task is this because it this acceptance
criteria is fulfilled.
>> to that source of truth. Otherwise,
there's there's an actual link.
>> So what happens is you get like 20
markdown files on disk and they end up
disagreeing. There will be inaccuracies
because of different terminology used
across the documents. And so so that's
where I I then was like, okay, Matt
Pocock, he he solves it using his
drill with docs with domain language. So
you establish a terminology so that the
agents can only write documents with
that terminology.
>> that video that Yeah, establishing a
terminology is so key, isn't it? Yeah.
>> Yeah, so so then once you have a
established a terminology, it also needs
less tokens. I mean, I like what he's
saying there cuz everyone wants less
tokens. And hopefully as a human you
also can read and understand it faster
because you have a shared language. That
should reduce the number of
inconsistencies across disk and across
conference and across sources. But then
you still have the problem that, you
know, a data model is a data model. It's
it's it's one set of of it's one set of
information. And then re you know,
visualizing the data model as tables or
or visualizing it in a in a sequence
diagram explaining the interaction
between systems and and the impact the
mutations that happens on the data
model, it's the same data model. And and
and those run out of sync. So I don't
like I talked to a friend and their
solution to to solve the context problem
for agents and also Google's OKR which
is like a a markdown on disk. I think
that's not the right way. I think you
just end up with the same problem that
you had with your confluence uh you
know, you have a thousand different
views of the same. Even if you have a
shared language, the LLM is
non-probabilistic. Uh sorry, it's
probabilistic non-deterministic and it
will just create different you know,
slightly different
texts and the data is the data.
>> Yeah.
I get that. So, don't don't you think
that that thing I just showed you, the
decisions
which is consumable by I AI agents cuz
it has LLM's to dot text. I purposely
>> one view of the data.
It's just one view of the data. It's
just an ADR view of the data. There's
actual data behind it and that's the the
thing we need to to to to capture.
>> What do you mean? Like the the data
structure and like with the detail some
further details you mean?
>> you may you may have an uh a decision
record and
I don't use them that much but
it may
modify a data model. So, the problem
that that I think a lot of people now
are trying to solve with what they call
ontologies is to to try and model this.
And there's a very good talk from I
think AI engineer conference from a
professor who talks about expert systems
back in the '90s and the concept of
ontologies and how that applies to
context management for agents. And and
they basically when they talk about
ontologies, they talk about a not a
relational database or a or a view on
markdown but actually a graph with
relationships because a
>> Oh, yeah.
I noticed that in my feed maybe
serendipitously that there's a lot of
talk about marrying a graph database
with your harness.
>> And that's exactly what Beats is, right?
I mean, if you think about Beats, it's a
it's a graph. It's a node of graphs. I'm
sorry, it's a graph of nodes. It's a
graph of nodes of type issue, of type
feature, of type epic. And they have
relationship, uh blocked by um
>> Sure.
>> And and and and and basically that's
what makes Beads so interesting because
you create a graph of tasks and uh you
leave comments. That's also another node
type and
>> Yeah.
>> that attaches to it.
>> You're right. I never actually made that
connection.
Well, I I feel like I just want to go go
back to basics. Like I want I wanted to
because because I think
leadership in typical companies won't
won't uh
even probably even grok Beads, but they
might grok a webpage.
You know, and then and then from from a
decision maybe maybe you can have a like
a Bead link, which would have more
details and you gradually Yeah,
progressive disclosure but essentially.
>> And you can see with Beads like the
Agent is really good at creating the
task and managing dependencies between
them, seeing which and doing a query on
the graph to find out which tasks are
>> Yeah.
>> you know, not blocked. But what you can
also do with Beads is you can generate a
Kanban board from it. You can show a
user which status all of the Beads are
in.
>> yeah, you can you can, sorry.
>> Another one that you can do is you can
show a like if you if you know the Kiro
and you see the the phases and the
tasks, you you have a a markdown
document with little checkboxes when a
task is done. And and you can That's
like a tree view because you have like
phase and then you have all the tasks
and you have sub children. You can do
that with Beads as well, right? That's
basically what I was doing with Pearl,
the the twee twee.
>> Yeah, yeah.
>> I was just I was showing like here's my
task graph, here's the tree, here's the
phases, here's what's completed. I can
see it in both views. And because it's
one set of data, you can get like
different views from from from Beads.
>> Yeah. I guess I I've been using Beads
myself just internal to my own little
projects and I love it. And I find that
useful. I haven't I haven't managed to
get my my my my team or my colleagues
adopting that sort of flow. Yeah, I
mean, have you I mean, you must have
come into this new this is this your
this um this company that you now work
for
with a ton of ideas.
Has any
of any of your ideas been adopted, would
you say? Like your your adversarial
reviews, your usage of the adversarial
reviews.
>> arrogant to assume that they are not
doing that already. They were already
doing that, yeah.
>> I often find that
s- like
the policy they have
>> have joined a company if they wouldn't
be if I wouldn't be the dumbest person
in the room.
>> Yeah, well, I often find
that this I've there's things that I
like to do, but my team doesn't know
about and it's very and that, you know,
they're they use Atlassian and for or
Jira and then you're just like, okay,
now we
now we're stuck or
I want to share my screen with you many
times before.
>> Oh, what was that, sorry?
>> I want to share my screen, but Chrome
doesn't have the ability to
to share it.
Maybe you can share it. I sent you this
the link. It's a
>> I have Hold on.
Are you sharing it with me? WhatsApp,
hopefully.
>> No, no, I'll share I share it on this
chat here and Riverside.
>> Oh my god, I don't even know where the
chat window is.
>> I don't have WhatsApp on this work
laptop.
>> Okay, okay, okay.
I'm going to share the screen.
Piaz, oh my god. They all look the same,
these sites. All right.
Where people in Asia share one
understanding, yeah, right.
>> It's what we were discussing, basically,
right?
>> Yeah. I mean, this this is this is
several implementations, like the
Mozilla CQ CQ is one one that I've CQ
is one that I would talked about in a
previous pod.
Where I was really impressed by
by Mozilla's approach because they had
these tool calls like validating the the
knowledge.
Uh
the knowledge.
I'm not sure what they called them now.
Uh and I thought that was quite
powerful.
But
what what I'm trying to say here Vincent
is that
there are lots of cool projects,
agent-friendly projects.
Though I'm looking for a way where we
start
essentially with an idea like that an
old idea like the ADR and then
progressively build on that using I
don't know something like this or beads
or whatever a graph database. But it
But you must understand like I'm super
frustrated when when clients or or
different companies they just don't have
a central point. This I'm just looking
for a source of truth at this point.
And that and that's that's step one in
my opinion get a source of truth and
then the rest of it will follow.
>> I'm trying to see if CQ is using graph
relationship. Well, you know beats is
also in
built using SQL light, right? It
represents nodes within the graph using
tables and the relationship tables and
so on. So
you don't need a graph database but
I never use graph database before. But
in terms of like what you just asked me
of of like being frustrated. I mean I
think beats
it's I I got rid of it, right? I I
replaced it with my own implementation.
But
I mean the idea I think under the hood
the idea of graphs and nodes
the problem is they're very very
specific like Jira has it, right? I mean
beats all look like me like Jira, right?
You have issues, you have child issues,
you have epics, you have features.
There's all different nodes of different
of of different types and relationships
that can they they can have with each
other. So, I don't think you need to
move out of those existing platforms.
Like when I I built Spec Ledger, I was
like, I hate Jira, I hate Confluence. I
think those systems are horrible. All
you need is markdown on disk. And then I
learned like the broken mirror issue of
everything is like running out of out of
sync and it's not easy to manage. I
think this I this approach of building
ontologies for companies to build graph
data like graph relationships of how
things link together and then building
on top of that, that's very interesting,
but it still requires you to move out of
those existing systems. And I think the
focus of a lot of the like even Cloud
Tag and and you know, the way that
people are building is to to land those
AI systems in the tools that humans used
used to use today.
>> Yeah.
>> And I think that's that's the realistic
approach
is to get AI to live where the humans
live.
>> Yeah.
>> Yeah, I mean that's assuming like
Well, like
I I've I personally noticed that in some
clients that even decisions are not
recorded properly in Slack cuz Slack is
more of like a informal space or they
they're rather jump on a Zoom call or
whatever you to explain
what the
what what the decision is.
I mean, I guess I guess it's maybe it's
maybe it's just a symptom
that many many of the clients that I
work for are not like, you know,
very mature software company. So,
so leadership in a sense is not used to
cuz like like what do you what do we do
as a software engineers? We we
essentially codify
the business requirements.
But sometimes
and and that's the job. But like and
maybe we should take responsibility for
just writing down these decisions.
Though what I'm trying to say is that
many many times that like
even Slack doesn't have the context
because it's in it's in it's in some
executive's head or something like that.
Like just just like I like what
just the fact
that some
I'm trying to think of the name of the
guy there was a a a some executive a guy
with a ponytail. I can't remember his
name now. He used to just write
blogs and and I think of course
>> Jeff No.
The and of course of course like uh
>> I think Jeff Bezos is is also good a
good example. Of course his blogs are
more internal, but he just releases
these memos and then it's clear to the
rest of organization what what we're
trying to achieve here.
The memo is the memorandum.
And it's clear. I just That's what I'm
I I miss a lot of the time. Just a blog.
You know, we talk about Jira, we talk
about all these graph databases, but
like just a blog would be so refreshing
in this darn age.
And that's where I'm at. That's that's
my frustration.
>> So you want your CTO blog.
>> Essentially.
That would be so
That would be so awesome.
>> I did have one CTO at some point
that had a blog. Yeah, at at GoodNotes
the the the the the founder he wrote
blogs about like what he learned, how he
saw the company evolve, how he saw the
ecosystem evolve, what he he believes
was like coming next, and he he he
shared them, and yeah.
They were insightful. He's a smart He's
a smart person.
>> that's the stuff I really miss. Cuz like
when people do their little demos on
Zoom and there's Zoom recordings and no
one can ever find the Zoom recording cuz
for some bizarre reason Zoom makes it
impossible to find Zoom recordings. This
is There's so much context that's lost.
And I hope And if we can just start with
a single point of truth, a blog, and
then progressively just goes, I'll be so
much more happier and less confused all
the time. And and And it's not so much
me being confused.
It's like when you work with AI, when
you work with agents, and you notice
that it doesn't have the context, you're
like you're frustrated. And like, how do
I get the context here? I have to copy
it here. I have to I have to summarize
this video
for it to know what we're talking about
for this particular
activity or job that we're trying to do.
And
you know, context engineering from for
me is almost
like
the frustrating experience of just
gathering bits and pieces from
colleagues and what have you to try work
out what the decision was.
And then And then when I've got it all
there, I'm not even sure it's right
because people have said different
things and what have you and things have
changed since then.
Yeah, anyway, that's just That's my
rant. Yeah.
Awesome.
>> Yeah, I mean, I think with agents and
the amount of, you know, these large
language models, the amount of text that
they produce and the inconsistency
between the text and and every human now
being hooked up to one of those one or
more of those generating more and more
text, I don't think the the solution is
going to be solved easily by by large
text document. Apparently, when they
look at usage of these LLM, a large part
of it is right like a very short status
update that gets converted into like a
massive long blob from like, "Hey,
Cloud, can we do a quick status update?"
And and creates like paragraphs of text
and then somebody else goes simplify
this. Hey Cloud, simplify this. Like the
LLMs are being used to to generate
massive amount of text and then they are
used to to summarize this amount of text
again. Where like if you want to There
was one of the insights of of of a
senior like leader in the company that
I'm at. He's like I looked at the
statistics of token usage and if we want
to save cost because it's way through
the roof, let's start by, you know, stop
using LLMs to generate
status updates and and and because
nobody understands them.
>> Yeah.
Like one thing that I'm thinking of
mandating in my I mean I mean I have
sort of mandated it in my team.
We don't allow people to write with into
confluence documents with a with agents.
If you're going to write a document,
write it by hand.
Because because often
>> How can you enforce that?
>> How do you enforce that? Uh well, you
can
Well, you could theoretically disable
the right tool.
Um but unfortunately, the whole the rest
of the organization doesn't share my my
team's view or the
least the views I project on my team.
>> Oh my god, I'm late for a meeting. I'm
sorry.
>> You you can just you can have some text
in the in the conference document like
agents do not write into this document.
That that also works. Sorry. Oh man,
there's some
>> Oh gosh. Do you have any time more
today? There's other things I wanted to
pick up on. Otherwise, I guess this is
the pod.
Episode What was the last one?
>> I'm sorry. I
I didn't give too much updates on but
but I have another call and a meeting.
>> Okay. No worries. That that was episode
39. At least we we we kind of got back
together again.
>> Okay. [laughter]
>> Okay. See you, man.
>> start on the hour, then it can be it can
be like 50 full minutes.
>> Yeah, yeah. Sorry. I was but I'm on
holiday, so I was a bit slow out of bed.
Okay, see you.
>> Okay,
see you.