Kerr's Law の誕生：エージェント時代のボトルネックはチームの「メンタルモデルの同期」にある（Changelog Interviews #689）

What's up, friends? Welcome back. This is the Changelog. I'm Adam Stokowiak, Editor-in-Chief here at Changelog. What if the real bottleneck in AI-sensit 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. workspaces. But what we realized is that we accidentally built the exact foundation for the AI age before the AI age even really arrived. So 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-stand boxed, 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 V-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, 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 sort of like gets 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 all 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 um 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 wow how did you do that like you just cleared the 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. We had a bit of a chat about it, but then I bounced back a message a little after 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 for humans. Some people. 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. It 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 um 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 with clients who write a lot of software and nowadays I'm not looking at things like you know is the syntax correct is it structurally correct it weirdly I realized I'm looking for things like hacker laws like you ain't going to need it this is cool what you what the agent's built you don't need it but also you've got this thing which says like backwards compatibility for x like 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 um 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 a GenSync AI. Yeah. You know, I take that back when 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, 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, a system that presents itself in that way. But I started to really navigate around Gall'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 change log uh the website there change.com and there's not a lot of change there because I'm not trying to add new features to do new things there so you know in this case I'm trying to like 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 And 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 Gauss Law is what popped up to me. It's funny you mentioned that. I opened a few on my other screen because, 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 Gauss 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 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,

if 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-shots, great, you get a working product for the one-use case, but trying to extend it, trying to augment it, trying to furtail 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 totally in time now. And 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, like, tools for Kubernetes that mean you can run agents and treat them a little bit like services you'd deploy and you'd 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 invent 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. So like 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 CLI. It's 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, dry run is probably the best example because 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 KubeCustle Apply or applying infrastructure or whatever, you get such good results just by the fact that they know if the dry run flags 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 cave-in and cave-women out here in the world of programming. Kraken sticks together and rocks 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? so we hear more about how things pipeline and orchestrate and less about the particular details mediums. I don't know, Adam. I feel like I go through a bit of a crisis on this day in, day out. Yes. I have some days. Yeah, 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. Yeah. Check the box. We pretty much one shot that because the team puts so much effort in to tune the machine.

But then if I'm looking at the Golan 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 hook my team to review specifications use open spec on and like why do you do this you can just do it faster without you know the code's fine and the reality of 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 pass over 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 it 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 slow down choke point so that we get a chance to keep our

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've got to read line by line, but I think in the case of an author, 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 type in, we want to change this to this, or just transcribing our conversations. One thing that I found useful was a little CLI that just beams up your current Markdown file into a shared online page that's using 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. 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 needed this to be secure I said about 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, you know, let's go through a proper audit on this one. And of course, well-directed, the LLM did a great job of the audit. But it's like that genie and bottle where, you know, 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 a 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's 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 used to 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 LLM 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 world where I feel like now more than ever, understanding Linux or even having a home lab with, sure, Raspberry Pi is like the most well-known home lab type of gear, but just minis for them. 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 GPU 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. I mean, I had this weird journey where I started on, like, kernel-level code and device drivers, and then I kind of, that's like my first coding environment was Ball and Turbo C++, so it was like DOS based and then when I first got to use like Microsoft Visual C++ and an IDE and interactive debugger it was just 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 and 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. That's why I don't do Java. There's so much folder structure and nesting that 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 while 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, well, 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 that 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 C-groups 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, like 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 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 blog posts, but it was literally build Docker from scratch. It was totally like you say.

The Linux-level primitives, the kernel-level primitives, existed and you kind of realize as you go through 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 mask, 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 is like I want to understand Linux primitives. I want to understand Linux pipes, 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 give it some validity and truth but that's kind of where I'm camped at I want to understand things that help me build the machine that builds the machine, not just the software I'm creating. I'm actually creating software around the software so the software we get created has maybe more determinism. In a non-deterministic world, we need determinism. And that's where my mind currently is just sort of like stuck obsessively on repeat is those types of things, those types of systems, not just the co-base that I'm building itself. yeah the machinery around it

