Kent Beck: Software Engineering in the Age of AI | Prodacity 2026

Kent Beck: Software Engineering in the Age of AI | Prodacity 2026 - https://www.youtube.com/watch?v=F8fBgDCf2Y4

I've spent my career in commercial software development. I've had occasional encounters with the military or government world. Remember working on a project at Lockheed way back in the day? Does Lockheed still exist? Yes. Okay, good. Glad I didn't sink them. So some of the things that I was hearing this morning were outside of my usual sphere of concerns. But much of what I heard was spot on and the constraints are very similar. And I also solved a long term puzzle. The way my brain works is I'll take a problem and I'll stick it in the back and I'll churn on that. And sometimes the answer comes within minutes, sometimes it's months, sometimes it's years or even decades. And so at the end I'm going to reveal a refinement of an idea that I've been working on for 10 or 15 years that I think I cracked this morning as a result of listening to General Whiting. But I'm just going to leave that out there to make sure that you pay attention to the whole thing. Is that okay? By the way, if anybody has questions as we go along, I'd rather have you raise your hand and ask right away than sit there and wonder about it. Asking questions is a form of leadership. I remember being a freshman in college and we had a, we had an experimental discrete math class and Professor Ken Ross, I still remember him at the whiteboard was not being terribly clear. And one day he was a little late coming in, this is probably three weeks in and the whole class was there and we're sitting there and just kind of the glazed eyes, everybody looking forward, trying not to make contact, eye contact with anybody else. And finally somebody said, does anybody know what's going on? And everybody said, no, no, we're completely, completely close about what's going on. And it was such a moment of. And then Ken Ross came in and we just blasted him just like nobody knows what's going on. Stop whatever you were going to lecture about, please don't explain what was going. And it was great for everybody. And he ended up writing a very popular discrete math textbook. And I would like to say that our class really had a lot of responsibility for that happening. So if you have a question, comment, please raise your hand. We have mic runners ready to go. Go around. So my name is Kent Beck. I've been coached by Gene Kim, who many of you will know that I ought to introduce myself in the following kind of way. I don't like it, but Gene says so. So I was instrumental in bringing patterns and that Pattern style of thinking to software development. Programmer testing. Programmer testing frameworks like Junit was my original invention. I refined it with Eric Gamma and it was then copied a million different ways. Test driven development, which is an age old idea. I recently found a book from 1957 called Something like digital programming where the distinction between binary computers and decimal computers had not been worked out yet. Which I thought was like, oh, I guess that must have been a question at some point. But late in that book it talks about how do you write programs? And it talks about you go to the users and you ask them for some check items, that is give me some input output pairs from your domain and we'll make sure that the computer program matches those input output items. And I thought that's test driven development right there. So I can't claim to have invented tdd, but I maybe rediscovered it or something like that and then refined it. Extreme programming is my baby. I was one of the signatories of the Agile Manifesto. I wasn't just one of. I was the first signatory of the Agile Manifesto alphabetically. And then since then I've spent a lot of time coaching high potential engineers. I'm deep in the augmented development world. I'm working with one of the frontier labs, which is its own set of interesting constraints. I mean it's one of the first. I work at the intersection of technology and sociology and this is one of the first times when it's not a press play kind of problem on how a team that's building a frontier model or building a sequence of frontier models, how they should actually work. I'm having to really think, I'm having to learn a lot, which I appreciate. So that's my background. I'm coming here to talk to you about craft and the role of craft in an augmented development world. I always say augmented development because to me this is still a human process, at least so far. I still have a lot to add to the decisions that the GENIE is making. I call it the GENIE because it grants your wishes, but it ends up not being what you really wanted. Just as a reminder that that's the essential relationship here, I'm going to make some requests, I'm going to get something back, it's going to seem really cool and then at the end of it I'm going to be a little bit disappointed. So that's how we work together. I wanted to say I'm not going to bury the lead. The one thing I would like you to take away from is there's a tendency now when people talk about augmented development, where they make a statement like, now that the genie, they don't usually call it the genie because they're not going to be that cynical now that the genie is better at coding than humans. And I'm calling balderdash on that statement, that attitude that just because GENIE can create syntactically correct programs doesn't mean that they're better than a programmer or even that they actually work. And one of the things I always loved as an autistic person, that I loved about programming is this binary red, green. Oh, that's so relaxing to be able to say, this program doesn't work. I fix a bug and now it's fixed. And that's the programs that we get out of augmented development oftentimes just don't work. They're plausible. Jeanne's really good at plausible. But actually working. No. And we've all read these breathless accounts of what? Well, we spent $10,000 in tokens and we got a working C compiler out of it. How amazing is that? And then you start digging and you realize that working C compiler, hello world, doesn't actually work. Or there were a few remaining bugs, and every time one of those bugs got fixed, three more bugs were introduced. If you dig a little bit deeper, it's close to a C compiler. It's C compiler ish, but it doesn't actually efficiently compile C programs that then run, which seems to my old fashioned way of thinking to be the criteria we ought to be using. So that idea that somehow it we've just replaced programmers because computers can do what programmers used to do is simply wrong. Now maybe someday it will be less wrong, but today it's simply not true. And that means your relationship as a programmer or as a manager of programmers or as a purchaser of software, if there's a heavy presence of the GENIE in the production of some software, you have to take a cynical view, you have to take an adversarial view and say, okay, you say this works, you made yourself happy. But did you make me happy? How real is that? How hard do I have to push? So the kinds of things that you do as a programmer to make sure that a program works by construction or that a certain class of bugs is simply not possible. Genie doesn't have those tricks. So things that you used to be able to infer, trustworthiness that you used to be able to infer, you simply just can't assume that that's true anymore. Which now I've been through a number of Cycles. One of the advantages of losing all this hair was I've been through enough cycles where people said, oh goody, we don't need programmers anymore. And as programmers, it behooves us to think about why they keep trying to get rid of us. Kind of at a strategic level. But also it's never been true, you know, because. Computer programmers are highly technical artifacts and we'd love for, say, business people to just be able to speak in a plain language to the computer so that we don't need programmers anymore. The business people can just state their requirements in plain language and the computer will just compute it. And that, of course, is the high level description of cobol. But that cycle has been going over and over again. And here we are at the next round of that cycle, which is why I'm not worried about having a job. That and because much of my job is coaching. It turns out that young engineers make exactly the same young engineer mistakes that young engineers have been making since the time of the Romans. And they can use someone who comes along and says, yeah, yes, you're kind of weird, but you're definitely not alone. And you know what? I've seen worse. And that's a very soothing thing for a young, nearly overwhelmed programmer to hear. So that word craft that's in the title of my talk is an interesting word. And I have a mixed relationship with that word craft. I've written at least three books which can all be described as craft oriented. Okay, you're a programmer. What is it that, like, how can you put your whole self into the act of programming? And all three of those books are completely obsolete and should be thrown away at this point, which is an odd thing to do. Feel it towards the end of a career. But there you have it. The kinds of activities that we used to use to express craft. Careful naming, careful decomposition of logic into little pieces that all compose together to create some larger effect. Indentation, use of white space, optimizing program structure for human understanding. Those aren't decisions. Those used to be decisions that had a lot of leverage. Now they tend to have a lot of leverage over time. So five years later, someone would come across some code and say, oh, thank goodness I can read and understand this, and they would feel good about it. Those decisions don't have the same leverage that they used to have. And that's just true. It doesn't mean that humans don't need to understand code. I think there's still a lot of leverage if I have to choose a system where the humans can read it and a system where the humans can't. I'd much rather have a system where the humans can read and understand about it. But I also have to recognize that that reading and understanding is going to happen in the context of I've got this genie, it can explain stuff to me if it's not lying to me, which is always an option. But if it's not lying to me, I'm going to be able to understand this more quickly. But that, that detail oriented which feels so good. Oh my good, you know, I'm like, how does this go together? And then I realize, oh, I inline these things and I extract those things and I rename these. Ah. Then it all becomes clear. That moment felt really good to me and there's just not payoff for that particular moment. Now, CRAFT was, let me say. From my perspective, that word craft was hijacked by a group of people who wanted, again this from my perspective, wanted to go in their little cave and they wanted to be programmers and it was just them and the computer and they would craft themselves until they were ready to be finished. This is the flip side of my relationship with that word craft. I really hated that. Oh no, it's not done yet because I haven't finished with my craft. Well, sometimes if the cost of delay is high, an ugly program that gives you feedback is exactly the right thing to do. Other times if the cost of delay is low, this software is going to live for the next 20 years, then absolutely. That Swiss watchmaker get everything exactly right is going to pay off over time. But the idea that as a programmer time doesn't matter compared to your experience of programming, I just disagree with that strongly. And I didn't like what that side of programming did with that word craft. But we have to recognize now that CRAFT is going to mean something different. It's still a valid concern, it's still a valid discipline, but it's going to show up very differently. And I'll talk as I go along more about how I see that change happening. So let me draw a little bit for you all. I've noticed that if you look at my GitHub, so I've been programming augmented development like back into programming hardcore every day for maybe the last 18 months. I saw Gene Kim and Steve Yeage give a demo and they were so excited. I thought I have to get back into this. And I gotta say, I absolutely love programming with the genie. I've always had bigger ambitions than my technical skill could achieve and now I can try ridiculously ambitious projects and make a lot of progress. I didn't say accomplish them because on my GitHub you'll see that there's a name of a project and then Project two, Project three, Project four. Because I kept hitting the wall, I kept getting to that place where I couldn't fix one bug without breaking something else. And then new project, new project two, new project three. Now it somehow never occurs to me to put a one by that new project. I just assume this time it'll be different. This time I'll be able to actually get this thing completed. But no, I have to release over and over and over again. So here's how I've come to think about this. If we look at progress. It took me a while to get to this visualization, by the way. This is. This is one of those ideas that went in the back of my head and I had to work on for a while. If we look at progress on features, what we see is it goes fast at first and then it goes slower and slower and slower and slower. And that's the like what goes into that dynamic, what goes on the other axis? And sometimes I call it optionality, sometimes I call it futures. So it's easy to see futures versus Features. And then I knocked out one of my front teeth and then I had to call it Futures versus Features and it was a really terrible choice. But then I got the tooth replaced, so now I'm good. The vicissitudes of age so here's what happens. We always start with a wide variety of things that we could do but we have no features. And then we implement something and we burn some of our futures in order to realize that feature. At the very least we're going to have to maintain backwards compatibility if we add the next feature, which will constrain what we can do a little bit. Or we'll decide we don't like that first feature and we'll have to take it out and then again constrains a little bit what we do next. But what happens next is we burn some more futures in order to get our next feature, and then we burn some more and then eventually we get down to the point where we have no options for change at all because everything is such a big mess. And then that's when I start Project two or Project three or Project four. So now we've made a lot of progress in software development. It used to take us 100 people 10 years to get to this absolute zero state where we can't make any changes without breaking something else. And now with AI, I can do this in the privacy of my own office. One person, one week, and I can make a complete mess. So that's a big productivity enhancer to get to a project that can't be changed with far less in the way of investment. But what's the alternative? What else can we do? So that's what I want to create that first feature. It's always going to burn some futures. Nothing you can do about that. But now we have a moment. When I was in music school, there was a story about Pablo Casals, who was one of the greatest cellists of the 20th century. And the cello is a very physical instrument. It's big, it moves a lot of air, takes a lot of feel, physical strength to play the cello. And Casals had a piece that was a long run of 16th notes, on and on and on and on. And someone asked Casals, don't you get tired playing all those 16th notes? And he said, no, I rest between the notes. And for me, as a young classical guitar major trying desperately to play fast enough, the idea that there was a between the notes was just mind boggling. Now it turns out Casal's never said this. The story's made up, but it's such a good story that I have to tell it. But here we have a moment. We've completed a feature. The genie said, okay, boss, you know, the finger guns, okay, boss, I finished that feature. Do you want me to implement the next thing? And we all have the opportunity to take a breath and say, huh, maybe I'm not ready. And that gives us a chance to add back some of the futures and maybe even a little bit more before we implement the next feature. And then again with the finger guns, and then again, we can say, no, I'm going to refactor what's there. I'm going to eliminate some duplication, I'm going to optimize some of this for readability. I'm going to throw away what I just did and implement it again in a different way, see if that turns out differently. There's a lot of things that you can do in that moment between features that are going to add value to the project. Because the economic value of a project is the sum of the features that it currently has and the futures, all the options that for what it could do next, I can add value by adding to the futures. And so this is the trajectory that I want to create, to go back and forth between adding features and improving the futures of the project. Now, the challenge with this Is adding features is visible, legible in that seeing like a state sense. Everybody can see the progress. They want the features, the users want the features. Now they have it. Woo. Thank you very much. Futures is harder to account for. You may have added to the theoretical value of the software, but the fact that you could make a change that you may or may not want to make seems like gilding the lily. Why didn't you just implement the next feature? Well, because if I just implement the next feature, I'm going to go down to zero and everybody hates that. So this is how I think about the challenge of augmented, not just augmented development. This is the challenge of software development is balancing the investment between the next set of features and the futures which determine what it is that you can implement next. With the GENIE involved, the whole thing ramps up. The timelines are shorter, the opportunity cost, you know, if you just say, yeah, implement the next feature, you're going to get it really fast. Something like it, maybe that works mostly. And if instead you go and future proof your software, you remove the sources of error, it's harder to account for that. It's not written in any spec that says, and this will be easier to change in the future. Nobody seems to ask for that. They're all looking for that project that gets finished. Whereas for me, finished, like I don't want to change, this software is a failure. I want to write software that inspires any number of new ideas to me, that's more valuable, but it's harder to write a spec for that. And I'll talk, I'll get cynical about spec driven development before this is over, I promise. So this is the trajectory I'm trying to create. If you step back from this as a trajectory far enough, you don't notice the back and forth. It just looks like the software is getting more features and more options at the same time. If you try to, as an implementer, try and actually implement more features and more options at the same time, it turns out that's a bigger problem than fits even into the combined brain of the GENIE and the human. The more effective strategy is to go back and forth between the two. We're going to make some progress, then we're going to consolidate, we're going to make some progress and we're going to consolidate. You can't wipe the knife while you're cutting. You have to cut and wipe the knife and cut and wipe the knife, but you have to wipe the knife. You know, if you went into a professional kitchen and you said, you know, you're wiping the knife and it's pretty much clean already. Why don't you just stop wiping the knife? Then the chef is going to offer to use the knife on you and then wipe it. So, you know, the commercial kitchen has developed these strategies that work out well. And in software development, I mean, one of the things about extreme programming that I thought was the biggest compliment I could have gotten was this is what really good teams look like in the wild. This isn't theoretical. This is an observation of what teams really look like. And that was my goal in extreme programming. If I said anything creative or I said anything innovative, it was definitely a mistake. And I wanted to take it out. I wanted proven techniques. But now we have this much more powerful tool that can go much faster, that can create opportunities for feedback faster than we're prepared to gather that feedback or analyze that feedback. And the temptation is there to just let it go full speed ahead. And for me, this is dangerous anytime I've tried fully agentic. The dark factory. The dark software factory. And the dark doesn't. It's not meant like dark, like evil. I was kind of hopeful. The dark software factory, like, oh, I get to finally write evil software. And no, it turns out that's not what they mean at all. It's just there's no human involved, there's no feedback. And that always goes off the rails. Always. And here's the problem. It's amazing. While it's going off the rails, the crash is so entertaining, right? You're like, wow, how did you get this much? How did you do this much? And it's still complete crap, but there it is. So the challenge for me and my personal practice for the people that I coach, for the teams that I coach, is how do you create this space between features to go back and enhance the futures of the work that you're doing and to do that in this environment where it's so tempting to just implement the next feature. The next feature. The next feature feature. So the comment is by pacing yourself, you're giving yourself the chance to form understanding. And that's exactly right. The best software that I've ever, that I've worked on is software where I tried to maximize learning, which threw off software is a side effect as opposed to I'm trying to produce software and sometimes accidentally I learn something because I messed up your habits. If you're trying to maximize learning, your habits look completely different, the pace looks completely different. You're not afraid to throw stuff away when it gets kind of messy. This is One of my early experiences working with Ward Cunningham, who was my mentor when I came straight out of school, the biggest piece of luck I ever had in my life. Ward invented the wiki and we had developed some code. It did what we wanted to, but it was late in the day, we felt a little bit like, I don't know. And he just reached over and turned off the computer and I about jumped out of my skin. Like we implemented this stuff and it was kind of working and we only felt a little bit bad about it. How could you destroy that? So I kind of huffed my way home and came in the next morning and we re implemented everything that we had done the entire previous afternoon in about 15 minutes. And it was absolutely clear and we understood it. And that was the light bulb moment for me. This is a learning process that throws off software as a side effect. Whereas the temptation in the Dark factory, you don't learn anything except at the end you learn how unreliable the genie really is. But we already knew that. So why is it that I need to keep learning that I don't know? So that's what I'm trying to create. This trajectory where futures and features go together in a little bit back and forth. Something I've heard echoes of earlier in the day is a distinction that I want to make that. It's coming back. This is again one of these advantages, disadvantages of experiences. You see stuff and you go like this again. Okay? And this is the distinction between one shot development and iterative. Demel. Sorry about that. Iterative development. Sometimes my mouth gets a little ahead of my brain, or maybe it's the other way around, but here we are. There is such a temptation in spec driven development to go down the path of I'm going to write a spec and the genie is going to produce the software and if the spec is good enough, the software is going to be good enough. And there's a word for that that's exactly waterfall development. Where it didn't work, it never worked. If you go back to the original Winston Royce paper about the waterfall, there's a diagram with the waterfall and it says right there on that page, of course this doesn't work because decisions you make later are going to inform decisions that you made earlier. So the next page has waterfall going down and feedback coming up. But it's the power of an image is everybody looked at that waterfall and thought, wouldn't that be awesome? If I could just write a spec that was good enough and then the software would be finished and that's what stuck? That's how careful you have to be when you're explaining things. What about formal methods? Great question. I have enjoyed. So when I was in graduate school, I was in music school and computer science school every other year and I just ended on the wrong year. So I'm on stage here during the day instead of in the evening. Feels good to be in a music venue though. I was a TA for the proof of program Correctness class. So I have those patterns baked into my head and I use them informally all the time to do some data flow analysis or control flow analysis and define some invariance and so on. But I hadn't done formal proofs until maybe a year ago and a friend introduced me to Lean and Lean with the genie and I tried it out. The challenge I have with formal methods is twofold. One, it still feels like a one shot process. I have some formal specification and I want to prove some properties of it. And I do a whole bunch of work and I prove the properties. What happens if I change one element? Oh, I got to wind back. And even if it's faster because I have the GENIE helping, it's still a drag on my ability to change. And I want to encourage, I want to build systems that encourage change instead of discourage change. So that's my first one. And the second one is even with formal methods, there's still a gap between this mathematical model and implementation. Okay, I can have some formal specification, I can derive some properties, I can prove those properties. Properties hold for this formal specification. And now I want to turn that into a running program. There's still a gap in that derivation of the program from the formal specification. And I don't know how to bridge that. Okay, I want to turn that into C code, I want to turn that into C or ARM 64. You can program an assembly language now. It's so cool. It's so. I mean, that's where I started, my dad and I soldering together a 6800 machine. You can do that now. You can just say, well, okay, implement this data structure and do it in x86 assembly. Chung chunga chung ding. I will come some. It's amazing. Figuring out all the different ways I can torture the genie is just so entertaining. Okay, let me make this even harder and more awkward. So the second part of the to finish that thought about formal methods, the second part is that bridge that gap between here's a specification and here's an implementation that matches that specification. Specification, as far as I can tell, is something that hasn't been fully bridged. Now the good news is you can get to low defect densities with a combination of examples, automated tests, carefully chosen and foolproofing of the design. If you work at those two things pretty hard, you can get software that is trustworthy. Unfortunately, the GENIE wants to make shortcuts, it doesn't want to foolproof the design and it will do things that subvert the intentions of test cases. You have to watch for returning constants, you have to watch for just all of the nasty things that you can imagine that a 14 year old programmer would do just to say, yeah, it works, boss. So it is possible to write though trustworthy program with the genie. Ah, so I got into that one shot versus iterative. So are you making some software that has value deployed in the world that you then change and now it has more value in the world that you then change and then how now it has more value in the world? That's one paradigm versus the I'm going to write a spec and the spec's going to be so good that the software is going to be good. Oh, it's not. I'm going to write more of a spec and a bigger spec and a until the spec is big enough and complicated enough that the software is correct. And there's times to do both. If I'm writing a little app, one shot is fine. If I'm writing as I am a virtual machine for a graph database with an embedded programming language, that's not good enough. It's going to have to be something. Where I have some software, it has some value, I see a way to improve it, and so on. The people who are getting really excited about spec driven development just reminds me, it doesn't sound like they've ever had a billion users because the kinds of things that you have to do, if you have a really large installed base and a lot of traffic to change software like one shot and then, oh no, never mind, let me one shot it again. That's just never going to work because you've got. You have continuity problems, you have data migration problems. You're better off assuming that you're going to be iterative all along the way. Now I said that I was going to show you an update of a diagram and I'm excited because anytime I get one of these, I have a puzzle and I can finally solve it. Then I'm a very happy person. So. Us programmers, I'm a programmer mostly and so that's the way that I speak. If we want to look at what we do. There's this sequence where as a programmer, you put in a certain amount of effort and then you have, say, a new feature that you can deliver to your customers, and that's output. And then the customers use that feature and their behavior changes. After all, if we produce software and nobody's behavior changes in any kind of way, we didn't need to produce the software. And that's outcome. And one of the big changes in my life was moving to the web and being able to observe what customers actually do with the software. Before then, you had software on a cd, you'd send it out. Are people using my new features? I don't know. There was no way of knowing. So just being able to observe outcomes was a big step forward. How much of what we did wasted effort because nobody used the feature at all? But here's what I learned today is outcome for the customers. The people using the software leads to, and I used to use the word impact, but I love this word mission leads to changes in our accomplishment of the mission. And the mission is shared between the people making the program and the people using the program. And here's where we get to the tyranny of metrics. People will be amazed. The genie produced 200,000 lines of code. That's a measure of effort. It has nothing to do with the mission. And whether the mission is making enough money for my next yacht or I don't have a yacht. Just using that as an illustrative example or making the country safer. The fact that we've generated 200,000 lines of code is irrelevant. And 200,000 lines is not 10 times as much as 20,000 lines from the mission perspective. It's just irrelevant. And yet it's the easiest thing to measure. And so we look for our keys under the lamppost, and the GENIE is able to produce so much output with so little effort, it's easy to see that as productivity, because after all, productivity, the very definition of productivity, is the ratio of output to input. And whether it's lines of code, which we've known was balderdash for a very, very long time, and somehow it's back PR count. Anything which is a measure of effort or a measure of output is, per definition, not a measure of mission. The problem with measuring mission is it's hard to do. Oftentimes value from the mission is bursty. Like you don't see it until a crisis happens, and then you realize that you're ready for the crisis. So it's hard to measure from the level of the mission, but that's what actually matters. So the fact that the genie can give you a lot of effort, and now I can just spin up 10 genies, and now I have 10 times as much effort. Yeah, but it doesn't matter. Doesn't mean that we're making progress on what really matters to people. And the earlier in this cycle you measure, the more likely you are to see Goodhart's Law. You know, when a measure becomes a goal, it ceases to be a measure. I think Goodhart was an optimist. It's not just that the measure ceases to be a measure, it's that people will twist the entire system out of shape. They'll make it worse in order to get better measures. So it's not that you just, you lose visibility by turning measures into goals. It's, you know, you lose progress on the mission by doing that. The later in this cycle you go, the harder it is to attribute, hey, the mission is now 7% better, and I own 0.075% of that. You know, it's hard to say what you did versus what he did versus what she did, like, which of us deserves the credit. And this is the challenge we had from earlier today. How do you incentivize progress on the mission? And I'll close with just a few words about this. I've had the great good fortune of having a few of my ideas spread out in the world of software development. And what I know about that process is you have to find an expression of what you're trying to accomplish of the mission. You have to find an expression of the mission that speaks to people's heads and their hearts. And then you have to repeat it and repeat it and repeat it. And that repetition that. Not getting bored with telling the story of how software development can be over and over again is part of the skill of leadership. To tell that same story for the thousandth time as if it's brand new. And then someday somebody will come to you and say to you, I have this great idea. And they'll tell you your idea without realizing it was you, without giving you any credit whatsoever. And that's the moment that you've succeeded as a leader. And I think we have these tools that have the capability of transforming the value we create in the world. And that's the challenges for finding those missions into which the tools fit for human purposes. And I'm looking forward to finding out what comes out next, to doing my little bit to shape what that is and to seeing what it is that you do that also shapes the future. Thank you so much for your time and attention, Ra.