The Software Factory: Why Document-Driven Development Is Reshaping How CTOs Build

Speaker A: I am very curious to talk to you about the impact that uh, AI assisted coding is having on our SDLCs. I'm very interested after 0111 to hear your thoughts on the general direction of, of how AI is impacting our roles as CTOs, how we design software, how we view incremental improvements and how we view technical debt and how we view refactoring.

Speaker B: I feel like we touched on uh, some big ones and I think there's a few that we've been focused on that we didn't even touch on. That I can talk about a little bit too. So happy to dig in. Um, obviously it's having a huge impact on the industry. It's having a big impact as well on how you should be negotiating with your partners and uh, for your company and setting expectations with how you're selecting software vendors. I can give you a little anecdotal evidence or anecdotal, um, some things I'm working on, just anecdotal. I mean these are real negotiations for some with some large partners that were auditioning and the first, first question I asked them is how are you writing software? And if they're not using document driven development and can't describe that process, I mean they go pretty far down the list to like fall off the table. Interesting, because in my, you know, and those partners that, the very, very small percentage of my, my partners that we're considering and we're talking, you know, big, big partners for either whether it's a CRM software, ERP software, whatever you're, whoever you're uh, doing a selection with, you know, if they're not taking into consideration the risk of their business when the cost of software goes to zero, as I like to say, then they're not going to be a partner in two years because they're going to be out of business.

Speaker A: Well, before we, before we go into that, um, we're going to, we're going to talk about document driven development. Um, I'd love to hear this modality of cost of software going to zero. But I do want to just ask that you introduce yourself as you are comfortable with the audience to know who you are. Sure.

Speaker B: Um, well, uh, Matt Ferguson, I'm currently the CTO of roofmax. Roofmax is the only nationwide roofing brand and we offer a variety of services through our dealerships nationwide. Uh, and that includes the rejuvenation of asphalt shingle roofs. Well, what's the importance of a CTO in this realm? Uh, we have 385 dealers to support and the marketing budgets to support them, the software to support them, uh, so that they can service our customers. Um, so while it's uh, you know, we're the, we're sort of inventing a whole genre of business, uh, in the roofing space and there's a lot of opportunities there. Um, I've been uh, been working in that role for little less than a year and before that had done a lot of research in the AI space and spent time, uh, you know, after the last startup really working solely in AI and AI consulting. So felt very comfortable in launching into this new business with an AI first approach and trying to reinvent the business as an AI driven company in every part of the process. So I hope that's enough of an introduction. Got it.

Speaker A: So your uh, your, your history obviously brings us to sort of traditional development modalities to you know, I saw you adopt the mob programming modality. I saw um, you go to Latin America. I saw, you know, so I've, I've had a sort of a front row seat to you being on the edge of trying, trying things out, adopting it. And then one thing I've learned about you is, is you go boots and all into. There's something that grasps your imagination and your conviction. You go for it. Like, it's like, okay, we're, we're burning the boats. Uh, this is how we do things now. And I, and I find that to be an admirable quality. Quality. So it's not sort of a pensiveness. I mean I know you have your own evaluation process so that I'm hoping obviously excludes, uh, or sort of excrete risk and um, recklessness. But when I've seen you adopt a uh, process, uh, it's been incredible to see how you do it.

Speaker B: Thank you.

Speaker A: I want to ask you just before we go into AI stuff, where does that, what is that mental model? Like how, how, how have you been able to say, you know, what mob? Hm. Yeah, I mean I saw you buy the, what was it like the 70 inch TVs um, at Zito and, and, and put developers around these big televisions and it's been fascinating to watch how you move the needle and so just tell me a little bit about mattferguson.com when it comes to thinking through things.

Speaker B: Well, I think innovation is an important part of all of our lives and we have to drive it into process, not just our technical implementation. You know, I think most of my innovation has been around the people in the process. Uh, I think that's where I, what I find fascinating is the operational side of writing software, if you will, or the, the modality side of, of writing software, uh, or building systems. Um, you know I'm a, I'm a big believer in systems thinking. That's where my head is at all the time. Uh, when I, when I come into a company, I'm consulting with a company or I'm m. I'm the CTO of a company, I'm m. I'm constantly thinking about the systems I'm observing and I think that's where I find I can have the greatest impact. Uh, and I think maybe you've read the book as well and I'll highlight for anybody, um, you know, the systems, um, thinking from Donello, uh, Meadows, which is ah, you know, can be a life changing book for those of you that.

Speaker A: Really life changing.

Speaker B: You know, I tell people, by the way, I've got a box of them here, I probably have five copies on me all the time because they're small and I can give them away, you know, and I do, I literally hand them out and they hand them out to my executive teams and I say the first thing you should do is read. I think it's not the last chapter, but it's the almost the last, uh, read. Read that last bit about the, the 12, um, the 12 leverage points, you know, 1 through 12 and then go back if you're still curious and read how, why they're, you know, how the, how some of the details of the nuts and the bolts but understand these 12 leverage points. So I think as a, as a professional it's important to understand that, you know, your leverage point needs to start around in the middle, you know, the six or the seven where we're, we're changing paradigms or we're, we're actually, you know, not down at. I can change a metric or you know, do I have the right metric? But it has to be, you know, I'm, I'm changing how these two systems impact each other. I'm changing the feedback cycles, you know, of the, of these systems. So when I look at you know, sdlc, which I think I've had the most impact on the organizations I've joined and then, and then how systems work in companies, you know, you're affecting not only the software engineering system, but that also affects in many cases the marketing system or the product management system. And that can. Those things all working together are greatly impacted by just one of them changing. So I think that's why I've gravitated. To, you know, influencing uh, the SDLC and the how we write software, uh, over time. And I think that's playing out really well for me now in the AI space because you know, the, you know, as I, as I heard someone say it the other day, you know, if you're asked the question, well, in the AI world, well, what's your tech stack or what language are you going to use? And the answer is it doesn't matter. And uh, I think that's always been a little bit of my view is it doesn't matter because we shouldn't have to worry about that because the process is more important. The fact that we can use any technology, we can use any stack, we can use any software, and the fact that we picked a particular software just as an example here is really an implementation detail. Uh, I want to operate to make sure we're making the right operational decisions and process decisions. That's where I can have the highest impact.

