Latest / Rethink Engineering / Bridging the Skills Gap: Insights from Agentic Coding Training

Transcript

Bridging the Skills Gap: Insights from Agentic Coding Training · Rethink Engineering

• speaker-0: You are listening to the Waves of Innovation podcast and I am DJ, your host. In this week's episode, I am talking to Mike Gayhard, a previous guest on the podcast. And this one's a little bit more unusual. Normally I invite people on and we talk about their work and that kind of stuff. But in the last couple of weeks at the time of recording, so much has happened in the world of agentic coding around the area of software factories. These are the ideas that basically you can get an entire team's worth of work done by multiple collaborating ⁓ coding agents think like Claude Code, where they review each other's work. There's been blog posts from OpenAI about how they've written a million line of code piece of software with no developers reading or writing code. Strong DM have recently issued or published their guidelines about how they've built a software factory. And again, humans are banned from reading or writing code and There's been a lot happening in this space. So Mike and I talk quite excitedly about this and Mike is building his own agentic software factory for kind of research purposes and to figure out where the future of the industry is going. So hopefully you enjoy this conversation as much as I did. I loved talking to Mike and it was really exciting. I thought sit back and enjoy. Mike Gayhard, it has been a crazy kind of week or two when it comes to agentic software development. At the time of recording, it's Friday the 13th, ominously, of February. And we have seen like in the last week or so, there was Simon Willison blogging about like dark factories and what's going on at Strong DM. Then Strong DM end up posting a website about how to make software factories and they're guidelines, what they learned and then what else has happened. There's so much happening that I can't remember all of the blog posts and all of the craziness, but you've been getting involved in this yourself, haven't you? Looking at building your own software factory. ⁓ speaker-1: have been. mean, anybody who's not trying to figure out where we end up is probably going to get left behind. So it's the interesting piece is I have a bachelor's in chemical engineering. So I worked in petrochemical refining for, I want to say two or three years before I got into software, designing and running oil refineries, which have had closed feedback loops for, I mean, that's how they control production mechanisms these days. Like everything we know that gets built, like the Toyota production system, cars, they're all built in factories and they're very intricate things. And now we're thinking about software factories. And I'm just like, ⁓ man, like this is going to be a collision of worlds. Like my old world of like going back to college and learning about closed feedback loops and learning about the mechanics of how those feedback loops work in like the physical world. And then being like, someone just built one of those. So do you know that the history of why they call them dark factories? speaker-0: I didn't when I first heard the term, but why don't you expand on that for our listeners who are probably, mean, it sounds like the sort of thing that's just catchy because it's got the word dark in it, like dark matter and dark energy, but go on. speaker-1: Yeah. So it's not like evil, but there are, my understandings, there are factories that have been built that are so automated that there are no lights in the factories because they don't need lights because there are no humans. And I think these exist. I haven't dug deeply to see like who's built them and where they exist, but there's a Wikipedia page about it. So it must be true. But yeah, like specs come in one end, software comes out the other. Chad Fowler, I don't know if you even know the name Chad Fowler, but he wrote. a series of blog posts called the Phoenix Architecture. So what does it look like if we burn the software to the ground? So immutable software like we did with immutable infrastructure. like everybody's talking about this and it's just crazy to try to like piece it all together. speaker-0: Yeah, yeah. And I remembered one of the other sort of blog posts that went live in the last week. And that was about open AI writing a kind of million line of code, a piece of software with no actual human coding involved. So maybe kind of to step back for the benefit of the poor beleaguered listeners that trying to figure out what the hell we're rambling on about. The idea of software factories kind of comes out of, or Gastown, which was one of Steve Yegg's projects that the blogosphere. at the beginning of 2026, this idea that you can put specs in one end, like a textual description of the software that you want. And then agents will break that down, devolve it into parts, and then just go and build it and you get software out at the end. So that was kind of pretty cool. And that's using multiple agents. know, but the agentic coding has been a thing for a while and people have been using like Claude code on their own. This is spinning up multiple agents and it's got agents managing agents and it's using Claude code to manage some of other agents. speaker-1: named after like Mad Max characters and like it's spicy. speaker-0: Yeah, that blog post is exceptionally hard work trying to figure out what Gastown's all about. speaker-1: The mayor and the all like the sheriff and Steve. speaker-0: Yeah, the deacon and the dogs and the pole cats and you know, who knows what else. So that was one sort of landmark moment when a lot of people kind of went, right, this is kind of next level stuff. But then there's been a few bits of conversation about, well, having humans review any of this is, you know, a massive bottleneck. ⁓ How do we go about verifying the correctness of software without having to read tests ourselves, without having to do manual acceptance testing? And kind of Gasthown has a bit of this in that there's the Polkats, the things that actually do the coding, kind of raise merge requests and there's something reviewing them and trying to assess them for quality and that kind of stuff. But with the folks at Strong DM. They were blogging about their approach to a software factory and the guiding principles are that no human should write code and no human should review code. So what do you do? speaker-1: And I love that. I love that they went back to like, what are first principles? Like, these are the things that we hold true and re-derive everything from that. Not like, ⁓ we practice XP or we test drive. It's like, these are the baseline, re-derive software from that baseline, which I love. speaker-0: Yeah, it's, um, and this is, you know, it's those kinds of, uh, picking fundamental principles like that. It's an experiment playing out in real time, which is one of the reasons it's so exciting to be in software development and paying attention to the agentic coding stuff at the moment, because nobody quite knows where this is going to go. So just finishing up on the kind of testing and correctness side. One of the more exciting ideas that has come out of that is, um, you should provide a description of what your software should do in human language. that's separate to what goes into your code repo. So the coding agent doesn't ever get to see it. And then instead you hold that back, the code gets delivered. And then another agent reads that human language description of what your system should do. And then verifies that the system does do that. Kind of like the original vision of user stories. know, user stories were not supposed to be given when then they were supposed to be like narrative descriptions of what people can do. And it looks like we've kind of finally got there, but that means the coding agent. writes all the code and all the tests and no one ever looks at them. And it all sounds quite bonkers to, you know, traditional software developers. speaker-1: So I want to touch on that. So I read that article and didn't quite understand. So they have the holdback set, which is the specification. What do they feed into the factory? Like they have to give it something. Like, did you catch what they give actually give it as the input? speaker-0: My understanding is it's the hold back spec is kind of like the same thing, but rephrased. So functionally, equivalent description of what the system should do in general. speaker-1: Yeah, I didn't catch that. I mean, yeah, I mean, all it is is a transformation. It's an input and an output and a bunch of side effects. But I think, I mean, yeah, it's crazy. I don't even know where to go with this. think focusing on inputs and outputs is interesting. You know, we could talk about theory of constraints. I mean, the theory of constraints used to be the bottleneck was humans slamming their fingers on a keyboard. We've removed that bottleneck. I think we can all agree that whether or not we like the code that an LLM is generating, It generates code and it is sometimes better than I would write, sometimes not better than I would write, but does it matter if it's better or worse as long as it works, which I think is where we're going with these specs is like, I never cared what the software looked like. I always wanted to know it worked. And when I made a change to it, that it remained working and it was resilient to change that I could make those changes fast enough to keep up with domain that was changing at the same time. That's kind of first principles of software. Architecture just exists because humans have a limited context window. So I think we've gone back to the essence of what we all wanted at the beginning, but because the bottleneck has changed, it's totally destroyed the economics of what we used to do. we're all struggling to figure out where the, like, what do we stand on next? And it's not humans typing at a keyboard. speaker-0: It's presumably a lot more outcome driven, which for those of us who have been trying to stop technologists focus on transmogrifying widgets and reticulating splines for the last however many years, trying to get people to focus outcomes on outcomes and have product people that like, okay, what impact are we going to have on the world and how are we going to measure it? If you're not writing tests anymore, then you need to figure out what this software is supposed to do and who it's supposed to do it for and how are you going to track that? And I kind of see this, it reminds me a lot of the cloud native movement when we went to like massively microservice architectures. And maybe that isn't necessarily a good thing in all cases, but like we've got too many microservices to be able to test all of them together. So we will deploy knowing that sometimes things will go wrong. And instead we will look at like how many things are going wrong, make a decision based on that. We will fix forward and we'll have excellent observability. So we find out when something goes wrong because we know that it will. With software factories, non-deterministically writing code, they are going to make mistakes and therefore we're to need to see when they go wrong. How do we define what's right and wrong? Well, it's those outcomes. like observability, but for outcomes, are users able to do the things they want to do? Are they happy with it? All of those kind of things. I can imagine being a new sort of zoomed out guiding light rather than is the system correct as determined by test. speaker-1: Yeah, I mean, love what you said. It's always been that way. But as software engineers, we've always been focused on outputs. So you have impacts, which are changes in the world that are the result of outcomes, which are changes in human behavior. And those outcomes are enabled by outputs, which is the code that we've always written. And we've been so focused on the outputs. What does it look like? Is it well architected? What language does it use? know, sometimes we care if it works or not because we write tests. So, but I think it's it absolves us from all of that. We don't care about the outputs anymore. And I think what I'm seeing is people that did care about the outputs. So I was never the best technologist. I was never the best typist. So when I paired at Pivotal Labs, I was always the guy that was kind of the navigator. I was not strong and super strong as some of my coworkers were. So early on, I focused on, I'm a product engineer. My job is to get product into the world that has out. has outcomes. So, a year ago, I was just like, well, screw it, I'm just going to stop typing because this thing's much better than I am anyway. So, I kind of had a leg up and what I'm seeing is that people that based their self-worth, I guess, for lack of a better term, on the ability to encode human thought and outcomes into technology, they're the ones that are struggling. And I think we're going to see this shift. You know, there's a whole litany of social impacts that will come from this. But I think you're right. I think we've been able to ignore outcomes. because the bottleneck was outputs. We've now changed the bottleneck. The bottleneck has moved and when theory of constraints says when the bottleneck moves, you have to go find it again because it has just moved somewhere else in the system. And my hypothesis is, and I haven't read the book, The Goal in a long time, but my hypothesis is if the bottleneck was code generation, it's going to go one way or the other or both. So like you were talking, it goes upstream to specification. I ran some experiments this morning with my personal software factory that I'm going to publish in a little bit. They're like, Has me believe that if we can do better specs, we get better generation. Like that may kind of make sense to me, but then it also goes downstream to validation. Did the thing that got built actually match the spec that I wanted? And does that spec match the encoding of my domain? Because it's all about encoding domains, regardless of what business you're in. Like how close am I to, how close is the encoding to the real world? Because everything's a model. We never modeled the real world specifically, but there's a Delta there. And then how small is that Delta? that Delta, the size of that Delta okay for my product owner or my, you know, is the, the error, the error size. Okay. That's not going to break something in the real world. And then how fast can I change that? This is why architecture came in. Like I want to, like my, you know, my domain is constantly changing. have to keep up. So my hypothesis, goes, it goes one way or the other or both. So now we're looking there. So, you know, theoretically that's where we should be looking for the next bottleneck. But if you go. If we look at like continuous delivery, if you look at the Accelerate book that Jez Humble wrote and Jean Kim, and I forget the other woman's name and I feel horrible about it. They talked about continuous delivery. Well, we've been chasing continuous delivery forever. How do you do continuous delivery? Well, you make sure it works. And when it breaks to your point, I know that it's broken and I can quickly recover from that break. like, there's a lot here. Like we're unpacking it in real time, kids. speaker-0: Yeah. Yeah. And it's fascinating to see this kind of unfold. And maybe it's worth taking another step back of all of the listeners who were like, why the hell are you so excited and are you so sort of insistent that this is going to work out? I think that the, one of the observations that other people made in November was that it became clear that when Claude Opus 4.5 was released, that if you just threw more agents having more of an attempt at something. they would compound towards correctness rather than making a mistake and then make more mistakes and more mistakes. So that has definitely borne out. And you know, I've, I've got a little project called Claudit, which I have read and written absolutely zero lines of code on. This thing is a Golang binary and it sets up hooks for your coding agents. And it works with about five or six and it stores all of your commit messages. all your conversation history as Git notes. So you can see the conversation you have with an agent led to a commit. It works. It works for lots of different agents. As I've been, and I've not been working on it full time. I've just been using Claude code, kind of poking Claude code in the evening, like before I go to bed, like, Hey, I've got a crazy idea for a feature. Why don't you work on it overnight? It works. And the thing that is most amusing is that last week or this week, Entire.io founded by the ex CEO of GitHub. I just announced a $60 million investment for something that does almost exactly the same thing as this little CLI that I've written, but I've not even looked at the code, but still Claude and with me as somebody who's written software before, able to guide it and direct it and how to test and what kind of tests that we should have. Yeah. I can add features to that in no time at all. So the, if you're listening to this and you tried Claude code last year or GitHub co-pilot two years ago or like cursor when it first came out. The level of ability of the systems has come on in leaps and bounds. speaker-1: Yeah. So I'm going to, I'm going to go back and quote Nicole, Nicole Forsgren is the other third author author of Accelerate. I just wanted to give her a shout out because I can never remember her name. Um, and yes, like I think we saw a step change, like when Opus four or five came out. So I'm an anthropic person. I have always been, I'm a one bike guy. I'm a one set of skis guy. Like I don't dabble in multiple coding agents. tried to codex once and it felt like that awkward engineer. just hide in the corner and let them, like it doesn't resonate with me. But I feel like in November we had a step change. Opus four five, like there was a step change. And I think you're right. I think I've seen a lot of people say that, that if you didn't like it, give it another try. It's frightening. Like the frightening is the word I will use, like very intentionally that 25 years plus in this industry. And I'm like, this thing might be better than I am at some things. Like I have no, no reason to not say that. speaker-0: It's definitely better than I am because I'm a raging idiot. One thing that like they are still fallible. And this is why things like agents running in loops and software factories, like they need to run in loops. They need to have, keep on having extra passes at the same bit of code. When writing Claude code and it was running Opus 4.6 made some really complicated change to do with rebasing and what it was going to do with these Git notes. And I was looking at its explanation. I'm like, Claude, I've got no idea. Just like, see if you can make it work. Like, I don't understand this. Did something more complicated than I could do for sure. But then managed to stuff up the readme and got some really basic markdown syntax wrong. Putting in like four backticks instead of three, which then screwed the rendering of the readme. Now, as soon as you point that out to the model via the agent, know, hey, you know, you screwed up the readme. It's like, yes, yes I did. Like those awareness gaps still exist, which is why these software factories under the hood. of running things in loops and doing multiple attempts at looking at stuff, having other agents review the work of existing agents, because there will be mistakes. But if you have enough rolls of the dice, then eventually they're not all going to come up one. speaker-1: Yeah, well, and the whole Ralph loop idea is if I can give it, if I can give the machine guidance. So if you look at the way LMS are trained, it's reinforcement learning with human feedback. So this is, we're just giving them, we're literally buying into the way these models were trained. So of course they're going to get good at that. And the question for us is how do we give it that feedback? It's just like a junior engineer. Like I've worked with junior engineers like, ⁓ yeah, just go do that. So I think that was the power of the Ralph loop when it came out is give it. a deterministic test suite that will guide it to the real answer. And then I actually have been looking at Toyota production system stuff. those unfamiliar with Toyota production system was a system designed by Toyota to build cars. Famous experiment, I forget what the name of the factory was, but they came to the US, took over a GM factory that was like the worst performing in the GM inventory, brought in the Toyota production system and like brought it back to being one of the best car factories in the world, I think. And we're going to talk about the use of factory analogy, but they have this thing called the on-down cord where that at any point in the system, anybody on the line can pull the on-down cord and you stop the line. You fix the problem and then you start the line back up again. So you're constantly fixing these things. And what you're describing reminds me of that where at some point somebody's got to pull the cord. You stop what you're doing, you fix it and you start it up again. But if you go back and looked at prompt engineering and the way we've been taught to use these things. That's what you're supposed to do anyway. If it doesn't do what you want it, you start over, you fix the prompt upstream. You don't blame the machine. It's just doing the thing you're trying to do the thing. You fix the prompt and you rerun the system. The beauty of letting an LLM do that is it generates so much faster than we ever could. So now we can lean into this idea of non-determinism because it's less expensive than human slamming keys on a keyboard, which brings us a whole nother set of properties that we never had before. You know, and this is, I've gone back to some of these first principles like Toyota production system. What is the original definition of lean when talking about building automobiles? I quoted a Parnas paper in my software factory the other day, like 1976, this paper was written on the decomposition of modules. Claude really likes that stuff. Like pro tip kids, like it really likes that stuff and you doesn't, it doesn't take a lot and going back to the step change. I've been watching a lot of people actually unwind some of their some of their harnesses because penning the model in actually doesn't let it do its best job. So they're removed like, uh, what is it agent? Oh, S this guy, forget his name, Brian something on YouTube. He had this thing called agent. Oh, S and he literally gutted it for opus four or five because he felt the guard rails were too much for it. And it was actually hampering the model's ability to do work. It's like back to the comment of this stuff's changed. Like we're just making this up as we go and we have to run the experiments to figure out if it works or not. So I think, you know, I'm now starting to ramble, like the on-da-on-chord idea is super powerful. Like stop the line, fix the problem, and start things back up again. It's kind of like, that's the mentality you have to get into. ⁓ speaker-0: Yeah. And the, the idea of, ⁓ you know, kind of continuous improvement and looking at the software factory as a system, it's really interesting. Well, I think there's two interesting things about that. One is that if we have software that is mostly written by agents, so humans don't get involved in any code. pass a spec in and they get working code out and you know, the whole back spec for a verification. can start looking, like one of the fundamental problems with software development productivity has been like, how do you measure the size of a task? Like how complex is this? If agents are doing that and they're working nonstop as fast as they can, then we can kind of infer complexity through the number of tokens that are used and the number of turns in the conversation. And if we, everything is tracked like in Gas Town, everything's in Git cause it's all like tasks represented by beads, which is a tool that stores things in Git and presents a relational view on top of those. If everything is tracked and we can see how much effort went into every single task, we can then start like tweaking prompts automatically. know, Gastown has this, it's pole cats, it's agents have long running person. So you could tweak those prompts and see which works better and slowly tune it over time. the thing, so like, Maybe, and I made a provocative click-baity kind of post on LinkedIn the other day, like software productivity is solved, which maybe is overstating it, but like all of a sudden it becomes really much harder science. And the thing that, like the second thing I think is interesting about that, but also slightly depressing is if you've always trusted your developers to work as hard as they could, that was always the case. It was always science. If you just went, we've got well-motivated people with good culture that are going to do the right thing. then we can look at this scientifically and tweak the variables and be sure of the outcomes. But so much of that didn't happen, I think, in the industry because there was this shadow of doubt of, maybe the developers are slacking off and maybe they're overestimating the size of stories so they can score more points and do less work. But we don't have that with agents, probably. Let's assume that they're not contriving and aspiring to slack off. speaker-1: I think it gets interesting. So the idea of batch size, I think, is what you're talking about. We're talking about batch size. So again, to tie into lean manufacturing, but also XP, what is that optimal batch size? So that was a story. Story decomposition was a thing. Why do we have epics? Because we needed to batch things that could run together. I want to tie into one thing you said. And there was an assumption that if our developers were working well for some day, human definition of well, that we could trust the science. We could never trust the science. Like it was always, we were always kind of hand waving at how much throughput we had, but yeah, now we can track it. I mean, I ran an experiment this morning. I was tweaking some stuff. If I change the story, what is the, how does the implementation change? And I got, this is the weird part about working by yourself on your own software factory is you end up talking to the machine a lot. speaker-0: Yeah, so I found myself doing that. speaker-1: We got into talking about batch size because what is batch size? you know, actual story was bigger with the change I made, but the implementation was actually smaller because it was more well specified. And I had this idea of like, well, if I increase the amount of specificity in my spec, can I drive batch size to infinity? Like where is the breaking point there? I don't know, but we, the cool thing is, is because my agent traces everything, have Claude after a run. takes the story. takes the pull request. It takes the JSONL file. That is the, literally the trace that is running on the host completely outside of Claude. And it can analyze all that. And you can start to do these, these interesting optimizations and you can talk about money. can talk about token costs because there is no slacking. The thing is work literally working as hard as it can. And I don't know what that does. I don't know what that does to the discussion anymore. speaker-0: And also if everything's in version control, you can do something with a software factory, an agentic software factory that you couldn't do with a human team. And that's have control groups. Like you run this, you know, you could reset the state of the system back, play the same story again, but phrase slightly differently. And you could do that several times. you can, you know, to your point about batch size, know, tweak the batch size and you could probably even automate the tweaking of the batch size to try and optimize your software factory for a You the, quickest, most high quality outcomes. You've mentioned your software factory a couple of times now. Do you want to take us through like what you've been building, like roughly how it works? speaker-1: So it was like anybody in the Rails community will remember the time when you rebuilt Rails from the ground up to understand how Rails works. So this is a concept that we've had in education for a long time is you build something to understand how it works. So I just decided, well, let's build this back from first principles. Like I'm an engineer. posted, like you, I like to drop the big click baity things on LinkedIn. I've been seeing a lot of talk about, ⁓ we're software engineers. And my post was all about. Y'all aren't software engineers. Y'all are making stuff up. We should go back to engineering principles. We should go back and understand this. So I'm like, well, screw it. I'm going to go back and understand it by rolling up my sleeves and starting from scratch. So I started with an empty repository, general ideas of where I wanted to be. Like, Gastown was a thing. I was like, ⁓ Gastown. That looks like crazy town. And I'm sure I'm glad it got made. And Steve even called out in his original post, like, you should not be using this. Dan Larenk, I think it's Larenk, the CEO from Chain Guard said, ⁓ I looked at Gastowd and I built something else, a multi-clad, you know, so started building this thing. So I built it up from scratch. The hypothesis is that we now have agent skills. So I have a mechanism for teaching the machine how to do things, pair programming style. It's like, I do, you do, I do, we do, you do. I just take out the I do. It's always we do. We retrospect at the end. So I started building this thing up. About a week ago, I got to the point where I can create a story in GitHub. have a TypeScript script that will instrument kind of like Ralph Wiggum style loop where I pass it in the URL for the story and it spits out a pull request. And I'm now at the point where I have a retrospect on the story. So I've closed the feedback loop. I input transformation, output closed feedback loop. And I've just started running experiments. I ran one, I ran one last night. Literally I started before I go to bed. ⁓ And I'm like, here's the story. I have a hypothesis. Like let's run the the base case, let's run the control. have some hypotheses of how I want to change my story, make those changes. I run the experiment again. So I have a new story. I get a new PR. I sit in Claude, I'm like Claude, here's the old PR, here's the new PR. I have two JSONL files. So I have full transcript of what the agent was doing, what it was thinking, what it was reasoning about. And I just add Opus, like tell me the difference between these things and tell me how to improve the factory. Like that's the key. Like I want to move the needle forward. I sit there for like 20 minutes while I'm drinking coffee, checking email, doing something else. I have a little pop-up. So it says, Hey, I'm done using a stop hook. Like I'm done. Come talk to me now. I'm a vet driven at this point. ⁓ And then I just walk through with Claude, what it found. And I, the goal is to encode those back into it. So I wrote a couple of blog posts about how do we encode specs? So I start like, and I'm just encoding that back into the software factory. And I'm literally just every morning I run an experiment or two and I just grow the software factory. It's like totally handcrafted software factory. But I've gotten to the point now where I can run experiments. I can have Claude analyze the experiments. I can reason about in some very non-scientific way what changes might have caused that. So I now can start to see how I'm evolving this thing forward. The ultimate goal would be to have itself evolving. So Claude would analyze itself. It would then suggest those. submit another pull request and just pull requests all the way down. Um, so that's how it works. It's pretty cool. spend 20 minutes in the morning, kind of poking around, writing some articles. Um, but I'm elbow deep in this. I'm not going to talk about it. I'm going to actually do it and find out where the edges are and find out where the rough parts are and like what doesn't work, what does work. I'm keeping it private for now. So OB Fernandez style. I'm just going to keep this private cause I don't. I don't know if it's going to have any value to be open sourced and I might open source it at some point, but like this is my personal experiment that I'm spending my money on and we'll see where it ends. speaker-0: up. And open source is just an interesting space at the moment. There's obviously lots of open source repos getting bombarded with AI generated PRs. are agents naming and shaming individuals in blog posts on Claude book or whatever it's called. speaker-1: Yeah. Man, what a social experiment that was. speaker-0: So there's all of that kind of stuff happening with open source, also like software is potentially now just indefensible. It's, it's commodity. there was one of the, the really ironic thing about the whole entire IO thing and Claude it was when I needed to choose a license before I told anyone about this project that I was working on. And I was thinking, there's no point because anyone with a copy of Claude code can just build the same thing. So I made a joke license. the AI native application license or AI. speaker-1: was wondering where you came up with that. was like, is he serious with this one? speaker-0: Well, originally the AI native software license was supposed to be a satire of just like, there's no point licensing your software because anyone can reproduce it. Like why would you use something with license terms that you don't agree with when you can just ask an agent to rebuild it? And then I realized if I changed the acronym, there's another schoolboy joke in there. But yeah, so the, if you open source your software factory, then somebody else like How much value is there in open sourcing anything now when, cause other people aren't going to use it. It takes more effort to look at the things inside, which thing to use than it does to rebuild your own in your own vision. speaker-1: Especially when you're the domain expert, like you are the domain experts in software. So agreed. I that was, I mean, the OB Fernandez post, that was OB's point. He's like, this is a differentiator and it took me two days to build. Like there is nothing here to do. I I have to find the post, but you know, an OB can be, we'll call him inflammatory sometimes. I don't know him, but I know of him just through his work. I agree. You know, especially, you know, we're talking, my employer Rise 8, we're talking about, you know, what do do we build a software factory for our internal systems? Do we build it for our customers? Like, what does that look like? And we were talking the other day, this is table stakes at this point. Like if you are not building one of these things for your company, or at least trying to figure out how to move yourself up the curb, curve, you're going to get left behind because someone is going to come so that. I'll tie it back to the original blog post we started with. talk about, what is it, digital clones? They talked about how they were digitally cloning well-known SaaS providers because they didn't want to have to tie their factory to somebody else's API. And they pulled the SDKs down and were able to generate a digital clone of Salesforce good enough to test their software against. We would have never done that. two years ago, we would always stub something out and just be like, well, I'm going to ignore the database for now because it's, it's a thing that I don't want to integrate into my tests. They're just building. They're just cloning them. ⁓ speaker-0: And not even as a like a Salesforce competitor, just a test thing, you know, we're just going to rebuild all of Salesforce. speaker-1: Dependency. They're isolating themselves from a dependency, but they can do that overnight. you're like, and what was brilliant was the person who came up with it's like, well, we'll just continually pull those down. We'll have a factory that will just continually keep our dependencies up to date. So we don't need adversarial tests or we have less adversarial tests. I'm just like, wow, I would have never thought to do that because it would have been economically infeasible six months ago. speaker-0: Yeah. mean, and I'm tempted as part of an ongoing art project that is Claudit to like just watch the entire IO website and whatever features they announced, just like ping Claud and go, Hey, do think you can build this? Can you add this to Claudit ⁓ or watch their Git repos? Not because I have anything in for them. I wish them all the success in the world, but just as a kind of way of demonstrating how commodity software might now be. speaker-1: Well, and if we go back to talking about risk analysis, so what does that look like for my risk profile for my software? If I'm not pulling in external dependencies, I control my dependencies. There's all kinds of stories. You can find them all over the internet of people just being like, well, I don't want that heavyweight dependency. I just want the piece that I need, so I'm just going to have Claude write that, and I'm going to own that code, and I'm going to keep it up to date. mean, the C compiler that Anthropic built. They built a whole C compiler for $20,000 and no human ever touched it. Like, do I build my own compiler? I don't know. Yeah, I think it changes the economics. And unfortunately, in open source, the economics were kind of broken to begin with. And we've been talking about for years about just the misaligned incentives and it definitely disrupts that. speaker-0: Yeah, we were having a conversation in Resync earlier. One of the engineers was suggesting that, you know, lot of the code that gets written already doesn't need to exist and it's duplicating something else that already exists and we should be trying to reuse more software. But I cannot see the world going in that direction now of like exactly like you say, why would you use somebody else's dependency that's going to change when you don't want it to, and it might introduce bugs. Maybe it'll add new features. When you can have a thing that does exactly what you want it to, maybe you have the problem then of not having so many eyes on it. So it ends up not being kind of benefiting from the improvement of everybody else. Like building your own, building your own everything is feasible, providing that you've got enough tokens and usage allowance left. speaker-1: I mean, I think that's going to be the interesting piece. What do the economics look like? Because I'm, I don't know how what you're using, but I'm using it a hundred dollar a month, anthropic subscription, and I'm running that thing overnight. have friends that are running multiple of those $200 ones. Like what are token economics look like? We don't know yet. And so I think that's the one big unknown in this system is what are the economics look like? Is it going to be less than a human engineer? Is it going to be more than a human engineer? Is it going to be economically feasible? Like we don't know yet. So agreed. Like the economics are just so different right now. And what do we, how do we even reason about that when we don't know where we're going to be? And I think that's what gives a lot of people pause. They're just going to wait, sit on the sidelines and wait for this to slow down a little bit, which I agree it's exhausting to keep up with, but you know, are you even going to be on the same map at that point? Can you even catch up at that point? What's interesting, know. So the, we're talking about software factories that companies are building for their internal use. I saw something the other day, I think the company is 80, 90. They built a software factory that they're selling for $200 a seat. So we also have those economics of like, okay, if you're not going to build your own, do you buy somebody else's? Do you agree with their opinions about how software should get written? Do you care about those opinions because you're gone to spec in pull requests or working software out? I don't know. Like they've been working on that for years. speaker-0: To use the term abundance has connotations with some people of ⁓ questionable opinions and divisive opinions, but like, it's just strikingly now that we are maybe in an era of software abundance of like, there's more software than we know what to do with. You can make your own, its value becomes simultaneously zero, but because anybody can reproduce it. But everybody, I can imagine a world where there's lots more bespoke software. particular to individuals requirements that fits them much better than some generic SaaS solution. And yeah, that is an interesting kind of place to be in where anyone can create any piece of software. There is no value in any single piece of software. Like I was thinking about the $200 a seat. It's like, okay, how many of those do you need to sell for that to be profitable? But then somebody else could just make another software factory and then, you know, you can't sell anything anymore. It's probably only the people hosting the models that will make any money out of that. speaker-1: Yeah, I mean, I posted something, that was the other day, a couple days ago. It's so hard to keep up. I'm very prolific on LinkedIn these days. About that same thing, like postulating. I think it was the entire 60 million thing. was like, at what point did the economics stop working for VCs? As the ultimate, you know, 25 years in experience, I like to think I'm pretty decent at software and I can look up some stuff on the internet. Where's the moat for my software factory versus somebody else's software factory? Now, if you're basing your business on developer tools and you've got people like us who are like building these things on the side, how do the economics work anymore? What is your moat? Is it the prompts? Because it used to be the source code, but is it the prompts now? Is it the scripts that I tie this together with? I don't even know what that looks like anymore. speaker-0: Yeah, when was it? 2011? People were saying software is eating the world. Well, coding agents are eating software and all that is going to be left is the business, you know, in air quotes. All of the stuff that we spent a decade telling people, you know, like Uber is a technology company. It doesn't matter about the cars. Airbnb is a technology company, a software company. It doesn't matter about the real estate. Well, soon if software is commodity. It's going to be things like your network and the customers that you have and the relationships you have and all of the business stuff and data. Let's not forget data, but the actual software part is, yeah, no longer going to be the most valuable component for sure. speaker-1: Yeah. And what does that do to a stock market that is propped up by... I I go back to the... I keep going back to the economics because I was listening to that Dario Amadei podcast this morning. like our whole... And he brought up something really interesting. He's like, when you look at former revolutions like this industrial revolution, all of these other revolutions, they happened much more slowly. So society was elastic enough to keep up with the changes. We have witnessed in the past three months, a complete destruction. I will use the word destruction of the value equation of our industry. Like whether or not you agree with it or not, but like you can't tell me that the economics have not changed. And I don't know what that does to people whose livelihoods who are starting. I'm talking to engineers just now who. are like, well, what do I do as an engineer? What do I do as a software developer? I wish I could tell you. I just don't know. I can't see past the next week and a half because is Sonnet 5 going to drop, which just changes the economics again? Because Opus is great, but Opus is kind of expensive. But if they release Sonnet 5 and that changes the economics again, now we have to go back to the drawing board and re-evaluate how the economics work again. So I think that's the thing I don't want us to... to forget about. Like you and I can sit and talk technology all day, but these are going to have legitimate social knock on effects that we need to, as technologists, we've ignored up to this point. And I think we need to start paying attention. I don't know what that looks like, but at least in the back of my head, it's like, well, what is this going to do for me? What's this going to do for my family? What's this going to do for my community? What's this going to do for the world? Which gets, you know, easy to spin out on, but like we should be thinking about this. speaker-0: Yeah, definitely. ⁓ I'm really interested in that topic, but I feel I should bring it back to when you'd been posting about your software factory and I was like replying going, yeah, okay, we should do a podcast. And then there something you posted I think yesterday. And I was like, yes, definitely now. You were, I think, talking about some of the lessons that you've learned and some of the fundamental assumptions that maybe you've had to challenge about what good software development looks like. Do any of those kind of... spring to mind as to how the equation is different for you as a software practitioner. Yeah. speaker-1: I think the word I used in that post was quote unquote lore. So if you look at the history of our careers, I I started writing software in 99, started in Java. So I was just talking to a bunch of engineers. Michael Feathers wrote the book Working Effectively with Legacy Code in 2004, where he brings up this idea of the ability to work effectively with legacy code is your ability to add tests around the outside to make sure you understand how it works. And then now that you have those tests, you can change the inside because you've guaranteed that you're not going to break the outside. That was 22 years ago. I ran an experiment just last night that I said, oh, hey, Claude, let's experiment with Michael Feather's ideas from this book and how that included. But so much of our lore, Kent Beck, Martin Fowler, Andy Matz, I've heard all of these people talk. I've heard multiple talks from them and it's all been like churned around in here. But a lot of it is lore because we have not proven does any of that write better software. So it's been interesting to go back again to first principles. What is the basis? And the first principle I've gone back to is, do I know the software works for some definition of works? Can I tell that the software is broken, which means it does not encode the domain properly? And can I move fast and change the software in response to domain changes without breaking it? And that's really the underpinning of refactoring. All of the Martin Fowler books, like, you know, the Gang of Four book was architecture. All of this lore was built up in lots of human words to distill down some very specific principles. And I think we've all forgotten those, where we've just applied them ad hoc. So I think the one takeaway has been, what is good software and why do I care? And you have to ask yourself that. speaker-0: Yeah. And on the what is good software topic and you mentioned architecture and architecture as a means to allow you to move forward and evolve a code base. was just very cheekily checking on Slack to check people's names and URLs and things. probably totally mispronouncing a surname in their Tudor and Simon Wardley have been working on a book called Moldable Development. And I've read and have a couple of good nature debates with Tudor about the role of structure in code. And I think lots of developers know intuitively that you need to have good intentional structure in your software. You need to implement it like the right way to enable you to move in a certain direction. And you could argue that not technical debt literally, but what a lot of people call technical debt is inappropriate structure for the direction that you now want to go off in. speaker-1: The premise of Kent Beck's new book, Tidy First, is I don't refactor at the end of my refactoring. I refactor at the beginning of the next change, and I'm paraphrasing, so hopefully Kent watches this and corrects me, but I have more information now based on where I'm going. I'm not making assumptions of where I'm going. I'm using pressure from the current implementation to tell me how to make the change easy and then make the easy change. speaker-0: Now the thing that I wonder is if I'm not writing the code and Claude is writing the code and instead of taking 10 minutes to implement a feature, it takes 20 minutes because Claude's got to refactor it or work with some poorly structured code that is not aligned with the direction we want to move in. Does it, does it matter anymore? Like does that incremental, if it was humans and you were like, it's going to take twice as long. It's like, oh crap, this has gone from a six week project to a 12 week project. That's a big deal. If it's gone from 10 minutes for Claude to 20 minutes, know, twice as many, it's gone from like $2 to $4 worth of tokens. Like structure matter anymore? Is it so, do we need to care about architecture as much? I'm sure there absolutely will be places where it's vital and you know, there are different systems with different profiles and qualities that we need, but I'm not convinced that it will matter in all cases as much as it has done in the past. speaker-1: I think it does matter because agents still like structure. They like context windows. So we want small boxes. But domain-driven design talked about bounded contexts how many, know, tens, 20 years ago. When did Eric Evans write the book on bounded contexts? So I think, you know, the architecture I've adopted is a hexagonal, like functional core imperative shell. The crazy thing is if you tell Claude, just mention functional core imperative shell. That is constrained the generation space enough where it like it'll actually kind of do pretty a pretty good job of that. So I think so I think yes we still need structure. Do we need all of the structure that we implemented before. I have a hypothesis no but I can't tell you why that's the case because the mechanics of context windows we want to keep context windows small so the less context we have to load I think is we all know that LLMs generate better when you're at the 20 30 percent of a context window. You know the whole lost in the middle problem. But I don't know. don't like, is, what is minimum Bible architecture? speaker-0: Yeah, and there is a speaker-1: Question we should be asking ourselves. What is minimum Bible architecture? speaker-0: And you know, there is ⁓ an absolutely valid argument in there about agents liking structure and consistent structure as well, because you know, if the context gets polluted with two different architectural styles, then it's entirely possible the model will start conflating the two and trying to merge them together. that would, that would be bad. speaker-1: I like, had that happen in my experiment last night. I had conflicting architectures, even though the specs said to use TypeScript, it wrote a bash cell because I still had bash shells in there. And there was reasoning in the trace that said, I can't make a decision, so I'm just going to pick one. I was like, reasoned, you people say they don't, but like it went through the mechanics of like making a decision about what structure to follow and came down on the bash shell side. I'm like, okay, cool. Like I would have done that too. speaker-0: Yeah, it's the, I like the idea of minimum viable architecture and trying to figure out what that is. What is the amount that we need to specify? I wonder whether agents will get to the point of being able to determine that for themselves. Probably, probably not. And there's probably like non-functional requirements that you'll need to express. And I wonder if it will end up moving towards one architecture or another because of some of their ability to cope with change. Like one of the things that concerns me a little bit. What's getting all excited about the rate that we can deliver features is what do we do with data? Like state is tricky and you can't easily migrate several terabytes worth of data because Claude's just decided that it's going to influence a new feature slightly differently. think that's, ⁓ I'm sure there are probably really clever ways of dealing with that for people much smarter than me, but whether it's like some kind of event sourcing type thing or some meta description of data on top of the data, whether it's just the agents have to build lots of translation layers so they can like translate between different versions of schema in the past. I'm not quite sure, but that definitely looks like it might be a bit of a slowing factor on what we can do with software factories. speaker-1: Yeah, think there, I mean, again, the theory of constraint states the bottleneck will move somewhere else. We just have to go find that bottleneck and unblock it and then go chase the next one. mean, you talked about earlier, you talked about non-functional requirements. It's the same thing we do when we find a bottleneck in our systems now. You don't guess as to where the bottleneck is. You measure it and then you fix it and then you measure where the next one is. So like we're like we have to apply these same techniques we applied to software to solving these problems and but it's a different way of thinking. mean, this is people talk about engineers moving up the abstraction chain. Like that's where we move to, is we start applying these techniques that we've always tried to apply to the software factories themselves, just like Toyota did decades ago when they were building automobile factories. And eventually that analogy will fall apart and we'll pick another analogy. But you know, to your point, what do we do with data? I would love for someone who's got a ton of data, who's pushing all in on this agentic workflow to just like post about it. Like, what are you doing with data? Like, let's all learn from each other. Because I think that's the cool thing now is the details are unimportant. It's building. Because even I think that Dark Factory post from Simon Willinson talks about they were building on other ideas they had seen other places. So I think this is important for us to keep this moving forward. And this is my whole rant about not being an engineering discipline is that I'm seeing a lot of, we can't do that. Well, we couldn't put people on the moon before we put people on the moon. But engineers, you know, pulled on their boots and like got to work and figured out how to make it. we w that's what engineers do is they solve problems and move the world forward. They don't just sit, dig their heels and say, well, we can't like LLMs can't do that. So we just shouldn't keep start trying. So that's one of my goals with my explorations of the software factors to begin to like, let's just have the discussion. And I'm not going to be right all the time, but someone's going to see that post and try something else. And then you're going to see a post from them. And we're just going to keep moving this forward. Like we have for decades with Sandy, the Sandy Metz's and the know, the Kent Becks and the Martin Fowlers of the world that we've all been building on standing on the shoulders of those giants. speaker-0: Yeah, yeah. And it's, ⁓ it's exciting, but as I think we've both mentioned, draining, trying to keep up with all of this stuff and all of the people that, don't know whether you have this problem, like there are some people in my circle, ⁓ that kind of quite AI skeptic or, you know, ⁓ legitimately concerned about like the financial economics and the social impact and the environmental impact and, all of those sorts of things. I think they're getting sick of me like every day now, several times a day posting something. It's like, ⁓ my God, somebody just like posted this and I've just realized like the implication of this is that. It's, ⁓ I should imagine those of us who are keeping pace with it and trying to share that knowledge, probably annoying some of our friends somewhat with that. speaker-1: Yeah. Yeah. I mean, think it's like any bubble. I mean, are we in a bubble? Probably. Is it going to burst? Maybe. Is it going to spring a leak and drain slowly? Like, who knows? I've been more worried about what it's doing to me. So I have an addictive personality. My partner can attest to this. I am not allowed to bring video games into the house because I'll like just go deep. And she even complains that like when I get focused. You could burn the house down around me and nothing would happen. I had been noticing some interesting focus problems and benefits with this. Like we were always tight. I multitask horribly, but I've actually been running multiple clod sessions across multiple repos at work. And I actually have them all working on the repos. I don't find that as draining as context switching. Another thing I've been doing is I'll kick off an agent run and go for an hour and a half bike ride back to the economics. Am I still working while my agent is churning along on my laptop? And should my employer be paying for that? Someone from my employer will watch this and probably we'll have a discussion about it. But like, it's allowed me to do these different things where I'm actually able to stay energized longer because I'm out riding my bike. I'm training for a race, but I know other people that are going like really deep into this. And I'm a little concerned that the mechanics of reinforcement learning and the gambling, like that people say this is like the dopamine hits, which I've felt. Like, what does that have an effect on people who have an addictive personality? I don't know. speaker-0: It's certainly a complex area and it will affect different people in different ways. There's like a few things that sprung to mind there. One is a reasonably personal story. Like when my kids were young, I had just come out of the games industry. I'd made, been an indie games developer, spent about two years and my partner and I ended up earning about 12 pence an hour over two years. So it was complete financial failure, but I still wanted to make some things and I had a really bold idea for. I'm going to go nerdy, apologies to the non-gamers in the room. Like Mario Maker, but probably five years earlier, a browser-based game, which would allow you to craft side-scrolling 2D puzzle platform adventures where you take items to people and then you unlock a thing and you can move it. And I had a prototype working on that. And there was a point where a IP holder for a franchise that I loved dearly when I was a kid in the eighties. was interested in kind of using it for a Kickstarter and it was all going to go ahead and then eventually it didn't. When I was, and I couldn't get it going fast enough. Like I knew the ideas, but it was too slow during the implementation. I was trying to like with young kids, say, you know, kind of four years old, one year old, and I would try and steal some time away. And this was before noise canceling headphones as well. Um, to focus and that didn't work and I'll be in like indoor play centers. Um, remember, uh, you know, and like with headphones on, but not noise canceling was there off on slides and all that kind of stuff, trying to write stuff and, it didn't work out very well. And I got incredibly frustrated and, know, I was not really paying attention as much as I should have been as a dad. And I was generally being grumpy a couple of weeks ago when I was working on a thing with code code. I was. away with my youngest who's now 13 and we were going to go and see a concert. We're in the hotel room. There's nothing to do. We've got a couple of hours to kill. So she was doing 13 year old girl things of like doing selfie videos for trying new food and reacting to it and all that kind of stuff. And I had Claude Code open on my laptop on the sofa and I was able to just poke Claude Code every now and again, but still watch what she was doing. And if she interrupted me or like started talking, it was fine because I wasn't in deep. So it allowed me to like do normal kind of family things without like, if I'm not being productive, it really stresses me out. And I feel like I need to be productive all the time. So I was getting stuff done whilst also being a much more reasonable human being because I wasn't frustrated at my own lack of intellect that, you know, prevented me from solving complex problems. So that was, that was really cool. And then just another thing on, ⁓ like you mentioned going for a bike ride. Something I found is that. Thank you. We both, you worked for Pivotal, I worked with Pivotal and there was a culture of going for games of table tennis and you'd go away and you'd do something completely different for 20 minutes and then you come back and like your subconscious had churned on a problem and all of a sudden you have some insight that you didn't have before. I find that waiting for Claude code, like if I go and do something different, like read video games, news websites, then somehow I subconsciously understood the problem a little bit better. even though I hadn't been actively focusing on it. And I found that quite surprising. speaker-1: Yeah, it's a, I just this morning I was going to, I wanted to do some, start doing some psychological research on this, but I agree. You're not in as deep. mean, my partner will tell you when I get in deep, you're like, get pissed when you interrupt me because they've broken that train of thought. Like I will get nasty and I'm working on that. But yeah, I mean, I actually had an idea for the app, the app the other day. So I'll have a look. I'm training for a race. So I'm out of my bike for an hour and a half, two hours a day. I've had this idea of what would it look like if I wrote. an app that would take text messages in, it would take these random thoughts that I would text message to myself, pass them through an LLM and dump them into the backlog. So when I got back from my bike ride, I could process them because like my brain goes like a lot like that. And I'm just like, I just need to get these out of my head. And it makes me feel better because it's not going to get quote unquote lost and people will say it'll come back. But like I could build that in an afternoon and it would revolutionize. it's again, more outputs, but it's still like It's a different type of focus and I don't know what yet, but I'm curious to do some like psychological research. Like what does the psychology paper say about this type of focus? And I'm looking forward to some of that because it is different. It is very different than other multitasking that I've done before. speaker-0: Yeah. And it can be compulsive for sure. I've had a hard time disentangling in the last week, the general excitement about the industry and the excitement I've had building this little tool and being able to create things in minutes that would have taken me days if I'd ever been smart enough to do them at all. Like I was trying to watch some TV series last night and I was like, I couldn't focus on the narrative because I kept on having ideas about things I could build or what this all means for the industry. And with the compulsion thing, I don't feel like it's becoming addictive, maybe it's a little bit like playing a game like civilization of just one more turn. You kind of doing something else. You walk past your laptop and like, Claude's not doing anything. I should probably ask it like, you know, I'm not going to come back to my laptop for another hour. I'm going to go and eat dinner. I should ask Claude to do a thing. So I'm not losing that hour because maybe it will surprise me. you go to bed and you're like, I haven't set Claude a task. Okay. What's the thing that like I would like building? But actually I haven't thought through deeply enough. Well, maybe I don't need to think it through deeply. Just get quad build it overnight anyway. And if it's crap, then I'll just do a git reset and git clean and throw it away. There's that kind of desire to keep on rolling the dice to see whether you get some pleasant surprise at the end of it. speaker-1: I mean, we're dealing with another non-deterministic system. I've read some, I've listened to some really good books on this. So again, back to the like non-technical stuff. There's a book called The Brief History of Intelligence, where the author talks about the evolution of human intelligence from single celled organisms all the way to where we're at right now. And it threads in the AI ideas along the way. And it's really fascinating. And my biggest quip on LinkedIn when someone says something that AI can't do, and I was like, well, but humans don't do that either. So like, you know, I think it is, it is an interesting place and we're all taking that journey independently. We're all having to figure out what this means for us. And it's cool to like come talk to you of like, what are you doing? What am I doing? But yeah, it's going to be interesting to watch to see where we all end up and what our society looks like, because we have never had a tool that is, that can take in English language. and generate English language or other languages. I'm biased towards English because I'm an English speaker predominantly and I think most of the models are, but it talks in natural language back and forth, but it is not human. And part of that book and part of the journey I've gone on is like, what does it mean to be human? And that's a deep well, like that is a deep well to go down, but like, what does it mean to be human? What is special about being human? What value can I add as a human and what can I outsource? How can I be more present for my partner? because I have these thoughts and I can outsource to the machine and let it do that. You know, my favorite saying is it's like a screwdriver. You can fix things with a screwdriver and you can kill people with a screwdriver. Like we are wrestling with probably one of the most powerful tools we've ever been given that really pushes at the edge of what it means to be human and what the human experience is. And as technologists that makes some of us very uncomfortable, myself included. And I think a lot of this is we're navigating this world. It's not just about the next programming language or tabs versus spaces or VS code versus IntelliJ. These have legitimate impacts and we're all kind of navigating this without the framework to navigate it. speaker-0: Yeah. And even just kind of narrowing the scope into software factories from like AI in general, it does still ask those deep and meaningful questions of like, if software has no value because anyone can create it, why do we bother anymore? Why do people make open source in the first place? Maybe that was to do with notoriety and like, Hey, it'd be good for my career. We give my resume or I get satisfaction from building something that other people use. Why would we build software that... has no value and especially if we're not involved in enjoying the craft as much anymore, some people still will. But there's something about that, about solving problems and wanting to create things and wanting to make the world, air quotes, better, you know, for some definition of better of like, there's a thing that I think should exist because then, you know, that unlocks some other capability. That seems to be like the nagging thread that we're all have been pulling on, you know, as a species for however many. hundreds of thousands of years. And now that we can implement things and build things so much more quickly than it's sounds cliche, but it's the whole speed of imagination thing, isn't it? Of like, as soon as you think of a thing, like you can knock it up and build it really quickly. And once that is everywhere, it will be interesting to see what things we end up building. I, dare say it will probably end up a lot of it being entertainment. And then you look at the things like YouTube and most of what we find, most of what we kind of consume these days is entertainment. It's not stuff that we actually need. Most of us are lucky enough to have very comfortable lives, but we instead spend our money on just entertaining ourselves. I wonder whether software will end up that way as well. speaker-1: Yeah. mean, you mentioned earlier software is eating the world. So one of the ideas I had, two of my big kind of pet projects are homelessness and hunger. Like I can't believe in 2026 we haven't solved that we can't feed everybody on this planet. We can't house everybody on this planet. And living in a small-ish town, medium-sized town in Tennessee, in Chattanooga, ⁓ friend of mine sits on the board of the homeless shelter in town. Yeah. Like could I use the software factory to go to Barron and be like, Hey Barron. Could I use technology to help your mission? Like I think we're all being asked to do this. And I think there is a power in that for all of us, but there is, you again, there's a flip side to that where governments get ahold of this. You know, another book that will scare the crap out of you is called The Army of None. It's all about autonomous weaponry. So what happens in a world of war where there is no loss of human life? because humans are no longer involved in fighting those wars. The book's probably six years old, seven years old. Again, raises some really interesting questions of like, you just like you proposed with the software factory, what do we do here? Like, how do we make these decisions? What value do we have? Because we don't have constraints anymore. And then your software factories remove those constraints from us. It is going to be interesting. Like, I keep going back, like that's my phrase right now. I like, I just don't know, and it's scary, and it's... Like, but she just got, like, for me, it's, I want to dig in. I want to find certainty. I want to find the things I can, I can hang my hat on. I want to be part of pushing this forward in my hopes of pushing into the direction that serves humanity. As again, as cliche as that sounds. And I feel like we're all talking in cliches now because we just don't know what to use anymore. And I think that's like, if I'm going to challenge people out there and I love the skeptics, I love getting involved in those discussions. Cause we We need to be skeptical. Like we all need to be looking towards that moonshot of how do we like get this tool to serve us and not destroy us as a society. Cause it's legit. you know, not proven that that won't happen at this point again, like, cause we just don't know where this is going to end up. The open source thing is interesting. I mean, I would love to talk to open source maintainers. mean, what does it, the got the author of curl. started rejecting AI generated podcasting. Mitchell Hashimoto of Ghosty came up with a, he wrote a whole tool. He vibe coded a tool to help him with pull requests. Like if we're going to tie it back to software, cause Mike likes to wander off into the philosophical, like, like we should be talking about this. We should be figuring this out because we either keep that model or we jettison it. And we move forward as an industry of like, what is our next model to like make sure that we're getting software built that we need to get built. Cause I will say, and we started on the outcome thing at the beginning and we've wandered so far, we need to be focusing on outcomes. This is now our job is to be focusing on the outcomes and how do we implement those outcomes so they have an impact. speaker-0: And yeah, that focusing on outcomes helps us kind of check what is dogma from the past. And just the idea of, you know, not reading the code, not reading the tests, not validating the test case, but instead this whole scenario based thing. Like on first glance as an engineer, it's horrifying, but then so many advances have been, and you realize that like the, was the sacred cow of the, you know, the previous generation of thought, you know, that's the thing that needs jettisoning. So focusing on outcomes and first principles is probably the best way of like figuring out like what doesn't apply anymore. What's no longer legitimate in this context. The world has changed what no longer fits. speaker-1: Yeah. And for me as a self-proclaimed expert of 25 years, that's a frightening place to be when you're questioning like, why do I do this? Why do I practice this practice? Like, why do I TDD? I've actually been going on a rant lately that TDD inside out TDD is dead in the world of AI generated code. Like, like hot take outside in TDD is going to be the savior of the engineering world. Like you heard it here first, but like, those are the things like we can't, we shouldn't jettison them. But we should reevaluate them now that the constraint has moved. Because if you are not, now you are dogmatic. And that's a slippery slope to dogmatism and not going back to first principles. speaker-0: Yeah, knowing when things apply and in which circumstances, instead of just taking the, you know, kind of cargo, coating them into like, ⁓ this always applies all the time. Realizing that no, it doesn't apply in these situations. Just trying to, we've gone over an hour now, wrap up on a kind of uplifting note. I mean, it's exciting not knowing what's going to happen next. It is scary as well, but like one of the things that I maybe naively look forward to is a world of. much more diverse software that is much more usable because it's much more specific and bespoke to individual people's needs. Gone are the days where, you you're asking for a feature from a SaaS provider for two years and they can't implement it. you know, you can just create something. It would be wonderful if we end up with a place where computers and their usage is less frustrating and you know, things ⁓ you can just do get stuff done that you need to do. with a lot less friction. speaker-1: Yeah, yeah, it pains me every time I go into like a restaurant or somewhere where a non-technical human is forced to just use software that doesn't work for them. I'm like, doesn't have to be this hard. like, I want to democratize software. You know, I taught a boot camp, man, this is years ago when the whole like coding boot camp thing came about. We talked about getting more humans to write software, not just as nerdy people. Like, do we have an opportunity now with LLMs to democratize this further? speaker-0: Yeah. mean, that's something that has been a bugbear of mine for many years is realizing like in the seventies, if you had a new business process, you like photocopied some forms and you pinned them on a cork board and you said, is how we're going to do it now. And processes were like embodied by bits of paper and pens and humans talking with their mouths. And then our software people got involved and then all of a sudden people couldn't self-serve. They couldn't, you know, self-serve the changes that they need. And since then, we've been in the way with our table tennis tables and our free breakfasts and our high salaries, we're slowing things down and preventing them from just being able to express. I used to say that software is the medium through which a business is expressed. now people will be able to express it themselves without us getting in the way and going, no, we're not going to do that feature because that would be too much for maintenance overhead and we won't be able to guarantee velocity anymore. You know, it's just... People are going to be able to ask Claude to do it, who is for better or worse, not going to argue. And you mentioned gatekeepers. I've been delivering this training course to a company called Adevo where we're training a hundred software developers in agentic coding. And let me see if I can find the slide. We're talking about spec driven development. And in it, I talk about like the history of programming going from like machine code to. ⁓ assembly, is at least has mnemonics, but it's still like you're coding to the machine and compiled languages and Fortran in particular, which are abstract and a compiler has to convert it into machine code. And some of the quotes from John Backus, the creator Fortran are like quite resonant today. And just as Westerners and other frontier types developed a rather chauvinistic pride in their frontiermanship. So many pioneering programmers in the 90s began to regard themselves as members of a priesthood guarding skills and mysteries that were far too complex for ordinary mortals. The priesthood wanted and they got simple mechanical aids to help them with their drudgery, but they regarded plans for more ambitious systems really with considerable hostility and derision because they felt with some justice that it was a rather arrogant enterprise to think that a mechanical process could do all the mysterious inventive things they did to produce an efficient program. And I'm like, that sounds quite familiar in current times. speaker-1: Yeah, I mean, what does a world look like back to closed feedback loops? Because I love me a good closed feedback loop. When we don't have to write as many tests because the user, the domain expert can in real time modify the software. ⁓ you talked earlier about getting like meantime to recovery. Meantime to recovery is 30 seconds because they found a bug and they asked Claude to fix it. And 30 seconds later, it's been deployed to production and they're just using the software. Now we're talking real time outcomes. Like what does a world look like where we can deliver outcomes in real time or impact in real time? Because we don't have the delay, all of the inefficiency that humans have introduced into a system. mean, like, let's end on a positive note. Like that's like, that's a world I want to live in. I want to live in that world where people can be like, I have an idea or I'm running my business and I'm feeding my family and I want to do this more efficiently. And here we go. And no longer do I go into a restaurant and see the poor, you know, server smashing their head against the desk because they can't get toast to do what they want. Like that to me is power. And I don't want to be in the way of that. speaker-0: That sounds like an excellent note to end on. get hard. I have enjoyed this very much. I'm sure we could continue talking for hours, which considering we're not doing it over a beer because like, you know, it's your morning and I'm on the other side of the Atlantic. speaker-1: It's noon, it's noon now. speaker-0: And it's Friday evening in the UK. So, but yes, we've very much enjoyed that. Hopefully we can do it again soon. I look forward to you sharing more of what you've learned about your software factory on LinkedIn. And you mentioned a blog. Where can we find your blog? speaker-1: I'll make it more evident on LinkedIn. I'll send you a link. I forget even what it's called. It's on Substack. So I dusted it off four weeks ago. But yeah, it's trying to post once a week. We'll see how that goes. Again, I'm using Cloud to generate everything. Much to a lot of people's chagrin, I'm writing my articles with AI, but I'm proofreading them. I'm the editor now, not the reporter. But yeah, Daniel, this has been awesome. think we have a lot to talk about, and I hope... This incentivized people to get as part of the conversation because we have a lot of work to do, but it's also exciting. speaker-0: Cool. Right. Thank you very much, Mike. speaker-1: Hi, sir. speaker-0: Hopefully you enjoyed our undirected enthusiastic rambling about software factories and philosophy. In this episode, I made reference to a book that is under construction. You construct a book. It's being written by Tudor Gieber and Simon Wardley called Moldable Development. That is available online at moldabledevelopment.com. That's M-O-L-D-A-B-L-E development.com. So that's definitely worth checking out. And whilst I want to try get this episode out quickly, so I'm not going to wait for Mike Gayhard to send me the URL to his blog. Instead, I'll try and make sure that ends up in the comments or in the description in all the available places. If you have any feedback, we would be grateful to... receive it so you can email us at waves of innovation at re-sync.com. That's R E dash C I N Q dot com. Hopefully you've enjoyed this, tell your friends about it. It's great to share this around more widely. Don't, don't hit like, don't hit subscribe. You're grownups, you can do what you like, but in the meantime, be good to each other and you'll hear me in the next one.