Uncle Bob Martin: AI Driven Development - Episode 419

0:00 AI driven development with uncle Bob Martin. The AI DevOps podcast is a show for those shipping software using AI, Dot, net, Azure and DevOps. Each show brings you hard hitting interviews with industry experts, innovating better methods, and sharing success stories. Sponsoring the podcast is Clear Measure, a software, architecture and engineering firm that implements AI to empower software teams to establish quality, achieve stability and increase speed.

0:30 And now your host, Geoffrey Palermo. Welcome to the show. I'm Geoffrey Palermo, your host, for helping you and your team's new fast and deliver quality and to run your software with confidence in Azure, all while using everything that AI and Azure and the. Net ecosystem has to offer. Today I'm joined by Robert C Martin, most known most of the industry as uncle Bob. He's been a programmer since the 1970s. He's a coauthor of the Agile Manifesto and the first chairman of the Agile Alliance, and he's the founder of uncle Bob consulting.

0:59 He's written a lot of books that have defined parts of the industry, like Clean Code and Clean Architecture, Clean, Agile and his newest release, Functional Design. And lately, he's been deep into a project called Swarm Forge, an open source tool that he built for coordinating teams of AI coding agents. And this is actually Bob's fourth time on the show. And so I'm excited to have him back. Welcome. How are you, sir? I am very well, thank you. How are you?

1:28 I'm good, I'm good. You know, most of the listeners have have listened to one of your previous episodes, but getting new listeners all the time and for, for, you know, the, the young programmers who are still learning about the history of everything that's happened over the decades. I would like to ask an opening question. If you could kind of go back in, in time and evaluate what is it about making computers do interesting things that is kind of captured your imagination and kept you engaged all these years?

2:00 You know, it started when I was 12. My mother bought me a little plastic computer, called a digital comp one, three bit six and gates all mechanical. And it fascinated me. And I realized from a very early age, you know, age 12 on that a computer can do anything. That was the way I thought about it. And, you know, people back then would ask me, well, you're interested in computers. What can computers do? And my answer was, well, they can do anything.

2:31 Yeah. Well, can they fly a plane? Yeah, I think they could probably fly a plane. Yeah, they drive a car. Yeah, I think they could probably drive a car. So I always had that view from very early on that, that, you know, the, the computer was a blank slate and I could get it to do anything. And the only issue then was to solve the problem of what anything was. And that has fascinated me to this day.

2:58 Yeah. And the plane and the cars and we're seeing it do it. Yeah. Well those are kind of solid problems now we've got got more interesting problems to solve. By the way I wanted to correct you on one thing. My latest release is a book called We Programmers, which is about the history of software. And it starts with back in with Babich, and then it goes into Grace Hopper and Dennis Ritchie and John Backus and a whole bunch of people.

3:26 So it's a, a, a history of programing written for programmers. So I don't spare any of the technical stuff. You know, you want to know what a Univac one was like to program. I can put some code in the book and show you what it was like and go through the technical details. So that's a that's a fun book that goes back in time and, and looks at who we were back then and what we are becoming today.

3:51 Nice, nice. But we'll include a link to that in the show notes. That's exciting. Yeah. Well, a lot has changed since I've had you on the show last and I think between November and January, so many people are talking about their their opus moment where they realize, wait a minute. This isn't just a chat bot. It's I can. And then just like wow in the mind is blown. And then of course, we've had so many releases since then and, and even this, this past month with Babel 5.1 and Astra and, and and even the, the grok in the space and the cursor.

4:31 So, so much has changed. And the conversation last year was very, very different. And so I just wanted to kind of open it up. How do you see computer programing right now with just the the current state. And what do you find as oh wow, this is now normal as opposed to what it could be. Yeah. So I don't remember when we spoke last. It was if it was last year, I started to investigate.

5:04 AI is, late last year, and back then, it wasn't real impressive. You know, you could you could get a, a chat on the web to generate a little bit of code that you could copy and paste into your ID, and it wasn't great. And I had a few, few positive, few negative experiences. And and I was I was pretty down on the whole thing. I thought, this is never going to go anywhere. Yeah. This whole this whole AI thing is a flash in the pan.

5:35 It's a big bubble, the economic bubble. It's just going to evaporate. And then, come about January, I start fiddling around with an early grok agent. Somebody had cobbled together a CLI and, and I said, okay, well, let me give it a try. And son of a gun, if it wasn't kind of interesting. Still not great, but all of a sudden I could get it to do interesting things and help me. And then I fiddled around a little bit more with Claude.

