Russ Miles (00:00):
Before you spend a whole lot of human attention on verifying this at the other end of the pipeline, and before you spend a whole lot of tokens on something you have no basis for having, question it.

Nicky Pike (00:14):
This is [Dev]olution, bringing development back to speed, back to focus, back to freedom. I'm Nikki Pike. Okay, so everyone's talking about how much faster AI makes you. Ship more, review less. But I keep getting stuck on one thing. When an agent makes a call on your behalf and it goes sideways in six months, who answers for it? The model can't, and it doesn't know what it did, and you can't make it care. So whose name is on that, and would you even know which decisions you were defending? My guest today is Russ Miles, principal software engineer at TechTalk, where he works on Agentik software engineering full-time. He's written nine publications for O'Reilly and two books of his own. And the argument running through all of them is that you can hand an agent a mountain of responsibility and still never hand it one ounce of accountability.

(01:03):
Russ, welcome to The [Dev]olution.

Russ Miles (01:06):
Oh, thank you so much for inviting me, my friend. I'm so very pleased to be here.

Nicky Pike (01:11):
How are you doing today?

Russ Miles (01:13):
I'm having an exceptional week. Bizarrely enough, although your introduction is absolutely right, I have been around and seeing how TechTalk operate for a long time, but I actually become a full-time employee as of tomorrow morning. So it's already shaping up to be a very good week. I

Nicky Pike (01:30):
Noticed that. We were looking right before we got on here. We were seeing that you actually posted that up on LinkedIn, that you took the full-time job. That's awesome.

Russ Miles (01:39):
Yeah. I like to work with a team. I like to work around people that have sort of a shared mission and they're trying to make a difference. I know that all sounds a little bit cliched, but it's still quite hard to find. And while I could probably operate independently to a large degree in many aspects of life, including my writing, when it comes to this moment in software engineering, I think the getting surrounded by people either smarter than you or with more fascinating ideas than you is the way to go.

Nicky Pike (02:10):
Oh, I agree. I mean, that's the crux of learning. If you're the only one that knows anything, you're not going to get any better.

Russ Miles (02:15):
Exactly. 100%.

Nicky Pike (02:17):
Well, let's go ahead and jump into this, Russ. So you started writing software at General Dynamics where somebody always had to own the call there. Then you went to Oxford, you were running your own companies, and now your LinkedIn summary is one line, building habitats for humans and AI to thrive together. Where did that word come from, habitat?

Russ Miles (02:37):
So the word was introduced very first time I ever heard it in reference to what we do, was around probably very early in my career, probably around 2000... Oh, it could have been 20 years ago. And it was brought up in reference to patterns and the way that we have the pattern language. And someone said that a lot of this had been evolved from the work of Christopher Alexander. So I went and took peeks at that sort of work. I've always been incredibly curious about language, the way we use it and what meaning it has. And also I find it hilarious to watch the little discrepancies and misunderstandings that language brings. I think it's wonderful. It's a beautiful tool. And when I looked at the work of Christopher Alexander, one of the things he talked about was the habitability. He used it as the quality with no name.

(03:30):
What is the quality with no name when you are living somewhere? What makes a particular environment have a quality that people recognize but struggle to ever describe? And sort of the word that was given to it after the fact is this idea of habitability and the habitat. And then many, many years later it came back to me and it came back on a circuitorous route through the wonderful Kevlin Henny. Now, I'm going to have to drop Kevlin one more time for those folks who haven't seen his work. They should. He's incredible, not just for his hair. His hair is a thing to behold, but his points, his smarts, his experience is incredible. The other thing that you wouldn't know about Kevlin unless you were quite close to the gentleman is that he is one of the few folks in the industry that is just so generous with his time.

(04:26):
And one of the things that happened is obviously I went through a very bad period health-wise about five years ago, just under five years ago, and many people really don't know what to do with that. When someone's ill, they don't know how to reach out. They don't know how to connect. Kevlin did. Kevlin connected. Kevlin asked how often can we have a call? He didn't wait for me to ask for it. He was very much, I'm here for you, whatever works. We can talk about software, we can talk about pens, we can talk about writing, we can talk about absolutely anything. Guitars is another favorite topic. So always lots on the table. And during those conversations, the post - COVID conversations I would call them, for me they're the cancer conversations. I got to know Richard P. Gabriel through Kevlin and he said, "You need to read the stuff you're talking about, you need to read his stuff because he had a similar take when it comes to how we build object-oriented systems.

(05:27):
What's it like to live in a system that's built using object oriented mechanisms?" And so his book, Patterns of Software is wonderful, absolutely brilliant book. And I believe you can get it for free online as PDFs, I think it's out of copyright and things like that. So please go hunting or try and buy a copy, a print copy if you can find one. Not easy to buy one. I've got two here at the moment. I think I'm trying to buy them all up before anyone else gets them. But the beautiful thing about it is it comes back to that word of habitability. What does it mean to inhabit, to intellectually build a mental model of inhabiting a piece of software, a system? And how does it evolve over time and how is it stored within us and how do we find ourselves feeling like we inhabit a world that allows us to be creative in software?

(06:20):
And that inspired me to use that as my main thesis. At the time, I was not close to AI whatsoever. I had done a little bit of tinkering with maybe a little bit of the algorithmic work, not much more. But when the first versions of coding support came to the fore, I watched the behavior of it and I though, "Well, what place does this have in that habitat?" At the time I was building platforms for humans and I though, "Well, this is interesting because while it's definitely not another consciousness entering the room, it is most certainly another cognition coming in the room. It's another potential decision making system." Back to your point around who's making those decisions, it's a decision making partner to reduce AI as we currently characterize it to a mere tool is dangerous. It is a system that can, is capable of making many, many decisions that could be incredibly opaque to you.

