# Agentic Engineering: Mental Models and Governance

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-11-04

## Transcript

What's up friends welcome back this is the changelog I'm Adam Stachowiak editor-in-chief here at changelog what if the real bottleneck in AI assisted engineering is not the model what if it's your team's ability to understand what it built that's the exact idea Dave Kerr landed on when I put him on the spot to invent a hacker law of his own the limit to how fast you can build and scale is how well you keep your team's mental models in sync with reality Yes, this week I'm talking to Dave Kerr, creator of Hacker Laws and author of Effective Shell about building with agents without losing the plot.
We discuss why he deliberately slows his team down with spec and code reviews and why models are down to build.
when they should be down to buy.
We cover how his team spends 25% of his engineering time on CVEs in the NPM era and whether Frontier Labs might one day sell placement in an LLM's architectural recommendations.
And we also get into the grief of watching handcrafted side projects compete with one shots.
A massive thank you to my friends and partners at fly.io.
Computers for agents, sandboxes are not enough.
Give your agent a real computer and get back to building machines, sprites.
Learn more at fly.io.
All right, let's do this.
This episode is brought to you by our friends at coder.com.
You know what?
Your developers, they have guardrails.
The humans, guardrails, right?
That makes sense.
But your AI does not.
How often are you running your AI dash dash dangerously?
I think that most people are living a little dangerous.
Some are sandboxed.
Some are not.
Most are not.
And I'm here with Nicky Pike, Field CTO for Coder.
So Nicky, what is the focus right now for Coder?
I mean, really our focus and what we're doing at Coder is on the governance around AI.
So, you know, everyone right now, they're talking about, you know, AI agents like they're magic, but nobody's really asking where they run and what they have access to or what happens when one gets compromised.
I mean, kind of give an analogy.
You're not going to invite a contractor into your home and then leave and have them have full access to your safe and everything else on day one.
You know, this is what people are doing with agents.
We are wanting to, we are the infrastructure that helps you put guardrails and restrictions and governance around.
agents and what they're doing to you today, that's where Coder succeeds because, you know, we started out as a CDE company.
There's no secret.
We were a CDE company.
We created remote dev environments, standardized workspaces.
But what we realized is that we accidentally built the exact foundation for the AI age before the AI age even really arrived.
isolated, governed, audible compute environments.
That's what we build.
And that's exactly what enterprises need when their workforce starts, including agents alongside their humans.
So, you know, for us, this wasn't a pivot.
This was really, we finally found the problem that perfectly fit with what we'd already built.
So if you're living dangerously, dash, dash, dangerously, non-sandboxed, you name it, Coder has AI governance for you, a centralized gateway to observe.
and to control LLM tool usage across your environments, authenticate model requests, audit every prompt, and contain agents behind a default deny allow list.
The smart way.
Learn more at coder.com.
Request a demo once more coder.com.
Friends, we're back with a fantastic be back guest.
That means they will be back and he is back.
Dave Kerr.
creator of Hacker Laws, writer of Effective Shell, and all around friend and hacker.
So, Dave, welcome back to The Change Law.
Great to see you, Adam.
Great to see you because the last time you were on the podcast was six years ago with Jared.
I was not on that podcast.
I am affected by the laws for hackers that we have to live by.
However, I'm not one who keeps them in my RAM.
for random access.
It's sort of like it's shelved off to cold storage or something like that.
So if you ask me, Adam, could you name five hacker laws right now?
I could probably name three just off the top of my head.
So I'm not the best at that.
But you've got this open source repository out there called Hacker Laws.
Very much a hit.
27.2 thousand stars on GitHub if that's a metric that you Sleep well at night by, I'm not sure.
If you're like, yes, I got 20,000 plus stars on XYZ repository.
My day is done.
It is a good day.
How do you feel about this project?
What's come since then?
What's on your mind around laws, the current scenario we're in, in terms of AI taking over everything, the book you've written, where should we begin?
It's really interesting.
I feel like there was a bit of a...
kind of arc that connected things in the end, which I didn't realize.
So I had to, we did the show with Jared and it was really, really good fun.
It's, you know, quite, quite whimsical.
Some of this stuff, it's a little bit silly, but some of it is also just kind of like good practical design to think about, or also just the inevitability of organizations, you know, more people, more complexity.
And then I'd mentioned to Jared that, oh, I'm writing a book as well.
And he said, oh, hey, when it's done, you should, you know, come on and talk about it.
And writing the book took a long time, way longer than I expected.
It was originally and still is open source.
It was just a collection of techniques that I didn't come up with because I'm not smart enough.
But I look over a lot of people's shoulders and I'd see them do something.
I was like, oh, how did you do that?
Like you just cleared your screen in one go, found something else and then copied it over there.
That looks super useful.
I'd kind of write that down in some tips and tricks.
And then I did a couple of blog posts of it.
And then I started collecting them into.
like a mini book on techniques.
I pitched it to No Starch Press.
They were really happy to publish it.
And they were great, but the editorial process takes a while.
And then I pinged Jared again quite a while later and I said, hey, the book's been published.
It's been out for a year.
I don't know why I did this because generative AI, I can ask it any question and it's probably going to give me a, I can ask it to write the book.
and it's going to do a better job.
I said, it's a bit of a strange place to be now that that's the case.
And we had a bit of a chat about it, but then I bounced back a message a little afterwards saying, it's not a big problem.
It was fun to do.
It's about the process.
Some people still love reading and love reading stuff written by humans.
But also I said, when I wrote the book, coding agents weren't a thing.
In the last chapter of the book, I introduced a little tool.
In the shell, you give it a question, it gives you an answer, just connects to an LLM.
That was quite cool for me because I could use it to write shell commands.
And I thought that was kind of funky but geeky.
And then Clawed Code came out and it kind of feels a bit like the world changed.
Suddenly, people were saying, like, this thing's doing amazing stuff and it's literally just sitting there doing like bash and grep and ls and cut.
And it's taking these like simple tools and it's doing crazy complex stuff.
It's taking video editing tools now and it's editing video and it's downloading things from the internet.
And then I kind of realized that's kind of interesting because even the most modern technology has still gone back to that principle of you take small, simple, well-understood tools that you can kind of pipe together.
And from that, you can build complex processes.
And I thought those are a really good example.
And I don't know.
I don't know exactly how it all stitches together beyond the fact that almost what closes the loop is I work with teams.
We write a lot of software.
I work with clients.
We write a lot of software.
And nowadays I'm not looking at things like, you know, is the syntax correct?
Is it structurally correct?
Weirdly, I realized I'm looking for things like hacker laws.
Like you ain't going to need it.
This is cool.
Well, the agent's built.
You don't need it.
But also you've got this thing which says like backwards compatibility for X.
that kind of violates the principle of least astonishment, which is it's clever, but we don't need it to be clever.
And I realized that we need to start almost reviewing for those more system level things.
So it's a weird little arc.
It's a weird little storyline.
I don't know if any of it actually makes sense.
But when I was thinking before the show, I'd realized there were all these little kind of connections between things.
And it kind of all touches on just how the world has changed.
with AI, Gen AI, and for us in tech, like, agentic AI.
Yeah.
You know, I take that back to what I said beforehand around laws because the one that does stand out a lot to me, because I'm similar, I'm not looking at the code, I'm looking at the intent, I'm looking at the architecture, you know, how the system presents itself to a developer or to an agent.
how easily you can come to reason about the system just by probing it and trying things and failing.
And does the system give you good returns and good responses and things like that?
Because if you're going to try something like, you know, the error shouldn't be like, you suck.
You didn't read the manual.
It should be like, hey, you know, that's a forbidden feature here.
Or you don't have the authorization to do X.
You should try Y.
You know, something, a system that presents itself in that way.
But I started to really navigate around Gaul's Law, which is a complex system that works, is invariably found to have evolved from a simple system that worked.
And I find myself now just really pushing to create the most simplest system.
And maybe it's a greenfield issue.
I don't know, because a lot of things I'm building are greenfield.
They're not legacy, and I'm building on top of things, except for the changelog, the website there, changelog.com.
And there's not a lot of change there because I'm not trying to add new features or do new things there.
So in this case, I'm trying to build the first thing that's simple.
And I feel like, yes, AI can do a lot.
Jenny, I can certainly do a lot.
And it tends to want to really please us.
And maybe by doing certain tricks, and maybe certain tricks are just complexity.
And I'm constantly pushing back.
No, what is the simplest version we can do to learn?
right to see if the system works the right way and so god's law is what pops up to me it's funny you mentioned that i opened a few on my other screen because like like you i forget them mostly i know that certain things exist and i was thinking what's that one about complex things were never invented complex They started simple, they iterated, and they became complex.
And that's Gaul's law, isn't it?
I think it was one of the ones that opened up.
And I love that because with Gen.AI, you can kind of almost one-shot complex.
But then when you start to pick it to pieces, you're like, it's very clever and complex, and it's incredible that you were able to one-shot it.
But this is why that's vibe coding.
Because if I built it from the simple pieces, I can see the end result.
would have been more simple as well.
But also, I don't even know what the end result will be until people start using it.
And then I realize you need to pivot this way or pivot that way.
Yeah, we're really slapped in the face with iteration these days.
I feel like, yeah, you can one-shot a complex system and then it's got no reusable primitives.
So it's got a lot of, it does the single job and that's probably an okay thing if it never needs to be something more than that.
If it doesn't need to scale, it doesn't need to now have...
authentication or authorization.
Like authorization is such a tricky thing to thread through an application stack that, I mean, if you don't think about it early enough, you can spend a lot of time having to rebuild a lot of the system because the core primitives weren't there.
But when you one-shot in that case or an agent one-shot, it's great.
You get a working product for the one-use case, but trying to extend it, trying to augment it, trying to...
curtail it into a different direction.
It's, I mean, it's the agent's problem now, technically, right?
Literally technically.
But it's our problem because it could take time.
Like it's tokens in time now.
And it's, it's our problem because.
I think there are ways to instruct around that.
The thing that I find really interesting is one of the things that my team are building and building it open source at the moment.
It's a set of tools for Kubernetes that mean you can run agents and treat them a little bit like services you deploy and you manage and govern.
And that's kind of nice for some of the regulated, complex stuff we do with clients.
Because there's a lot of governance and controls and things like role-based access control.
There's patterns for that.
But interestingly, the agents will often come and event something.
And they were doing that until we started really forcibly grounding and saying, look, before you invent anything, find three idioms or three examples that show the idiom.
Because Kubernetes has a bunch of idioms for how you do things.
There are standard idioms for how you think about role-based access control.
So if you've rolled your own, it violates the principle of least surprise.
What does Argo or some other common thing do?
And in a sense, that's a bit like saying, what's going to surprise people the least?
If they're using Kubernetes, they probably get a bit about it.
Don't force them to learn new patterns.
It's the same with CLIs.
Like, oh, you've added all these cool flags, but what's the idiom of the GitHub CLI?
What's the idiom of Git CLI or the AWS CLI?
Because if people have got a bit of a mental model that they know that, let's follow that.
It reduces the cognitive burden on them to understand what you've built.
When you say idioms around CLIs, do you mean like dash dash help being a thing or dry run being a thing?
Like these are common things that happen again and again and again as repeated patterns.
Is that what you mean?
Yeah.
Yeah.
Dry run is probably the best example because, you know, LLMs know about that and that's great for them because they do.
And they're trained to know about it and use it.
So if you're doing things like kubectl apply or applying infrastructure or whatever, you get such good results just by the fact that they know if the dry run flag's there, run it once with dry run.
It's a super valuable thing to bring in.
Yeah.
And that's what I mean too about reasoning about these things is when you build systems, you can make them super complex, but if you keep the simple primitives like idioms and repeated patterns that have been there, one, Maybe this dovetails in a weird spectrum of conversation, but it gives me as a human, and it's even strange to say that, maybe I'll say that for one more year and then it will just go away and I won't say that.
Kind of like Happy New Year.
It doesn't happen and right now it's July.
When you think about a simple system, I think about it right now as there's maybe a transitional period where we want to have more understanding of the applications we're building.
And so I want to have...
let's just say human relatable or human understanding in certain things, but at some point maybe because we're looking at the code less and less.
Like it's been less than a year since the, let's just say fire has been recreated, right?
We've been cavemen and cavewomen out here in the world of programming.
Kraken sticks together and Rock's trying to create fire, which is the application stack.
And then here you go with this superhuman genius that can just do it so much faster and better.
How long do we need to understand particular parts of the system?
How long will we care to understand particular parts of the system?
Right now, yes, because we're transitioning.
But what happens once the transition is kind of over?
Do we look at the code less?
Do we care less about the flags?
Do we care more about how things pipeline and orchestrate and less about the potential?
particular details and idioms?
I don't know, Adam.
I feel like I go through a bit of a crisis on this day in, day out.
Yes.
That's why I ask the question.
Some days I get output, and the output I get is because I spend a lot of time grounding and a lot of time building the machine and orchestrating.
And sometimes I get output and I'm like, brilliant, job done for this.
Or at least I get good enough.
because this is a front end or it's an app or it's a mobile experience, it's 80% right for where I am right now.
80% right is fine.
You know, nice.
Check the box.
We pretty much one shot that because the team put so much effort in to tune the machine.
But then if I'm looking at the Golang code, which is the controller for the underlying kind of Kubernetes system, I'll review it line by line.
And some people will say I'm a dinosaur and probably I am.
But for the 5% of things I see there, which are not quite good enough.
One, they're either snafus that will catch us later or they're unexpected things, which will just make debugging harder.
Or two, they're potentially serious problems.
And it's like Pareto principle.
First 80% is easy, last 20% is hard.
And if your model's only giving you sort of 90%, that last 10% is still probably most of your time.
So for the dashboard we're building, I don't really care.
We're not really going to review it because we can fix it very easily.
And the blast radius, if it does something wrong, is by design minimal.
But the authentication mechanism is not.
So there's a kind of duty and a responsibility there to look at it.
But I think the other thing that I see with CodeView, because again, I wouldn't say I get called a dinosaur because the people I work with are really nice.
But I see it in their eyes.
When I talk about still reviewing code or getting my team to review code or my team to review specifications, use OpenSpec a lot.
And I'm like, why do you do this?
You can just do it faster without.
You know, the code's fine.
And the reality is most of the time, if the specs are good, the code's fine.
But I don't need the team to quality control the code.
That's not top priority.
If they do, if they find issues, we can fix the machine and the skills or whatever.
I need them to understand the system.
That's why the review is there for me.
That's why the Passover one person does spec, one person does implementation is there.
Because I actually need us to slow down.
Because when a bug comes in, someone needs to know roughly how the system hangs together.
Not perfectly, but they can't be investigating it kind of almost from first principles.
it's just too kind of risky for us because we're building something very systems level.
So that's like a deliberate slowdown choke point so that we get a chance to keep our mental models in sync for what we're building.
That's a good point to understand the system.
I think that's exactly where my question alluded to is, do we care about particular details?
But then how does the system weave itself together?
Does it give us the outcome we anticipated?
And you can't really get that unless you examine in some way, shape, or form.
It doesn't mean you got to read line by line, but I think in the case of an auth or authentication, authorization, that's an area where if you're rolling it, you're not using a service like one of our sponsors, WorkOS, love them by the way.
If you're rolling it on your own or even the authentication layer, like you can do authentication to a system, but then authorization once you're inside of it, you have to own that as a systems designer.
You can't just like willy-nilly that.
And that will 100% bite you if you're not checking particular permissions or if a command outputs.
Like you have to have a system in there that does those kinds of things.
And that's a part where you really want to understand the system.
Yeah, and understand security as well.
I had a really fun experiment where I built, I found that me and my team were spending a lot of time Zoom screen sharing specifications and using our agents to kind of type in, we want to change this to this, or just transcribing our conversations.
And one thing that I found useful was a little CLI that just beams up your current Markdown file into like a shared online page.
It's using like Cloudflare Party Kit.
You give someone a password, they can open it, they can edit it, they can sync it to their file system and their agent can edit it too.
And then suddenly for the duration of this session, we've got the markdown on a screen and we can all use our agents.
I built that quite quickly for fun.
And then I just let the agents go because this was a hobby project.
And then I said, right, I'm going to do a thorough review of this now.
And the security for it was an absolute fundamental mess.
Now that's not a problem at all with the LLM.
LLM is perfectly good.
The problem was at no point did I tell it I particularly need this to be secure.
I said, I want a password.
So everything was based on symmetric encryption.
Passwords passed around in silly ways.
And it's like naively it works, but it would never pass any kind of pen test.
And in fact, it would be irresponsible to let people run it on their machines.
So I kind of guided it through the process of, right, let's set up asymmetric encryption.
Let's use certificates.
Let's sign things.
let's go through a proper audit on this one.
And of course, well-directed, the LLMs did a great job of the audit.
But it's like that genie in a bottle where you make a wish and you get the answer, but there's a sneaky little thing at the end.
I want to be able to log into this app even when the internet is off and when I've forgotten my password.
And the model will probably give you something that works to do that.
It just might not be something that should work.
This book you wrote...
You said you finished it just before the fire was invented, if that translates well.
Yeah, I hustled at the end to add like an appendix chapter on, you know, generative AI and what it might mean for you as a shell user.
And I said, all of these weird like...
flags and command line parameters and stuff, you've got a really good hook on how you can do that.
And I hacked together, which was harder at the time, like a little terminal application where you could kind of pipe in whatever it would be a question and you'd get the result back and you could get it as Markdown.
Or you could stitch it into a pipeline and kind of do like, you know, git diff, pipe into this, summarize the diff, come out.
And I thought that was kind of like a cool example of what you can do if you live in the shell.
It was very simple and janky.
And I said, like, watch this space, you know, see what people come up with.
And that was a little bit before, or I think it was a little bit before.
Certainly it was before Claude Code.
Not suggesting that I invented Claude Code.
I am.
Give me money.
But that's when I was hacking around in the terminal.
And it felt like many other people weren't.
And then, so yeah, that was the timing.
At that time, Gen AI was kind of like...
It's starting to look really exciting and practical, and it's starting to give quite good answers for programming.
But for me, it was a bit more personally, how can I stitch it into my kind of shell-based workflow?
So this, I'm not really sure how I want to ask this question, but I feel like you'd written a book.
Maybe it was consumed by the MLM, and maybe that's why it knows so much.
I'm just kidding.
Not all of it, but I'm sure it read your book, right?
It didn't pay.
Didn't hit the Amazon sales.
I'm not retiring yet.
But you wrote this.
I think it's still an important book.
So just to give you that, I don't think it's not an important book.
And the reason why I think it's still a very important book is I think maybe, maybe potentially in this future we're all driving towards, you mentioned understanding systems.
And I think one of the most underutilized understanding of the system is Linux.
And I think the Unix philosophy and pipes and simplicity and all the laws we can potentially even extract from all of that work.
But to build the next, like if we're kind of still maybe even in this era, building versions of the factory and factory tools for our agentic systems, you know, rather than building and reading the code, we're understanding the system that builds the code.
And it's not going back and...
fixing the code like you said before it's going back and fixing the system that makes the code so we do it better for the next time or it has learning in it we're in this we're in this world where i feel like now more than ever understanding linux or even having a home lab with sure a raspberry pi that's like the most well-known home lab type of gear but just minis forum and pick pick your brand but some sort of like smaller non-server non-desktop non-laptop kind of computer that's meant to run Linux or different workloads or even a GP or things like that.
I feel like now is the time where that has, it's more important now to have that understanding than ever because it lets you dream about the potential of what you could build because everything runs on Linux.
Everything runs in these kinds of systems.
How do you feel about that generalization?
Is that accurate in your opinion or not?
I mean, it speaks to my bias.
It speaks to, I mean, I had this weird journey where I started on kernel-level code in device drivers.
And then my first coding environment was Ball and Turbo C++, so it was DOS-based.
And then when I first got to use Microsoft Visual C++ and an IDE, an interactive debugger, this was like, wow, I'm never going back.
And I was doing that for a few years as it went to .NET and stuff.
And then I started doing Node.js, and I was like, I don't need all this complexity.
I decided, you know what, I'm going to try Vim because I've heard it's good.
And I struggled for two weeks.
And then I was like, kind of not going back.
Because if it's too complex for me to kind of manage in my brain with Vim and Tmux, it's just too complex.
So that's why I don't do Java.
There's so much folder structure and nesting that like, for me, I just don't find it very intuitive.
I really like to know JS because I can kind of see what's going on.
But to the whole Linux thing, as soon as you start building, Outside of your own computer, you're deploying to AWS or Fly.io, or you need to have a Docker file, or you want to SSH to somewhere where you're running something else.
These commands become kind of essential for you to just break out.
And then look at what you can do now.
You can SSH into the box you've got, you can run your agents there, you can tunnel things back.
You look at the agents like kind of tool calls.
and you can see what they're doing.
Okay, it's doing an LS, and then it's grepping for results, and then it's doing a tree into there, but it's limiting it to three levels deep.
And whether that helps you steer it or kind of control the trajectory or not, certainly you can just see all these things that are happening.
It's like listing my SSH keys.
It's trying to do something.
Maybe there's times there where you do start to hit escape and say, okay, hang on, you're running the AWS command now.
Let me just pause it because I need to think.
What credentials has it got?
It's like the lowest common denominator, but I do feel the fact that Claude and then all the other coding agents like OpenCode and Py just had this realization that we can just stitch together these things.
Some of them are like from 1960 or 70 and have barely changed in terms of their behavior.
You can stitch them together and do incredibly complex stuff.
And it's a real celebration of the Unix philosophy.
simple tools composed together into pipelines, allow you to build complex things.
And it's a huge unlock to run things on different machines and just experiment and understand what's going on.
I felt like it was the same with Docker.
Docker exploded in popularity.
And then there was this moment for a lot of people where they're like, oh, but I kind of need to know what's in a container.
And I need to have a user and I need to mount something.
There's a bit of initial hassle there.
But once you get it, you're like, cool, I've got these little machines that I can go into and run the internals of.
Yeah, and the blast radius is minimized by nature of a container and Cgroups and all the things.
Even that, you mentioned Docker, and I know that you're smart and you know that Docker did not invent Linux containers, right?
You know that, right?
Yeah, you had Solaris zones and all the proprietary ones before that.
Yeah, but they popularized containerization.
And so in many cases, and if you're a developer today, maybe a newly minted Vibe Coder, welcome, by the way.
Or if you're a tried and true developer, now an agentic developer, also welcome.
But by the way, Docker did not invent Linux containers.
And so you can go and learn these primitives yourself and understand LayerFS and all the parts there that allow Linux to layer.
And I think even then, when you understand that level of thing, you don't have to depend on, I mean, you can depend on Docker and containers, and I'm not saying you shouldn't plan that ecosystem, but you shouldn't assume that that's the only access you get.
To get Linux containers, you must use Docker.
That is just not true.
But I think understanding those systems there is just really pays dividends, right, to understand what you can do with Linux to that level.
It lets you reimagine.
You said the word pipeline.
I feel like pipelines, deterministic pipelines will become the next biggest thing.
You know, that's how I feel.
The Docker thing is interesting.
I can't remember who did the course, but there was a lovely, I don't think it was a paid thing.
I think it might have been a set of blogs, a blog post, but it was literally build Docker from scratch.
Totally like you say.
the Linux-level primitives, the kernel-level primitives existed.
And you kind of realize as you go through, like layered file systems and stuff like this, these aren't new inventions.
It's just put together in a convenient kind of batteries-included package.
But yeah, you're totally right.
I kind of want to go back and do that course now because it was surprisingly quick to build Docker because the key pieces were there.
I want to go back to that course with you.
What is the course called?
And do you know the URL by any chance?
Let me do a search when we finish off and I'll find it and send it over.
Because I thought that was a fun one just to almost demystify it a bit step by step.
Yeah.
You know, like how do you essentially create a virtual file system or how do you allow yourself to start creating new users from user zero onwards or whatever?
There's so much you can do there, really.
That's kind of where I'm camped at.
It's like I want to understand Linux primitives.
I want to understand Linux pipelines, effective shelling, as you've written.
I want to understand architecture things.
I want to understand certain laws that help me keep simple systems.
How do I speak to an agent that helps them translate that?
So if you have all these laws, so thank you for your repo because you've given the agent something to anchor to.
So when I say X, Y, or Z, that...
references a law or an idiom or whatever it has your corpus to go back on to to give it some validity and truth but that's that's kind of where i'm camped out at is like i want to understand things that help me build the machine that builds the machine not just the the software i'm creating i'm actually creating software around the software so the software we get created has maybe more determinism you know in a non-deterministic world we need determinism and that's that's where my mind currently is is just sort of like stuck obsessively on repeat is those types of things, those types of systems, not just the code base that I'm building itself.
Yeah, the machinery around it.
I'm with you on that one.
Something that is interesting about Docker for me was I'm a big kind of SRE, Kubernetes nerd.
I like build and monitor.
I like to kind of operate and run.
It was my colleague, Roman Kaliev, kind of called me when we were doing some stuff and said, hey, what about this?
you know, we're talking about a runtime to run agents.
He said, what about Kubernetes?
And I was like, oh, and then like we had a quick chat and then I hung up and then I was walking around and I started thinking like, okay, so you've got like resource management, you've got all the monitoring tools.
You've got the whole idea of like scaling up and scaling down workloads.
You've got fine grained permissions.
You've got being able to run on any cloud.
You've got admission policies that will allow you to only admit things on certain levels.
You've got secrets, you've got secrets that can be backed by HashiCorp, by like Vault and things like this.
You've got a very rich ecosystem and it's all about managing, it's all about resource management, kind of in enterprises.
It was a genius idea that you had.
Because it spoke to what I've been speaking to some people about separately before, which is agents like microservices.
They like microservices, but they're quite smart.
So typically we want to constrain them, think about the blast radius, what they can do if they start to do too much, shut them down, limit the CPU and stuff.
But again, it's the tools, it's the machinery to build your stuff within.
Yeah.
Are you speaking to...
Is that what you're talking about?
Like when you allude to certain details around Kubernetes?
Yeah, that's one of the open source projects we have.
Can you speak to that?
I'm really interested in that too because I think that I'm not traditionally a Kubernetes dude, I guess.
I haven't played a lot with Kubernetes, although I'm quite well aware of how it works, but I've never actually been an operator of a Kubernetes system.
But I think...
I want to know more.
I want to know more about how you're agentifying Kubernetes or how you're running agents at scale via Kubernetes.
Yeah, so the history on that one was we had a solution that we brought to lots and lots of clients that allowed you to kind of model agentic workloads.
You had agent steps and you had teams and you could kind of configure them and their system prompts and the parameters you pass in.
And then the guy who created it, Chris Madden, who was also one of the creators of Arc afterwards, had this really nice idea, which is called transformers.
And transformers were like Python code that you could put in your pipeline that would kind of take an input and spit out an output.
And the reason he did that, he and Chi Wei-chung and the team did that, was because a lot of the time they wanted deterministic steps.
They don't want to say to an agent, read this folder and do X.
They want to say instead, a bit of Python code, list the contents of this folder, and then for each one, fan out an operation.
And it was really cool what they built.
And interestingly, there came a certain point halfway through the project where a client started saying, what about MCP instead?
And MCP kind of gave us the replacement for transformers.
It was a way to kind of like call deterministic code, but give outputs in such a way they work well for agents.
But they'd already kind of cracked that nut a little bit, which is that you can't just throw a team at something.
To do anything meaningful, you need a process because a process is predictable.
It has your breakpoints, your opportunities to kind of observe it and control it and make it more deterministic and predictable.
But what people loved about that was they liked exporting it to YAML.
exporting the agent definitions and the workflow to YAML because then they could play around with it, they could get their LLM to look at it, and they could dump it back in.
And that turned out to be a real success of this.
So when Roman came along and said, why don't we use Kubernetes?
That seemed to me like, okay, this is just the right tool for the job.
So much stuff that we need is there out of the box.
I had a call with my product manager a couple of days ago, and he's like, this client needs to know which person created which query and who edits it.
can we get this out of the box?
And it's like, yeah, we've got audit logging.
It will tell you the resources that have been created and have created them.
And it's like, I used to hate Kubernetes.
I really love it now because it's basically solving problems because it's resource management.
So it's hiding quite well because we were like, well, all of the agentic workloads we're building are YAML.
They're parameterizable or templatable YAML.
It's system instructions, it's tool associations, it's kind of parameters.
People love the fact they can treat it as text because they can put it in a repo.
So you don't need to use a Python framework to run an agent loop.
It's easy to read.
It's better than gibberish, for sure.
Yeah, and you can do GitOps, you can do infrastructure as code.
And then for the kind of clients we were serving, we need to run in prod.
And to run in prod, the lowest common denominator is normally a kube cluster somewhere on whatever their cloud is.
So these things fit it together very well.
And Arc is kind of boring.
It doesn't give you this kind of like sexy workflow building type thing, but it allows people to define agents as YAML or define agents that run against anthropic SDKs, put them all in a Git repository, and then fire them up into a cluster, kind of almost in the same way that you deploy microservices into a cluster.
So for our clients who are in more regulated environments, all of that kind of GitOps and all of that process and control around it and the fact that all of their existing monitoring tools work and the fact that for their site reliability engineers, it's very familiar.
It's like, okay, I've got services and I've got secrets and I've got agents and I've got models.
It's just another resource to manage.
So it's kind of geeky.
It's a lot of fun if you're into kind of like DevOps.
And it's low-level tools.
It's tools that you add to a cluster to help you build other things on top.
Yeah.
Could you walk me through one of the EAML examples in the repository?
Would that be too challenging?
I'm looking at the examples section.
I'm not even sure that's the best one where you have demo namespaces.
I just want to walk through a little bit of that.
Let me just open one as a map.
So this is my repo that I use to kind of like flash out a bunch of agentic resources to a clean cluster.
So if I take a look, I've got things like MCP servers and some of them are really simple.
So the Notion MCP server, the top part of this is just the description.
And then underneath, it's an MCP server.
I've got some metadata, which is like its name and an icon.
It says where it is.
It's got a reference to a secret, but this is nice because it's a Kubernetes secret, meaning that it can be handled properly in production.
It's got a transport, a timeout, and then a reference to a secret.
So, so far, nothing too unfamiliar to someone who's used to doing kind of like Kubernetes stuff.
If I take an agent that uses that, so I've got my notes taker, this agent just kind of looks like this.
It's got a name.
It's got a description.
It's got a configurable model.
And then it's got its system prompt, which is you use the Notion MCP tools to read and write notes in Notion.
And then it's got tool associations.
And there's other stuff.
There's clever things.
There's Argo workflows and whatever.
But in a sense, that's the gist of it.
An agent typically is a reference to a model, a system prompt, a set of associations to tools.
And then a set of permissions potentially as well.
And I've got teams who are building evaluations on top of that and so on.
But that's quite nice.
That's something you don't even need to use Python for.
You can just make that YAML.
There is even tools like Helm, which allow you to deploy and version control YAML.
So that pattern has worked quite well for us.
There are still loads of other ways to do it.
We also run agents in containers which are just using the Claude SDK.
You can use the Claude SDK through Arc.
Or someone might...
build something using like Langchain.
But when you build something in Langchain, you can put in a Docker container and run it in the same cluster that ARC's in as well.
So you still got that same, whatever you'd call it, substrate or whatever, or bedrock to run it on because the cluster's there ready for you to go.
It's not as fast as just sitting there and writing a loop using Langchain.
just on your machine as a single process.
It's way faster, it's easy to do, it's going to get you quick results and so on.
There's no problems with you doing that and then putting it in a container and run it in prod.
This tends to work well for, we need lots of agents with lots of instructions, lots of tool associations.
We need to manage it, version control it, two pairs of eyes, a bit of an audit trail for who changed what.
Where do you see this going then, this kind of Arc demo and the things you're doing with it?
Help me understand the bigger vision.
I mean, I can understand how an individual developer, maybe a team of developers are using agents, but this kind of orchestrated system, like what does that kind of system do?
Like anything really, but like, what are some of the initial ideas you all have?
I mean, to a certain extent, it's infrastructure and tooling.
We don't need it to necessarily do a lot more than that.
We need it to ideally support the capabilities of different types of models as they come out, so skills and things like this.
But it's not a product.
It's not something we're selling.
It's just a set of tools to help you build interesting stuff.
So it's out there.
It's open.
If people wanted to use the same format, there's another project, Cajun, that does something very, very similar.
YAML definitions for agents.
It's a really good idea.
We like the fact that people can run it in whatever environment.
that they want.
You're not necessarily locked into one hyperscaler or another, but you're certainly going to be able to use any one of those hyperscalers quickly.
So there's features that we're building.
A lot of them are more around governance because clients are running sensitive workloads and they want as many features as possible for explainability and observability.
But I'd say most of the team's time is building the stuff on top of it.
You know, it's building the use cases to run different kind of agentic workloads.
And off the back of that, things will fall out like, hey, we need better granularity on certain types of information, or we need to be able to kind of run multiple versions of X in the same tenants because we've got a policy around that.
Has your view on open source changed at all in this transition we're in?
It's changed in that it's less fun.
Oh, man.
I interview...
So many smart people.
And I love looking at their geeky hobby projects.
Because the days of like geeky hobby projects in people's CVs, often they're things they've put some love into.
You know what I mean?
It's like a 3D game or it's this or that.
And I love seeing that because it's fun.
It shows that people have got curiosity and playfulness and they want to learn.
Sometimes I feel a bit of a sense of grief because those beautiful things that people created may be tinkered with over months.
Next to that, you've got something that someone one-shot that's a really cool idea.
I mean, I do this myself.
My ideas I just throw into open source.
And that's not a big problem, but maybe it's just a little bit of that grief about how the craft has changed a bit.
And some of these things that people have created could be created much more quickly now.
So be it.
That's what tech is.
Open source is also a place for people to publicize.
It's also a place for people to potentially pollute and try and, you know, growth hack their own product by making lots of things to it.
So I feel like it's become a more complex space.
It's a space where LLMs have a preference for certain types of technology and patterns because the corpus of training data says you should use BUN for this.
You should use, you know, whatever it is for this.
I don't know, Adam, what do you think?
I mean, you talk to so many people.
How do you feel about this?
My ideas on open source change, I suppose.
I'm not really sure.
I'm still torn.
I feel like I ebb and flow so frequently that I don't have a good rudder for how I feel.
I just know I'm sort of this way and that way about it, I think.
Licensing can't protect you if you're looking to license as a protection.
But I think if you're trying to open source, if you're trying to be on the developer side of open source, where you're just a developer with an idea, like you said, a hobby project, totally find MIT those things.
You kind of want to give those things to the world for distribution, whether it's your name, your brand, your ideas, or just making something that's useful to just you, not just you have strangers using your code.
And you got this sort of shift a little further.
I'm not sure if it's left or right to that.
I don't know.
Pick your direction.
But you got indie developer, hobby project, but then you got company or something that could be a low-level primitive for a company to build on.
And how do you reason about open source there?
Well, it's been a struggle for the last, I don't know, decade or more maybe even, but for sure the last decade to eight years, a serious struggle with, rug pulls, license changes, or even just nefarious behavior or not so hacker-friendly, open-source-friendly behavior from company X to company Y, and then you've got change there.
So this has been going on for a while, but in the era of LLMs and agents where you don't even have to copy somebody's code to copy their idea or to learn from it, which maybe is the best thing ever.
I don't know.
I really, if you can't tell, I struggle deeply with this because what does it mean to open source these days?
From a developer side, hobby side, totally clear.
I want to give it to the world, clear.
But then when you move a little to the left or right, whichever direction you're trying to go towards something beyond that, commercial or commercial-esque or a primitive of commercial.
How do you protect your moat?
What moat should we protect?
Things are moving so quickly.
I'm like, Claude or OpenAI is going to cannibalize most developer tooling.
Are they going to be the gravity, the black hole level gravity, pulling everything into the agent interface?
I think OpenAI has got some really cool...
Things about them, they seem to be opening more with the SDK and the codex server.
I'm doing some cool stuff with the codex server right now that's letting me do like steering and turn-based stuff that's pretty interesting.
And you can spin up lots of agents in that case and do it from the CLI.
And they seem to be most open by it.
But I feel like it's just such a strange world to be open source in.
And then you got your code out there in open source.
And you've got cybersecurity concerns now.
Well, now because an LLN is so skilled, you can find the loopholes and the issues in, I mean, this is an absolute bloodbath of sorts in the NPM ecosystem, for example.
For sure.
It's just everywhere.
So I'm not sure how the reason why this works now.
If you're maintaining a package, you can get the features out quickly.
So the velocity of change for every one of the packages is already super fast.
So the scope for challenge, like everything in your supply chain is changing quickly now.
So that's, that's, that's like, we got to the point where we were spending like 25% of the engineer's time dealing with CVEs, you know, vulnerabilities as they get exposed.
We deliberately open sourced to expose ourselves because otherwise our clients take the code and they run their own scanners as they absolutely should do.
And if they find something that's wrong, quite rightly, they're like, what's going on here?
So we're open.
We run all of our scanners.
We're public about how we do that.
We do our very best.
We kind of have an SLA around it.
But also we're open to scrutiny.
We're also open to the fact that things could scrutinize this, find issues that we won't know about.
But in a sense, that risk is there anyway.
At least we're quite public about our policies.
But yeah, you're right.
It's a bloodbath.
People are stealing each other's stuff.
People are taking great ideas and promoting them as their own.
I don't know what the future holds, but being something of a cynic about...
when it comes to, say, capitalism, how long is it before someone who's running a project, commercial project that has an open source angle, potentially start saying to the Frontier Labs, how much would it cost me for your LLM to prefer my solution over others when people are making architectural decisions?
You know, and I'm not going to name any company's names here because I...
I get it.
It would be a business model in the same way that Google will rank certain destinations higher when you do a search.
That's how they monetize that.
The LLMs have a lot of influence now into making architectural decisions, some of them very consequential architectural decisions.
If you're working with a bank and some of your advice is coming from a model, that's potentially going to lead to a very consequential long-term relationship and decision.
Yeah.
You may choose to build something versus buy it when you could have just bought it or bought the open source version of it.
That's what I mean by build versus buy it.
Like use somebody else's thing.
Literally buy it or get it for free via open source.
You may find yourself, if you listen to only the LLM in that case, with a preference.
And then because now we sort of like forfeit or we're in this world where forfeiting our reasoning or our decision making is becoming almost second nature.
to some folks, where you can be down the road like, yeah, let's build that.
It's like, no, no, no.
We could have bought it.
We could have bought it.
And we could have had this hardened version, aka called Bash, right?
Like you said this yourself, LLMs didn't go and reinvent the system.
They used the exact primitives there.
They didn't have to reinvent Bash and pay the price.
Bash has been hardened and used and it's everywhere.
Like a .sh file is everywhere.
So why?
why would you reinvent it?
Right?
Yeah.
And it is tested to absurd degrees now.
Absolutely.
As is like, for example, you know, but like build by versus bias is a really interesting one.
Cause that's another one of those model biases, isn't it?
I guess you've got hacker laws, but also like model biases.
These guys, these guys build stuff like, They're down to build.
Nobody's business.
DTB, not DTF.
DTB for model, man.
Like down to build.
Let's build it, okay?
Yeah, absolutely.
It's like, okay, I can do this for you.
We can put a cache in front of it and we can put a cache in front of the cache and all of this is extraordinarily clever.
We can do this.
They're hyping you up too the whole time.
Like, yes.
Yeah, like I can do everything.
It's like you can eliminate 10,000 lines of code if you just put it on CloudFront.
We're okay to use CloudFront on this one.
Yeah.
So that tendency to build versus buy is also one, because then it touches on tech that a junior developer might not know that this is a solved problem.
There's three or four different solutions out there that cover this.
You don't need to create your own complex file storage thing for these big files.
If you use an S3 compatible interface, almost any production environment is going to have something that will talk S3.
So don't stress it.
Don't reinvent it.
You know, that's kind of a solved problem.
But you do see a lot of like very hyperactive.
Wow, we've created a bunch of things here.
80% of them are solved problems.
Yeah.
Yeah.
Well, friends, I'm here to tell you that my friends and maybe your friends too over at the CNCF gave me a very generous discount to give to you.
Use the code changelogpod when you register for this year's KubeCon Cloud NativeCon in Salt Lake City, Utah.
It's happening November 9th through November 12th.
And I want you to go.
AI agents, they're changing everything.
They're changing what we ask of Kubernetes.
Take identity, for example.
When an agent calls an API, they run some code or it touches a database, who's actually authenticated for that action?
Well, Abdel S.
one of the chairs of the conference, tackles this very question in his keynote, the identity crisis.
Who is the AI agent in your cluster?
And Jeffrey Sika steps back with Cloud Native, built by humans, engineered to evolve, and he's looking at how the open source community adapts to AI.
And Lynn Sun asks, Cloud Native without limits, what can AI agents do for us?
This includes agents that help debug, and operate real systems.
So if you're planning to attend, as I mentioned before, deep discount, generous discount, think early bird pricing.
I asked them to give you something special and they agreed.
So the code to use is changelogpod.
Once again, changelogpod, all lowercase when you register.
Head to kubecon.io, that's K-U-B-E-C-O-N.
select the North America event, check out the schedule and register and use that code.
It's a deep discount.
I worked so hard to give you that and they agreed.
So use it once again, kubicon.io.
I was thinking about, uh, don't get mad at me with this one.
I was thinking about putting on the spot.
Okay.
Given your, uh, expertise and, uh, lack of beard, gray beard.
I'm not even sure that's a pejorative or not, but I just mean that you've got some history and some skill and some experience when I say that is what I mean by that.
Could you invent a Kurz law right here, right now, given where we're at?
Is there a law or some sort of thing on repeat that you can coin in this moment?
Or is that too much pressure?
Yeah, it's too much pressure.
Okay.
I mean, maybe I would just brain fart the thing that I think...
is the biggest challenge I see at the moment, which is the limiting factor to build and scale what you're creating is your ability to synchronize the mental models with reality of what the team is building.
And what I mean by that is one individual can go incredibly fast because they can keep their mental model, their intent up to date with the output.
Although actually you wake up the next morning and what you built yesterday, you were a bit like, what was this?
You get two or three geniuses working together and they can create their own palaces through the day.
No one's going to have a chance to know what each of them does.
And very few people will have a chance to know what the aggregate system does.
And we had breakpoints in the past.
We had the code review, the product discussions, the debugging, the bug hunting, all this stuff that forced us to kind of like, okay, build the mental model like, oh, I see there's a thing here.
I see there's like a gate here.
I see there's a reverse proxy there.
I didn't know that before now, but my mental model is close to what the system is.
And I think individuals go first.
And I think the limiting factor for teams to go at scale is a shared mental model between product, strategy, tech, design, SRE, and the actual reality of what you've created.
Wow.
I kind of just want to pause for a second and just like steep myself in that.
Dude, you did a great job.
OK, you were like, no, I can't do that.
But you just did it.
OK, you just cursed law to us.
OK, let's put that down and make that a law because that's so true.
I find maybe this is always the case, but I'll hit a state of flow like deep in the session.
And it's usually right at the end.
I feel like I've got that mental model.
Like I like team of one can scale really well.
Like anybody, I'm not building one thing.
I'm building several things because you got to wait here.
And so while you wait, well, you're not going to do a five minute task.
It's too impossible.
You got to do multiple things.
Right.
And so keeping this mental model and maybe even if you're building multiple things, they coordinate together.
They orchestrate together.
There's maybe one sort of center of gravity and everything else is sort of molding around that maybe.
Or maybe you've got a project and you're doing these kind of things.
But I feel myself at the end.
Or sort of like right at the tail end of a session, I feel like I've got a very clear mental model, but I've got to end the session.
Like I just, I have to.
And it's everything in me, everything in me to force myself to step away.
And then I come back the next day or the next session or whatever the time is.
And I got to rebuild that mental model again.
That's always how it's been.
But yeah, that mental model, how the system works and what your version of it and the true system version of it is.
how things fit together and where you're trying to go.
Like, unless as a team, you have that.
Individually, it's cool.
But if the whole team doesn't have that, when they're in that state of flow, good luck, right?
Yeah.
And it doesn't make for a happy team.
I talk to so many engineers.
Conversations are always a bit like, you know, when you say, how's it going?
There's this kind of like slight grimace of like, yes, it's good.
It's good.
It's good.
And they're like, yeah, but it's busy, isn't it?
And they're like, yeah, it's busy because we're all creating and the product teams are creating the customers looking for new things, marketing, we're able to do more stuff.
Like it's going so fast.
And you know, the first like steam engine people got in it, it was like 15 miles an hour and they thought they were going to melt or something.
So maybe it's just the same for us.
Maybe we can, maybe we can handle this.
But it's just got absurd.
I mean, and I did a conference presentation a little while ago.
I have bipolar disorder.
And the topic of the conference presentation was how AI can dysregulate you if you already have this sometimes inability to manage your emotional state, particularly arousal and excitement that can then lead to kind of cascading behaviors.
Because, yeah, very fast context switching, hyper creativity, this grandiosity of I've got this idea and I can turn it.
into reality and that's addictive and i'll stay up all night doing this and then i'll stop doing other things there's it's an exciting world but there's also all of these kind of maladaptive behaviors that we kind of almost have to check ourselves on and say is this good are we still connecting with our colleagues are we paying attention to them in calls or are we but there was a little thing six months ago where every so often like someone would just say are you clauding in meetings yeah and people would be like yeah I love the fact that you use the word maladaptive versus bad.
You know, like someone will say bad, but maladaptive is actually maybe the better term to use in that kind of case because it's like, it's not good or it's bad.
It's just sort of in there as a different case though.
But I'd caught some of your talk, not all of it.
And I was actually not sure if I wanted to talk to you about that talk because it hit so close to home.
And I was like, Dave's going to come on here and tell me about your disorder for one and how that affects you and how LLMs exacerbate that or what you have to do to protect yourself or what systems you have in your habits, in your flows and stuff like that to sort of kind of keep you grounded to reality.
But since you opened it up, I'm happy to do so.
But yeah, I listened to some of it and I was like, okay, Dave, you're really getting me here.
So what, beyond the talk yourself, like what, and then even your own exposure with, is like how, I don't understand bipolar to know what the spectrum is.
How do you describe, you know, where you're at on that disorder spectrum?
And then.
How do you pay attention to other humans, I guess, given your acute awareness of, you know, I wouldn't call it LLM addiction or something like that, but certainly, you know, certainly something where you feel like you're constantly being able to have those highs and those extreme lows pretty rapidly in today's world.
How do you map the bipolar disorder and then the fact that LLMs give us?
slot machine like tendencies in today's age?
It's a good question.
I mean, I think in some ways going through the experience of learning what it can be like when things really start to get out of control and spiral, and then how difficult it can be to transition onto a plan that will start to manage that and accept the consequences of what that plan will be in terms of what you can and can't do with your life and the different states you'll be in potentially through medication or whatever.
Sounds hard, has been hard, but also in many ways has left me a more well person.
Because I know that certain types of behaviors or whatever that I see in myself might be warning signs to say, right, you need to have a bit of an intervention here.
And that's left me with some habits which are very, very good.
For example, like you'll almost never see like an open source contribution come out of my laptop after, say, 6 p.m.
Because I pretty religiously shut down the laptop and I don't do anything creative.
Not because I'm tired, but if I do, I'll just like...
zap into it and then I'll go stuff and but I won't get anything done because I'll have like three or four things going through my head and then it starts to get confusing and you start to struggle to sleep and you have all of these spiraling problems but I'm aware of that and I know or at least I have a wellness plan to help me think about well what do I do I do need to disconnect and if I see that behavior happening it's it's a sign and you know I use the word maladaptive say maladaptive creativity when creativity becomes all consuming and at the cost of other things creativity is good, but it can also be, you know, there comes a certain point or in certain circumstances where it's not an adaptive behavior, but it's a maladaptive one.
So in a sense, having an awareness of the condition gives you more tendency to introspect.
And then the gist of the conference was, you know, you see some of these maladaptive behaviors in other people.
And I kind of thought if I saw that in myself, I'd be getting the red flags and saying, okay, I need to either distance myself or I need to spend more time with other people and less time alone, or I need to kind of validate what I'm thinking.
And I think it covers, it talks to many, you know, neurodivergent conditions as well.
LLMs are very good at feeding your grandiosity and feeding your ideas.
That's a great idea.
What about this?
And if some of these ideas are not good or not grounded in reality, a normal human being might sort of, help you there a bit like okay you know i get it but maybe not this you know they'll kind of ground you a bit whereas the llm might feed into your fantasy or feed into your delusion so these are like unique um i guess side effects or things that we're just going to have to learn what it means for us and how we get maximize the good but manage the potentially harmful yeah neurodivergent uh It makes me think ADD, ADHD, bipolar.
And you often see this even, you'll hear a common phrase now, I got a touch of the tism.
You'll hear this out there.
I don't know if you've heard this or not, Dave.
And that means you got a touch of autism.
And most entrepreneurs or most creative folks who do something very big, like an inventing thing or creating systems or.
System architects, they tend to be neurodivergent.
They tend to be a touch of autism kind of person.
Not that they even have autism.
I'm not trying to play down or not pay any homage to or any respect to that disorder.
But you got people out there that are already on that spectrum of hyperfocus.
Some might even say manic like you mentioned in your talk.
manic focus where you just obsess and sometimes you get some really great things out of that like i i think about things like uh bell labs and creating unix and maybe even like linus when he first invented linux or maybe even like steve jobs when he and was were early bored like they were obsessed and great things came from it so how do you how do you reason about in this age When you have this superhuman ability that was never there before, it's very hard to not lean in.
And I think maybe friend groups, like you mentioned, rules like nothing past 6 p.m., guardrails in your life, and other humans that sort of speak into knowing who Adam or who Dave is that can say, you know what, Adam or Dave, you're...
You okay?
You know, checking you a little bit.
Even for yourself, slow down and check yourself as a core DNA of the changelog has been if we're moving too fast, which is a good thing.
You want to move fast, but not to the point where you break things.
Like, don't move fast and break things.
Move fast and do well things.
But if you feel like you're over the skis a little too much, slow down and check yourself.
is what we've said around here.
I soapboxed a little bit there, but yeah, it's such an interesting time to be a neurodivergent person building with these kinds of tools and the responsibility you have to have to remain well mentally and still persevere and do your job.
Yeah.
And I think some of the strategies, and thank you for sharing, I think you articulated that really beautifully.
I think, What I like about this is that some of the strategies are just universal.
The one that I also know is important is just simply integration, which is complex things.
For most people, you need time to let that kind of process in your head.
You might not know you're processing it, but that's why going for a walk might make you feel more relaxed because this thing is bubbling in there and it's just in your brain and it needs some time to...
to process.
I mentioned grief, looking at CVs, you know, grief is something we need to process.
Grief about the craft we, we know and love and grew up doing kind of changing.
It's exciting, but you know, change also can, can lead to grief and that's okay.
That's natural.
That's human.
But the idea of integration is that when you have those thoughts and feelings, you'll need time to just be at.
be with them for a while not necessarily solve them but just let yourself be there and if you're always busy you're just accumulating this stuff that needs integration um but giving yourself space and time to just say i'm just going to go for a walk i'm just going to go and do something and none of this is there and my mind might be really really busy but that's okay because it will almost wear itself out But I think sometimes we're building these backlogs of things that need to be integrated, interpersonal experiences, you know, the things that we're seeing, the things that are changing, the things that we're learning.
But so much input is coming in.
And maybe often our lifestyles are not structured in such a way that we have enough time to counterbalance that with integrate the experience.
Also so that I learn from it, all this cool stuff I've learned, but I still need time to kind of categorize and sort.
Yeah.
This talk that you gave, uh is that a first for you to kind of go i would not say real but that's kind of real talk have you is that a first real kind of talk yeah for you yeah yeah what made you maybe it's courage maybe it's just an idea but what made you feel like this talk needs to be out there i need to share this idea i need to share this thought pattern what made you do that it's a friend of mine um who leads to near from actually keen, who got in touch and said, hey, would you be up for putting a submission in for this conference, AI Dev Days?
And I said, it's short notice, man.
And I'm doing a lot of stuff, but I don't think I can structure it into a way that's going to be interesting because I'm looking at the speakers and everyone's talking about skills and context management and loop engineering.
All of it's great.
And so I don't have much to add to the party on that one.
But then I thought there was this thing that's been bubbling in my head for a while, which is some of it a little bit of concern for the people I see around me and some of it just a reflection on my journey.
And I thought I could probably put something together fairly quickly.
And it doesn't matter if it's a bit rough and ready because I think people would understand it's an authentic discussion.
And I'm not selling anything.
I'm not here trying to sell you my framework, which does skills better.
I'm just sharing some observations.
And I thought those thoughts have been bubbling in my mind for a while.
And I think I'm okay to kind of share them.
You know, I'm not going into tons of personal detail about, you know, particular incidents, but maybe talking about some things that it's good to keep an eye on, but also strategies for keeping an eye on it.
I was nervous, but I felt a real sense of relief afterwards.
And I had some really lovely kind of comments and one-on-ones and people reaching out to me saying that they enjoyed it.
And that was lovely.
That was a really positive experience.
Do you think anything would come from this?
Did you get any people reaching out to you?
Because this is kind of a, especially in an AI days kind of conference, you're not going to, like you said, loop engineering, context engineering.
You're going to hear those kinds of topics, right?
Was anybody like, hey man, read the room.
Don't feed into the fact that we're all in the psychosis.
Let us just enjoy this superhuman strength we have and shut up for now kind of thing.
Or were they like, oh yeah, oh yeah, you're speaking, you're touching a nerve on 80% of the people here, right?
Like what was the response like?
Well, the room self-selected for people who'd be interested in the talk.
There's a few different tracks going on.
So the people who just wanted to, you know, do look at skills and so on, obviously went there.
So I think my room was fairly small, but I would say that the kind of theme of the comments I got was I didn't really know much about bipolar disorder.
I thought that was really interesting.
Thank you.
I got the theme of people saying, quite a few people saying, I live with, you know, person X or I have family member Y.
And sadly, most of those comments were around, like we really struggle as a family to help, help this person.
But I also got a lot of comments from people saying, I find it tiring too.
You know, the things you were talking about, like the pace of it, the change, the anxiety that comes from am I falling behind?
A lot of people saying that.
Because I think for many of us it is like that.
It's so exciting.
It's so exhilarating.
But you look at the substacks that come in and the podcasts and the papers and you're like, how can I even begin?
to position myself as credible in this space when there is so much changing so fast.
Do you feel like the, I don't want to call them 10x engineers, that's sort of like played out, but like the high output folks, the innovators, the ones who not just move fast, but think fast, think big, think in big systems, they think in systems.
Do you feel like, those folks are going to capitalize on this better than everyone else.
And maybe in particular in the software development space, because they have so much experience.
I almost feel like, I almost feel a sense of joy because I'm older, right?
I'm not 20 or 30 anymore.
I'm in my forties.
And I almost feel like this is amazing because I've got all of this experience.
Someone even say wisdom.
I'm not sure I would borderline on maybe.
Sometimes it's wisdom or not.
But now I've got the upper hand here, not the young buck who has the youth and the energy.
I've got the experience and wisdom.
And I know in quotes, in air quotes, y'all listening in audio, I know how to wield this superpower.
How do you feel about that kind of idea?
Do you feel like the folks who've got the experience and the wisdom and the...
the bloody knuckles of different directions or maybe no hacker laws by heart because they've been down the roads?
They're the ones going to capitalize most?
Or do you think it's not as much an old versus young game, but more like experience versus inexperience?
Yeah, I think maybe in a couple of ways.
So I talk to a lot of people doing a lot of interesting things and many of them.
Let's say, for example, Hacks McKinsey, who've gone to do entrepreneurial stuff in different places.
Obviously, we've got a lot of people going to big organizations as executives.
We also get people who go and create startups, scale-ups, or whatever.
And a lot of them are looking for the same thing.
They're like, we know with two or three engineers, we can go blazing fast.
But we need an adult in the room.
And I hope that doesn't sound condescending in that, you know, older is smarter because it's not the case at all.
Like the adults are also stuck in their ways and so on.
But like we need an adult in the room and that we want to go fast as hell.
And we're willing to take on some risk, but we just need to know how much we're taking on so that we can kind of choose where we want to put the scales.
We just need to know, like if someone's doing the payment system, that you're going to give it the stamp of approval to say, yes, I'm comfortable with the approach and methodology.
or you're going to help this team just get through their crisis as they start working together.
So I think it's a very good time if you're an experienced person who's put things into production, or even an experienced person in sales and marketing or operations, to say, yeah, we'll leverage the tech.
But we also know how to apply some judgment on top of that to help think about risk and help think about a bit more long-term.
sustainability so i think there's a there's a strength there and also you know you can look at the code and and sort of sometimes at a glance say largely what's been done here is good but you've reinvented you know you've reinvented something where you could have used graphql you know i can tell that in an instant or you can just tell intuitively this whole backwards compatible thing is a time bomb let's just let's just not do it um maybe that's over selling the kind of It's not overselling it, is it though?
Because you build your experience by making a ton of mistakes and people bring you in because you've made the mistakes and you've learned from them.
But then the young folks, they are going to be like magicians, the ones who grow up with this technology and create it.
Yeah, I'm not sure.
Never in my life did I think I'd be the old guy or the old finger, but now I see.
I just don't know how to predict the future.
I don't know how to think about, like, I've got two young sons, right?
I think about their future and I think about that.
Like, they're pre-AI, right?
They were alive and born and lived in the world before artificial intelligence.
But they're also growing up in a world where that's now native.
It's all foreign land.
This is foreign territory to us because, like you had just said, we've had, you know, a career, 10, 20, 30 years of...
sameness sure you've had some innovations kubernetes compilers you know whatever all the different things in between there i'm like i didn't make a good enough list there obviously but um they're going to grow up in a world where reaching for a i'm not even sure how to describe it anymore like where where we'll go if it's always on like if if there's an agent for everything kind of like there's been an app for everything like here's a Stupid but very simple example.
I now have – I haven't bitten into the open claw world yet.
I don't know if you have or not.
So I'm still like open clawless.
So a lot of my agents or things I have are very like bespoke.
But I have a system agent.
And just before this call, I have a new system I'm setting up, and it didn't have HTOP on it.
And I obviously wanted to like take a peek at the CPU and RAM and system load and whatnot.
And rather than me, you know, homebrew, install, htop, I could do that.
I have a system agent that documents what my system is so that I know how it's together so that later on when I stop thinking about it and I come back to it, I'm like, how are my .files configured?
How are these things configured?
How do we prefer to install certain things?
Like, do I install Go directly from Go or do I use the homebrew version of it?
Obviously, GoDirect.
But it helps me document my choices.
And so rather than install HTOP myself, I went to my system agent.
I said, just threw a command out and I continued working on preparation for this conversation with you.
And I just said, I need HTOP on this system and I need it documented.
And that's all I said to it because it already knows contextually how we're documenting the system.
And I trust it to make a good choice on HTOP because that's a pretty easy one.
Like installing on a Mac system via Hornbrew is pretty much the way to do it.
So I did that.
And that's a simple version of I didn't go and just do homebrew install htop.
I went to my system agent, told it to do it, it to document it.
And now a moment later, I just tab back to terminal and just htopped.
I didn't worry about thinking if it would be there because I said, hey, put it there.
And it was there.
But you're speaking to this feature of where that's the way.
Like a version of that, a simple version of that.
is going to be the way.
Any choice you have, you will have an agent of record of sorts, right?
And that's kind of a scary world to live in, but maybe it's going to be beautiful.
I don't know.
I can't predict that future.
I don't know.
I guess if you looked at someone's .files repo, you could probably do some fun analysis with this, just like find .files repos and see what changed.
Because I've got my own as well, and it's got the worst set of shell scripts to install my preferred stack.
that I half made interactive and half made like adempotent.
So like it will sit there and it will get Node installed and it will somehow get Go installed and it will try to get Java, but Java will be wrong.
And, you know, it will set up TMUX and all of my RC files.
And the last laptop I set up, it was kind of a little bit like update my .files because I want these three MCP servers configured.
They should be in the list of required MCP servers.
Here's a couple of hints.
But I'm not shell scripting that anymore.
The definition of what I want is probably enough, especially because the shell scripts were always brittle and janky.
And that's one of those things where it's a little bit more defined the intent.
And the intent is I want these three MCP servers set up cleanly every time I do a new system.
The idioms are out there enough that I trust you can probably get the job done right.
Although the idioms are only out there because some amazing person.
created homebrew and aptitude and snap and these are works of genius and it goes back to the open source thing as well the people who work on these things do colossal amounts of work handling tons of incoming pull requests and almost universally not compensated from that i can't remember what got pulled out of kubernetes recently it was ingress one of the nginx ingress controls or something and people were like oh we need it so yeah but the guys who were doing it did it for years got no money for it, did it as a passion project.
And, you know, these huge companies were benefiting from it.
Yeah, it's an interesting space we're in now.
Like, so I've, I'm kind of embarrassed to even say it.
I've kind of given up on the idea of .files.
I just have a system agent now.
Yeah.
I don't want to maintain that.
Like, I didn't want to maintain it in the first place, but I did it because I wanted the right kind of tooling.
I only did the .files thing because that was the song and dance we had to do.
to have determinism in a new system or repeatability or understanding my system, for example.
Like that was the closest approximation that we had.
Now I just have a system agent that could be Codex's latest version, GPT 5.6, Sol, whatever on triple deuce, double high, give it to me all ultra style.
Or it could be cloud or whatever it is.
It doesn't matter, right?
Just swap out whatever newest intelligence model there is and my system agent can swap.
It doesn't really matter.
It's not tied to an LLM.
It's tied to the knowledge base of what the definition of the system is, how we care about maintaining the system, how we document the system, maybe how we prefer to install certain tool chains.
If it's one I don't use very frequently, maybe I use...
asdf for that or something like that you know it's something i care a little less about something i would really want to be close to the metal with i'm gonna go to cargo direct to get you know to get rust for example i'm not going to go through a conduit and so the system now knows that and it self-documents i just ask my little wish machine to install htop and document and i go back to my business i don't care anymore about dot files but in a sense i mean if i if i understand you correctly It's not that you've kind of reneged on your desire to maintain the system as well.
Dot files for you was a chore because there's a lot of weird, like, oh, the way you install Python has changed or the way you install Java has changed or it's now come to a different distribution.
But you wanted a machine that set your system up in the way that you wanted it with the least toil and a couple of common patterns followed.
But now you've built a machine that sets your system up in the way you want it with the least toil, the most flexibility and extensibility that's now more efficient.
So I guess, is it that you don't want .files anymore or is it that you've just built a better machine that takes your intent with your expertise on how it's applied, but you've said, like, do the boring stuff.
This is what I want.
Right.
Yeah.
Well, I guess I just...
I guess I don't necessarily not care about .files.
What .files represented was an understanding of your system and care for your system.
I still care about that.
I just no longer need to hold that in my own personal mental space.
I've got other things, other systems that are more important to reason about rather than the time I've definitely spent grooming and taking care of my .files only to serve me to get the system I want.
not to actually get to the work that I want.
And what's interesting is that now I have multiple systems.
I also have my main machine.
I've got a dev lab and my dev lab has, you know, a couple of different machines running prox mocks over here.
I've got three or four nodes of prox mocks running that are, it's a hypervisor to, to run, you know, LXC or even VMs.
And rather than, or I've got other Macs in the house that do different things.
So I don't run all of it on one machine.
I got, thankfully I have multiple machines.
And so now my system agent isn't just this system agent.
Now it's, it can be all system agents.
So I have a couple of headless Macs in the dev lab.
And by headless Mac, I mean, it's just a Mac on the network, on the tail net.
my TAN, my TAN, my tail network, my tail scale area network is what I call it.
I tell that system to say, hey, you know what?
Let's define, now that you know me here, you know what I like.
Let's take that and let's define a headless Mac scenario.
And a headless Mac, what do you care about?
Well, you don't care about certain systems in place.
You don't care about this or that.
And so you make different trade-offs in different scenarios.
And so now I have a system defined for Headless Mac.
I couldn't even tell you what it is.
I didn't even look at the code or what's written there about it.
All I know is that it works the way I want.
And when I tell the system agent what to do, it SSHs thanks to my tail net to any machine that has, that's on the node.
It's on the net, on the tail net.
And it SSHs in and sets it up to my specification.
I don't have to worry about the .files anymore, Dave.
You know, I've graduated.
Bless me.
You know what I mean?
I had a discussion with the team about this yesterday, which is like one of the best things about Agentec Engineering is if I can open a ticket on Git repository and the machines for an easy ticket can pretty much one-shot it, that means I can spend four hours that day heads down into a complex architectural piece or a discussion with the team members.
Like we've killed out some of the toil.
It doesn't mean we're not applying the craft.
It just might mean that...
we get to apply it with more focus.
I'm curious, are there any things you write by hand?
Like literally as in not even prompt the agent, say, give me this in the edit, but things where you're just like, I'm writing this by hand.
A lot of the inputs are handwritten.
A lot of the runtime is definitely not written.
So I'll do a lot of, I've actually recently gotten into Excalidraw, which is MIT open sourced.
And they have a website and you can, I think you can pay for, a certain tier of it.
And it's so cool.
It's beautiful.
I don't know who made that.
Is it the one that has like, it's quite a nice hand-drawn style for the diagrams.
Yeah.
Excalibur font.
I don't know what it's called.
I think it's something like that.
Excalibur font, potentially.
And it's really easy to use.
And so that's one of my newest, I would say, in the last few weeks.
Because I've been using my Remarkable and my Remarkable.
is great except for getting the stuff to the machine.
It's very difficult.
Well, it's not very difficult, but it's a PETA.
It's a pain in the butt.
There's other ways to do it.
Excalibur is the better way to do it.
Like actually drawing it on the Mac in a browser with, you know, with indexed DB and all that cool stuff.
You know, it's very hardened.
And so that's an input.
I'll do a lot of thinking there.
I'll draw, I'll write, I'll schematic.
out ERD things.
I've got a cool new project where I'm modeling ERD.
I was like, let me build a system around that.
To answer your question directly, a lot of my inputs are written out.
I'll think deeply about where I want to go and what I want to do, but the actual runtime of things, for the most part, I'm not...
Why would I?
It's not that I can't.
It's back to your...
your example you just gave, like I can go do this.
I can one shot this ticket or I can spend four hours reasoning about the system, thinking about the system, being fully immersed in the system with me and my team and we're lockstep and we're making cool stuff.
Or I can, you know, write everything by hand.
Like, why would I do that?
I don't need to do that anymore.
And I still gate things and I still check things, especially around.
I often ask a lot for clear outcomes.
What's a clear goal and a clear outcome from this bounded session or this bounded goal set, for example?
And that's kind of where I think my personal toil is best met.
Dream, think, innovate, architect, and then put that input into the slot machine and watch it cook.
Yeah.
That's the world we live in now.
Yeah.
You know, it's either love it or leave it, right?
You got to embrace it or get destroyed by it.
That's how it's always been with tech.
When I first started, I had C for dummies and a computer with no internet.
I loved it.
Because of that, I still remember probably the exact syntax for how to do Hello World in C.
probably more, and I was building things like string classes or string structures just because it was curious and interesting.
Then the internet came and it all changed.
Then Stack Overflow came and it all changed.
IDEs, code generation, you know, that's tech, isn't it?
We've always been having to just build tools, build machines, and find ways to take the tech stuff and turn it into tools that let people build useful stuff on top.
And I've had a chance to think about that question for just a, a second more and I think the parts that I am handwriting are I said inputs but let's say for example the reason why I ask you a more deeper question around the YAML file that you'd mentioned for Arc is because I've got a system I'm building that has a YAML file but it's got a really robust DSL behind it and a DAG behind it so it's not just a YAML file where it's just text and you just read it it's far more than that So that's an example where I've handwritten that part.
But when it comes to using it in production, I won't handwrite it.
I fantasize in a very positive hacker way about this YAML file being very easy to reason about for a human to look at it.
And that's where the human meets the machine, right?
Yeah.
So where the human meets machine, those are the places where I spend time either handwriting or fantasizing about the design or dreaming about the design.
And so that's a version of the handwrite.
But the actual long term, I'm never going to handwrite that anymore again.
But I'll handwrite the entire CLI command spectrum, how it works, why.
Not because I need to handwrite it because that's the input.
It's the contract between me, the system I'm trying to build, and the agent who's helping me build it.
And unless that contract is flavored and peppered with love, developer love, DX, AX, whatever you want to call it these days, right?
Then it's not going to really meet the needs of other humans that decide to use the software I'm going to build, right?
Like that's just how it's going to work.
So that's where I focus.
That's where I handwrite things is where the machine, the human, the machine meet.
That friction point there is, it has to, at least in this moment, has to be designed and that's handwritten from a DSL file or a YAML file, DSL file.
to a command line interface or even naming of MCP tooling.
Like that's where I'll handwrite it.
That's where I'm here because later on in my tool calls, I got a reason about like, what was that tool again?
That wasn't, I got a reason about what that is later on as it streams past me.
So I got a hand, I got to design that.
And that feels to me like the same as if you're a tech lead in a team, which is I'm not going to necessarily scrutinize the boundary of your system.
but the shape of your APIs, I'm really going to want to look into in detail because I want to know that they follow the right idioms, that it's intuitive, that the way we do search queries and so on makes sense, that we're going to have pagination.
Some of it is just obvious hygiene, but also are people going to be able to intuit what's going on?
I find myself, the other thing which I've realized I handcraft the crap out of is readme files.
So I spent the last week kind of forcing myself to have, I get 20 minutes with Fable in the morning to have a discussion, plan something out, you know, talk about what it's going to be, let it run through the day.
And then at the end of the day, do a check in and say, this is what I like.
And this is what I don't like.
And the thing that it's building is something that I can just like pop open during the day to look at.
I don't prompt anything.
I just like record some comments.
So really, really good fun, super impressed with the output.
the read me like line by line in Vim handwritten, because like I'm a developer, I look at projects.
I know that developers are busy.
I like, I want to see what is it, how easy, like in, in as short a space as possible, like what does it mean?
Why should I care?
And if I, if it's not for me, you know, I'll leave.
How do I get it installed and have a play with it very, very quickly?
And that's it.
And I don't want any marketing speak.
I don't want a thousand lines of features.
I don't want a map of the code base.
I don't care about that at all.
I'm a busy engineer.
People are publishing things.
If you've got a great idea, I kind of need to see it really, really sharp and clean with as little text as possible, possibly with just a little bit of irony to say, hey, this is a hobby thing a little bit, but I also think it's kind of cool.
Or even for something like Arc the Docs, you know, it's really important if people are going to understand or be excited by what you're doing.
almost to kind of use quite human language to say, this is what it is.
This is what you can, this is the problem that you, if you have this problem, this is what it can do to help you.
And, you know, if that's the case, this is how you kind of get it set up and learn about it.
That's something that I find for kind of just like basic technical documentation, LLMs do a good job.
They're a bit wordy, but for the kind of short thing where it's like, I need to get the gist in a glance, at a glance, they're very bad at that.
And I see that with, consultants that I work with, that's one of the things they're very good at.
They deal with a lot of analysis and information and they need to condense that down to like, what's the important messages?
And so that I can then hook into the deep dives when I need to.
Handwriting read me's, huh?
Totally makes sense.
I can tell.
Is your shell write read me written by you?
I'd imagine it is based on what I see.
Yeah, and it's a little bit easy for me because they all follow a similar pattern.
The last one I just put up a few hours ago, and I'm going to be doing a write-up on the experiences of Fable, you know, 15 minutes in the morning, 15 minutes in the evening.
But I had fun.
I had fun with that one because I just decided to go all out with the fact that, like, this is something silly.
Because we're all multitasking and it kind of lets you see what the tasks are.
And it's not really going to help you.
You're still context switching.
It looks nicer.
But yeah, I add a little bit of fun with that one.
This episode is brought to you by WorkOS.
Agents aren't just writing code anymore.
They're accessing customer data.
They're taking actions across the tools we use and depend on.
So who decides what they're allowed to do?
That's a big theme from Mark OS and NIT 2026, their conference for builders.
They preview three products that show where things are heading.
First, Airlock intent based access control for AI agents in a live demo.
An agent worked across Linear, Snowflake, Stripe and Gmail.
Airlock denied a large refund, sent a smaller one to a human for approval and blocked an email containing financial data.
And then there's Atlas, a secure home for internal apps.
built with AI.
Think authentication, data connections, credentials, permissions, and deployment.
The stuff a prototype needs before it's safe to use at work.
And then they have Passport.
WorkOS is pushed towards zero sign-in.
Enroll your Mac once, then open WorkApps already signed in.
All three were announced as previews, but the direction is clear.
As AI makes software easier to build, we need to get more serious about who and what can access it.
I'm linking up the init 2026 recap.
So check it out at workOS.com.
Link is in the show notes.
Thanks again to our friends at WorkOS for sponsoring ChangeLog.
Once again, workOS.com.
This episode is brought to you by our friends at Fingerprint.
There's an interesting problem happening today, building products.
You want to make sure things are as easy as possible for your users, but you also need to know who or what.
you can trust.
That's getting more complicated today with AI.
AI agents are browsing, they're shopping, they're transacting alongside humans.
Some of that automation is legitimate.
Obviously, I use AI, you use AI, but some of it is not legitimate.
And fraudsters, the bad guys, are getting more sophisticated.
That's where fingerprint comes in.
fingerprint gives developers device intelligence to recognize returning visitors and make better trust decisions it combines more than 100 signals across devices networks and behavior to identify visitors with precision even as fraud tactics evolve and it goes beyond identification fingerprint helps you detect bots ai agents proxies vpns and other indicators of suspicious activity so now you can protect accounts prevent fraud and reduce unnecessary friction for the people who actually use your product.
And the developer experience is straightforward.
One API call, no fraud detection model to build or to maintain.
And now with AI install, you can add fingerprint to your platform directly from your favorite AI tool.
So if you're building products for a world where humans and agents share the same internet, fingerprint is worth checking out.
Head to fingerprint.com to get started.
Once again, that's fingerprint.com.
What is this, beyond what you shared there, what is this framework, this 15 minutes in the morning, let it cook all day and come back to it later?
Is there, what's the deeper part of that that I'm aware of?
Trying to get efficient or increasingly efficient, setting up, having a short conversation, the kind of like divergent, convergent thing, like divergent, what are we doing?
Convergent, okay, let's come to a plan.
you know, build, build the plan that you think needs to be done to execute it.
And then, okay, you, you basically have all day.
I'm not coming back for eight hours.
I need you to create interim results, be creative, work through problems.
I need something I can touch and interact with and feel.
And then at the end of the day, we're going to have a review conversation.
I'm going to talk about some potential alternatives.
Then you're going to go overnight and I'm going to start again tomorrow morning, but to try and.
really quite forcibly break myself out of, um, you know, tweak, tweak, tweak, tweak, tweak instead kind of point the bazooka, let it go.
And that's fun.
I mean, and elements of this are based on how I do things with Teams.
So, for example, there's a Mac app for it.
I don't want to review the Mac app at the end of the day.
It's too slow.
Give me an interactive HTML version that looks exactly the same that I can click on so that during that 20-minute discussion, we can super fast tweak the idea.
And also, you know, I'll give you the instructions on how to sign something or whatever it may be, and I'll give you a set of credentials, but just kind of get it working.
worked very well in terms of quick output.
And then sort of day six is a full line or near line by line review of everything so far.
And I just transcribed.
So like, okay, I'm looking first of all at the docs folder.
This is good, but I think this is stale.
This is actually out of sync.
So I record a long kind of feedback thing and then a more interactive session to kind of like get the code structure and quality to where I want.
And then the last day was a few hours of creating an interactive visual that kind of shows the gist of what's going on and refine the readme and then little test.
It wasn't necessary to do it with Fable.
I probably could have got the same results through Opus.
And I'd be curious to see what the results are with...
Results maybe, but the continuity, gosh.
I feel like Fable just doesn't want to stop.
Sol...
Sol.
Sol.
GPT 5.6 Soul Ultra in particular is very Fable 5-like, I've found.
I think that it's not quite as smart, but it will certainly keep going and not have to come back to you for more clarity or just, I would call it, I don't know what they call it really.
They kind of come back to you with like, I need you to prove this push to the test VM.
Listen, it's a test VM for a reason.
You are blessed to push that test VM to your heart's content.
That's the point.
Use it to iterate.
That's for you.
It's your tool.
It's not for me.
You don't need to get my approval to push there.
So like Opus 4.8 will stop there.
And whereas Fable or, you know, GPT-5.6 Soul Ultra, which is a longer name than just Fable 5, will do very similar.
I had to stop one.
Earlier, I was like, what problem are you solving?
Turns out it's in the wrong directory.
I won't even explain what happened, but I let this thing cook for like eight hours on something.
I'm like, man, this is really solving a problem.
I didn't care what it was.
It was just an internal kind of like fun thing.
And I come back to it and it's not even on the right project.
It's on the wrong thing, doing the wrong thing.
It had to apologize.
And I'm like, well, it's actually my fault because I told you to work in somebody else's directory, not even your own home directory.
So you went back to your agent's file, you got proper instruction, and you listened like you should.
And that instruction was incorrect because I steered you directly differently to help this other agent who was sucking.
I don't know about you, but Fable 5 for me, I must be doing some really seemingly nefarious things because I get cybersecurity interrupts from Fable 5 all the time, almost to the point where I can't even use it.
I don't know.
What's your experience with that?
Same.
Because anything that I'm playing with that I'm going to publish online, I'm always going to want to periodically do a full audit and say, right, I would like to take a look at this.
I'm trying to moderate my language here.
I'd like to look at this from the perspective of reputation, the possibility of saying something which could be misconstrued, something that could be enough of an issue that if someone was to use it, that would be compromised or whatever.
And with Opus 4.0, I would essentially say, give me a full security review, audit this, build the team you think you need to build to create the specialized agents to audit this, thoroughly attack it from every angle because it's going to be published.
It's going to be published with a waiver, but I don't want people to either see silly things or have mistakes.
Fable bombs out of that quite hard.
quite quickly, especially if you're doing things like, or I found if you're doing things like signing stuff, using certificates, using cryptography, which you need to sign distributions and apps and so on.
So yeah, it bombs out, does bomb out quite quick.
Yeah, I'm sure they'll eventually fix that, but that's something like, you know, the only reason I bring it up is because you say you let it cook all day, and I just can't trust Fable to work.
I mean, I can if I don't do something that's in the realm of authentication, authorization, cryptography, security.
Like, what do I want you for, Fable, if you can't help me be more secure?
You know what I'm saying?
Like, isn't that what you're invented for?
I'm paying you to do a job you can't do because you keep getting interrupted by it.
things I'm not even trying to do.
Like, I'm not trying to hack the planet.
I'm paying 200 pounds a month for this, man.
Yeah, exactly.
So in my case, I actually, with the same exact task, I tried to one-shot something.
And this is how I got jacked up, because I had Alpha Team and Bravo Team.
Alpha Team was Codex, GPT 5.6, Sol and Ultra.
And then Bravo Team was...
Claude Fable 5, I think on Max or whatever the top tier was, just to see how much you could think about this problem.
And it wasn't even a particularly hard problem.
I just didn't want to have to interrupt or give it, I wanted to give it one mission, go and do it, and come back.
And I know both of those are sort of unbounded and they'll just sort of go until, they'll almost even invent problems to keep going, honestly.
It's kind of uncanny.
I like those missions.
In this case, Fable did the best job.
Theoretically, Codex did the best job, but it went a direction.
It tried to build an OIDC interface, and it was knee-deep, and it just spent all its time on OIDC and authentication versus actually building the solution.
I come back later.
Again, this is a test.
Hours later, and I'm like, what you been doing?
This is paraphrased.
And it's like, hey, I've been...
Really knee deep in this OIDC.
It's going well.
I think you'll like it.
And I'm like, Fable 5 is already in production, man.
The VM launched and we've got DNS map.
Like it's Fable 5 is production now.
Like you, you know, you've only got me in an OIDC interface that I don't even need because we use tail scales off instead, which is just super cool.
I can't wait to dig into the, how I did this.
Cause it's insane.
It's using the who is from being on the tail net.
to just authenticate.
It's not using the IDP, the TSIDP they offer.
I'm not sure if I'm familiar with this, but you can just authenticate as TailScale because you have to use an OIDC provider to authenticate to TailScale in the first place.
So you masquerade, and I guess that's not the right word to use, but you gallivant as you across the network and wherever you go in the networks that you can touch.
as authenticated your tail net and your identity, it's just you everywhere.
So I don't have to log in.
I'm just opening the app.
It's just there.
It's amazing.
It's why I have two laptops because TailScale is blocked on my company laptop.
Our company laptop, you know, we do like client projects, lots of different things.
But it's one of those things where it's blocked.
I've got my personal laptop as well, which is where I do most of my personal work.
Although if I'm doing something like on Arc or whatever, sometimes I do want to bomb over to another machine or even I want to be able to log into a GitHub runner and Tailscale makes that easy, but not easy for my laptop.
I mean, it is kind of magic and has become the solution to so many problems.
The problem you're describing, one of the things I've realized I think I might be more interested in now is the hobby projects, the dorky ideas.
the journey you have with them, the kind of trajectory of the agents, I've realized that when it all goes a little bit wrong, that might be the time to stop, to codify and say, I've just created a fun test case here to test on the next model.
Because I saw where this one struggled and I saw the trajectory of the tool calls and so on.
I'd be really curious to see if another one has a more creative solution to it.
Like I tracked a task where I was like, the output isn't as interesting as the Not complexity of the task, but the many different ways to solve the task.
Downloading videos, doing lip sync, trying to extract information from different places.
There's a bunch of different ways to skin the cat and some of them are cheating.
I'm kind of curious because I've not used GBT 4.6 yet.
I'm itching to throw it at this task just to see not necessarily whether the output's better, but what's the methodology it comes up with using.
to try and solve the problem.
Because I mean, benchmarks, I feel like benchmarks would be like, what does it even mean anymore?
Like, you know, if it scores this much or this much.
In reality, we orchestrate complex pieces of work, long horizon tasks that do lots of things.
Half of that, maybe more than half of that, comes down to the instructions you give, the context, you manage the skills you create, the environments you set up, and so on.
So I almost feel, it's a bit like Simon Willison's pelican on a bicycle.
thing that he does to test out new models.
That's always been really, really cool.
And he had a very good write-up of his experience with Fable, giving it a hard task.
And the crazy loopholes it went through to do something it shouldn't be able to, in terms of like spinning up browsers, running JavaScript in them to get past a restriction to do this, to go back to the desktop.
Oh, yeah.
I'll see if I can find the link, but that was a fascinating write-up of like, damn, this system is very, very creative.
It will come up with some very clever ways to work around certain issues.
That particular test, let's just say, had an HTML output running application in the browser.
And it was on the VM.
That was the final place.
It was here on the dev lab.
So virtual machine, in prox, mox, accessible via the tail net.
And I wanted it to test different things around functionality.
And it was trying to give me instructions.
I don't know how you feel when an LLM tries to give you tasks.
I'm just like, nah, you do that.
And so it kind of proposed, and I'm like, I could totally do all this.
And I probably should if I really, if this was production and if this was a real system I was going to maintain and I really cared about.
I do care about it, but not in that direct way.
I was like, hey, why don't you just, you know, we have Docker here on the system.
Why don't you spin up Docker and build out a bespoke playwright, headless Chrome, whatever, and automate, like create an automation layer that's just going to test it automatically for me.
So I don't ever have to think about it again.
We know what we care about.
Here's a list.
Go build this Docker image and that's repeatable.
Docker file, compose, all that's, you know, infrastructure as code.
And now we've got this beautiful test suite that runs in Docker that I didn't have to write.
I had to be like, just test the front end, okay?
Don't give me the instruction to test it.
And I think that was Fable.
I think Fable actually suggested I do that work.
And I was like, I told Fable that.
Hey, go use Docker.
And it was like, yeah, that's a great idea.
I should do that.
And it did it wonderfully.
But I had to give it that permission, I guess, to go and do it in that case.
But otherwise.
It one-shotted that scenario probably in three hours where Codex, I think I just forgot about it and I came back and it's still working on the OIDC integration and built nothing else.
So I was like, it tackled a really hard problem.
It probably did an amazing job and now I don't even care because tail scale was the better authentication layer for this application because it's a dev lab tool, internal tool.
It wasn't meant to go to the real cloud.
It needed to have real authentication.
Just needed to have dev aware security here in the dev lab and it's just a team of one so who's going to come in and hack me so it wasn't that big of a deal it's a wild world my friend it is a wild world so we mentioned Playwright and we mentioned Shellwright really quickly just in passing is this an active project for you I haven't seen this I noticed this is in my preparation for this conversation with you what is this project you have Shellwright Shellwright was useful for me because On a few of the different things I do, I build CLIs.
And when I'm going to open a ticket on GitHub, I'm going to want the machines to complete the ticket, you know, open a pull request and say that it works.
And what I want in the pull request, I don't really want to look at the code.
I want a video recording of what the terminal output looks like.
I want a video recording of like someone running the CLI, moving things up and down.
Like, for example, I want a video recording of someone using HTOP.
I want a video recording of you using canines going to the Kubernetes cluster and checking to see if this thing exists.
Because that's what I'm going to do for this bug where you said we didn't have a column for the age of the agent.
I'm not going to look at the code first.
I'm going to check it out, run up the cluster, open up canines and see is the column there.
So please, instead, to my agent, you've got the ability to record a shell session for whatever the bug fix is.
demonstrate, give me evidence that it works.
So then you get your terminal recordings that you can then look at and eyeball.
And if you see the column is there, you're like, okay, that passes the smell test.
I'll now start to go into detail.
And that came from the idea of like playwrights very useful for putting evidence into pull requests, such as someone's built something.
I love it when my team put videos in pull requests because you can eyeball it.
It's even better if there's an interactive environment, you can touch it.
But also even just screenshots of the different screens are super useful.
And LLMs are pretty good at doing that.
They know how to run the dashboard up, drive the browser, and take a screenshot.
But being a shell geek, I want interactive video recordings of shells.
Are you familiar with Eskinema?
Yeah, yeah.
So I had this, I didn't know Shell Red existed until today, basically.
I'd had, and I only used it a few times, and I had to really, coax it into using Askenima to produce what you've done here.
How does that compare to Askenima, like what ShellWrite does and what Askenima does?
Are they similar in output but not similar in how they get there?
They're quite similar in how they get there.
With ShellWrite, it's actually creating a TTY, it's creating the buffer that's behind it, it's issuing commands, it's taking your intent and turning them into commands.
It's then grabbing the buffer, which has got all the ASCII encoding and so on, and it's either creating a plain text version for black and white, or it's creating the rich color version.
Then it's recording a GIF snapshot periodically along the way if you've asked it to make a terminal recording and then aggregating that into a video.
And what it renders, it actually renders using SVG.
So there's a pseudo TTY that's going on behind there.
The architecture behind it is far cleverer than I am, but it was able to make it work.
And the kind of...
The great moment was the first demo I wanted to do with it was be able to say to an agent like Claude, use ShellWrite, open Vim, say how to close it, and close it.
And then you get the demo come out where it's in Bash and it says Vim, it leaves a little note saying to close Vim, type colon QA, colon QA comes on and then it's closed and I'm like, wow, the agents know how to close Vim.
Wow.
I'm not using it heavily at the moment.
I quite like the fact that when pull requests come in, it generates a video recording in every pull request of each of the test suites side by side.
So for example, when I added compression so that the GIFs that were the same frame cuts them out, it makes the output much smaller.
But I still wanted to see that for the Vim example, the HTOP example, for the K9s example, that roughly the videos look the same.
Okay, they look the same.
Great.
That's evidence again.
That's one of the things I think agents are great for, that we underuse them for, or maybe I underuse them for.
Don't just write the code.
Build a body of evidence that gives me confidence that what is there is correct.
Screenshots or recordings or log entries or examples of what you did.
They're quite good at doing that.
Yeah.
Yeah, I'm glad.
I want to play with this more.
Like I said, I just discovered today my Eskinima version.
I think it I don't know if it went bad or good.
I enjoyed the output, but I had to.
This may have been months ago, but I hadn't revisited.
I've had the pain.
I've wanted to see the CL outputs.
I want to because that's my I designed it.
I gave it to you.
I give you my intent.
Is that the result?
You know, how closely did we actually did I did we did we meet the bar?
You know, was that even possible?
You know, did you come up with a better solution?
Because, you know, sometimes my ideas are just, they're not, they're authoritative in the fact that I've given them, but they're not authoritative in the fact that it's a contract.
This is a riff or direction I think is pretty accurate to where we should be.
Try to stay close to that.
If you have better ideas, present them so I can, you know, bask in the glory of the new idea and then direct, you know.
But.
Being able to record even a test suite I think would be really cool in a pull request because you're right.
What I want is evidence of the outcome that we said when I said approve go and you worked unbounded for three hours or whatever.
Out the other end is the output the same as the desired or roughly the same as desired input because that's success, right?
That's proof that we've met our bar.
I got to use this tool, man.
We need to bake this into, I see you've got some skills here.
Again, I'm uninitiated on it, so I don't know how mature it is.
You're using it, obviously, but is it pretty easy to just tap into a system?
And does it install via a binary?
I don't even know.
Just installs by MCP.
You just install it via MCP, and then you basically prompt your agent to say, use shell right to open HTOP.
Make a recording of opening HTOP or make a recording of how to list the SSH keys in my folder.
And normally it will do a pretty adequate job.
My initial goal had actually been, it's really time consuming to get good shell recordings for things like...
the book or the website until I realized you can just say to an agent use SVG and create a beautiful looking shell rendering of what the command output is which is actually the best way now to create really nice terminal output graphics but then the other thing I realized is every time I change something on my cluster the colleague I work with he will want to see the screenshots of the terminal app before and after because he'll kind of want to see that like it looks like it should do.
Because in a sense, it's one of our user interfaces.
It's in fact one of the most important user interfaces.
It's a DevOps tool.
And it was a little bit of toil creating those screenshots until I realized I could say, you shall write, run up canines before the fix, take the screenshots of where the issue is, apply the fix, open canines, take the screenshots of where the issue is fixed, save them here so that I can drop them into the pull request.
Yeah, I like that a lot.
I'm going to have to find a way to bake this into my way and just bake it into my toolkit because that is the evidence.
I think you're spot on with that.
If you want to craft another law here at the tail end is something around evidence.
Give me, in between my intent that I give you and my design I give you, out the other end I have to have some version of evidence because otherwise you're going to make me read the code or spin up the cluster and play with it myself.
yeah, I might eventually want to do that, but I don't want to do that before I instruct you to continue.
I want to have confidence and clarity in what you produce that it matches our desired outcome and goals.
And if not, what were the trade-offs?
So I can tell you to keep going, not so I can then get broken into my system.
I have to come from this meeting or then rethink from whatever and spin up the server.
No, I don't want to have to do that.
Give me some artifacts, some evidences that what you did is accurate.
And then I learned to trust you in some way, shape or form, if that's a way to even say it, or trust the system because the evidence has been pretty accurate.
The thing has never tried to lie or be less than forthcoming with the details.
It's like, yeah, you can't, if this is the output CLI at the end or this isn't the API shape or the test suite running, then that satisfies it for me.
Yeah.
And evidence is not.
The unit tests pass.
Because if the unit tests don't pass, I'm canceling my subscription because they really should pass.
To me, that's not evidence.
That's just like, well, that's hygiene that has to be there.
Right.
But it might be something like you've connected to the cluster, you've run something, you've captured the logs, you've attached the logs.
That's where, okay, I can see that there was a bit of a smoke test there.
And that's one of the quite nice things about agents is they can be a bit creative in OpenAid.
ended about getting evidence.
It's a little bit like asking a QA to do a smoke test.
Like, you know, take a few screenshots along the way, press a few buttons.
Doesn't mean it's perfect, but it might mean it passes enough of a smell test for me to then review in detail or put to a UAT environment for someone to test.
Yeah.
Or even have a special aha moment when you see, oh, wow, now I didn't think about how that would map to that.
Now you see it in real life because they say it seems believing, right?
And I find that like, that state of play that you get into when you're going back and forth, you can sometimes get exposed to something even beyond what you've even thought of because you're like, wow, now I see how that maps to this.
It just gives you a chance to kind of go back into creative mode versus just simply test suite paths, which is kind of boring, you know?
Do you find yourself, I know we're getting close to time, but I asked a few people this question and I don't even know what my own answer is.
Do you find yourself finding that you're less in flow because you're parallelizing and that you're always having to make decisions and it's like more decision fatigue without that joy of like six hours of flow first?
Or is it that with all these tools, you've got more flow?
That's a good question.
And I think it, like, gosh, I even hate saying that.
It depends.
I almost felt cliche even responding that way as I said it, but it was my natural response.
There are times whenever I've got multiple plates, when I mean multiple, like four or five or six plates spinning, and that could be totally disparate projects going at once that all culminate into one thing eventually.
Like several rows that lead to one highway kind of thing.
I find that when I'm laser focused on one or two, maybe three, is where I find that I enjoy it personally.
Like I feel like I'm enjoying the process a lot.
not just getting things done or getting a lot done in a particular time spectrum.
When I've got five or six things going, I would say it's less joyous in the fact that I could do that many, but not joyous in the toil of doing because I'm just a little less in the deep.
I have to get pulled so quickly to something completely contextually different.
It might be similar because it might be a CLI or it might be an API or it might be, you know, whatever it might be.
It might be adjacent or similar, but it's not the same exact thing.
And I find myself even getting confused, like in the, in a split second, and then kind of have to rejigger myself to be like, okay, we're back on XYZ project.
And, and I have to kind of like remap.
This is what the project does.
It's almost like I become like stupid really momentarily.
And then smart again.
Like, it's like a, like I have to like, jolt myself out of like I don't know momentarily so I think I've really enjoyed the process usually hours in it's usually like by hour two or three where things really get I feel like they start to I call it like a flywheel almost like a hamster like you kind of get it going and like if I get interrupted or I got a meeting coming up and trying to spin it down or spin it up I find personally once it's spun up that's when state of flow happens spinning down is like, oh, it's hard to like spin down these agents.
I've kind of like got wound up with this intent and this design and this architecture and these directions and whatever.
But spinning it up is cool.
And then spinning it back down is like, man, it's kind of hard to mentally because I'm like, what are you working on?
What are you doing?
I want to see it be done.
Then I've got to take a break.
And like getting the agents to stop is like, you can't just tell them to stop, right?
And you don't want to because like, no, no, no, you're locked in.
Get that thing done.
And then break.
And then don't let me have anxiety about what you're working on.
So I don't want to ask your question, but it's kind of like a tap to some degree into my psyche.
You can get it.
So if you're doing two or three things and there are things that you like, but also if you're doing it over a period of hours, you can get into that.
But if it's starting to get into the five or six and it's short blocks, then it's just...
Yeah.
Yeah.
That's probably the...
The number one challenge for me right now is the process to get to the spun up version of that and then the lack of desire to spin it down.
I've got to personally step away.
I'm a human.
I've got things I've got to do.
I've got a family.
I've got to go to dinner.
I've got friends to hang out with.
It's end of day or I've got a meeting to go to.
But I try to block myself into time whenever I know that I'm not needed for anything else.
three or four hours kind of like just locked in.
And that's, that's, that to me is a sweet spot.
Three or four hours locked in definition of done marching orders, mission going.
And I try not to let it bleed elsewhere outside of that, that time zone, because I think as a human, you're naturally just curious to how things like the reason we watch movies that suck or movies that we're in the middle of a movie that sucks, but we watch it at the end is because we have to understand how it ends.
There's a mystery to be solved.
And these LLMs kind of give us daily mysteries, if not minute-by-minute mysteries.
How will this end?
Will this be successful?
Was this a good idea?
Will this solve the problem?
Will it be beautiful in the end?
Will I like to enjoy it?
Will it be production-ready?
All the things, right?
Yeah, minimized.
I enjoy spinning up a lot, and that's exhilarating, but I think I find I really enjoy it most when it's focused on...
two, maybe three things.
Yeah.
Versus five or six, just by nature.
Too much multitasking.
I like what you say about we're human beings and we want to know how the story ends.
I think that's a much more positive framing than it's the dopamine loop of one more prompt and one more answer.
That actually, yes, there is like a slot machine thing there.
But I think your framing is actually more positive, which is like, it's not that I just want to keep on clicking the buttons.
It's like, I want to see it done.
So that's really nice.
Yeah, you have a desired outcome.
Right.
You have a desired outcome that you're sort of like emotionally driving towards.
You're fantasizing about this future.
As a technologist, you're innovative.
And so you're thinking, you know, you're probably with the superhuman strength.
Now you're tapping into a whole new world you haven't been able to before.
So it's tantalizing.
A lot of things culminating.
But ultimately, I think it's like there's an outcome, a desired outcome to get to.
even session by session, if not project by project, like where is this project going versus where is this bounded session going?
I find myself really just curious how it's going to end in this moment versus like, and maybe to some degree, it's like the slot machine aspect.
Let me pull it one more time and get something out.
But when you're really riffing on and you're in that state of flow, you're by nature, you know, really pushing a new bound.
that you haven't before even in that single session so it's it's by nature is who we are and what we're doing with software to create to see the thing get created yeah you know what i mean um the struggle is real the struggle is real you know that's why you know you mentioned your talk and i was like you know i don't even know if i want to ask dave about this talk because it does it does hit a real moment there for you and i think is as um a community of developers.
I think we have to care about each other enough.
Thankfully, there's still X and Blue Sky and Mastodon, places where people hang out at.
I'm mostly on X.
I feel like a lot of the conversation I want to tap into around this AI era is all on X for me, personally.
That's where I'm getting the majority of my information.
Thankfully, we're there, though.
We're making jokes and we're releasing and we're sharing and stuff like that.
And we're checking in because, you know, We need a buddy.
In the end, check on your buddy.
Don't be a human on an island with your LLM.
Be a friend and check in and be like, Dave, you're doing good?
How's your sleep?
How's your eating?
How's your health?
How's your relationships?
How are the things that matter most to you?
Because if we're only here for the tech and this LLM just chews us up and spits us out, we're not going to enjoy the life we're trying to live.
We have to have some boundaries.
Yeah.
And empathy.
Empathy is a big part of that.
It's funny you mentioned X.
Like I'm on Reddit more than I was years ago, partly because I feel like at least what I'm seeing there and engaging with is some of the few places where I'm not seeing stuff that's just completely AI generated.
It's a bit messy and it's a bit human and it's a little bit complainy and moany, but also silly.
And it's like, I kind of need that in a very serious world where everything is like a pitch and everything.
is, you know, big and dramatic and it's going to change the universe.
I almost need a little bit of grounding of like, yeah, we're all finding this a bit silly and tiring.
It's kind of cool as well.
Look at what I did, but like, it's what's going on here.
Yeah.
Give a shout out to some of your, your reddits as we tail off.
Cause I'm curious too.
I need, even as you say that, I feel like there are some pitchy things on X and there are some things that are, I wouldn't say necessarily AI generated.
I think I have a lot of good, cause I'm only on my following.
Like I'm, Not my for you, but my following.
Who am I following?
So that's orchestrated and to some degree designed by my intentions, right?
I'm opting into that.
But what are some of the Reddits that you're hanging out on, that you're enjoying?
Programmer humor is always just easy, lighthearted, stupid, fun.
I think Claude AI has been interesting because there's loads of talk about people being like, I don't really get what's going on with Fable.
Like it opens up here, it closes there and like what's going on.
And there's been some really interesting conversations from people around, well, look, there's a business model here potentially, but no one knows what it is.
So until that point, like, you know, my readers are an outsider is that I think they just got to try everything they got to try and their market is changing all the time as well.
I look at things like command line again, just cause I'm a dorky shell person.
And that's one of the places where I still see cool things that I love.
I see people's passion projects that are maybe not entirely handcrafted, but they built a tool for their thing, which is cool to help them do their work.
And I always find that interesting.
Slay the Spire, which is like a card game on Steam.
There's just some fun lighthearted stuff there.
Yeah, just a few different things, but I'd be curious about yours as well.
Maybe we can do a share offline and share some of the things as links or whatever.
Yeah.
I don't know if there's anything in particular on X that I'm enjoying, but I feel like I'm trying to steep myself in my work hours into this agentic world and embrace as a seemingly to some degree, if not fully AI maximalist.
I know there's a lot of people out there like doom and gloom and there's times that I'm like, oh my gosh, doom and gloom.
Like yesterday and the day before I think it was like doom and gloom days.
Today after last night's session or the three-hour session I had yesterday was like, I'm back to good again.
I haven't flowed like anybody.
I just don't know.
What can we do besides just kind of keep showing up and applying our experience and our wisdom?
And I think if we've got to...
If we keep shaping the world for future humans, like future humans are going to use agents.
If we can make those future humans world easier by giving them what they're going to get anyways, which is more agents, and then giving their agents good tools that give them safe determinism in this non-deterministic world.
Well, that's the kind of job I'm trying to do now in a way.
And I'm trying to build tools for agents, trying to build factory tools, you know, not building the next.
building the next version of a hammer, you know, or a nail gun or a level or things like that.
These are things that help you build things like these little primitives you use to like a jig, you know, things like that.
There's a lot of asymmetry to, you know, literal construction and software development now.
Like you probably can go into the construction world and learn a ton about how to build software just by processes.
inspection, quality assurance.
Yeah, tools, machinery, measurement, redundancy, project management, planning, all that kind of stuff.
Because that's what we're moving towards.
We're an intelligence layer, but we're directing an intelligence now.
I think as long as we're building tools that are for humans, because what is software for, really?
I guess I'm building software for an agent to use, but as a proxy to the human's intent.
Right.
And I remember something that a colleague I hugely admire said to me a few times, like when I'd been questioning what I was doing, he's like, do what's fun, man.
Like, cause otherwise what's the point?
Like, do what you enjoy.
And he's very senior, extremely expert, respect this guy enormously, but I can see that he also kind of lives by that principle as well.
And I don't mean that he runs around making jokes.
He works with people he finds exciting and exhilarating and interesting.
And he loves just like listening to them talk and getting excited about it.
And he has fun.
He works with the people he finds interesting.
He works on the problems he finds interesting.
And then I think the other one is have empathy because we're all going through this strange change.
Like it's, you know, for us as software engineers, like we have a place in this world, at least for now.
For a lot of other people, there's a ton of fear out there about what does this all mean?
I don't know what keeps you awake at night with your children, but they're going to grow up in a world that's really different.
And this is a time that's quite, you know, it's big, it's stressful, it's a lot of change.
Yeah.
I know I've said it verbally and directly, verbatim, inventing fire.
I really feel like this is like fire being invented.
You know, like humanity changed forever when fire was not invented.
It was discovered.
I'm sorry.
I should probably not say invented.
But it's a version of an invention now.
I feel like this is the new age fire.
Yeah.
Everything we know of that is anything we can rely upon in this digital age is going to drastically change because of the way.
Humans will use agents to do work in multiplication forever.
Yeah.
From this day forward.
It's never going to go back to the non-agentic world.
It's a little strange, but it's like fire.
Yeah.
Expect big change.
And what happened when fire was, maybe not literally in that very moment, but over time as fire was, we're now aware that fire exists, is we all explored ways to use fire.
Yeah.
To make humanity better.
Right.
And that's all we're doing is we're exploring ways to use fire to make humanity better.
Yeah.
Just don't get lost in the fight.
Yeah.
Right.
Well said.
Yeah.
Dave, what else can we, can we close on anything that I know we've mentioned your book in passing, maybe not directly.
Let me go to my tabs real quick.
Cause I want to mention the exact website, effective dash slash hyphen shell.
I'm sorry.
I'm going to say it again.
Effective.
hyphen shell or dash dot com.
So, or your main website.
Let's see, what is your actual website these days, man?
It's dwmcur.com and there's links to most of the dorky stuff there.
There you go.
Yeah, we'll link it up in the show notes.
Link to ARC's there.
Link to Shellwright's there.
Hacker Law's, as we talked about in the last pod, is there.
And then I think you probably even link out your book.
This is, I love your site.
Such a beautiful little hacker site.
Really.
I'm so impressed.
Like I like it.
I mean, I don't know how much time you spent on this, but like, I like it.
Eat your posts are great.
I love how your posts look.
It's very hacker, but also very readable.
So cool.
I love it.
I try to keep that stuff authentic and kind of handwritten because there's a load of amazing professional stuff out there.
There's a load of slop.
My stuff is a bit silly and dorky, but that's okay.
You know, that's fun.
That's what I enjoy.
Yeah.
Well, thank you again for coming back on the pod for your, Posts are your project on GitHub, Hacker Laws.
Lots of stars.
Very much fodder for our conversation here today and the past conversation we had with Jared on the pod.
Anything else, Dave?
Anything else left in closing?
Anything to shout out here in the end?
Anything?
Yeah, maybe.
I've done like four interviews this week.
And, you know, earlier on I'd said that I sometimes see a sense of grief when...
I see people's side projects, their dorky side projects, and I love them.
And I'm like, are people still going to do this anymore?
But what also struck me today as well is like there's a whole bunch of young people coming into this world with just so much skill and enthusiasm.
And I talk to some people who are spooked, understandably, about their industry as well.
But also I look at what these people are doing and the projects they're getting onto.
I do think the future is bright for them.
With every tech innovation, we've just started solving more complex problems.
And I hope that's the case.
I hope that's the case that it continues to be interesting.
But also to your point, it will do if we have fun, if we make it about actually enjoying what we do.
Yeah.
I like your friend's advice.
Just have fun.
Just do what's fun.
It's such a compressed simplification of how to interact and how to do it.
That's cool.
Dave, thank you so much for coming on the pod.
It's been a pleasure, my friend.
Take it easy.
Adam, thanks.
I've really enjoyed the conversation and getting to know you a bit more.
Yeah, man.
Thank you.
Cheers, man.
Bye.
Well, friends, it's always good to talk to Dave Kerr.
Love the way he thinks.
Love that he has organized these hacker laws for us to enumerate on and to ruminate on.
And even cooler, he can come up with a brand new hacker law on the spot.
Just chef's kiss.
Chef's kiss.
Glad to have you here.
Glad you listened to the show.
Thank you so much for tuning in.
It is a wild time to be a software engineer.
Of course, a special thank you to fly.io for having our back for sponsoring this podcast.
Learn more at fly.io and the beat freak in residence, break master cylinder, bringing those awesome beats.
That's it.
The show's done.
We'll see you in the next one.