Speaker A: Yeah, I mean it's, it's, it's interesting. That is an interesting paradigm shift that the process is more important than the tech stack. So I would, I would imagine that that includes the consideration that if the tech stack is erlang, the process to hire people into that stack is, is, is solved or is accounted for. Okay, it's not, it's not, it's, it's, it's still, there's still consideration inside of the process. It doesn't mean that there's um, it's still thoughtful process. Um, but that does govern how we choose tech stacks just to use sort of a.

Speaker B: It has example, but it, but it's rapidly becoming not right.

Speaker A: Yes, yes. And I'll give you an example of that which is um. A few weeks ago I Posted on our uh, 7cto Slack a question around which hybrid framework people are using these days for hybrid mobile apps. And I think um, Mick Hermes responded and he said who cares?

Speaker B: Who cares?

Speaker A: Just in the age of AI you build it native and then the Android version gets built native by the AI. And that was such a liberating moment for me because I feel like cognitively I knew that, but connecting it with unbridled creativity and realizing there is a massive um, constraint lifted from my back end choice, my containerization choice, my infrastructure choice, my front end coding, because it doesn't matter.

Speaker B: Uh, yeah, another example to that cognitive change is someone mentioned the other day, uh, whether they should start with microservices or not as a, as even a younger company, as a, you know, and I think there's been this rule. Well, they're really expensive and complicated to do and you should, you should, you should eventually become a microservices job. Or when I say microservices, maybe I mean macro services in my, my, my religious view on that. But nonetheless, the monolith, um, approach versus a services approach, uh, you know, is a startup with. Well, I'm going to be a. We'll build as a monolith and then we'll switch like. Well, no, actually in the, in the, in the, in. In the world of AI, the complexity goes down to nothing. In fact, microservices macro services is actually better for an AI because you can contain the context of what you're trying to solve and put boundaries right around the context versus in a monolith. You've got to understand the entire context. You know, in, in every question you have to the AI. So yeah, uh, it's a much better approach. And now with AI, with the cost, as I mentioned, the cost of software goes to zero. Why wouldn't you make the right choices from the get go in your company

Speaker A: now, uh, expand on that a little bit. The cost of software goes to zero. So I'm assuming you're talking mostly about labor.

Speaker B: I think mostly. I mean, and it's a euphemism, of course, you know, but the euphemism holds true when you're talking about a exponential change where instead of a hundred software and engineers, I need five or ten. Right. Or I can do a hundred times the work or 10 times the work. With the hundred, one way or the other, you. The economics of software changes monumentally. And so I like to use the euphemism because it causes guys like you to react, which is the cost of software goes to zero. Which makes my point, you know, more dramatically than saying it any other way.

Speaker A: I understand. No, I, and I, and I love it. Um, I think, I think especially in the context of which you mentioned it earlier, which is when you're interviewing partners and service providers and uh, considering, you know, uh, you know, you have Parkinson's, uh, law. Have you heard of Parkinson's law?

Speaker B: No.

Speaker A: Parkinson. What?

Speaker B: Educate me on this one.

Speaker A: I have not heard of Parkinson's law. Says that any project that has an allotted time to accomplish it will take, Will fill that time.

Speaker B: I thought that was Matt's law, but okay, whatever. Yeah, I thought I always ended up doing that, but okay.

Speaker A: He was in the, it was in the 60s. He came up with that. And, and um, and I just, I just thought to myself, man, that is Such a fascinating law right now because um, apart from the, from the, the nuances around estimation and scrum and the, you know, the Parkinson's law was generally around you know, time box what can be done in X amount of days or whatever. You know, so two go sort of the no estimates route and stuff. But now we're in a world where what time are we allotting to work, getting done and, and, and, and can we even relate to that as humans when the super intelligence is doing it?