(07:24):
And in that balance, there is an advantage, there's benefits, but there's also significant things to be aware of. And so my hypothesis, my thesis for things evolved into what is the habitat for humans, platform engineering being my major work at the time, to okay, what is the habitat for humans and their AI collaborators? And I framed that right off the bat. I was like, this isn't about a tool, this isn't about a replacement of other humans. I do think many of the vendors that claim this is a replacement for humans should be asked to explain themselves in some depth, perhaps on a cliff edge somewhere with someone who's a little bit clumsy. We don't need junior developers is one of those phrases that haunts me when I hear it and it just

(08:17):
Triggers me completely. But being aware that this is not a replacement for humans and human decision making, what part does it play? What is the collaboration that works for us? What amplifies both us and what we can produce with this collaboration was the thesis. And at the moment, two books later, possibly three soon, I'm still exploring it. And that's another reason why I'm not publishing it traditionally is it's an exploration. This is new. This is very different than many other... I mean, I've had a 30-year career and this is the first time where I felt the entire landscape shift enormously. Forget cloud, platform engineering, all the other wonderful things that have happened in this career of mine. This is different. This is bigger. This affects people more intimately than it did before.

Nicky Pike (09:12):
I couldn't agree more. And I mean, we've watched this, like you said, with cloud, with containerization, with the dot com, we've seen this type of shift. And I do think that AI is following some of those same patterns, but the scope of it is so much larger and it's happening on such a quicker timeframe that when we looked at containerization, when we looked at cloud, those were tech ideas, right? They didn't affect people much outside of tech. Com, that affected the world. AI is like that, but AI is going to affect everybody because it's got a place in every person's life and it's going to be interesting to see that go. And I think this is one of the most exciting times to be in tech right now for just that reason.

Russ Miles (09:52):
I couldn't agree more as well. Yes, that excitement has to be tempered with a certain degree of trepidation about where it's going to go and what our part will actually be in it. But as I've said on stage a few times, again, a core piece of the thesis is that this is a changing literacy. Every change in literacy asks a simple question, who owns the agency now? Something has changed dramatically. What's the agency that's involved now? And I don't mean agents and I don't mean anything of the terms that are becoming confused in our industry. I do think we are geniuses coming up with terms and then giving them multiple meanings. I joke often on stage that the one thing a software engineer should never ever be allowed to do is name anything and probably including their children because we're not very good at it.

(10:41):
We've got a terrible history. I always joke that no sequel is the canonical example. We name something by what it isn't most of the time. Terrible naming. But yes, this change in literacy, which has happened multiple times in our history. I use two examples. I use the example of the printing press and the fascinating thing, and I use this occasionally in my talks, is that the similar complaints and concerns and worries, legitimate or not, they emerge every time literacy changes. Something changes that's going to change the agency who owns that power. And with obviously moving from scribes to the printing press, there are multiple complaints including we're going to lose our jobs, of course. I think that's fair that played out pretty strongly. But of course a new industry of taking those scribes and them being the typesetters, the people that create the type themselves, another thing emerged.

(11:37):
The other joke, I use another sort of tongue-in-cheek variant of where the synthesizer for music was introduced and all the musicians were complaining that you'll no longer need musicians ever. You'll just need a keyboard in someone's bedroom and you can create a chart topping here. Yes, that's true. I think Billie Eilish has very comfortably proven that one, as have others, but that doesn't mean we don't have the Rolling Stones. It doesn't mean we don't have very successful musicians. So maybe the world is big enough. When it comes to AI and now we have the same complaints, same concerns, same worries. Which ones are legitimate, which ones are not, I think does sometimes depend on who you want to believe or what you want to worry about. For me, writing my books, the thing I wanted to worry about was what is the collaboration? What helps me?

(12:24):
I was having more fun as an engineer than I had in decades possibly. I was enjoying the experience of exploring something new and quite honestly didn't want to go back. The deeper I went, the further I pushed it, the less I wanted to go back, but I could perceive the dangers. I lived some of the dangers myself, and that means that I could write in a book some guidance and go, "Okay, what does it look like when these sorts of problems manifest, when you hit these levels or what does it feel like beforehand so you can perhaps avoid them?" And that's what fed into the sovereign engineer book. And then the sovereign apprentice came out of a conversation, two conversations I had, one with a friend who was a researcher over in Canada, that would be Artie Starr. And then I had another conversation with some professors at Oxford and with some students there.

(13:14):
And I think the one conversation that hit me hardest was watching a student in tears because they felt they'd wasted years of their training, dedication, pouring themselves into becoming a software engineer, a career they were looking forward to, to find not least the fact the message they were hearing is, "We don't want you. We don't need you anymore." That was literally what they were holding up the screen showing me what, I think it was be a Bill Gates or somebody in the world, someone who should know better saying something very stupid, but they were legitimately concerned for their career. And I though, right, I need to write something new as quickly as I can that meets that fear, that meets that what am I doing now? And so I built a book around three responsibilities that all humans have when they're in software engineering at least, which is can I defend my decisions?