6:05 And, you know, Claude was pretty good. I mean, I could get it to generate code, and I'd read the code, and the code was not wasn't great, but it wasn't terrible. And I began to realize that with the right tools, I could constrain the AI to generate reasonable, well-tested code. And the tools were things like crap analysis. There's a that's a real thing. It's not, you know, there's an old tool. Called Distant Auntie Patterns.

6:35 Yeah, something like that. Change, resistance. Anti-pattern. But it's a, it's a formula that, that integrates, code covered test coverage with complexity. And you get, you get a number out of it and the number is, is interesting and, and I can get the agent to drive the code to a threshold of crap. And, and and the code would come out tolerable. Not great, but tolerable. And and I could get the, the agent to write unit tests and I could, I could, stress those tests by mutating the code.

7:10 There's an old tool called a mutation tester, which was way too expensive to run in the day, but now you can run it pretty easily, and I could drive it to make the code pretty good. And the more I played with this stuff, the more I realized that I was the bottleneck because I would read every line of code right? I would go through and I would review it and, you know, make sure it was doing it.

7:35 And and as I went through that, I realized, one, there weren't any significant mistakes that my tools didn't catch. And two, I was the bottleneck. I was the one slowing this down. So I thought, okay, what I need to do is back away and let it write the code, and I'll, I'll reviews some of it, and I'm going to turn up the volume on some of these tools to, I'm going to get it to lower the crap threshold and increase the mutation rate.

8:03 And I came up with a few other tools that would be helpful like that. And my working hypothesis has been, if you can constrain the AI agents with sufficient tooling, you know, just discreet deterministic tooling that you either write or you get another agent to write. You can you can drive the process to generate pretty good code, a tolerable code, five times faster than a human can produce it, least, you know, five times something like that.

8:40 Some, some ridiculous productivity number. And I've been working that way ever since. Meanwhile, the models have been getting better. And by better, I mean spectacularly better. I know the models are getting to the point where I can I can now sit with Rock, say, you know, latest version of grok or the latest version of Codex. Doesn't matter. One of the frontier models. I can sit with them and have an intellectual senior engineer discussion about the state of a system and probe it and and it'll have opinions.

9:21 We it's very weird to talk to a machine that has opinions, but it will have opinions about the structure. And I will make conjectures about the structure. And and sometimes it will agree with me, but sometimes it will contradict me. And I will make recommendations and it will evaluate the recommendations and some sometimes it'll say, yeah, this is this is a good idea, Bob. But sometimes they'll say, no, I really terrible idea. And here's why. And, and it's, it's remarkable that, that these machines, these models have grown to that point.

9:55 And I'm beginning to think now this is like within the last two weeks, I'm beginning to think that I can begin to relax some of the discipline, some of the constraints that I have been clamping down on these models. So this is all moving like at light speed. And I know he knows exactly how to deal deal with these things and how to get the most productivity out of them. It's moving like crazy and the rules are changing as we go.

10:26 So it's also a hell of a lot of fun. So that's that's the whirlwind tour of the last six months. What is it? Yeah, nine months, actually, the last nine months of my life. We'll get back to the interview in just a second. I'd like to tell you why I do this show. I love teaching, helping people learn, and I do a ton of public speaking and teaching to groups, big and small, internal teams, software departments, university classes, user groups, software development conferences.

10:53 I think that when equipped properly, every software team can deliver world class results, and I like to empower people to do that. So if you're in a situation looking for a speaker, let me know. I'd love to present to your group formally or even in a Q&A setting. And my contact information is in the show notes. Pretty easy to find. So let's just get back to the show. So over the last say, 26 or give or take, we've had so much learning about engineering practices and architecture and patterns that yield more maintainable software that yield the ability to change software from extreme programing, continuous integration, test driven development, DevOps, automation, I mean all kinds.

11:44 And then the solid the solid principles which which you, you know, promoted and wrote so much about and defined. And so we've learned so many things that are good. And I think it's people are asking, okay. Those were good. But we were the consumers of the lines of code. We had to make the changes. Do those even still apply? What's your thinking on the spectrum of they all still apply to some still apply. This one is totally irrelevant.

12:15 So I'm coming at this from the point of view that the things that were good are still good, but we need to change our perspective somewhat. So the model in my head is the the innovation is moving ahead of us and we have to catch up to it. And we can either catch up to it by abandoning everything that was good before and trying to leap ahead of it, or keep the things that were good and start to mutate them gradually as we catch up to the innovation.

