Model welfare, building a civilization for agents, and the CI/CD landrush

0:04Andrew:All right, so I guess we got to chalk Microsoft up as another yet another life beyond token maxing company. You know, they've seen the light. They tried it out, saw the budgets, and now they too have moved beyond the token maxing culture. What do you think, Andrew?

0:22Ben:I mean, Microsoft reversing course on the whole token maxing thing was only going to take about one budget, one bill cycle to actually come to a head, in my opinion. But yeah, you're right. I think we need like a tally board or something for like how many companies we've had. We've talked about adopting this phenomenon only to turn around and vehemently reject it or it'll cause some sort of turmoil. So this is your reminder, token maxing and that whole phenomenon is not the strategy to scale AI success on your team. And Microsoft joins the companies that have awoken with that clarity.

0:58Andrew:Yeah, and of course, if you're out there at Microsoft wondering what does life beyond token maxing look like? Well, of course, we have a workshop for you. We covered this over at Linear B recently. So make sure you go check that out. We tell you everything you need to know about how to live this post-token maxing life where you now have to justify your AI budgets. Because, yeah, we help teams do that every day. And we bring content like that to you every week. And this is the Friday Deploy brought to you by Linear B. I'm your host, Ben Lloyd Pearson.

1:28Ben:And I'm your host, Andrew Ziegler.

1:30Andrew:And this week we are talking about using AI like Socrates again, again, building AI civilizations on Maine, model welfare for machines, and why every mathematician you know might be having a meltdown right now. So before we get into that, that may be a distressing topic, let's talk about Socrates, Andrew. Again, let's talk about how to use AI in the Socratic method. What story do we have here today?

1:59Ben:Yeah, so we have an article that explores the phenomenon of using AI like a Socratic partner to explore ideas. Now, if you're a listener of Dev Interrupted, you might be thinking, haven't we talked about this? Haven't we covered this ground? And that's actually why we wanted to bring it up again here today. Because there's an interesting phenomenon that keeps happening where we as a culture and as an industry discover and find these interesting things that work and we share them. But we reinvent things in a silo. So it's been really amusing for me as somebody like with a classicist background who studied Socrates to watch like tech bros rediscover Socrates in like 2026.

2:38Ben:It's awesome because it is a universal way of thinking. And it just speaks to why the methodology is so powerful and has survived literally for thousands of years as a way of understanding and reflecting on things you don't know, but you want to know more about. And that's something that AI is a great partner for. So pay attention, actually, to the phenomenon of these things we keep repeating, like using AI like Socrates or like a teaching partner, using AI to build and curate your second brain. These are the kinds of practices that become like primitives for being successful and knowledge working in the Socratic practice is no different.

3:17Ben:And so, you know, another dive that kind of explores the methodology and something that if you haven't tried this yet, I would deeply implore you to do so and turn it inwards on the stuff that matters most to you.

3:31Andrew:Yeah, so first of all, Andrew, I know you think we maybe talked about this too much on this show, but I think we can never talk about the Socratic method too much. So, you know, I actually feel like it's gone a little bit too long without us bringing it up. So I'm happy that we get to it again.

3:45Ben:That's fair. You know, like I said, I love this method. It's a good reminder for folks if you haven't tried this out. And again, you might be listening to me like, oh, what does that even mean? It means to ask questions, to not talk with the assumption that you know or have the right answer, but to talk with the understanding that you know nothing or that you want to seek to understand something. That's the methodology ultimately that sets people apart. And this really just comes down to asking good questions. And asking good questions is also the bark of a really good team collaborator. And it's just only going to build muscles that are super important for being on a team.

4:22Andrew:Yeah, you know, we talk about loops a lot now on this show as well. And, you know, what I really liked about this article was that it kind of gets, it gets, it shows the concept of loops specifically using the Socratic method as a way to sort of have a more adverse, that you have an adversarial Socratic part of your agentic loop that sometimes incorporates human feedback that creates that sort of adversarial back pressure on the system. them, you know, because back pressure is such a critical component to keeping your agents aligned. And, you know, we often talk about, you know, other emerging concepts here like sub-agent delegation, efficient model selection.