(14:12):
Can I debug what the decisions result in and can I evolve it with or without AI? And if you take those three positions were already in the sovereign engineer, that's what sovereignty looks like in the level five. But then there's what does that mean for an apprentice? What does that mean for somebody coming into our industry? That was what went into the sovereign apprentice. And the heart of it is the same three things, but obviously with the sovereign apprentice, how do I build the skills and awareness? How do I justify those building those skills? Well, you do it because you need those three discernments, if you like. You need to be able to defend, debug, and evolve. And the way the sovereign apprentice attacks that is it gives the new engineer the license and the argument, I suppose, to use certain techniques, even if AI is present, where they may actually engage more manually with their work in order to build those capacities within themselves.

Nicky Pike (15:15):
Well, and so I want to go back because there's something interesting there and it's not related to AI, it's related to the way that you write your book. So you've written nine books for O'Reilly, you've got two out that you put out on your own, and we just heard, everybody keep an eye out, there might be a third one coming out. Why did you go to LeanPub to publish your last two books? I mean, what did that let you do that you couldn't do with a publisher?

Russ Miles (15:39):
I mean, I'd love to say it's because I met Len, the person that runs Leanpub, and he's one of the most lovely human beings I've met, which is true, but that was after the fact, I'm afraid. Right? No, I went to LeanPub because I'm going to be super honest. In the very first instance, I wasn't sure if it was a book. I wasn't sure if it was real. And I thought if I position this as something I take to a publisher, they're going to ask questions I'm not ready for. And so I thought what I need to do is start writing and I need to start seeing what this could be. And I always felt traditional publishing, traditional publishing isn't in a position where there's enough money, resources to take big risks. And so I thought, to me, this isn't a big risk, but it's a risk.

(16:31):
It's not an easy sell book. I can't convince anybody that there's thousands of people that are going to cry for this on publication day, but I felt it was necessary. So I thought, let me see if I can write it. So I wrote it clandestinely on Leanpub for quite some time before I released it. And even after release, I though, I need a mechanism which allows quick updates. It can't be a print book. And I also found that I didn't want to enter into the usual promotional game of a new book and making sure that I aim for bestseller straight out. I really wanted this to be something that I had some fun writing, a lot of fun writing. I developed a style of writing where I like writing stories. So I write little vignettes that I've got a number of regular characters I use, a little cafe called Le Bonma, which doesn't exist.

(17:21):
I wish it did. It's in my dreams. It's always there. In my mind, it's always on the left bank in Paris somewhere. But originally when I wrote it, it was an Eastbourne and I though no one's going to know that. So now I never mention where it is. I just say there's a cobblestone street outside and I use it as a mechanism to explore topics. So I have multiple people coming at multiple angles, trying to unpack quite difficult stuff sometimes. And I though, I want to channel that. So that's going into my blog, the Software Meridian. I thought, let's use this in a book. And I though, I don't think I'm going to find an editor that's going to love this straight off the bat. Maybe I would actually. Personally, an editor might love it, but in terms of churning through the production and getting it to the bookshelves of the world, maybe not.

(18:05):
So rather than jump through those hoops, I wanted to jump through the hoops of trying to create it in its form or whatever it was going to be. And so I did that. And in fact, I deviated even from that form. I've got a story in there about the tango, the fact that in the tango, you learn to dance with another human and it did, particularly Argentine Tango is incredibly improvised. It's all about the way you lead a move in the moment. And I liken that to any collaboration. It's more like an improvised Tango than it is anything else. So I put a vignette in there about Tango. Can't see that getting past another editor, if I'm being honest, my friend, but Cooper and I am the editor, so we're okay. And then of course I started using agents with the editing as well. So I could do that too.

(18:50):
Agents could help me with some of the more clunkier parts of my writing, which was a great deal of help. I mean, I had to stop them being too AI-ified with their edits, but generally speaking, I drafted it, then I had agents go and look at it and go come back and go, "Nah, don't like it. Need to change this." And that improved it. So I found I had a working process that works.

Nicky Pike (19:13):
So you kind of followed your own advice there. You had the sovereign engineer, the sovereign apprentice, and now you got the sovereign writer, right?

Russ Miles (19:20):
It could be the third book, right? It could be. I've got options on the third book. I think the third book is either habitat thinking where I want to double down on what habitat thinking actually is. I've written a manifesto for it. I swore I'd never write a manifesto, really. I've always had a staunch hatred of them, not for any justifiable reason, just a gut reaction. And then I though, I need one. I need one that says this is what it is because otherwise someone else is going to write it and it's not going to chime. It's going to be awkward. But it wasn't a book, so the manifesto exists out on GitHub somewhere under Habitat Thinking Org. But yeah, the third book, it could be Habitat Thinking. I've also been working on something called The Sovereign Self, which is many of the lessons I've learned in the last five years about how to protect your decision making.

(20:16):
All things largely back to decisions and that sovereignty of being able to defend, debug maybe less so, but certainly defend and evolve and understand your own decisions is protecting your decision making potential is at the heart of that word sovereign across the whole collective of books is there for me. All

Nicky Pike (20:34):
Right. Well, let's use that. Let's go ahead and start jumping into the technical. So I'm going to put the challenge out on the table here for you. So the challenge on the table, we saw that Pharos AI, they published about two years of telemetry. They looked over, I think it was 22,000 developers, more than 4,000 teams. And what they found was that pull requests merged with zero review were up 31%. Now, Pharros is careful about why, right? Teams didn't sit down and decide to drop their oversight. Reviewers just can't keep up with what the machines are producing. So nobody chose us, it just happened. Now, before I let you go at this, Russ, I want to hear from the audience and I want you to be honest. I will be the first to admit I've absolutely hit a prove on a diff that I skimmed and didn't look through.