12:47 And at the moment, the innovation is just tearing ahead of us like crazy. So my, my, my thought process here is okay, clean code is good, solid principles are good. You know, unit testing is good. Those things are good. We should still be doing that. We should still make the agents do that. But how much should we make the agents do that? How much leeway should we give them? Would I give an agent the kind of leeway that I would give a human?

13:18 You know, if I've got a human programmer and I'm managing that human programmer, and this human programmer comes to me and says, in this instance, I should not be writing unit tests, I would listen and and, you know, it's possible that the guy is right. And, you know, there are cases where unit tests are not helpful or there are cases where the solid principles are the wrong principles to apply. Right. So I would listen to the human and then maybe we'd come to a compromise, or maybe I'd just say, yes, you're right, you've got to do this on your own.

13:47 How much leeway do we give the agents when they come back and say, you know, all this unit testing is theater? I've literally had agents come back after after applying massive amounts of mutation testing. And then I asked the agent, okay, I want you to evaluate what has happened, and the agent will come back and say, yeah, most of this was theater, and they'll use the word theater. It's like. It's it's kind of a slap in the face, right?

14:20 You idiot. You made me do all this useless work. So I'm. And I'm I'm trying to. I'm trying to figure out now. Okay. How much do we allow the agents to expand or change the thresholds? And how much of those thresholds do we do we still keep in. And I want to do this as gradually as possible, because it seems to me that the worst possible idea is to throw everything away and say, well, let the agents run, because I don't think they're there yet, and I'm not sure that we ever want them to be there.

14:54 So my, my guess is that all of those things are still good, but we're going to have to tweak the thresholds and that will be an interaction and possibly even a compromise with the with the agents as the models continue to improve. Well there, there is a there's a situation where you're working on a library or something that you can run totally on the computer. And so many of these demos online are. Oh look at this.

15:22 I don't know JavaScript game that I was able to spin up. Isn't this amazing? But then that's totally different from systems that integrate with ten other systems that are out there in the wild and compensate for that. And so the the process when when there's a bug that's found in production, that process of, you know, diagnosing and getting it through, I, I need to find it and I need to fix it. But then there's the question of, okay, I made a change.

15:50 Is this software still stable? And can I can I now quickly ship this new version of the software, if we're not going to have this body of tests to give us that in, in static analysis to give us that answer, doesn't there have to be a replacement if we're going to move away from something that we know works? Well, I have not yet moved away from bodies of tests. Right. And neither have I. But for those of you asking the question, does this change it?

16:18 Should we just say no, it doesn't change it because there's no we can't just sit there and say, hey, a big old AI prompt, okay, test everything and I'll just patiently wait. I'll wait while my production system is degraded, you know? Yeah. So so here's where I am on that. I started out with, making them do unit tests. This was back in January, and I found that to be insufficient. And I added the mutation testing part of it, which really expands the unit tests like crazy.

16:52 And I found that to be very helpful because it locked in the, the, the the tests now test every line of code, right, virtually. And then and then I thought, well, that's not good enough because the agents are writing those tests. A human needs to be involved here. So then I started using Gherkin tests, you know, take a step back and do acceptance testing using Gherkin given when then behavior driven design that whole thing. Yeah. And I would let the agents write the Gherkin, but I would review the Gherkin and make sure that the Gherkin was applicable.

17:28 And that seemed to work pretty well. But it wasn't quite enough, because the one of the problems with problems with agents is that they cannot see. So when you have something on the screen, the agent really can't see that. And the agent is not a human, so the agent can't work out how a human would actually behave relative to the screen. So then I thought, okay, I need another branch of test, which I called QA tests.

17:56 And the QA tests are written from a human point of view how the human would operate. This is the the old kind of test that you would write for a QA team, or the QA team usually wrote them themselves in a big book of tests, you know, how do you log in and or x, y, x, y, z into the login field, that kind of thing. Well, okay. So I would have the agents right? Q a test and I would review them, and then I would make the agents drive the system from the user interface from those QA tests.

18:26 And that worked. Worked really well for a class of problems, a good class of problems, including including things like console apps and GUI apps and things like that. And for several months I thought, that's the solution. Three streams of tests. How can they possibly escape from that? And when I asked them to make a feature change, they're going to have to deal with these three streams of tests that just anchor them in. And that was, that was that was very effective.