Speaker B: Uh, I, I'll give you a little, I mean we're in the process of asking our developers, uh, and I'll remotely ask answer your question, but probably through a securitious route. We are reinventing our software engineering team to be more product managers because we believe the, there has to be in my view, uh, you know, product managers are becoming software engineers. Software engineers need to become product managers. We were, it's hard to find a lot of product managers. And so how are you going to fill this gap of understanding product? You've got to get your software engineers to be able to write requirements, to be able to work with stakeholders because writing software is not the hard part anymore. And certainly interpreting what gets written and is it getting written right, Obviously, you know, is important, um, and being able to judge that. But the value is writing great requirements or writing great user stories and you know, the use cases and making sure that you're writing those initial documents correctly. And I think software engineers have to become, you know, excellent at that in order to be the master of the agents that they're tasked with doing the work. So I think um, you know, software engineering is becoming a, you know, when we talk about the SDLC and document driven development, it's coming down to becoming a software engineer has to be great at understanding writing requirements, um, writing, just writing in general. So we have been shifting our team to spending more time writing requirements, probably like 90% writing requirements, 10% in looking at code. So I wanted to get that out on those because that changes my answer, you know, that that affects my answer to you about the, you know, estimation and what should we be focusing on? Uh, we need to be focusing our teams on do we understand the problem? Because solving the problems, if I, you know, I can solve the problem, but am I solving the right problem? Uh, is more important, you know, and also if the cost of software is, goes to zero, well the fact that I got it wrong in my code doesn't matter. I can just rewrite the requirements and regenerate the code. And in Minutes. Right. So let's not be afraid of, of writing the wrong software or being perfect with our code. And I think spending more time on the right problems to solve, which includes having those abstraction discussions. And how do you interpret that? Like we think of, we think of the AI or we think of how we want to communicate. You know, I always think, hey, how would you communicate to this, to your most junior developer? How would you break it up? How would you make sure that you're thinking about as a software engineer? Yeah. I have certain abilities that as I become a product of product owner, or I convert you from just software engineer to product owner, you now have this software engineering skill around abstraction and about, uh, compartmentalization and context that you can bring to that product job. So that when you're authoring product requirements, you are already framing contextual boundaries. And the fact that, gosh, you know, we need to think of a, think of this abstraction here, not just lay out what I want. Right. Which is an important melding of these two roles.

Speaker A: Yes. And, and if I relate to, if I relate to it with my own evolving journey, I'm finding that the, the, the greatest value that I add in my partnership with AI agents is the architecting, because the decisions that are made along the way, you know, there's some key decisions around, um, you know, do I want to have, do I want to, like, for instance, how do I cash? You know, am I caching through local storage? Am I caching through backend redis stuff? Um, there's a bunch of decisions that I find as a sort of a veteran computer scientist guy who went through the traditional world like you did, they're just some very strong guidance that I have to provide my agents. Now, that's probably rapidly being redundified and as we start getting into sort of more, you know, the AI making those decisions for you, because I mean, ultimately you could just say, I don't care how you solve it, just go and solve it. And clearly the LLM will have an opinion on how to go about solving the problem. But I do find that for now, my greatest value to the coding process is architecting. And of course, then what you're saying around product and understanding the problem, that's a, that's a big one. Uh, because the AI doesn't understand the problem necessarily, or doesn't really know what problem you're trying to solve unless you are explicit about it.

Speaker B: Yeah. So I, uh, I believe these caching, these patterns, we'll just say the architectural patterns that we want to impose is no different than you have that junior software engineer who's raring to go and, and can write code. But you know, we need to, they don't. That person, when they're, you know, um, is not going to understand the business. So they, you know, we, we, we need to write. Sure. Make sure their use cases get written and we need to also hand them the architectural patterns that are going to make them successful. It's the same discussion we've always had with, with managing a team of junior software engineers which I think are uh, what our current world of AI agents are, you know, wonderfully skilled software engineers that need guidance and that keeps, but every month that gets better and better and better. And so we start to be able to step back a little bit from the patterns and a little bit more abstract in the user requirements so that we're not having to give not as much guidance. But yeah, I think it's naturally going to evolve. Um, so you know, you got to start now because you know, you'll be left behind if you don't uh, get engaged with this stuff, you know, as soon as possible in your, in your, in your company because I mean it works really well. It's, it's amazing. And you know, where it's going to be a year from now, you know, who knows? But it's going to be exponentially better.

Speaker A: So part of converting your team from code people to product people. Product or problem oriented people. Right. Solutions to problems people is helping them fall in love with that. And I'm assuming some people adjust and others are like, no, this is, I, I, I, I took this job because I wanted to code and craft. Now uh, you're asking me to think about the business and the problem domain space and that's not what I signed up for.

Speaker B: You know, I, I thought we would end up with more of that and uh, more challenges related to that. And by sure. Haven't everybody has really said this is, you know, it might be a little frustrating. I'm learning a new skill. I, you know, there's, there's certainly the case of perfection and I want it to be perfect. Um, and you're like, no, no, no, no, no. Show us your first version. Get it out there. Let us, you know, don't be afraid of being wrong, don't be afraid of showing something. And I think getting it into your comfort zone around writing is something people have to learn. Uh, you know, as much as they were comfortable around their code. So there, there is some disposition that way. But I think that's rapidly Melting away as people have gone through a couple cycles.

Speaker A: But the uh, but the writing is also AI assisted.

Speaker B: Sure. I mean it's somewhat, you know, we don't dictate the AI assisted part there because we are, uh, but, but people sometimes are like looking at old code bases, trying to distill that down into business requirements and then hand doing things or, or maybe they're, you know, feeding it a bunch of screenshots of, of, of things they like or, or maybe CRM tools or, or this tool or that tool or, or how to represent, you know, different types of objects so we don't have to do everything from scratch. But at the end of the day, you know, we are, we are treating those documents as code and they go into our code base in our documentation folder. They become something that have to get approved. Like any, um, you know, like, like any uh, uh, any, any push to the, you know, commit has to get approved before it's, before it's pushed into the main branch. Um, because that, that is the foundation of our code is, are those documents and if those, so those are being reviewed by myself and other senior people on the team to make sure that they're meeting a bar because we want to go through iterations of training with those team members just as if they were, they were, you know, the first code that person wrote. So documents are your new code, bottom line. Treat them like code, put them in your, put them in your GitHub repository as code and iterate them, iterate on them as your source code. Those, that's what your documentation is.