(21:18):
I told myself it was fine, moved on to the next thing. But when's the last time that you did this? So drop it in the comments and let us know. Tell us what it was. Tell me whether you came back to round to bite you in the ass later. And I want to know how many of us are sitting in that same boat because Russ's argument is that accountability doesn't move just because your attention did. So what happens today you're on the hook for the decision that you never actually saw? Now, Russ, you draw a hard line between responsibility and accountability. An agent can carry one, but it can't carry the other. Break that down for us because most engineering orgs, they don't draw that line at all.

Russ Miles (21:56):
Yeah. We have that phrase of you write it, you run it, you take responsibility and accountability for it. Accountability though, so being responsible for something can be an assumed role. You can say, I take responsibility. That means someone will come to me and be able to hold me perhaps to account, but whether I can take accountability is a different quality entirely. So there's this idea that accountability is a position you take. It's not a role. I'm not just the accountable boss. I take a position and that position then requires you to protect your understanding of the decisions being made. Like any good, I suppose, manager/leader will know is that they delegate the ability to take responsibility for something and the package of decisions it contains, but they still will need to be able to come back and say, "What were the decisions? How did the decisions work together?" If they ever need to defend it.

(23:00):
And a phrase I use in the book, in an update to the book actually, is that accountability comes with a forum. It comes with a third party. It's that ability to defend your decisions. Being responsible, it means you can be responsible for producing. So I'm responsible for my PR, but being accountable is being able to defend and to be able to debug, as I mentioned earlier, defend, debug, and evolve what we have in front of us. And if you can't defend the decisions because your position is too distant, you're out of the loop too far, then that's a signal. That's a signal that says you need to find a mechanism to get back closer to inhabit the decision even if you are not in the room. There's a lot of research out there about your proximity and position to the decisions that are occurring. So what I try to do in the book through various mechanisms is show that as agents and agentic teams become more capable of delivery, of its entirety, of being able to look at a PR and go, "Really, they're building as good as I would write." That's not the only point.

(24:15):
That isn't the point of surrender because you are still accountable for the decisions they're making inside that code, inside that system. In two or three months time when the system falls over because some retry logic was pretty much LDTM when the PR came through and maybe you didn't even look too closely at all, then that's you on the hook. And I'm very clear that agents don't take accountability. It's not something they can do. There's been even legal cases in more recent times where we've shown that there is no precedent yet established forever going to an agent and saying, "You're accountable." Not even an LLM vendor. No one on that side is accountable. It is you. The human is making the decision. This even goes back to, I think, I can't remember, I don't want to paraphrase it too badly, but there was a lovely phrase in the early...

(25:11):
I think it's the operating user manual of the IBM computer systems where it said humans are the ones that make decisions. No critical business decisions should be given to a computer to make. Well, I'd extend that and say we need to have a framework for discerning what decisions really count. And when we have that framework, we can then go, okay, how do I retain close to those decisions? How do I get close to them so I can still retain that defensibility? And I give some examples. So one of the things I say in the book is that decisions are gathered around goals. So you have a thing that you are trying to build, a thing that you are trying to do, a change that you're trying to shift, a goal described like that. And then you look at it, the question to ask is, it comes out of Carl Popper's ideas of falsifiability.

(26:02):
If you think of every change to software being a hypothesis, I think I'm putting this out there and I'm going to see if it lands. But truthfully, if I'm following the poparian view, I'm looking for falsifiability. I want to make sure, I want to see if it doesn't land. That's where I'm interested. If you take that perspective, then the critical dimension to a decision is its ability to be reverted, to be gotten rid of, stepping back. And if you think about life, your decisions in life have a similar property. You would say it's a big decision if reversing it is extremely painful and you say it's a small decision. Our language here is interesting, big or small. Decisions have the same size physically, but anyway, big or small is based upon our ability to roll it back. And so when a software engineer is working on a specification, high level spec to give to perhaps an agent team to produce it, one of the things they need to stay close to is what are the decisions being made in there and how easy are they to revert or roll back?

(27:13):
Because if decisions are made in there that end up being what I would quantify the big decisions because they're hard to roll back, maybe there's a database migration in there. Everyone thinks we can roll back a database migration, but no one likes doing it, right? So maybe it's one of those things in there. Well, that's the sort of thing I'd want the agents to tell me about. I don't really care if they've written the perfect line of Java. I really want to know that they're doing something that's going to be hard to back out later on and including shaping the stories and the package of deliverable that I'm putting through so that I'm trying to package the minimal set of ideally reversible decisions as possible so that I can try this thing and then revert it with a high degree of comfort. So you're always looking for small decisions.

(28:04):
Shipping of small decisions is ideal, not always possible, but ideal. And staying close to that is the human job because it's our human job to not necessarily weigh in on every decision, but to be close, positionally close to the big ones so that we can then be held accountable for them because we were close enough to them. So that's some of the hypothesis that's in the book anyway.

Nicky Pike (28:31):
So here's the part that stuck with me. Russ just said that accountability is a position you take. You can't hand it off, you can't split it up, and there's no legal precedent anywhere for pointing at the agent or the vendor when it falls over, which means that that retry config nobody really looked at, the one that takes the system down three months from now, it's got your name all over it and the decisions big enough to hurt you are the ones that hide the best. Now, here's where it gets good. Russ has lived every bit of this himself. He told Claude to go build while he went to bed. He threw away an entire day of work in Nashville because he couldn't understand what he had just made anymore. And he's built a set of agents whose only job is to get in his way, including one that tells him to take his hands off the keyboard.