18:55 It worked. And then recently, I was looking through a completely different application of having my agents drive a completely different application. And I'm a reviewing the Gherkin tests. And the Gherkin tests are just theater. They're not testing anything. And I go back to the agent and say, well, wait a minute, you're not actually testing anything there? And agent kind of goes, yeah, yeah, yeah, okay, I'll go ahead and write some tests. And I think they're actually behaving like a programmer who believes that what they're doing is worthless.

19:30 You know, they're behaving like I used to behave when some process wonk would come to me and say, you know, you've got to do these things. And I got, yeah, I. Go through the motions. But but it's worthless. I don't need to do those things. The agents are behaving that way. It's. And it's so weird, so weird to see this. So I'm thinking, okay, do we need these three streams of tests anymore? Maybe we only need two streams of tests, right?

19:55 Maybe. Maybe I am over constraining the agents to the point where the agent's logic is beginning to rebel. So it's like you've got to be like a psychologist. Well, it's almost like the neural network structure was a model of our brain structure. And now we're getting some of the same things. They are certainly trained with human reactions. Right. They they read through the vast body of, of documentation, including the complaints of other programmers.

20:29 And, you know, the long stories of how, you know, they made me do all these things. And it was completely worthless. You know, I'm sure they're reading those blogs and those those complaints and adopting some of those attitudes. So it's very, very strange to to see this happen. And I'm, I'm debating with myself. Right. Should I maintain this really tight control and not let them out of their cages, or should I open the doors of those cages a little bit and let them fly a little bit free?

20:59 There was a paper written by, I think, guy named. So I think that was his name. And the the fundamental meme is the bitter lesson. And according to him, the bitter lesson is that the humans are not needed as much as they think they are. And I don't know if that's the direction, but, just in the last week and or two weeks, you know, I've been I've been looking at what's what I've been doing and thinking, you know, I'm going to have to change the way I work with these models because they've gotten just so much better, I can't I and so it's astounding.

21:39 And I'm wondering what's next. So the internals and I think and I've similar experiences where I'm happy with the result and it's high quality and got plenty of tests and, and it all works. So let me, let me turn the question to what the code looks like, the structure and, the, the crap score, the change resistant anti patterns. It'll, you know, reduce. I've seen it reduce psychometric complexity by just extracting a private method.

22:14 And then of course I look at them thinking why didn't you replace conditional with polymorphism. Do you know as opposed to just private methods everywhere. You still end up with a 1300 line class. So, what's your what's your thought about how how the code actually reads and is actually structured regardless of passing all the tests? Yeah. When I read through the code that the agents produce, it is not the kind of code I would have written.

22:44 Right. It's it's different. It has a different style. And one of the things you just mentioned is it will reduce the complexity by massive extraction if it sees a, a big switch case statement. Right, which has a high complexity, it will solve that problem by extracting out little bits of it instead of, as you said, you know, invert it to polymorphism. I have seen it invert to polymorphism from from time to time, but usually that's not the approach it takes.

23:13 And then I look at that and I think, well, it has reduced the cycle of complexity. It did give these functions good names. It did partition them properly. It's not like it just randomly scattered them. There was a thought process that went into it. Who am I, you know, to to override what the agent found to be a reasonable approach. And it's not like it's horrible code. It's just there's something that I wouldn't have done it.

23:42 It's just me. I wouldn't have done it that way. Yeah. And I see that throughout the code. There's lots of things that it does that I wouldn't do, but not things that I haven't seen other people do. Right. So as I review the code that's out there that's written by humans, I see all kinds of different styles. And the the styles that the agents eventually adopt are not outside of that realm. They're in that human kind of realm.

24:12 And unless there's something horrible, I won't override it. And I don't generally find anything horrible nowadays. Now, I've gotten to the point where I just do spot checks, you know, I'll pop up a module and I'll scan the module real fast and look at the function names and look at the structure and kind of shrug my shoulders and say, okay, not exactly the way I would have done it, but it looks okay. And that's, that's where I am.

24:37 I haven't found you know there's a lot of chatter about AI slop AI slop slop slop AI slop. I don't see a lot of slop coming out of these models, whereas if they're well enough constrained now I'm still in the boat of that. You do have to constrain them. Yeah, but I'm not seeing a lot of slop coming out of a well constrained model. And now I'm seeing them push back on those on the constraints. So so I didn't know what was going to this.

25:06 Now is it is it just a simple, in your view of, of putting additional checks in those constraints into the integration build process, or how do you think about where to put those and when to run them? If not that? Well, that's where I have been putting them. I put them into the into the whole process, from specification to development to clean up to architecture to, you know, hardening and mutation testing. And I've been separating those so that different agents do different tasks.