Speaker A: And all the, all the documents just generally just this is the problem, this is what, this is how we solve it. This is the suggested solution. This is, or this is the proposed solution. Like is it kind of like a product, one pager, uh, where we used to define why we're doing something, what success looks like, what the outcome is, blah, blah, blah, all in one document. All of that.

Speaker B: Yeah, absolutely. So at a domain level. So first do domain level analysis, right. As a senior team, divide and conquer and we use AI to help with that a little bit. But we still use, you know, our senior people to say, well what would a domain driven design for this look like? What are the major domains and contexts? Then you know, break those up into documents that you can, that you can now, um, assign so that everybody's handling a domain. And then the, each of those documents then is a set of use cases and each of those use cases is going to have, you know, what are we trying to solve what's the paragraph? What's the narrative? What's the exit criteria? So those will be the product, those will be the, the product requirements. Um, um, those. And, and our goal is that, you know, as we write code,

Speaker A: I mean

Speaker B: those are going to drive the next step. Those will drive the prd, those will drive the, the technical design. Right. And then the last thing we do is code that's, that's like the, because we want to go to one shot, you know, we're not here to like, you know, push the. Pull, the old pull, uh, the old, um, you know, the, the wheel on the, on the, you know, the machine and see what we get. Oh, all jacks. That's wonderful. Oh, we didn't win that one. Try again. Try again. Until, until AI gives us the right answer. That's not what we're after. Right. We're after as much one shotting of the code as possible. And if we're not one shotting the code, why not? Well, either. Okay. The AI is not good enough yet and it struggles with X. That's fair. Or M. Our requirements, our patterns, you know, are somewhere upstream in our three levels of. We start with the requirements document that's hand authored. Typically the, the PRD is generated through, you know, our experience with cloud code and, and doing the plan exercises and, and having it ask us questions and then we have to answer the questions and it iterates. So we iterate through that with our claude code sessions. The technical design same. So we're already three or four levels before we ever try to write code that we aren't gone through with him with approvals from senior team members. Our goal being that we're spending so much time doing, planning that writing the code is one click.

Speaker A: Yeah. Which is, which is so interesting. If I draw the, the line back to MOB programming and uh, again, just remembering MOB programming where we basically said it's conversational coding, like the actual typing on the keyboard is the least of our, uh, concerns. We, we are mostly, you know, and I, and I think in some degree this is a representation of that.

Speaker B: It's not only.

Speaker A: It is.

Speaker B: And I think it also goes back to, you know, some of the fundamental principles of Agile, you know, not the implementation of Scrum and whatnot. That's not what we, what we want to talk about here. But you know, you know, making sure we're solving the problem that you know, being able to iterate, you know, is it should be through language and communicating and describing that thing. And I think the, the one thing that we're evolving here is that, you know, actually writing the code and showing a working system doesn't have to be what we do every day. It's great once we're evolving, but you can, you can do a lot of work of just getting the, the document right and making sure you have the right patterns, you know, the right pattern, the right document, the right, um, the right design that you've interacted with AI enough that you're like, damn, this thing, it understands what I've got. It's asking me great questions. I've really thought about some of these hard questions it's asked me and I've thought about it and I'm changing some ideas and I'm going back and refining a document and seeing if it has some of the same questions again. You know, that's a great conversation. And I can't hear you now. Your microphone's, um, off. Can you hear me? Yes, can hear you now.

Speaker A: I can hear you. This is weird. Um, the interesting thing about the one shot comment is it's really, you know, people should understand that it's not a vague document that you're trying to one shot. It's actually multiple interactions with AI assisted tools that help.

Speaker B: Yeah, we want to one shot the code, but we probably did a lot of interactions with AI to conversations with a highly intelligent, highly well, reasoning.

Speaker A: Yes.

Speaker B: Right. Just so that we're getting to that point where we think a one shot is possible in code.

Speaker A: Yes. And ultimately it's, it's a one shot on the code, but it's not your first interaction with the AI. Um, so, so, so let's just, let's just canonically state what document driven development is. Can you explain that to someone who's never heard that before?

Speaker B: I'll try. Um, our, our document driven development is the concept of writing down what you want to do, what your problem is, that you want to solve in a descriptive enough way that the AI can interpret and plan the work and through that plan can execute the code. Uh, you can kind of look at that, uh, you know, from a. I love fractals. Right. You can either look at that at the smallest, smallest piece of. I want to do this hello world piece of code to a little bigger, to a pretty massive scale. And so, you know, certainly, uh, as an enterprise shop, uh, we're doing something at a pretty large scale. So we're doing a lot of these iterations, you know, on this. Um, you know, our document driven development is, let's make sure we got the right documents written so that development so that the AI's interpretation of that development is streamlined as possible.