(29:18):
Then he ignored all of them for eight straight hours. He's going to walk us through what he built and why he blew right past it. So stay with us. Well, now we were both at Prodacity here just recently and I had the joy, I had the honor of following one of the talks that you did. And there was part of what you said in there, one of the part of the talks that you talked about was that nobody asked the question about how AI actually thinks. When we were talking backstage, you even said that slide is, when you start to explain it, it's the one where kind of the room glosses over. When we start talking about decisions and the accountability for that, is that one of the major things that people are missing in being able to really take accountability for what the AI is doing?

(30:00):
Do they not realize how this thing thinks and what the process it goes through?

Russ Miles (30:05):
I think it's a lot to ask anyone to know. As you say, the eyes do gloss over and I try and treat it very lightly. Admittedly, I go to reference frames, which is a little deep, but I talk about the fact that the human brain is aware of a 3D where it's tuned for a 3D world. It builds a 3D world to a large degree in each cortical column, and it has the reference frames for it. It's why we know when we go into a room, we can know if something's moved. We don't always know how we know, but we know something is moved because our brain is extremely good at understanding the 3D world that we inhabit and building a model of it and also understanding consequence, knowing that there is danger in the world for certain decisions, for certain outcomes. An LLM doesn't have any of those things.

(30:54):
It doesn't think that way. Its thought processes are based upon token manipulation and trying to find proximity to guess the next best sentence for you to hear. And I'm not trivializing, I'm not trying to downplay it. I think what LMs can do is astoundingly fun and extremely helpful, but it's limited. And because it doesn't, at least in its current incarnation, and I would argue perhaps for all time in the case of LLM, because it cannot inhabit that 3D world, it doesn't understand the consequence in those sort of ramifications, it isn't going to be ever held accountable because it is guessing sentences. If you look at what it's doing under the hood, it's guessing sentences and that's good where it's guessing the next piece of information you might want to see. And that's good and helpful, but it doesn't make it a party that can be held accountable.

(31:53):
So back to your point, I try to explain how LLM's cognition works, including how it's stateless under the hood, underneath your Claude code session, there is a stateless exchange of information, but more importantly, why it is trained in such a way that is trying to satisfy and please you. And when you understand its biases over yours, because I do love it when we say, oh, well the models are biased. Have you met humans? Have you met them? But there's always biases. These are the short circuits of our cognition and they're in LLMs and they're in us, but they're different. They're fundamentally different. So again, I think the key message really that I try to convey is that LLM doesn't think like us. And that's okay, but we have to remember that because a lot of the time it looks like it does. And it's very easy to fall into the trap that Richard Dawkins did where he started to anthropomorphize Claude into, I think it was Claudia.

(33:04):
I think it makes me cringe slightly. And even to the point where he's convinced that it has consciousness. And what it really had, I love the experiment. If you ever watched the video, it's great fun. But one of the things I point out is that actually it's a good study in how to flatter a college professor to the point where they'll believe someone has consciousness. So if you're a student out there and answering to Professor Dawkins, then you know exactly how to get a good result.

Nicky Pike (33:33):
Well, and that's one of the things that kind of gets me with AI, and I think it's a trap that a lot of people fall into is when you're working with AI and you're working with these LLMs, the work that you're doing with them, it feels frictionless. And when there's no friction, it makes you feel fluent in what you're doing. Now, you had made a statement, that's exactly where most people get in trouble. When they start working with this and they lower the friction, they start to feel more fluent and they start to actually put more trust into the LLM than they actually should. So what do you think is actually happening to a developer in that stretch? When they're developing and they're looking at this and now all of a sudden everything's much easier, that also comes into accountability because just because it's easy doesn't mean that you're not responsible for what comes out of it.

Russ Miles (34:17):
I mean, I can speak from personal experience on this one. So I told the story on stage of being at 10:00 PM and doing the one thing you must never do, which is saying to... I think I actually explicitly said to Claude, "I'm going to bed now. Can you please stop asking me questions and just do the work now? Here's the thing I want. I'm going to go to bed and I'd like to see the PR in the morning." And I woke up in the morning and I looked at that PR and I realized several things. But number one, nothing wrong with the PR. It was okay. It's all right. At least I think it was, but I'd lost all context of what I was trying to build. I'd lost all touch with what the code base had. I basically spent the entire previous day building the wrong thing, but building it in an environment where there was an awful lot of reinforcement that I was building the right thing.

(35:12):
I did that at Prodacity. I spent my first day at Prodacity sitting at a table talking occasionally to beautiful, wonderful people around me. And then at the same time, if anyone saw me, they saw me tapping away or Claude in the background and I was developing a whole bunch of things that I threw away at 8:0 PM that evening. I threw them away. Why? Because I couldn't understand them anymore. So we call that cognitive debt. It's this inability to understand what you have anymore because you've outrun yourself. You've outrun your ability to create a mental model. You've certainly outrun any awareness you can have of decisions that have been piling upon each other in what you've just built. And so I threw it away because I worked myself into a dead end and I couldn't figure out how to fix it. Why? Because couldn't understand it anymore, my friend.

(35:57):
I couldn't understand it. So that's not the only time. There's the 10:00 PM incident, that's the 8:00 PM incident of Prodacity. I mean, thank goodness that Nashville was full of celebration of Dolly Parton that evening. I could go out and enjoy the evening and sort of cry into my lemonade whilst listening to Dolly and realizing that I'd delivered nothing in a day and used lots of tokens in trying to deliver nothing. But I though I have a story and it comes back to that fluency. I felt good for that entire experience during that day. I felt good. I felt I was making progress. But the 10:0 PM incident that happened some months ago, I mean we're talking about six months ago, that incident had caused me to introduce what I call the sentinels. These are agents whose responsibility is maintaining human understanding. They're there to keep me in a healthy position of judgment, discernment, and understanding.