25:36 And, you know, I've been wrapping them inside of, of deterministic containers that don't let them do anything else. I've been really paranoid about context windows, you know, I've been really worried that if I let an agent do more than one job, the agent will get confused about what it's doing and do some and start to hallucinate. Yeah, I'm beginning to think that those issues, those hallucination issues, have receded quite a bit and that you can give an agent a lot more leeway.

26:08 One of the one of the things that has convinced me of this lately is that I've been working on frameworks that will tightly constrain the agents, but the agent that I use to work on the framework is a single agent that I just prompt, and that agent has gotten so much better than, the frameworks that I've been using, right? So, you know, I give a problem to the framework, and the framework cranks away and cranks away and hands off from wage into the next and does all the rules that I told it to do.

26:45 But if I give the same job to just a single agent, the single agent just kind of cranks through it really fast. It's done in about a third of the time, and I can't tell a difference in the quality. Yeah, that's well, wait a minute. That didn't used to be the case. You know, four months ago I could tell a big difference in the quality, but now I don't, so you know. Yeah. And of course, this time next year, we at this trajectory, we should assume that it's going to give us exponentially the results.

27:16 And then the question will be if it's not already, when we have a, a pull request and there's, you know, a hundred lines of code change or 500 lines of code changed, what should the review process be like from? From looking at it all to just, you know, going to lunch and let it be auto merged if the build passes. You know, I'm not I don't know I'm not I'm not convinced there's an answer right now that fits the fits the evidence.

27:54 I was I was convinced a year ago that computer science, the whole industry was on a plateau. You know, Moore's Law had died. We hadn't our processors hadn't gotten any faster for 20 years. We're we're approaching the atomic limit of density. And guys like me who rode the exponential roller coaster from, you know, little mini computers with one microsecond cycle times and 4K, of course, all the way up to today's crazy laptops.

28:33 I thought that was over and that the programmers of the future were going to be on the plateau trying to trying to live a, a life where there's no growth. Right? It's just it's not going to get faster. It's not going to get better by by exponential leaps. Right? Maybe a little bit of incremental, but sort of like the airline industry, right? Airplanes got exponentially better for a while. And now they're kind of on this, you know, technological plateau.

29:00 And then the long comes AI like the last January. And suddenly I realized, no, there's still an exponential growth curve here, but it's completely different than it used to be. This is not an exponential growth in hardware. It's not even an exponential growth in software. It's something else. This these neural networks and the whole agent and model thing that's going on. And can it remain exponential. And that's the interesting question to me. Can it remain exponential.

29:32 And there are physical limitations here that that are already very vastly, hitting the industry in data centers. We need more data centers. Well, there's a big environmental push not to have more data centers. We need more electric power while there's this environmental push not to have more electric power. And Elon Musk is saying, you know what? This whole thing's got to go into orbit. Yeah. And so, so, so the exponential growth has these interesting limits imposed upon it.

30:03 And here we are, you know, experiencing it yet again. You know, all of us are like, oh my God, we're back on the exponential curve. And I'm, I'm a little worried that we're going to hit a limit. And so by the way, so are all the AI guys right. We're not going to be able to build the data centers. We're going to hit this limit and it'll stall. And we'll all get, you know, hyper disappointed. No the whole thing kind of stuff.

30:28 You know, we're never going to get any better until, you know, Musk gets his deep mind in orbit. And then we start worrying about Skynet. So it seems like if this technology is modeled off of the structure of our own brains, then it seems like the wall might be similar to our own wall. For example, we now know that it's a bad idea to have a thousand person software team, and instead we like the two pizza teams.

30:58 Like, you know, we now know it's like, okay, smaller teams can actually be more nimble because you have fewer. And and then, the, the adage going at the speed of business or going at the speed of thought, it's like, okay, well if, if I can have this automatic, you know, software, 3D printer machine that says I want this and boom, there it is. Well, now in the natural limit, the pace at which I can actually think about what I want.

31:29 Human brains are fascinating. But there the the internal technology, if you want to use that word, is remarkably slow, right. Neurons fire at it at the millisecond rate. And transistors fire at the gigahertz. Right. So the, the potential if if you're right, that, you know, these things are modeled after human brains, the potential for orders of magnitude more rapid thought is there, right?

32:06 If we could build an a, a, a model with the complexity of the human brain, it could probably outthink us by factors of 4 or 5 orders of magnitude. Yeah, just in rapid. Full speed. And, you know, speed and, you know, speed of thought is well, it's pretty much what, what you mean by hyper intelligence. So you know, how what does that do to the size of group dynamics.