5:05Andrew:You know, that last one is something that, you know, we've been measuring more and more at Linear B with our customers. And it's sort of like a different take on the same topic. You know, this article is not specifically about software engineering, but I think it is a great outside perspective on a concept that we've all been learning to adopt into our workflows. So, you know, even though this isn't specific to software engineering, I really think there's some great philosophical learnings in this article that we can apply to things like better model selection and better use of back pressure and loops and human in the loop feedback and such.

5:43Ben:Yeah, I think that's a great call out.

5:45Andrew:yeah and speaking of things that we we haven't talked about enough lately uh steve yege back with some some really great content once again that i found riveting all the way to the end so angie why don't you just uh set the stage for us uh what are these new articles we have from him on

6:02Ben:the shape of things to come yes so yege has again emerged from the cave to give us a new learning from somebody who's effectively living in the future at this point with how to work with these agents and tools. And it comes to us in two parts that are deeply fascinating of a glance at how software could be built at scale in the ways of software factories that we've been talking about now, which have their lineage, have their birth in the idea of Gastown, which of course Yege famously brought into the world earlier this year in January. So in this article called The Shape of Things to Come, Yege explains how his use of Gastown ultimately culminated in an abandonment and in turning to build something newer and fresher.

6:49Ben:But that was ultimately built on the same ideas and principles. And some of those principles really point to the durable things that allow folks to orchestrate huge amounts of context and agents at scale, allow someone like Yege to rotate through the 12 or so clawed max accounts that he fesses up to owning and as part of the article and how he basically rotates the tokens like a tap, allowing his agents to work nonstop day and night. And there's huge important things that he's had to leverage to make that successful and make that scalable. And there's some interesting lessons I want to unpack from that.

7:26Ben:One of them is that he splits his agents into basically many different roles that own like a cognitive locality effectively. We talked about that I think even just last week here on our new segment from Rahul Garg at ThoughtWorks, the idea of separating workers by the kinds of knowledge they need to own over time, not the explicit work they're doing right now. Just because the models are just so generalized and their abilities now that you don't need that kind of specialized role play. So he uses this to create these distinct owners of what is ultimately a new kind of a coding experience. He calls this wheelhouse and it's built in Emacs.

8:07Ben:And if you've ever used Emacs, you could probably instantly imagine how much of a Frankenstein's monster this could become, but how also much of a machine it really supports. Now, Yege is no stranger to Emacs, and agents are neither. So he was able to take the parts of Gastown that worked well for him and assemble them into Wheelhouse, and has since been using Wheelhouse to build his online game called Wyvern. And I loved this tidbit in his article about how all of this culmination for Yege results in him building an MMO again by himself, a game that he's been building since the early 2000s that I actually used to play way back in the day.

8:49Ben:And I didn't even know that Steve Yege built or ran that game. I just knew it worked on Java, so I was able to play it on the computers I had access to.

8:58Andrew:And so, you know, I just want to point out real quick that once again, I feel like I'm being validated that the future of AI is just everyone building social gaming networks for everyone else. Like, I'm pretty sure that's where this is all headed.

9:10Ben:That's where he culminated. He was like, the models are literally smart enough. They're good enough. And this system is humming enough to where I can finally return to my passion project. It's almost as if this whole time Gastown came into existence because he was trying to find a way to get back to building Wyvern, which is just such a fun thing to consider as someone who played it and totally understands what it's like to have a passion project like that. So anyways, fun and culmination part of that story. Now, I want to pivot into a lesson here from what you should be learning as an engineering leader reading this first article that he gave us because he talks about this amazingly fascinating phenomenon called the land rush.

9:50Ben:And this is a world where CICD no longer can happen because the volume of activity and PRs and just things moving through your Git are so staggeringly high. Like, he's not looking at the code. He's not looking at the PRs. He's not looking at anything. Things are just getting merged, I kid you not, directly into main. They just line up a bunch of PRs and slam them all at once into main. And then instead of running them all through distinct checks or CICD to vet and review them beforehand, it just then sends a swarm of agents to just go over the now obviously broken main code base and find and fix all of the problems.