(37:01):
And so I built those sentinels and they were in my working process when I was in Nashville. So what I could see is me ignoring them all day long. They were screaming at me from about midday onwards that you've made a lot of decisions, Russ. Here's the decisions you've made. Do you understand them? Do you want to take a moment and look at them? These are all built into sort of runtime hooks of claws. So they're telling me as I go, stop, but I'm ignoring them because I'm in flow. I'm at the slot machine. I'm placing one more bet, just one more. I'm sure this is the one where I win the jackpot, which by the way is a pattern of dopamine usage and injection, if you like, that does happen when you're doing this level of development, this type agentic development. And so even though I had the sentinels and they were trying to inject friction, they were too gentle with me.

(37:56):
And so I was like any good slot machine addict, I kept going. But again, I made an interesting sort of read back historical retrospective at the end of the day looking at all these messages that have come up going, "Yeah, you've context switched 20 times now whilst the maximum you're supposed to do is four. We've watched the way you behave and context switching is a problem and this thing. It's all there, but I'm ignoring it. I'm still tapping away and kept going." So back to your point around fluency, the answer is in, I think, the right amount of friction and delivered in the right way. And I'm still trying to figure out what the right way of delivery of the friction is because I'm not a big fan of a Sentinel saying step away from Claude now. I'm not going to allow it to launch for the next 15 minutes, 20 minutes because you need to go and take a rest.

(38:46):
I don't think the Sentinels are that strong yet for me to believe it to allow them that much power, but that's kind of what needs to happen. It's a bit like in the UK, we have a system when people are gambling where they start to get reminded that they've been doing this for a long time and they're spending a lot of money and maybe it's time to take a break. I think we'll end up with the same mechanisms inside of Claude eventually, if not made by people like me, maybe maybe by people like Anthropic, because there's a really good reason why this is important. It's not just about token usage or the waste of time or anything like that. It's to do with the fact that we know in advance that judgment is a reservoir and it can be exhausted. It's exhausted fastest by context switching.

(39:39):
It is also exhausted by your circadian rhythm. So earlier on in the day is a better time to be making big decisions, not later for most people. And then there is, all depends on your rhythm. And then there is the how many judgments and decisions you've made, raw tally of how many things you've weighed in upon. And that's one of the weaker signals, by the way. I always though that would be the big example. If I do 50 big decisions, I better stop today. But no, that turns out not to be the most powerful thing. It's more the context switching that is the more limiting factor. And the point being that you lose touch with your decision-making reservoir, you're no longer able to execute great judgment, which has a problematic side effect because you can't judge that you're no longer good at judgment. So it has this toxic inter-affair of, oh my goodness, I actually cannot make a great judgment anymore and I don't know.

(40:35):
It's a bit like someone saying, if you've got a problem drinking alcohol, it's a bit like someone saying, "Just stop." And you go, "Yeah, but once I've had two or three drinks, I no longer have any concept of judgment to stop." You realize that, and it's the same with this. You're too tired to know that you should make a different call and stop now. So that's why I have the Sentinel, it's called the reservoir warden. It sits there in my working process. It reminds me, Russ, you probably need to step away now. You've made a lot of decisions. It's a lot stricter since Nashville. It doesn't prevent me from working, but it does scream a little louder. And again, it tries to help me make good decisions, me make good judgment, protect my reservoir.

Nicky Pike (41:15):
I love the fact that you talked about how you built these sentinels to keep you in line and you ignored them. And that's proof that the dopamine hit absolutely can override good judgment sometimes, but that's kind of why you built the sentinels, but then you ignored them, so then you had to go strengthen them up. You've got the reservoir warden. I want you to talk about the other sentinels that you have because I love some of these names. They're very descriptive. So tell us about the other sentinels that you have and let people know how those work.

Russ Miles (41:42):
So very first, the sentinel agent does not change any code. It doesn't have any right capabilities. So when I set out permissions for sentinels, one of the things they mustn't be able to do is change anything. They literally cannot. They can write disc, they can write files, but they can't change anything that's happening development-wise. So that's one of their, if you like, their contract. The other thing is what they can do is surface things to me. So I have the choice cartographer, I have the Advocatus Diaboli, and what else? I have the Carpachio agent. Now the Carpachio agent is on the cusp of not being a Sentinel. I should warn you of that. It does actually provide a mechanism of manipulation in my workflow. But just to talk briefly about those, because my favorite is usually the Diaboli just because I love using Latin terms like that just because I'm a bit of a word geek.

(42:34):
But I'll start with the choice cartographer because I can make another reference to Kevin Henny again, because he came up with that one. He did many talks in the past where he talks about using a pattern is a set of decisions and you need to be aware of what those choices are and what you get for those choices and compare those choices. And one of the things he advocates is to explain decisions as stories, that every decision is a story, as a reason around it, a context around it. So the choice cartographer does that. What it does is it looks at what is going through your specifications and your implementations and it's surfacing stories for decisions. It's saying there's a story here, there's a decision here. Are you aware of it? Do you want to understand it? Should I keep a record of it? And what that does is help me stay close to decisions that maybe I am not in the room for.

(43:28):
So there's decisions my agentic teams may make where I wasn't around. Things like a retry number or something like that. The choice cartographer would typically pick that up and say to me, "Russ, I've spotted a decision and here's the story around it as far as I can tell. And I've asked the agents to explain why it's the way it is. Here's the story around it. What do you think of it?" And so that's a way of keeping me close to the decisions through the mechanism of very short sort of stories, contextual stories around them. So that's the choice cartographer.