Speaker A: So the instinct to, I uh, mean this is of course juxtaposed against vibe coding where you kind of just start with a blank slate and you just sort of see where it goes and then reverse engineer a document potentially. You're saying, hey, I have this hobby project and instead of starting with um, a, a massive prompt and then setting the thing loose and then coding against the code base with the help of AI assistance, you're saying, I'm rather going to use that cycle and iterative process to create the document, or let's say the blueprint for what I'm trying to develop. So what I like about that is, is you are all the cycles that you're spending, like this is a waste elimination, right? Because you're spending a lot of cycle still, but you're investing it into a gold standard for what you're trying to do rather than a reactionary make this work. Um, and then tell, remind me how we did this. And then Claude gives you a whole. Oh, well, you know, so. So I see this as two very fundamentally different, uh, approaches.

Speaker B: Yeah, I think you're right. And that's why I've always been a little. I m. Don't like this word vibe coding. Just because I've tried to, you know, as it's been represented and as I've done it personally and I understand exactly what it is, I'm like, oh, uh, wait, I don't want my team doing that. I want my team. I want there to be a more reproducible deterministic process. And I think that's also been a bit of the hesitant or the. Where we've seen companies that have not had the 10x improvement and they're like, oh, I get 25% better when I use AI tools. Okay, well that. Because you're not using document driven development, that's becoming and turning. Turning what is, you know, a non deterministic slot machine into, you know, I've counted all the cards and I know I'm going to get an ace, which is what I think document driven development gives you. But only if you follow a pretty stringent document driven process that is iterating on the documents, iterating them into the plan, the technical design. And you're actually iterating there. You're not writing code. I mean you are trying not to write code until you think you have this whole thing. And I'm not. And I'm not saying you shouldn't write code as soon as possible. But you need to have, you need to have confidence right, in that once, uh, you start writing the code. And the reason I look at that that way is where do I want to make my change? As soon as you write a bunch of code, people that are really comfortable in code are going to change the code and make the code work. And they're going, uh, I could do that better. And I could do that better. Instead of saying, gosh, I didn't articulate that pattern, I didn't go back to my GO skill and tell it these, this is, this is how I want. Oh, gosh, I should have defined a better pattern for my, you know, how I want to build database tables, and my naming convention for my database fields should have had these, you know, this prefix and this suffix and these verbs and these nouns. Oh, you know, and so I go fix it over here instead of saying, oh, I should have designed the skill better. Because we're not only defining our documents better by doing this, we're actually, you know, in Claude code, in our case, saying, how are we communicating our expectation for each of the skills that we teach our cloud code to use? So our Go skill needs to have a, have a mentor, right? So we have a couple Go people on our team. They're like, ah, uh, we'll take that. We'll make sure that the go is produced the way we like Go, right? And our database guy that's more stronger in database is like, I'll make sure that the syntax we're using in our database, you know, in our tables names and our field names are of a certain syntax so that we're all cool. Because, well, AI didn't know what we liked, so it just picked something and hopefully it picked the same thing, but not always. Every time it had a table idea, right? So you have to teach the skills, not just the document. So you've got to come at it from both sides. This is what we're.

Speaker A: Yeah, it's like, it's like, um, if you boil it down to pure LLM speak, or I guess it's really designing the prompt for the one shot.

Speaker B: I mean, listen, at the end of the day, we're creating a factory. We're creating a software factory. This is not software development anymore. We're engineering a factory. And the engine in our factory is AI.

Speaker A: Yes.

Speaker B: As a factory mentality now it's a system. Goes back to systems thinking.

Speaker A: Yes, yes.

Speaker B: You have inputs to the system. You, uh, have feedback loops to the inputs of the system. You can either impact the Feedback loops and you'll get reoccurring results that are virtuous. Or you can just fix the toys at the end of the line and fix them if they come off the line and never fix the feedback loop. Right, right. So if you're going to build a factory, you better have a systems thinking approach to building a factory.

Speaker A: That is so critical.

Speaker B: We are building factories.

Speaker A: Yes, I think it's a critical distinction and I'm, I'm also just getting it now, which is, um, you know, I, I, I think the shortcut that the industry is making in terms of reducing team size, cutting cost is that they are thinking AI is replacing a developer. But what they're not thinking is where we have a tool to create better, like you said, factories or better process that whether it's code, whether it's a robot, whether it's a flying duck, whether it's a spaceship at the end of the line doesn't matter because we have ip, we have empirically built something with enough feedback, like you said, where we actually uh, we actually own something. Whereas, whereas if you're just shortcutting to AI, replaced my team of 10, what, what do you actually own? What did you, Right. Do you own the code base? No, the code base is now the, like you said, it's, it's um, the cost of it has gone to zero, euphemistically speaking.

Speaker B: Right.

Speaker A: So the investment is not there. The investment is in the machine. I think that's a fascinating reframe, Matt.

Speaker B: Well, the software factory and those of us that have ever walked a factory floor or been involved in a factory, know that there's still people involved in a factory to make it work. There's a, and I think software engineers are the process engineers of a factory. And uh, that's the new world you know, of a software engineer is you have to think of yourself as a process engineer. I understand how this factory works. I understand the inputs to the factory, I understand the outputs of the factory. I understand if the outputs are, you know, are high quality, you know, I have a testing process, you know, I understand that how I can impact the inputs to the factory. And I think maybe there are even sub factories, you know, or there's different factory places on the, on the floor under that big roof because there's our document driven process that gets us great requirements, that's like its own mini factory that feeds the actual software factory or sub factory that actually produces code. And each one of these are subsystems. Like as you break down the system of systems into this factory, you know, idea, each of which is AI assisted along the way in, in different ways. But at the end of the day, you're getting out this, this wonderful toy that we call a working piece of software.