yeah 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 as my colleague Roman Khalif kind of called me when we were doing some stuff and said hey what about this we're talking about a run time to run agents he said what about Kubernetes and I was like ah And then we had a quick chat and then I hung up and then I was walking around and I was 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 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 like agents like microservices. They like microservices, but they're quite smart. So, you know, typically we want to constrain them, think about the blast radius, what they can do if they start to do too much, you know, 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 Arc? Is that what you're talking about? Like when you allude to certain details around Kubernetes and the system? 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-Cheng 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, to their Python code, list the contents of this folder, and then for each one, found out an operation.

And it was really cool what they built. And interestingly, there came a certain point halfway through the project where clients 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 edited 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 it's like, I used to hate Kubernetes. I really love it now because it's basically solving our 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. I mean, it's easy to read. Easiest to read. It's better than, you know, Diverish, for sure. Yeah, and you can do GitOps. You can do infrastructure as code. So 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 the 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, like, 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 of them up. So this is my repo that I use to kind of like flash out a bunch of hedging 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. there'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 for 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's 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 ARCs in as well. So you've 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, which is 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 or maybe a team of developers are using agents. But this kind of orchestrated system, what does that kind of system do? Anything, really, but what are some of the initial ideas you all have? 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. We have more 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 know, you're not necessarily locked into one hyperscaler or another, but you certainly can 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, you know, 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 tenant 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 um because the days of like geeky hobby projects and people's cvs often they're things they 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 and 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's on 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 There was a 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 whatever it is for this. I don't know Adam, what do you think? 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 but 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 a, you have strangers using your code. And you've got to 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've got indie developer, hobby project. But then you've 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, Cloud 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's 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 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 sourced in. And then you've got your code out there in open source, and you've got cybersecurity concerns now. Well, now because an LLM is so skilled, you can find the loopholes and the issues in, I mean, this is an absolute bloodbath of sorts in the MPM ecosystem, for example. I mean, like, it's just everywhere. So I'm not sure how the reason I'm supposed to. 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 we got to the point where we were spending like

25% of the engineers 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 scrutinise 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 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 starts 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?

decisions, you know, and I'm not going to name any companies' names here because 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 over 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 let's build that 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 and 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, .sh files is everywhere. So why would you reinvent it, right? Yeah, and it is tested to absurd degrees now. Absolutely. As is, like, for example. Bash is on Mars, you know? But, like, BuildBuy versus BI is a really interesting one, because 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 build stuff like nobody's business. DTB, not DTF, DTB for a while.

They're 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 to the whole time like, yes. Yeah, it 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, you know, 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. That's kind of the sole problem. But you do see a lot of very hyperactive,

wow, we've created a bunch of things here. 80% of them are solved problems. 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, Adele 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, engineer to evolve. 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.io. Select the North America event, check out the schedule and register and use that code. It's a deep discount. I've worked so hard to give you that and they agreed so use it once again kubecon.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'll 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... How is it that? 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 kind of just want to pause for a second and just like steep myself in that uh dude you did a great job okay you were like no i can't do that but you just did it okay you just cursed law and i was afraid to now okay 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 team of one can scale really well like anybody I'm not building one thing, I'm building several things because you've got to wait here and so while you wait you're not going to do a five minute task it's too impossible you've got to do multiple things 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 the 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've 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. 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, and 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, yeah, it's good. It's good. It's good. Yeah, 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 are looking for new things, marketing are able to do more stuff. Like, it's going so fast. and you know the first like steam engine people got in 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 um it's just got absurd i mean and i i did a conference presentation a 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 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 as 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? There was a little thing six months ago where every so often someone would just say, are you applauding in meetings? People would be like, yeah. I love the fact that you used the word maladaptive versus bad. Someone will say bad, but maladaptive is actually maybe the better term to use in that kind of case because it's not good, it's bad it's just sort of in there as a different case though but yeah i i've caught um some of your talk not all of it um and i was actually not sure if i wanted to talk to you about that talk uh because it hit so close to home and i was like day's gonna come on here and tell me about

you know your disorder for one um and how that affects you and how lms exacerbate that or what you have to do to protect yourself or what systems you have in your in your in your habits and your flows and stuff like that to sort of kind of keep you grounded to reality right 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 you're really getting me here so what beyond the talk yourself like what and And then even your own exposure with – I don't understand bipolar to know what the spectrum is. How do you describe 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 – I wouldn't call it LLM addiction or something like that, but certainly something where you feel like you're constantly being able to have those highs