Nicky Pike (44:02):
So let me ask you a question on that one. Why stories? Why not just here's a response or why did you put stories around this?

Russ Miles (44:09):
It helps with understanding the trade-offs of a decision. So it's like someone coming in saying, "Right, I'll do this to you now. I've ordered Chinese food. I made the decision to order Chinese food." That's a decision. A story would go, "I looked at all the other options and the curry shop shut and the fish and chip shot, we had that last night. We really can't eat and that is killing us. So now I've gone Chinese because it seemed the better of the two evils. And so that's the decision I've taken in this particular moment." That's a story. By story, I mean something with a little more narrative than just here's what I did.

Nicky Pike (44:54):
The context behind the decision.

Russ Miles (44:56):
Yeah, and the trade-offs as well. It's got to be some of that, "Here's the options I explored." It's really important for a accountable person to know what options were explored. To defend a decision, I need to know what was not chosen. And so that's why the story again is so important. So that's the choice photographer and it gets involved a couple of times in my workflows. The other ones, let's go to the Carpachio now. Let's go to the controversial one. Carpachio is fun because what it looks for... Okay, so I'm doing a talk about this in Vienna next week. I'm doing a talk which is called Does AI Deliver Waterfall? And the answer is no, if you configure the workflow appropriately. And one of the things you have to do is slice for the smallest verifiable piece of value, which is usually the smallest package of decisions that you want to verify and ship.

(45:58):
And that's what the Carpachio agent does, is it tries to look at a spec for something you think you want, however detailed you've made that spec is up to you, and it looks for a slice in it and says, "What if we just did this? If we ship this, then these are the decisions I can see in here. The choice cartographer has worked with me on this. These are the decisions I can see." And that gives us the minimal set to start to verify these decisions when we have built something with them. So we have a falsifiable hypothesis in this decision and it's the smallest thing I can see that we can build. All of this comes from elephant carpatchio exercise that Alastair Koben runs when he's saying really explore something you're trying to build and rather than going, "Here's my big spec of everything I want or here's my little spec of everything I want, good luck with the decisions with that one." Rather than do that, which is what waterfall taught us was a bad idea, let's go for a more agile manner of going, "Well, let's take the finished slice and see what that means when it hits the real world." So that satisfies things like Dave Farley's scientific approach to software engineering where we're trying to ship hypotheses and see how they land and whether they can be reverted or falsified, and it fits with agile as we've been working with it for some decades now.

(47:23):
So yeah, I find the Carpachio brilliant fun. My favorite agent though, if I may -

Nicky Pike (47:28):
Mine too.

Russ Miles (47:29):
Is the Advocatus Diaboli. The reason I love this agent is because it saves me money, frequently saves me a considerable amount of money. It's also the most irritating agent I've ever made. It's what happens usually. And this, by the way, happened... I should tell you, this is a concrete story. It's what happened in Nashville, my friend. So day before I go on stage, I'm making all the wrong moves whilst trying to get something built. And the Avocadis Diabele is telling me this in its own obnoxious way. So what I'm doing is I'm building a spec for a change to my AI literacy superpowers, and I think it's going to go great and it's looking pretty good. It's gone through the Carpachio and it's come out with the smallest thing that it thinks we can build. And then what happens is this Diaboli looks at it, looks at the spec, the small spec and goes, "I don't like this." There's a lot of decisions in here, big ones, critical decisions.

(48:25):
And what the Diablee does is object to them. It says, "Look, there's a decision here and I don't think we've got any evidence for this. I think you need to get closer to this and understand it and you need to weigh in on it." So it does two things. It challenges the spec, that's the practical thing. But an even more valuable thing is it forces me back into the room near the decision. I am back there looking at it and I have to defend it and go, "Right, I understand why this decision is being made and we're okay. We can move on this." And what happened is, and this is what actually happened in Nashville, is the Diaboli was going, "I don't like it. I don't get it." So I was weighing in and I was discussing it with Claude and going, "Right, okay, maybe the spec should change and we need to do this." And I did this probably six times, and every time it hit the Diaboli and the diabelee went, "I've got critical concerns about this," and it was right.

(49:26):
This thing should not be built. It was basically saying, "This is too complicated. I don't understand it. It doesn't look right for the code base. Think about it again." And this is another one of those pieces of friction that was telling me I need to stop with this. The Diabele was absolutely earning its money because it was turning around saying, "Before you build anything, this isn't right. Russ, this doesn't make any sense." And I was obnoxious enough and possibly multitasking enough with my machine in listening to the talks and everything else that I was just like, "Oh, please keep going. Please keep going. Keep trying." So the reason it saves me money is that it usually is so obnoxious at the beginning that it is challenging all my assumptions about why I should build this slice. And more often than not, if it proves to be a real problem, number one, we've struggled to find a slice.

(50:26):
So that's the first thing that's usually a smell. And the other thing that it'll point out is you're going to do this with no evidence. You don't know why you're doing this. And it's one of my favorite answers because as a product owner, it's one I hate the most. I love it, but I hate it because it's basically saying you've got no evidence for doing this thing. Now, I have to speak to a little elephant in the room now, which is the phrase I heard a couple of times at Prodacity actually was that code is now free. Code has no cost. Okay. Well, I've seen token costs and I've seen time and I've seen, and the most critical cost of all, the economics of attention, human attention is a cost. So when you take those three things, token cost, and so you've got tokens, you've got attention, you've got all these things layered in, then it's not free.