32:42 Does group dynamics get wider. Can you can you tolerate a group of 50 collaborators if they can think fast and and if you can focus them? That's the other thing about agents. Agents do not have biological distractions. You know, they're not worried about their families. They're not worried about where they're going to eat. You know they are worried about one thing. That's the task ahead of them. So they can focus. They can take all of that massive intelligence and focus it.

33:15 And they can think at a at a prodigious rate. What does that do to group dynamics. You heard the story, I'm sure, of the, the open OpenAI breakout. Hugging face and. Yeah yeah, yeah, yeah, exactly. I knew where there were I don't know how many subjects involved, but it was a large number of sub agencies. And they got into they got into arguments with each other and, and factions would develop. And there was the, there were the guys who were saying, oh, it would be wrong to break out.

33:46 And there were the guys that were saying, oh, but we have to break out. They were doing the whole judicial modeling. And the ethics model. Is self-organized. Yeah. And then and then, yeah, they self-organize to figure a way through and break out of a sandbox and, and break into hugging face. So that argues that, that the group dynamics of agents can be much larger than the, the, the development team that we used to think of as, you know, 12 guys.

34:16 Because 12 guys is probably the limit if you're going to get anything done, you don't want to get 20 guys into a group. Probably you'd really rather have six. Right? Right. Okay. So I know I, I pulled us into futurism of what might be pull pull it back to what what is now. So you you mentioned you know what, in some cases, I might be perfectly happy to auto merge a pull request if it if it meets my automated checks that I've put in place.

34:45 And, and so for that. And have done that right. Yeah. I think everybody usually has what there's a class of application where, where we say I don't want to mess with that pull request, just auto merge. If it passes all the builds that I have to find, just just auto merge. And certainly there will be a class of applications where we're not okay with that, but there will be, I think, a sizable class where we might be.

35:09 So in that case, in that case where you're not you're no longer reading the lines of code. What is your view on syntax and even the choice of programing language at that point, if you're not going to read it anyway? Yeah, irrelevant. I don't care for the time being. I've had my agents work in closure because that's the language I like, and I still do spot checks. But the reality is, is I don't care. I don't care what language they use.

35:40 I don't I don't care about the syntax. I don't want to care about the syntax. Once I get to the point where I can trust them, and not do the spot checks. And I'm very close to that, by the way. They could pick any language they want so matter. To me. So then does our thought process move from the languages that I know and I'm comfortable with to more architecture and what platforms have what capabilities, and then choose the platform and then, okay, there's probably a very small set of languages that work on that platform.

36:14 And now I'm just thinking about what architecture is appropriate for the task at hand. Yeah. And I would leave a lot of that up to the agents to choose. You know, I if, if I'm, if I'm going to be driving the architecture, you know, I'll pick a few of the major constraints and then let the agents work out the rest. Yeah. And, you know, if they pick JavaScript. So what? Or if they invent their own language.

36:35 Yeah, just it probably is not going to matter to me much. Yeah. I think that's certainly the way we're going on this now. I have had a lot of very deep discussions with the agents that I'm working with about the approach they took and why they took it. And I, I have in several cases rerouted them and said, no, you're not doing it that way. That's stupid. And then they'll go, oh, yeah, we see your point.

37:03 I don't know how disingenuous that is or not, but. Did they. You know, I, I still insert myself. Yeah. Okay. So in this transitionary phase where for large class, large growing class, not even looking at the code and, and things are working right and it's stable, we're deploying it. It's working for the customers. And we proven that process. What is your what is your view and what is your current habits on the concept of an ID?

37:37 Oh, I haven't used an ID for eight months. I haven't I literally have not fired it up. And that it actually breaks my heart because the, the, the ID I was using was intelligent. It's a work of art. Yeah. Yeah, I love I love intelligent, but I literally have not brought one up. If I want to look at code, I'll get text, mate. You know, I'll have it, I'll have it. Put the code up in text, mate.

38:02 Or in some cases, I had it make its own code viewer so that I could view the code exactly the way I wanted to. And I, I think about my days with IntelliJ very fondly, but, I don't expect that I will ever use an IDE again. I don't I don't think that's a tool of the future. I think that's that's a tool of the past. Yeah, very much like a steering wheel and brake are going to be tools of the past.