and the extreme lows pretty rapidly in today's world. How do you map the bipolar disorder and then the fact that LMs give us slot machine-like tendencies in today's world? 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 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 but as 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 of the conference was you know

you see some of these maladaptive papers 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, OK, 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, I guess, side effects or things that we're just going to have to learn what it means for us and how we get maximized for good. but manage the potentially harmful.

Yeah, neurodivergent makes me think ADD, ADHD, bipolar. And you often see this even, you'll hear a common phrase now, I got a touch of autism. 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 you 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 that are already on that spectrum of hyper-focus.

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 think about things like 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 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 are sort of speaking to knowing who Adam or who Dave is that can say, you know what, Adam or Dave, you're 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 figure, like, you're over the skis a little too much, slow down and check yourself is what we've said around here. I so bossed a little bit there, but, yeah, it's such an interesting time to be a neurodivergent person building with these kind 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 kind of about this is that some of the strategies

are just universal. Like 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 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 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 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 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 me all this cool stuff i've learned and but i still need time to kind of categorize and that sort. Yeah. This talk that you gave, is that a first for you to kind of go, I would not say real, but that's kind of real talk. Is that a first real kind of talk 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? There's a friend of mine, at least near from Ashley King, 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, I had 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. You know, I'm not here trying to sell you my framework,

which does skills better. I'm just, you know, 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 kind of conference you not going to like you said loop engineering context engineering You gonna 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 this 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 8% 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 you know there's a few different tracks going on um so the people who just wanted to um 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 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 sub-stacks 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 um 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. Some would even say wisdom. I'm not sure I would forward 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 bloody knuckles of different directions, or maybe know hacker laws by heart because they've been down the roads, they're the ones who are going to capitalize most? Or do you think it's not much an old versus young game, but more like experience versus inexperience?

Yeah, I think maybe in a couple of ways. I talk to a lot of people doing a lot of interesting things. and many of them, let's say, for example, Hex 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 older is smarter, because it's not the case at all. Like the adults are also stuck in their ways and so on. But 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 kind of like crisis

as they start working together. so I think it's a very good time if you're you know 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 kind of apply some judgement on top of that to kind of help think about risk and help think about kind of a bit more long term sustainability so I think there's a strength there and also you know You can look at the code and sometimes at a glance say, largely what's been done here is good, but you've reinvented something where you could have used GraphQL. 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 not do it. Maybe that's overselling 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 thinker, 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, But we've had a career, 10, 20, 30 years of saneness. Sure, you've had some innovations, Kubernetes, compilers, whatever, all the different things in between.

I didn't make a good enough list there, obviously. But 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 it will go. If it's always on, like if there's an agent for everything, kind of like there's been an app for everything. Here's a stupid but very simple example. I now have – and 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 I 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. And 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 Homebrew 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 tabbed back to terminal and just H-topped. 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 future 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 of this. You'd 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 interact with and half-made, like, a demo turn. so 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 it will serve 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. 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 income or regress 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 are benefiting from it yeah 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 dot 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 dot 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 full, 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 going to 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, and 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 .files. But in a sense, I mean, if I understand you correctly, it's not that you've kind of like reneged on your desire to maintain systems well

like .files for you was a chore because there's a lot of like weird like 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 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, 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 don't have my main machine. I've got a dev lab, and my dev lab has, you know, a couple different machines running Proxmox over here. I've got three or four nodes of Proxmox running that are a hypervisor 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 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 T-A-N, my TAN, my tail network, my tail scale area network is what I call it. But 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 tradeoffs 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'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 .files anymore, Dave. You know, I'm like, I've graduated. You know what I mean?

You know what I mean? I had a discussion with the team about this yesterday, which is like one of the best things about agendic engineering is if I can open a ticket on the 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 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 Source. And they have a website, and 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. The one that has quite a nice hand-drawn style for the diagrams. Yeah. Excalidraw Font. I don't know what it's called. I think it's something like that. Excalidraw 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. But Excalibur is the better way to do it, like actually drawing it on the Mac in a browser with, you know, with IndexedDB 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. I'll ERD things. I've got a cool new project where I'm modeling ERD. I was like, let me build a system around that.