(51:24):
And what the Diablo is doing is it's going, "Before you spend a whole lot of human attention on verifying this at the other end of the pipeline, and before you spend a whole lot of tokens on something you have no basis for having, question it. Let's use some tokens right now, but not many, to question whether this should even exist." And I find that so powerful and helpful and so annoying that it is perfect in many respects. It's one of my favorite agents, even though if it wasn't there, I still have that strange sense I would get more done, which I would. There'd be more output, much less outcome though.

Nicky Pike (52:04):
Well, I mean, come on, Rush. You named it the devil's advocate. That kind of tells you that you need to listen to it. You say it saves you money, but it only saves you money if you actually listen to it, right?

Russ Miles (52:15):
Yes, true. Very much true. Yeah, I wish I did, but the stories are there to explain why I didn't.

Nicky Pike (52:23):
Yeah, I'm with you. Now, we're coming up on time, so a couple more quick questions for you. If people want to look at what you did with the sentinels, is that out there for people to look at or is that something that's proprietary to you?

Russ Miles (52:34):
No, it's always free. It's open source. I've spent my entire career in open source land, so the AI literacy superpowers are available under the habitatthinking org on GitHub.

Nicky Pike (52:45):
Okay. Well, we'll make sure and put that in the show notes so that people can go and look at this because yeah, your naming of these sentinels is one of the greatest that I've ever seen. I love everything about it. It makes them fun as well as useful. All right, so to wrap this up, we're going to go through a quick rapid fire. I'm going to ask you a couple questions. Tell me the first thing that comes to your mind. Don't put a whole lot of though in this. Ready?

Russ Miles (53:05):
Okay. Yeah, I'm ready.

Nicky Pike (53:07):
All right. Agent or colleague, which word do you actually use with your team?

Russ Miles (53:11):
Agent.

Nicky Pike (53:12):
When it comes to AI, agent. Frictionless or defensible? Which one would you rather have?

Russ Miles (53:18):
Defensible every time.

Nicky Pike (53:20):
What's the best time of day for you to make the hard calls?

Russ Miles (53:23):
Now for me, and I should be careful here, it is only for me. According to the rhythms that Claude has gradually realized I work to and make good decisions on, big decisions in the morning.

Nicky Pike (53:33):
And the one thing that people are auto-approving right now that you think is going to come back to bite them in the butt later?

Russ Miles (53:38):
It's always things like retries, non-functionals. The devil in the detail of those things are the things that are subtle, they come back to bite us. They're the reason people like Adrian Hornsby do so much brilliant work around resilience engineering. So yeah, I mean, I don't want to put Adrian out of a job, but he's going to be kept in the job brilliantly if we keep auto approving things that contain all sorts of interest and characteristics like a retry configuration. Well,

Nicky Pike (54:02):
And it goes back to your accountability. You got to look at the details as well as you do the big picture, I think is what I'm kind of getting out of what you just said right there.

Russ Miles (54:10):
The big decisions hide, right? So what you need is the agents that can detect the bigger decisions and then come back to you and go, "Are you close to this?"

Nicky Pike (54:19):
Gotcha. All right, last two questions. So one's going to be a prediction. Russ, it's 2030. An agent is making calls inside of regulated companies and it's cost somebody some real money. Put a number on it. What are the odds that a court will ever hold a vendor accountable instead of the engineer when it comes to AI making a mistake?

Russ Miles (54:38):
I'm going to say 0%. It'll always come back to the human, the engineer, or it'll come back to the engineering company.

Nicky Pike (54:44):
So there's no use case that you see where we're ever going to give an agent agency. It's always going to be, and I think that's kind of your point here, there's got to be a human that's going to be accountable for what AI's doing.

Russ Miles (54:56):
Until we can create AI that can maintain a model of the world in the way we have it and can understand accountability and consequence the way that we can as humans, then you cannot be giving the current batch generation of AI any implied accountability.

Nicky Pike (55:14):
I gotcha. All right. This is the last one and this is the one that I ask everybody, Russ, you went from writing defense software to where somebody actually had to own the call, you've written nine O'Reilly titles, you've written two and possibly we got a third coming up, to building a team of agents that cut you off when your judgment done. All of that in consideration, what does it mean to you to be a coder?

Russ Miles (55:39):
So I would question the phrase, I don't think I've ever considered myself a coder. I've always considered myself a software engineer and software developer maybe at times. So for me, what it means to me is owning the decisions that produce an outcome that means a lot to the people that are using it. And by that, hopefully a positive meaning of a lot to those people. So I've always been that sort of software engineer that I'm proud of my code, I'm proud of what I can write, I'm proud of what I can construct, but ultimately there is no pride, no feeling like it when you give someone something they need to do to navigate their world, their job, and it's of true value. So I'm not a big fan of output, I'm a big fan of outcome, and that's how I calibrate my world.

Nicky Pike (56:27):
Love that statement. All right, man, well, we appreciate having you on. It's always fun, Russ. And for those that haven't, go look up the Predacity event that happened a couple weeks ago if you want to see Russ in the cowboy hat, it was the coolest thing I saw during the show. Russ, can we consider you a full-fledged member of the [Dev]olution now?

Russ Miles (56:45):
I certainly hope so. Absolutely. I'd be honored.

Nicky Pike (56:48):
All right. Well, we will talk to you more. Thank you for coming on and we look forward to having more conversations with you, Russ. Appreciate you.

Russ Miles (56:55):
I hope to come back soon. Appreciate it.

Nicky Pike (56:59):
Thank you for listening to [Dev]olution. If you've got something for us to decode, let me know. You can message me, Nikki Pike, on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.