Speaker A: I love it. This is definitely helping me. So, so what have I, what have I done if I simply fired up Claude, gave it a broad spectrum of what I need and then started coding against that? What am I talk to the CTO out there who is, who thinks that that is what using AI is about. Hey, developers, go try out Cursor, go try out Claude, go do this, go do that, and let's see if you can output code faster. Uh, essentially. What are they building?

Speaker B: Well, they're not building a repeatable process. And so there's no governance, right? So this new thing, the factory and that shop, you know, needs to be able to show repeatability, that in the future, if I decide to press that button again and rebuild that piece of software, I get the same results or better, you know, better meaning faster or improved software faster, uh, to build better performing or more usable by my team, by my, by my, by my humans and uh, or systems. And so I think that, you know, that what we're up against is determinism, right? Or deterministic nature. If you're not putting time into governance and you're giving everybody free rein to do whatever they want, or you're not really looking at the governance of how you're building documents, which are driving, which are the requirements and many different variety of documents go into this. Right? But if you're not putting, uh, a level of governance there, which is what we're doing of how, and treating that as the gold, you know, you're going to get different results. And when you try to build that piece of software six months from now, you might get a different result, which is not acceptable. When I say a different result, a bad result.

Speaker A: Right, yeah. And, and, and in the traditional sense, hey, senior developer, uh, you, you bear the brunt of the variability or the change or the, like. You use your skill to manage that change for us. Whereas we're saying in this new world that is, in the documents, it is,

Speaker B: and it's, and that's what a senior software engineer has to be, you know, very, very skilled at, is knowing that what they're writing, the AI, is not going to understand or is going to misconstrue. And until you go through a few cycles of seeing it fail, you're not going to realize, oh, you know, and it's still. Until you and making sure that how you improve is you impact the uh, the inputs instead of fixing the output.

Speaker A: Instead of fixing the output. Yes.

Speaker B: You, you as a, you as a senior engineer won't, won't bear the burden of, of making the process better.

Speaker A: Right? Yeah.

Speaker B: So that's a learning curve that everybody has to go through and there's a, you know, there's only a few of us or, or team members that have, I think done it well in a few enough cycles to have that experience. But I think it's something you can rapidly get. But there are those people that kind of think that way. They're, that they just get it. Like I know exactly how this LLM is going to react to this thing and I would not write it that way sir. I would write it like this.

Speaker A: So just two things I want to circle around before we wrap up. Um, one, so if I have done my work well, so I'm ctoing a company, I am doing document driven development. So I am um, creating a folder with uh, just an immaculate list of documents. AI feedbacked AI cycled documents. What happens with this one shot approach? Do we then just say, is there a prompt where we press enter on and then we just watch the magic happen?

Speaker B: Well, I mean the way we're looking at it is it's per domain, like per service. Uh, yeah, it's, you know, you're, you're producing a service and then that service then it's, you know, because you want to do things in order, you still need to use. I, uh, I think it's important to be able to still understand how the machines connect together. And you have this, you know, you produce this service and this service which are the required before this service. And so having these SDKs of how, or, or, or how this, these services are going to communicate to that service. You know, there's a lot that has to go to still making sure all this thing connects and looks right. And you know, you don't need to be doing A before B, uh, or B before A. Um, so there's a lot of uh, I think um, at this point in time, you know, making sure all that's coordinated. Right.

Speaker A: Orchestrated.

Speaker B: Orchestrated, yeah, by, by, by I think some human oversight. And, and that's almost like another document is how we thought of it.

Speaker A: That's what I was thinking. Is it, Is there another agent that's orchestrating all of that?

Speaker B: Yeah, so we, we have document. Yeah, there's, there should be another document. I uh, know a partner that walked me through their AI that Does just this. They have a special AI that's trained just to look for these dependencies and to find. We m. Don't have an SDK for that. You should be doing, you know, stop, hold the presses, somebody go. It finds missing pieces. So when people get out of the loop and you know, just like a senior engineer would, when they show up to stand up in the morning, they're like, hey guys, just realized last night when I was, when I was going to bed, we forgot we didn't build this other thing and we're going to need it in a week. Right.

Speaker A: So. Yes. So in other words, the, the domain again, domain driven design, uh, becomes even more important so that you can isolate these document driven design or document driven coding to sort of smaller scopes.

Speaker B: Yep. And test driven if uh, you want to throw in another driven, um, you know, all of the fundamentals, the best practices of what, you know, the, you know, really the, the best of the best software engineers have been practicing and, and evangelizing for years, for 30 years are the things we should be following and not cutting corners. And that's what we should be promoting. Uh, is domain driven design, test driven development. You know, in my opinion, service, you know, service implement, you know, service oriented architectures, uh, whether that means microservice or whatever you want to call it at some point, you know, these are the patterns that I think are the, the hallmarks of uh, that we should be based on. And anything else has always been cutting corners and trying to say oh that's more complicated than I can afford right now. And if the cost of software is zero, you got no more excuses, man.

Speaker A: Yes, yes. And I, and I, I'm just really struck by, you know, when I watch a lot of these TikTok videos and uh, it's not coding has been made easy.

Speaker B: No.