So a lot of my, 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, like, why would I? It's not that I can't. It's back to 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 write everything by hand. Why would I do that? I don't need to do that anymore. And I still hate things. 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. That's the world we live in now. Yeah. It's either love it or leave it, right? You've got to embrace it or get destroyed by it. That's how it's always been with tech when I first started 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 and probably more. I was building things like screen classes or screen 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. 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

and let people build useful stuff on top. And I've had a chance to think about that question for just 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 asked 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 handwriting. 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 handwrite things, is where the machine, the human and 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 to reason about, like, what was that tool again? I got to reason about what that is later on as it streams past me. So 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 if 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 um 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 readme, 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 as short a space as possible, like, what does it mean, why should I care, and 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, so that I can then hook into the deep dives when I need to. Mm-hmm. Handwriting readmes, 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, 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 had 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 WorkOS 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 is 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? What's the deeper part of that that I'm not 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 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, going to talk about some potential alternatives then you're going to go overnight and we're going to start again tomorrow morning but to try and really quite forcibly break myself out of you know, tweak, tweak, tweak, tweak

instead kind of point the bazooka let it go and that's fun 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 I can click on so that during that 20 minute discussion we can super fast tweak the idea and also 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 transcribe. 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 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 let it test. It wasn't necessary to do 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 doesn't want to stop. Sol, Sol, Uh, Soul, uh, 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 approve 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 Sol 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 the thing cook for like 8 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 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 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. and 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 the stakes 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 cryptopian keys, which you need to sign distribution maps 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. what do I want you for Fable if you can't help me be more secure

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 things I'm not even trying to do like I'm not trying to hack the planet I'm paying 200 pounds in London this man yeah exactly in my case I actually with the same exact task I try to one shot something And this is how I got jacked up, is I had Alpha Team and Bravo Team. Alpha Team was Codex, GPT 5.6, Sol and Ultra. And then Bravo Team was Cloud 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 like knee 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 have 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 is launched, and we've got DNS Mac. Like, Fable 5 is production now. Like, you've only got me an OIDC interface that I don't even need because we use tail scales auth instead, which is just super cool. I can't wait to dig into how I did this because it's insane. And 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 you're familiar with this, but you can just authenticate as tail scale because you have to use an OIDC provider to authenticate the tail scale 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, trying projects, lots of different things. But it's one of those things where it's blocked. So 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 like Tailscale makes that easy, but not easy for my work.

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 trajectories 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 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 the 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 just like it will come up with some very clever ways to work around certain issues that particular test let's just say had a HTML put a running application in browser and and it was on the VM that was the final place it was here on the dev lab so virtual machine in proxmox 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 proposed, and I'm like, I could totally do all this, and I probably should 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 we have Docker here on the system, why don't you set up Docker and build out a bespoke playwright, headless Chrome, whatever, and automate. Create an automation layer that's just going to test it automatically for me so I never 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 infrastructure's 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 instructions to test it and I think that was Fable I think Fable actually suggested that 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 EIDC integration and built nothing else, you know? So I was like, it tackled a really hard problem. It probably did an amazing job, and now I don't even care because TailSkill 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, the need 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 in my preparation for this conversation with you. What is this project you have, Shellwright? So ShellWrite was useful for me because on a few of the different things I do, I build CLIs. And I'm going to open a ticket on GitHub, and 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 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 if there's a column there. So please, instead, to my agent, you've got the ability to record a shell session for whatever the bug fix is, 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 are 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 is 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 Eskenima? 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 Shellwright 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 Shellwright it is 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 kind of black and white, or it's creating the rich color version. Then it's recording 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 great moment was the first demo I wanted to do with it was to be able to say to an agent like Claude, you shall write, 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. So colon QA comes on and then it's closed. 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, makes the output much smaller. But I still wanted to see that, like, for the Vim example, the HTOP example, for the K9's 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 I'm glad I want to play with this more like I said I just discovered today my Aschina version I think it I don't know if it went bad or good I enjoyed the output this may have been months ago but I hadn't revisited I've had the pain. I've wanted to see the CO outputs. I wanted – because that's my – I designed it. I gave it to you. I gave you my intent. Is that the result? How closely did we actually – did we meet the bar? Was that even possible? Did you come up with a better solution? Because 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. It isn't a – a rift or a 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 work unbounded for three hours or whatever. out the other end, is the output the same as the desired, or roughly the same as the desired input? Because that's success, right? That's proof that we've met our bar. That's, 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? Like, I don't even know. Just installs by MCP. Okay. You just install it via MCP and then you basically prompt your agent to say, you shall write to open HTOP, or 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, a lot. 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 we'll kind of want to see that 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 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. And, yeah, I might eventually want to do that, but I don't want to do that before I instruct you to continue. You know, 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 tradeoffs? 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. and 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 seal at the end or this is the API shape or the test we're running then that satisfies it for me yeah and evidence is not the unit test pass because if the unit test don't pass I'm canceling my subscription 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 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 and open-ended about getting evidence. It's a little bit like asking a QA to do a smoke test.

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 uh 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 um it just gives you a chance to kind of go back into creative mode versus just simply test we passed 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 hate seeing that it depends i almost felt cliche even responding that way as i said it that was my natural response there's times when i've got multiple plates when i mean multiple like four or five or six plates spinning and that could be totally disparate projects uh going to ones that all culminate into one thing eventually all right 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 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 a split second and then kind of have to rejigger myself to be like, okay, we're back on XYZ project. 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 I have to, like, jolt myself out of a sentence. Like, I don't know. momentarily. So I think I really enjoy 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 wheel. 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. Cause I'm like, what are you working on? What are you doing? I'm going to see it be done. Then I 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 be like, no, no, no, you're, you're, you're locked in, get that thing done and then break. and then don't let me have any anxiety about what you're working on. So I don't know if I get 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,

