Daniel Jones (00:03) You are listening to the Waves of Innovation podcast and I am DJing 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. Daniel Jones (01:19) Mike Gahard, 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 their 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. Mike Gehard (02:00) I have been, mean, anybody who's not trying to figure out where we end up is probably going to get left behind. So with the interesting pieces, 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. So 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. Daniel Jones (02:04) You wow. Mike Gehard (02:26) 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 the history of why they call them dark factories? Daniel Jones (02:55) I didn't when I first heard the term, but why don't you expand on that for our listeners who probably, I 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 and... Mike Gehard (02:58) Yeah. Yeah. So there's not, 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. 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. Daniel Jones (03:10) You You Mike Gehard (03:32) 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. Daniel Jones (03:48) Yeah, yeah. And I remembered one of the other sort of blog posts that went live in the last week. And that was about OpenAI 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 hit 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, develop 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. you know, agentic coding has been a thing for a while and people have been using like 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 the other agents. Mike Gehard (04:45) and they're named after like Mad Max characters and like it's, whew, it's spicy. Daniel Jones (04:50) Yeah, yeah, that blog post is exceptionally hard work trying to figure out what's guest town is all about. So Mike Gehard (04:56) the mayor and the all like the sheriff and ooh, Steve. Daniel Jones (05:00) 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. So 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 Gastown 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 in that? Mike Gehard (05:53) 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. Daniel Jones (06:09) Yeah, it's, and this is, know, it's those kind of 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 that 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. You 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 your 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. Mike Gehard (07:15) 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 did 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? Daniel Jones (07:29) My understanding is it's the holdback spec is kind of like the same thing, but rephrased. functionally ⁓ equivalent description of what the system should do in general. Mike Gehard (07:37) Mmm. Okay. Yeah, I didn't catch that. I mean, yeah, I mean, yeah, 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 like, I don't even know where to go with this. think, I 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. 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. Daniel Jones (08:17) you Mike Gehard (08:32) 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. Like 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 took. 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. Daniel Jones (09:03) 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 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 you're 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. 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 a software factories, non-deterministically writing code. They are going to make mistakes. And therefore we're going to need to see when they go wrong. How do we define what's right and wrong? what it says 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 tests. Mike Gehard (10:28) 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. 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 up with the 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 output, has outcomes. So about 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 gonna see this shift. There's a whole litany of social impacts that will come from this. But I think you're right. 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 can theory, theory of constraint says when the bottleneck moves, you have to go find it again because it is 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, 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? Is that Delta, the size of that Delta okay for my product owner or my, know, is the error size okay that it's not gonna break something in the real world? And then how fast can I change that? This is why architecture came in. Like I wanna, like my, you know, my domain is constantly changing. I have to keep up. So. My hypothesis it goes one way or the other or both. So now we're looking there. So, you know, theoretically that where we should be looking for the next bottleneck. 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. So like, there's a lot here. Like we're unpacking it in real time, kids. Daniel Jones (13:41) Yeah, yeah, and it's ⁓ fascinating to see this kind of unfold. And maybe it's worth taking another step back of all 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 Claude it, 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 of your conversation history as Git notes. So you can see the conversation you have with an agent that 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 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 system says come on in leaps and bounds. Mike Gehard (15:40) 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-byte guy. I'm a one set of skis guy. Like I don't dabble in multiple coding agents. tried it codex once and it felt like that awkward engineer you just hide in the corner and let them, like 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. Daniel Jones (16:07) Hahaha Mike Gehard (16:26) 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 Yeah Daniel Jones (16:37) 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 keep on having extra passes at the same bit of code. When writing Claudette, 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 and putting in like four backticks instead of three, which then screwed the rendering of the readme. As soon as you point that out to the model via the agent, you hey, you you screwed up the remix. ⁓ yes, yes, I did. Like those awareness gaps still exist, which is why these software factories ⁓ under the hood are 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 in the dice, then eventually, they're not all going to come up one. Mike Gehard (17:47) 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 LLMs 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, will guide it to the real answer. And then actually I've been looking at Toyota production system stuff. So 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 U S 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, use a factory analogy, but they have this thing called the Ondan cord where that at any point in the system, anybody on the line can pull the Ondan 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 I, 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 pending 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. This stuff's chain. 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, but like the on-down court 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. Daniel Jones (20:52) Yeah, and the idea of, you know, kind of continuous improvement and looking at the software factory as a system. It's really interesting. And 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, they only pass a spec in and they get working code out and, you know, the whole back spec for a verification. We can start look 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 Gastown, everything's in Git, because it's all 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. you know, Gastown has this, it's pole cats, it's agents have long running personas. 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, well, 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. Mike Gehard (23:03) I think it gets interesting. the idea of batch size, I think is what you're talking about. you're talking, we're talking about batch size. So again, to tie into like lean manufacturing and, 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 were, you know, 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 human definition of well that we could trust the science. We could never trust the science. We were always kind of hand waving at how much throughput we had. But yeah, now we can track it. I ran an experiment this morning. I was tweaking some stuff. If I change the story, 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. ⁓ Daniel Jones (23:53) Yes, I found myself doing that. Mike Gehard (23:55) we got into talking about batch size because what is batch size and you know, the, the 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, if I increase the amount of specificity in my spec, can I, can I drive batch size to infinity? Like where, where is the breaking point there? I don't like, I don't know. But we, the cool thing is, is because my agent traces everything, I have Claude after a run, it takes the story, it takes the pull request, it takes the JSON L 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 cost because. There is no slacking. That thing is 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. Daniel Jones (24:54) And also, if everything's in version control, you can do something with a software factory, agentic software factory that you couldn't do with a human team. And that's have control groups. Like you can 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, you know, do that several times. So you can, you know, to your point about batch size, you 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 Mike Gehard (25:05) Mm Mm-hmm. Daniel Jones (25:24) you know, 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? Mike Gehard (25:34) 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. Like by rolling up my sleeves and starting from scratch. I started with an empty repository, you know, general ideas of where I wanted to be. Like gas town was a thing. I was like, gas town. 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 Gastown and I built something else, a multi-clod, 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, do it's always we do we retrospect at the end. So I started building this thing up and about a week ago, I got to the point where I can create a story and get hub. 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. Like I ran one, I ran one last night, literally I started before I go to bed. Um, and I'm like, here's the story. I have a hypothesis, like let's run the base case. Let's run the control. I 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 need 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. Yeah. 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. 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. It's just pull requests all the way down. So that's how it works. It's pretty cool. I spend 20 minutes in the morning kind of poking around, writing some articles, 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. And I'm keeping it private for now. So OB Fernandez style. I'm just going to keep this private because I don't, I don't know if it's going to have any value to be open source 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 up. Daniel Jones (29:17) It's a yeah. And open source is just, just an interesting space at the moment. There's a, obviously lots of open source repose getting bombarded with, ⁓ AI generated PRs. There are, agents naming and shaming individuals in blog posts on, Claude book or whatever it's called. Malt book. Yeah. so there's all of that kind of stuff happening with open source, but also Mike Gehard (29:33) ⁓ Mulkbook. Man, what a social experiment that was. Daniel Jones (29:42) Like software is potentially now just indefensible. It's, it's commodity. Like 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 null. ⁓ Mike Gehard (29:46) Mm. I was wondering where you came up with that. was like, is he serious with this one? Daniel Jones (30:13) Well, originally, the AI native software license was it was supposed to be a satire of this site, 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, because 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. Mike Gehard (30:50) Especially when you're the domain expert, like you, are the domain experts in software. So agreed. mean, 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. Like, you know, Especially, 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. They talk about, 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 like 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. So I, I don't know. Daniel Jones (32:10) Yeah. Yeah. And not even as a like, not even as like a Salesforce competitor, just as a test thing, you know, we're just going to rebuild all of Salesforce and just so we can test against it. Mike Gehard (32:26) It's a dependency. They're isolating themselves from a dependency, but they can do that overnight. you're like, and I, 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 advertorial tests. I'm just like, wow, I would have never thought to do that because it would have been economically and feasible six months ago. Daniel Jones (32:52) Yeah, I mean, and I'm tempted as part of an ongoing art project that is Claudette to like just watch the entire IO website and whatever features they announced, just like ping Claude and go, hey, do think you can build this? Can you add this to Claudette 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. Mike Gehard (33:05) Yeah. Well, and if we go back to talking about like risk analysis, so like, what does that look like for my risk profile for my software? If I don't not pulling in external dependencies, I control my dependencies. I could, you know, I mean, 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. I mean, the C 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 boat. Daniel Jones (34:02) Yeah, we were having a conversation in recent 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. Mike Gehard (34:40) Mm-hmm. I mean, I think that's going to be the interesting piece. What did 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. 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, I know. So the, were talking about software factories that companies are building for their internal use. I saw something in their day. 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. Daniel Jones (36:10) It's, you know, to use the term abundance has connotations with some people have, you know, 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. 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. Mike Gehard (36:52) you Daniel Jones (36:52) 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. Mike Gehard (37:14) Yeah. I mean, I posted something, it was the other day, a couple of days ago. It's so hard to keep up. I'm very prolific on LinkedIn these days. But 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. If you're based 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. Daniel Jones (38:05) Yeah, the you know, 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 doesn't matter about the cars, Airbnb is a technology company, software company 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 no longer going to be the most valuable component for sure. Mike Gehard (38:33) Mm-hmm. Mm-hmm. Yeah. And what does that do to a stock market that is propped up by, I mean, I go back to the, keep going back to the economics because I was listening to that Dario Amadei podcast this morning and 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, are starting, I'm talking to engineers just now who are like, well, what do I do? as an engineer, what do do as a software developer? I wish I could tell you. I just don't know. 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 reevaluate 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 gonna 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 gonna do for me? What's this gonna do for my family? What's this gonna do for my community? What's this gonna do for the world? Which gets, you know, easy to spin out on, but like we should be thinking about this. Daniel Jones (40:24) 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's something you posted, I think yesterday, 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. Mike Gehard (40:29) Yeah. Daniel Jones (40:49) Do any of those ⁓ kind of spring to mind as to how the equation is different for you as a software practitioner? Mike Gehard (40:56) Yeah, 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 Effective 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, talk like, let's, let's experiment with Michael Feathers ideas from this book and how would that include, like, but so much of our lore, Kent Beck, Martin Fowler, Sandy Metz. 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... apply them ad hoc. I think I think the one takeaway has been what is good software and why do I care? And you have to ask yourself that. Daniel Jones (42:44) 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. I was just very cheekily checking on Slack to check people's names and URLs and things. Tudor Gieber, probably totally mispronouncing his surname there 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 instead is inappropriate structure for the direction that you now want to go off in. And we've had quite a Mike Gehard (43:38) Yes, that's the whole 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. Daniel Jones (44:02) 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. So, ah, crap, this has gone from a six week project to a 12 week project. Mike Gehard (44:30) Mm-hmm. Daniel Jones (44:32) That's a big deal. If it's gone from 10 minutes for Claude to 20 minutes, and you know, twice as many, it's gone from like $2 to $4 worth of tokens. Like, does 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. 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. Mike Gehard (44:50) Mm-hmm. Daniel Jones (44:59) as much as it has done in the past. Mike Gehard (45:01) 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, you know, tens, 20 years ago, when would, 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'll actually kind of do a pretty good job of that. 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 we all know that LLMs generate better when you're at the 20, 30 % of a context window. not the whole lost in the middle problem. But I don't know. don't like, is minimum Bible architecture? Like think that's the question we should be asking ourselves. What is minimum Bible architecture? Daniel Jones (46:01) Yeah, and there is the... And there is an absolutely valid argument in there about agents liking structure and consistent structure as well, because 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. And that would be bad. like that. Mike Gehard (46:22) I had that, I had that happen in my experiment last night. I had conflicting architectures, even though the spec said to use TypeScript, it wrote a bash cell because I still had bash shells in there. And there, 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, like it, it, it reasoned, you know, people say they don't, but like it, it, it went through the mechanics of like making a decision about what structure to follow and came down on the bash shell side. Daniel Jones (46:37) You Mike Gehard (46:49) I'm like, okay, cool. Like I would have done that too. Daniel Jones (46:51) 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 not. There's probably like non-functional requirements that you will need to express and I wonder if they 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 implement a new feature slightly differently. I think that's, I'm sure there are probably really clever. Mike Gehard (47:26) Mm. Mm-hmm. Daniel Jones (47:39) 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 bit of a slowing factor on what we can do with software factories. Mike Gehard (47:56) Mm-hmm. Yeah, I 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, 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, where we have to apply these same techniques we applied to software to solving these problems. And it, it's a different way of thinking. I mean, this is people talk about engineers moving up the, up the abstraction chain. Like that's where we moved 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. Cause I think that's the cool thing now is the details are unimportant. It's building. Cause even I think that, that dark factory posts from Simon Wilinson talks about they were building on other ideas they had seen other places. You know, 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 what 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, pull down their boots and like got to work and figured out how to make it. So 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 gonna be right all the time but Someone's gonna see that post and try something else and then you're gonna see a post from them and we're just gonna keep moving this forward like we have for decades with Sandy the Sandy Metz is and the you 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 Daniel Jones (50:08) 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 I don't know if 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 is like, my God, somebody just like posted this and I've just realized that the implication of this is that it's yeah, 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. Mike Gehard (50:47) Mm-hmm. Yeah. Yeah. I mean, I think it's like any bubble. 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. Daniel Jones (51:06) I'm You Mike Gehard (51:15) I have been noticing some interesting focus problems and benefits with this. like we were always tied. I'm 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. And 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 you 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. Cause I'm getting out and 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. Daniel Jones (52:13) It's certainly a complex area and it will affect different people in different ways. There's a few things that sprung to mind there. One is a reasonably personal story. When my kids were young, I had just come out of the games industry. 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. Mike Gehard (52:56) Hmm. Daniel Jones (53:01) 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, I can't 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, um, 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. Mike Gehard (53:34) You Daniel Jones (53:51) Couple of weeks ago when I was working on a thing with Claude 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. Mike Gehard (54:27) Mm-hmm. Hmm. Daniel Jones (54:46) So that was really cool. And then just another thing on, like you mentioned going for a bike ride. Something I found is that, thankfully, 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, Mike Gehard (54:59) Mm-hmm. Daniel Jones (55:13) 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. Mike Gehard (55:25) 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. I'm out of my bike for an hour and a half, two hours a day. Daniel Jones (55:39) Yeah. Mike Gehard (55:51) 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. So 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. Daniel Jones (56:41) 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. Mike Gehard (56:44) Mm-hmm. Daniel Jones (57:06) And with the compulsion thing, 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're doing something else. You walk past your laptop and you're like, Claude's not doing anything. I should probably ask it. 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. And you go to bed and you're like, I haven't set Claude a task. Mike Gehard (57:15) Mm-hmm. Daniel Jones (57:31) 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 called to 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. Mike Gehard (57:51) Yeah, I mean, we're dealing with another non-deterministic system. I've read some, I've listened to some really good books on it. 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. 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 that'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. Daniel Jones (59:53) 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