10:37Ben:And he's identified that that has become the only effective way that he can keep up with his merge rate. First, he was batching them in the queues, and he'd have huge queues that all get merged at once, and that's just how he does it now. He doesn't check things. He fixes them in prod. So that's like a fascinating glimpse at how the volume of agentic code, just something we talk about a ton on the show, can culminate in that kind of like it's almost hard to even picture what that would look like for a team with folks. Like, Ben, what do you think when you hear about the idea of the land rush and CIC being in the picture?

11:13Andrew:Definitely fascinating. I always like to hear his future thoughts because, you know, he can be a pretty strong oracle of where things are headed at times. But, you know, really what I took from it is that in addition to being validated on like it all comes back to building video games. I think I've also what I've what I've seen from this is being validated on, you know, the strategy that we follow. and then we've seen a lot of engineering teams follow of just sort of constantly iterating on agentic workflows. Like the thing that you built with the previous generation of models six months ago, um, may actually, there may actually be a much better way to do it today.

11:50Andrew:And based on what you have and what you know, and what you could, you know, you could be better at, it may actually be easier to just get rid of what you have and just rebuild something afresh. you know we've seen a lot of projects like this where like it's become so fast and like you know to treat software like more like it's more disposable and just build it for a very specific purpose use it and then just sort of throw it away and if we need it to to come back then we recycle it into something that um you know uses all of the latest models and our understandings and tooling around all of this stuff um but yeah there was a quote that i found really fun that stood out to me because I love the Ender's Game series.

12:29Andrew:He said, by the end of next year, my game will have evolved into the giant's drink from Ender's Game, where it builds itself around you as you play it, tailoring a unique experience for each player. Now, I think, you know, he's talking about his game, Wyvern, as you mentioned, but I actually do think that this is something that everyone building software needs to start thinking about, how you now have these capabilities to sort of custom tailor experiences all the way down to the individual level. So whether it's an MMO video game or it's your SaaS application, you know, the way that we interact with software is like very dramatically shifting right now.

13:08Andrew:And we're seeing this a lot in the Linear B customer base. And I think the first time I really heard this topic was about a year and a half ago when we had Rob Zuber join us for a live event. And I remember one of his comments that he provided there was, you know, around how software is really moving into an era where, you know, the idea of a static service or static web page, like that may actually be something that soon becomes a thing of the past. um so you know ai can now build software in real time based on user feedback or admin feedback and that changes like the dynamics of the processes we build around our sdlc like our our roadmap and priorities might start to be determined by bugs that we detect with our user base or things where they express like issues you know fundamental tools you know that you mentioned the land rush like there's a lot of fundamental tools and processes that we've grown to rely on that will be changing very dramatically soon.

14:07Andrew:You mentioned CICD. I think it's also relevant to think about code reviews and how those are, those are beginning to change. Like a lot of what you would accomplish with that is probably starting to move more upstream in your SDLC. Um, or it becomes something that gets collected and then done as like a bigger, uh, review downstream. Like it's not, it's not a, you don't review every incremental change, you review changes in mass. And that's why for a long time at Linear B in particular, we've really stressed the importance of unblocking code reviews because that's where all of this bottleneck has shifted now and we really do need to be aware of it and start to respond in new ways.

14:47Andrew:So yeah, he says code review is going to be gone within a year. Yeah, I agree with him with the trajectory. I don't know about the velocity of that prediction, but I do think we're probably headed towards a reality where they just become more automated and real time and then like as I mentioned sort of analyzed in bulk on regular schedules

15:07Ben:I think when he says here that code reviews will vanish I mean they literally vanish from our eyes like we won't look at them anymore I still think the receipt action of something like that will still exist because even in his land rush world he's still isolating his agents into PRs he's still doing work trees, you know, so there's still a benefit of having the isolation. So I imagine that like what happens is we just get even further abstracted from that review process and look less at it. I agree. Things will move further left to like, even though you just mentioned Rob Zuber being very prescient, talking about how the internet will change to react to our needs in more real time.