then it's like short blocks, then it's just... Yeah, yeah. that's probably 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 pursue a 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, and I could just spend three or four hours kind of like just locked in. And 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 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 right 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 you know 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. Versus five or six, just by nature. 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. You have a desired outcome. 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 to 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 if it's that single session so 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? The struggle's real. The struggle's real. You know, that's why you mentioned your talk, and I was like, you know what, I don't even want to know if I want to ask Dave about this talk, because it does hit a real moment there for you. And I think as a community of developers, and 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 it's 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 them we're sharing and stuff like that and we're checking in because you know we need a buddy and in the end check 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? What 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 mention X. 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 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, 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? Program of humor is always just easy, light-hearted, 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. It opens

up here, it closes there, and what's going on? 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've just got to try everything they've got to try, and their market is changing all the time as well. I look at things like command line, again, just because 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, like, they've 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 next 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 keep shaping the world for future humans, 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. I'm trying to build tools for agents, trying to build factory tools, not building the next version of a hammer 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, you know, project management, planning, all that kind of stuff. Because that's what we're moving towards. You know, we're an intelligence layer, but we're directing an intelligence now. And we're trying to, 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 when I've been questioning what I was doing. He's like, do what's fun, man. Because otherwise, what's the point? I love that. Do what you enjoy. And he's very senior, extremely expert. I 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, 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, like, there's a ton of fear out there

about what does this all mean? You know, 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-agented world. It's a little strange, but it's like fire. Yeah. Expect we change. You know, when, and what happened when fire was, was maybe not literally in that very moment, but over time as fire was, uh, we're, we're now aware that fire exists is we all explored ways to use fire. Yeah. To make humanity better. Right. 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 close on? Anything that – I know we've mentioned your book in passing, maybe not directly. Let me go to my tabs real quick because I want to mention the exact website. Effective-shell.com. So order 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 arts there Link to show rights there Hacker laws We talked about in the last part 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 spend on this But like, I like it Eat your poster, 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 that's fun, that's what I enjoy yeah well thank you again for coming back on the pod for your post or your project on GitHub Hacker Laws, lots of scars 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 else? 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 talked to some people who were spooked understandably about their industry as well but also i look at what these people are doing and the projects they're getting onto and i do think the future's bright for them with every tech innovation we've just started solving more complex problems um 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. Yeah. 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 this 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 to the Beat Freak in residence, Breakmaster Cylinder, bringing those awesome beats. That's it. This show's done. We'll see you in the next one. Win it. Win it. It really whips the...