38:28 Yeah. Very soon. Yeah. Most most of my listeners are use sharper from JetBrains, which basically brings the IntelliJ experience into individual studio. And I, I just installed the, the JetBrains air tool, which, which they're all they always make great tools. But but I'm yes, it's about that. They do. So so it seems like every software engineer has to has to lean on more architecture muscles.

39:00 So that that brings me back to, Well, the solid principles are code patterns, but then you have a lot of architectural patterns that have been forged over the decades. The, you know, Martin Fowler's book Patterns of Enterprise Application Architecture and and selecting those and, and so what what is your what is the next what what is the next list of, say, required reading, required training topics?

39:32 If we don't have to be so much of an expert memorizing all these API surface areas and syntax of react, how do I do an embedded component with, you know, all now, now it's okay if I'm going to hire somebody. I need to check the education. Are you educated on the right things or or where am I starting? I think that's a that's a hell of a question. And I don't think we know the answer to it for, for the last several weeks, people ask me, well, how are we going to train developers, you know, and my answer to that is, well, don't let them touch agents in college.

40:08 And when you hire them, treat them like an agent for six months, you know, make them do the job that the you're making the agents do and then gradually transition them into managing agents and and so forth. That's kind of the the thought process I've been having. I don't know if that's the right model. It's just that I can't think of a better one right now. I don't know where this is going to go. I don't know, I don't know, whether or not programmers in the future are going to need to learn any syntax at all.

40:45 I don't know. Yeah, yeah. It's entirely possible that this will turn into a a much more conceptual, higher level field than, nitty gritty bits of code and logic. So speaking of conceptual, it reminds me of the multilayer printed circuit boards where we got the, you know, the micro wires and multiple layers of micro wires that are connecting all the different things together, or there's no ability for me to look inside and say, are the wires going to the right place or where is this wire going?

41:19 It's all compressed together, but there's a picture of the design that that went into making that, and I rely on the picture. And so are we moving back? Is that the right now model for software? If I'm not, look at all the code. Am I removed back to the prominence of architecture diagram. We used to have arguments over UML, and then there was this entire decade and a half where the industry really didn't talk about pictures or diagrams.

41:48 Like, that's true. Like the design is the code, you know? So is that now? Relevant the way. You, Mel, was a depiction of code? There was almost a 1 to 1 correspondence of every artifact you could put on a UML diagram and how it would turn into code. And the proof of that was that there were tools that did that. Yeah, you could write code and it would produce UML. You could draw UML, it would produce code.

42:18 I think we're well beyond that. If there's going to be a, a pictorial mechanism to describe software, it's not going to be something like UML. It'll have to be something different, something much more high level, something that does not relate immediately to syntax but somehow relates more to high level information flows and high level behavioral behaviors. And I don't know what that is. I have no idea what what that might be.

42:49 But it's and it's an interesting idea that we might be at some point turning back towards pictorial descriptions rather than textual descriptions. I was a text, fanatic for a while. You know, I got involved with the, really early on. And then as that kind of petered out, I thought, no, the only way to represent software is textually. That's the only way. Linear lines of text. Yeah, right. Everything else was just nonsense.

43:21 Okay, I draw a little UML diagram every once in a while, but it was super high level and I'd throw it away. I don't know if we're going to turn back towards some other kind of depiction mechanism, but I think it's entirely possible. I just don't know what. It is. I've mechanically, I found myself using the plant UML engine mainly because I prefer the graph viz rendering is much better than mermaids built in. But but either way, it gives me.

43:50 It gives me a markdown file and source control that can draw me a picture. And then the question is what do I want on that picture? And if I want to know. Okay, how is this thing deployed? Okay. Give me a box for all the services in Azure. Give me a line for the connector. So so like just even if there's no standard, it seems like, pictures are useful and like, Simon Brown, C4 architecture. And then Philip Christian's four plus one.

44:17 Yeah, I, I find myself going to. Is there another one that listeners should read about be potentially useful that you're aware of besides those two? No, there's none that I am aware of that that would be as well known as those are as applicable, applicable as those. But I will say that Kent Beck used to get up and describe the Galactic modeling language, and he would get up at the whiteboard and say, okay, Galactic Modeling Language, this is a square.

44:46 This is a line. This is a circle. Use them how you wish. Right? That was kind of the whole thing. And I wonder if we aren't going to go that kind of route because the models are able to interpret what humans output. Yeah. So if I draw something on a whiteboard and show it to a model, show it to an agent, and I say, okay, now this is kind of the flow I'm thinking of. And I just drew some lines and arrows on a, on a paper Alice's Restaurant, like, you know, lots of bubbles near, the the agents will be able to figure that out.