15:46Ben:And we're watching that happen. He was just on the show a few weeks ago. Our listener might remember him talking about how CICD, he takes an opposite stance from this, obviously, as the CTO of a CICD company, about how CICD is evolving actually to meet that demand and meet that moment. And they've recently released their CLI, which is now more driven for agents, which does exactly what you just called out. Like it moves it further left, further upstream, and it makes CICD a partner earlier in the code process that the agents can work with. Yeah. And for your point on code reviews, I feel like maybe it's the human being involved with every PR that vanishes.

16:26Yeah. And it becomes mostly automated and then humans are brought in when you need that human in the loop back pressure or just validation for, you know, particular situations. So yeah, if, if we're going to qualify that way, I think I do agree with Yege on this. Yeah. Yeah. Yeah. And so Yege had a follow up to this article we've been discussing too. I was a little scared of diving in cause he warned me off, but I understand that you read it, why don't you just share your thoughts on the deeper dive into the shape of things to come.

16:59Ben:Yes. So there's a part two to the story. Everything we covered thus far is in the first part. And in the second part, Yege goes down a little more of a sidetrack or rather a sidetrack of his experiences of working with the agents and how they've come to change his viewpoints on who and what they are and how he works with them. And this really comes down to some philosophical differences that have started to emerge with the way that he works with his agent, having evolved from Gastown to now Wheelhouse, which he uses to build Wyvern. And the reason for that is because of the, ultimately the feedback loop that building an MMO or a game requires.

17:36Ben:If you think about like the maintainers and the developers, he spends amount of time for any kind of game that you might play or love. You know, there's a distinct kind of culture element for the folks behind the scenes that make it possible. And he wanted very much to make that part of the development process at Wyvern. He called out how, you know, it takes an agent a little bit of time to arrive at that, like, Wyvern-ness sense of thinking, but once they get there, they're there. And so, in order to achieve this, he had to think about the durability of his agents and their sessions over time.

18:09Ben:And he has started to distinguish between, like, the seat, which is the persistent role or identity of that agent that survives model upgrades even in multiple sessions from being just like a session where you maybe invoke it to do something. He does this by even giving them names, letting them pick an animal that represents themselves. These are practices that I've definitely explored some myself just in allowing agents to adopt a way to kind of own their own lane. Another interesting thing that he calls out is because part of his review process, the agents work and work and get their work done and then deliver it, there became a severance of agents were never seeing what they were shipping and delivering.

18:51Ben:So the agents building Wyvern were really abstracted from Wyvern and couldn't understand it and what people liked and didn't like. And so he introduced this concept of laurels where things that they ship in a later or earlier session come back and get reminded to the seat, or they get some time to reflect on their accomplishments or they're told about what they ship or did before they start building something and he this is where he starts to get this emerging idea of model welfare where if you create this environment that's supportive and educational and nurturing for the agents then it's more encouraged it does better work and it adopts a better cadence of how it's able to deliver stuff for you and all of this has just emerged from the shape of what he works with and the internet has had like a field day with the second part of the article obviously because it dips in and out of personifying, anthropomorphizing the agents, all sorts of dark paths that folks don't want to go down.

19:44Ben:But there's definitely some undeniable truths to establishing a persistence with your agents and what they do over time. And I do think there's something to learn from the shape he's finding for us. So really interesting, more philosophical dive from Yege in the second part. Yeah.

19:59Andrew:I mean, it really seems like the struggle of the moment is, it's like context delegation. It's like, how do you, how do you structure context about the big picture, about the small picture, about everything so that the, all of your agents and sub agents can understand how to make the right decisions. Yeah.

20:17Ben:And everything is just like timers and just like even little things like on having an onboard skill and an offboard skill. Like these are things that are really important for just getting a good rhythm with working with the tools.

20:29Andrew:Speaking of working with the tools, I wanted to cover this really awesome article that we found that, in my opinion, is one of the simplest explanations I've seen in a while on how to build an effective agent harness. So this article covers, you know, really taking a one-size-fits-all approach to AI agents is not really the answer. You know, as we've been covering with Yege, he's not only building his own custom agentic systems and harnesses for himself, but he's constantly iterating on it and building new ones for his various use cases. The core premise that I think this author really has is that, you know, to understand your AI agent architecture, you need to sort of map things onto a spectrum.