Speaker A: It's just that one component of it has been made, has been collapsed in time and cost. But, but, but the other aspects of building and orchestrating these services and domains and having everything work together and it being repeatable and it being, not to mention, uh, uh, uh, an advantage in the marketplace and being able to respond quickly to, you know, to, to remain competitively advantaged, you know, it's, it's. That stuff is all still complicated. It's still hard, it's still hard problems to solve.

Speaker B: It is, but it's gonna, you know, these are problems that are gonna solve pretty quickly. I mean that's where as we've all seen the advancement of the tools we've been working with for Even what, maybe six months or I can tell you in the last eight months, month after month. Like, oh, it couldn't do that a month ago. Oh, geez. Couldn't do that like three months ago. Right. I mean, I have a project I worked on two months ago that, you know, it was just fighting with API versions. Well, this API version from three different vendors, you know, very, very odd why it wasn't working. The documentation wasn't great and you know, it was kind of big experimentation and look, you know, and you know, and the tooling was literally looking into the source code of these SDKs, trying to figure out what to do. And then I was like, okay, I gotta put this down for a weekend, let me come back to this. And uh, you know, did the same thing in, um, I was like, oh, it works now. Yeah, I mean, you know, and it was, it solved it, it was just better reasoning. Yeah.

Speaker A: I had a similar experience where I built a, uh, mobile app. This is not document driven, but I kind of saved the prompt and put um, the thing down for six months and kind of got reinspired to do the prompt, uh, to do the same app. And so I kind of started with the same prompt in. I think it was Opus 4.5 or something.

Speaker B: Oh yeah.

Speaker A: And the difference in what the model came up with was astounding. It was like watching, you know, uh, Wireframe MVP version and then watching it like a full production, gorgeous app, same prompt, upgraded models. It was, it was really amazing. What's happening?

Speaker B: Yeah, that's where we're going. Which is why it's important to ask your vendors. Right. I'll, uh, get back to my intro, which is like been the fundamental thing for me over the past few months. Has been, well, where. What are you doing about this? Because I expect the cost of software to go down. What's your business model like? You're a billion multibillion dollar company. Are you going to be a multibillion dollar company or are you really the bad bet? And this startup that gets it is the one that's going to have the right economics because they're not going to be saddled with what you're saddled with. And they have the right approach. Yeah, really interesting. You know, when you look out, well, two years from now, who's the right partner to be with. These are big changes. Right.

Speaker A: And when you talk about partners, are you talking about sort of software development partners or uh, infrastructure or data centers or what are you talking about?

Speaker B: Yeah, in this case I'm looking at like SaaS partners like uh, okay, SaaS. If I wanted to purchase your piece of software and it was going to be a critical piece of my infrastructure, like, like a, like a, like a, like a CRM. Right. Uh, or some other piece of software that's a chunky thing like that, I want to know, uh, you know, what's your development methodology? Because I believe so strongly that this is going to turn upside down the software, uh, you know, industry, that the economics of these companies is going to be put at risk. You know and a lot of us have heard the horror stories but you know, there will be truth in that. Even if it's not zeros and ones, there's going to be somewhere in the middle that could devastate some. You know, just having market share or being the 800 pound gorilla in a market, you know, might be the worst thing for you, but it's certainly not going to protect you because um, a startup is going to run, run circles around you.

Speaker A: Yeah.

Speaker B: And all it is is marketing at that point and it's a price point. Right. Yeah.

Speaker A: Uh,

Speaker B: I was just going to say that, you know, one of the questions I ask is, you know, tell me about your software practice, but also what's, what's your size of your team? I was like well how big will your team be with document if they understand document driven development, where's that going to be? And the right answer is usually, well, probably be about half. You know, I like that answer. With some of these partners that have hundreds of people, thousands of people. Yeah, we might not need them all.

Speaker A: Yeah. Let me uh, let me get to my second question because now I have a third. So um, what, what, what are you going to tell, what do, what would you recommend to a CTO that's listening to us? Uh, and is like um, I currently have a SaaS product and I have a team. Um, I'm really intrigued by this document driven thing. I think at the 0111 conference I heard some ctos are like taking their legacy software and building the twin with AI and just from, from scratch to get, to get to the playing field to be able to participate in document driven development. What would you recommend to a CTO listening to us who was like um, I thought AI adoption was more of my developers vibe coding. Uh, can you have like a 1, 2, 3 steps for them to kind of get into this process?

Speaker B: Well number one, you know, they've got to take on the, you know, the requirements, the product side of things and where is that structured in your business? Um, you've got to solve for that right away which is the product boundary, product specification. I think that needs to be the entry point into AI is the product set, product requirements, how is that getting authored and how is it getting, you know, the, the feedback loop there. Make sure you've got that covered and make sure it's, you know, whether it's, if it's not in your organization then how do you influence it and how do you get people on board with being part of this? Uh, because I think without that you're just, you're going to waste a lot of time. Um, next is I think you've got to invest in this process and you've got to model it, you've got to prototype it and then you've got to roll it out and enforce that it's used because you, everybody can't be doing their own thing. You know, we're not building Etienne Software Factory and Matt's software factory and John's software factory. We're building a software factory and, and I think the word factory indicates it all needs to work the same way and everybody's following the same process. You know and the, you know, the creativity is still there. It's in the problems we solve, it's not in the how we write software. Right,

Speaker A: Got it. And if you were advising a CEO right now or a founder or and let's just call it a CTO with an um, with a development team of zero. Um, roughly the same process.