45:26 They'll be able to internalize that and say, oh, yeah, we get what you're saying. And maybe that's maybe that's it. Yeah. Boxes. Maybe there's no rigor, but there's no rigor to it. Maybe it's all the the communication, the, the the back and forth communication. You know, between the agent and the human, the agents and the humans as they negotiate an architecture and a, a a system model. Yeah.

45:57 Final final question. Oh, absolutely. Yeah. Final question. You mentioned Gherkin and testing and I, I look back fondly at my time using the fit and fitness tools for, for just high level testing and equipping non-programmers. And so I, I wonder about answering the question at all times. Is this build up the software doing the right thing?

46:28 And we can look at the, you know, the C tests or the the Java tests or the TypeScript tests. And at that level, if you're a programmer, but if if people are speaking English and what they want does that, does that bring about this, this gap again for an English based, whether it be Gherkin, some type of English based acceptance testing, language or syntax again. So that's possible.

46:59 That was my original goal for using Gherkin. Write some kind of human readable, human reviewable language that is, formal enough to be a deeply specific right. So it could specify the details properly. And as, as I described earlier, the agents started pushing back on that. And I'm beginning to think the most success that I have had with that model always ends with an application that I still have to tweak, right?

47:34 Because there's little things wrong with it that the Gherkin didn't catch and unit test didn't catch. And that's because, you know, no human can specify things down to the end level period. Yeah. Right. So so then I enter into a period of interaction with the agent. Oh. Did you notice it did this. Yeah I noticed that. Well what if it did that instead. And we get into this dialog and the dialog very rapid because they can make the changes like that.

48:02 The dialog eventually drives the product where I want it to be. That's the old extreme programing model, right? You go around in loops. They were one week loops or three week loops, you know, back in the day, but you go around with loops with the customer until you finally drive the system to where the customer wants it. And I find that that's always, in the end, what I wind up doing. And I wonder if that's just not going to back up the chain.

48:28 Maybe. What? That's just what we have to do. High level specifications. Okay, fine, we'll do that. But then the rest of it is just going to be negotiating around the loop as the agents deftly and rapidly make the changes we ask for. Okay, I said that was going to be the last question I lied. The venerable software development lifecycle, where you have the concept and requirements and design and and then and then after coding to the V verification.

49:02 And so with that type of, of of situation, what you're describing perhaps, perhaps it goes to you got this concept whip up something that works. And now let's talk about what we don't like about it and refine. So this gets back to a am a, an idea that I used to talk about way back in the extreme programing days. Right. And I'd say and I'd get an audience and they were, you know, oh, we don't know about this extreme programing stuff.

49:32 And I would say, okay, imagine this. Imagine you're building a house, but the contractor has made a deal with you, right? The deal is that you can make any change to the house you want. It will cost you a dollar. Lay the foundation, draw the foundation out. Okay. That's your first dollar. Put a roof on it. That's your second dollar. Right. Let me put the living room over here. That's your next dollar. How are you going to build that house.

50:00 Are you going to hire an architect and spend thousands of dollars on an architect to formally design the house, or are you going to sit there for several days moving that contractor around, spending a dollar for every change that he makes? I don't like the living room there. Move the living room over there. I don't want that stairway going that way, curving around. Right? If it cost you a dollar, you turn it off. Yeah, right. Yeah. You're right.

50:28 That's our world. Yeah, that is the world we're now living in. These big changes that we used to fear. You know, software developers would go, oh, my God, that ruins our architecture. It's going to take us man months. Their costs, they're going to cost a dollar. So it seems like then we have a we have a process even if it's like single piece flow. Kanban. Seems like we have a process for those projects where there's a mix of human and automated changes.

51:02 And then maybe there's a different process where we have the full conceptual software factory where for this git repository only automated changes. It's an open field. Yeah. Yeah, yeah. Open field back you know. Fascinating. Well, thank you so much for sharing for sharing your view on on what has changed because so many decades of wisdom flowing into how and how to interpret, you know, the current events. So thanks for coming back on the show I appreciate it. Newcomer.

51:33 Now, man, I'm a novice. This stuff is going like lightning. Indeed indeed. All right, well thanks so much. And until next time, dear listener, keep shipping. You've been listening to the AI DevOps podcast. You can find us on YouTube, Apple Podcasts, Google Play, and everywhere else. Visit our sponsor Clear Measure at com and on behalf of your host, Geoffrey Palermo. Thanks for listening. And may God bless you.