Speaker B: Yeah, I mean I think you got to look broader across the business. We've been talking about software development. You know as a cto, many of us have other, other duties to help other departments and I think uh, AI across the organization has to be the other aspect because you can't just be improving the software side of the shop. But what are you doing about you know, ordering and marketing and all these other processes that are, that may not be seeing the same uh, advances. Right.

Speaker A: Yeah.

Speaker B: So are you investing in some AI frameworks that allow you to build agent or agentic frameworks that allow your uh, really, really skilled non programmers build agents with a little bit of help from the occasional software developer to maybe wire up an API here and there. But can they build great rag based agentic workflows? You know phone answering the phone, making phone calls or having conversations with people? That needs to be a skill. So I think going back to good fundamental business process mapping, looking at a business process and we have a handful of these that we're doing where it's not even with my software Team. It's like, okay, let's go map this business process. Let's put our, you know, business process, uh, hats on. And what, where's the human inserting themselves to make this process work? Oh well, why is the human inserting themselves to make this work? And why is, why is that rusty and you know, why does that need grease from a human all the time? Oh, they're making this decision and trying to, oh, well, okay, do we have the right inputs that an AI could make the same decision? And all of a sudden you've created an agentic, you know, work. And so you got to create those digital twins, uh, in each of these spaces, whether it's your, some ordering process or procurement process, uh, you know, that currently requires a person and the measurement of the people in your company needs to be. How many agents am I managing? You know, I shouldn't be doing work. I should be managing my agents that are doing my work for me. And if you have a, you know, so if you're judging your teams by how many agents they're managing, I think you're on the right path. But it needs to be a metric.

Speaker A: Such a gorgeous, uh, way to look at the role and the evolving role of the cto. Because in a way, uh, it was always there, but it was more like, can you fix the printer or route the phone lines or set up the call center? Now it's like, no, how are you helping the non programmers in your company, marketing, sales, ops, cx, whatever, to get to this place, as you mentioned, where they have X number of agents running that. And that's the responsibility, I would say, of a, the technical co founder slash cto. You can't sort of be like, hands off to that. And I am personally convicted a little bit about this. Like, you know, we're so caught up in the, in the technical realm of what's going on and this revolution that's happening that we forget that it's impacting every aspect of the business process. The company playbook is up for grabs. It's not just uh, how do we output software, it's the whole playbook is now in the sphere of the super intelligence.

Speaker B: Yeah. And I think that's how you can take a company that you know, might have been successful or doing well and, and turbocharge it either with the same amount of people doing 10 times the amount of, of, of hopefully uh, profit and, and sales or you know, scaled down and highly profitable with, with spending less resources. Right.

Speaker A: Matt, um, before I say goodbye, can I ask you a More existential question. Um, I mean, do you think we've heard this phrase SaaS companies are in trouble? We've heard even SAS is dead. Uh, you know, do you think we're just moving to the great big data bucket in the sky with a configurable real time LLM prompting that just gives anybody what they want whenever they need it? And really every person who uses tech becomes their own bespoke configurator of the thing that gives them the data that they want. Like I. E. A landscaper decides I don't need a SaaS product for my finances. I just tell the big thing in the sky what I need and off it goes.

Speaker B: Yeah, well, it's a great question and it, you know, I think the answer to the question is the cost of energy, right? And because obviously, uh, you know, just like software code, if, if I wrote the same thing in assembly language, it would be far less energy intensive than writing in a, in a, you know, you know, in Java or some other language which is, you know, interpreted and, and then the same thing as moving up the stack all the way to AI is, you know, worst case scenario, I'm burning more electricity to do the same thing. So the cost of electricity will give us that answer. Because the answer is yes, if we can afford the electricity, why would I want to have software sitting on the shelf that I have to maintain? That's stupid. But if the cost of electricity, you know, the economics will answer that question for us. So if we get to fusion or we get to data centers in space, that the, you know, the cost of electricity goes down, you know, this in the world of abundance to a fraction of what it is today, then absolutely no one writes code anymore. Right. Because things are real time interpreted into our answers. But I don't know that that cost will ever go to zero quite yet. That could be, uh, 20.

Speaker A: Uh, that's a fascinating, that's a fascinating view on it. I mean I have wandered so many times the mundane queer. I thought about cached answers where the same question being asked by 500,000 people. Surely there must be a cash layer in OpenAI or in.

Speaker B: You'd hope, right? Yeah, I don't know if there is,

Speaker A: if it's roughly the same question, uh, it's roughly been answered. Who's going to know if it just spits out the answer it gave to the other 499,000 people?

Speaker B: Well, that's, that's a beautiful way to save energy, right? Or to save or increase your profit margin depending on how you look at it.

Speaker A: Well, I think it's the latter. I don't think it's the fourth thing. Uh, Matt, any. Any final words on where people can go for learning more about this and, and their toe? And I mean, we talked about systems thinking.

Speaker B: I mean, I. We're certainly standing on the shoulders of lots of great people out there. You know, the works from Ryan Vice, you know, has been phenomenal. And his YouTube channel, you know, I think has been linked to that.

Speaker A: We'll definitely link to that.

Speaker B: Yeah, I think, uh, I think a lot of. A lot of credit goes to him. And I know when I was doing my work and I was like, oh, this feels like a document I should write. Then I saw he was doing. I was like, oh, Bear did my own. Thought I was going to take what he's been doing. So I felt very encouraged when I first saw it.