Kent Beck

Thank you. Thank you, Gene.

And I do have to personally thank Gene for reviving my programming career in April. I had no idea. I was invited to a workshop and I had no idea that things were about to change dramatically. I watched the Gene and Yagi show as they talked about vibe coding and how much they were enjoying it. And I caught it.

Up until then I'd been kind of like, yeah, the autocomplete's kind of nice, but it doesn't change my life. And that was enough for me.

Here was the moment — the expansion. Here's the thing that happens when you get to be a senior developer. When you're a junior developer, you don't know what would be cool. And then as you gain experience, you think, oh, you know what would be cool is if I implemented a new programming language, or I implemented the network stack from scratch, or whatever it is. You start having bigger and bigger visions. And then what happens is you realize, but that would be an awful lot of work. You know, it'd be a hassle. And so the boundaries of what you can imagine start to shrink.

And if there's one thing that I'd like you to take away from my presentation today, it is that the universe of possibilities for all of us has just expanded dramatically.

In jazz, they say, just 'cause you can doesn't mean you should. So there's an element of choice now that we all have. We could implement far more than we've been implementing, either as individuals or as teams, but there's a price to be paid.

So this is a good news, bad news kind of talk. There's good news — we have these phenomenal cosmic powers — and there's some bad news — the itty bitty living space.

So I started ridiculously ambitious projects. I'd always wanted to write a just-in-time compiler for graphics operations. It was something I'd seen done early in my career. I'd tried a few times, but it just never got very far. And I thought, well, this is the possibility. This is the chance I have to actually do this.

And I made some progress, and then I kind of ran out of steam. So I started over. If you look at my GitHub now, I have a bunch of repositories with suffixes: `bitbl`, `bitbl2`, `bitbl3`, `bitbl4`. And then I jumped to `bplus3`, `bplus3-2`, `bplus3-3`. And I found myself continually starting over with these projects.

And I got frustrated, but I also wanted to understand: what is going on that I would need to restart over and over again? There's a second part of it, which is what's wrong with me that I keep restarting these projects — but we don't have time to go into that one today.

I wanted to understand what it is about these tools that makes it so that you have rapid initial progress followed by a slowdown in progress, and eventually it just goes solid. As they say in the nuclear power industry, going solid is not a good thing. It means you've lost the ability to control your system at all.

So I came up with — this initial giddy feeling of "I could implement anything" — I call that being feature drunk. It's that feeling when you just type in a prompt and out comes the feature that you wanted. Oh, well, here's the next prompt, here's the next feature, here's the next prompt, here's the next feature. This is fantastic — right up until you have to open up project number four or five or six because you've been unable to add any new features.

It took me a while of thinking about this. I live in San Francisco and I walk, and I was thinking about it. I wanted a graphic because I'm a visual thinker. I would try and graph the progress over time and it just didn't quite fit for me.

And then I remembered a trick from Tufte — The Visual Display of Quantitative Information. Fantastic book. He said in there: eliminate time as one of the axes.

Alright, so on one axis we've got features. What goes on the other axis?

Personal thank you to Tim O'Reilly for publishing my book, Tidy First?, almost two years ago now. I figured I would reuse an idea from this book on software design that it took me 18 ridiculous years to write.

In Tidy First? we talk about the two dimensions of value of software. One dimension of value is the cash flows that it has today. But the other dimension of value is the things we can make the software do differently tomorrow. And so we talk about the difference between features and options.

So I thought, what happens if we graph features versus options?

And first, there's good news — I told you there's a good news, bad news talk. The good news is, used to be we would start with the usual options. We can do certain things. And the genie — I call the model "the genie" because it grants wishes, but it is not what you really wanted. So what the genie does: it enhances everybody's options immediately. We can possibly do more things. But left to its own devices — and honestly, our own devices too, our preference for seeing visible progress — when you implement a feature with the genie, you inevitably burn some of your options. Now you've got some code; you have maybe some bugs left in it, maybe you've got to keep it operating. So inevitably implementing a new feature burns some options.

And then, left to its own devices, you'll ask for the next feature, and that's gonna burn more options. And then you ask for the next feature, and that's gonna burn more options. And progress is slowing on those features. And eventually you go solid, where you just can't make another change.

Now sometimes you can add a little bit of optionality by doing a little bit of cleanup and then burn the options — but this is not very satisfying. And oftentimes you just get to where you can't change this software at all anymore.

So this is the natural state of the genie. This endless sequence of features. And features are great — don't get me wrong, they're visible, they're legible, everybody can understand the value of the features. But this isn't just a genie problem. We've been dealing with this for 25 years in the Extreme Programming world. When you get this flow of features, it's easy to just try and crank that up to 11 and leave it there. But that just doesn't last.

So what's the alternative here?

The alternative — and this is what I started practicing as I did augmented development — the alternative is, well, when you implement a feature, you're gonna burn some options. There's no getting around that. But now you have a choice. This choice comes very specifically as a programmer: I type in some prompt, it says, "Yeah, boss, I did it." Do I go to the next prompt, or do I go and look and see what it did?

It is so tempting — this is feature drunk — it's so tempting to just go to the next feature. But what that does is miss out on the opportunity to restore the options we had, and then some. Oftentimes implementing software in a tidy way gives you more options for the future.

That vertical jump — I'm not making any progress on features while I'm doing that vertical jump. I am writing more tests. I am refactoring to make the code easier to read or easier for the genie to digest. I am asking for explanations. "What's that feature in Rust?" Oh, this is so cool. There were all these programming languages that I just never tried, because learning a new language — ah. I'm implementing stuff on a weekly basis in languages that I'd never heard of before. And it works because much of the judgment that we carry from years and years of hard work still applies.

I can read the code even if I couldn't have written it. But I'll see some construct in a language I don't know and I'll say, "Well, what is ampersand, curly brace, close curly — what?" And the genie will answer it.

This is one of the things I love about augmented coding: it's this endlessly patient tutor. I remember I was reading something and somebody mentioned Eigenvalues, and I just thought, ugh, I got a little bit of matrix math a long time ago, but what's an Eigenvalue? And I thought, well, they know, and I don't, and that's just — wait a minute. So I asked Claude, "Hey, give me a tutorial about Eigenvalues." And it came back with some explanation. I thought, "Hey wait a minute, that's not true because da blah blah." And it said, "Oh, you're absolutely right. What a brilliant observation."

Glazing — you know, it's called glazing when it answers like that. Anyway, it was a brilliant observation, so fair enough.

But it's this endlessly patient tutor. And while I'm augmented coding, if I take the time to learn after I've done something, that increases my options for the next thing that I'm going to implement. I'll do things like, "What are two other ways you could have implemented this?" or "What are the trade-offs between doing it this way and doing it some other way?" Those don't add features. But if I take that moment to learn about it, it increases my options for the future, and then I can implement the next feature.

And if I'm not feature drunk, then I take a moment to add more options back. And I never slow down.

Now, every single moment of "next feature or add options" — it's always like, ugh, I'd like the next feature, 'cause I have big plans for this project. But I always have the option of taking a moment and restoring the options that I had and then some.

And that's the bad news. The good news is we've all just expanded our universe of what we could implement. And the bad news is we have to take the time to restore options — to test, to tidy, to learn, to explain, to turn this architecture into a haiku. Do you do goofy stuff like that too? I love it. "Write a rap in the style of Biggie Smalls that describes the architecture of the system." I mean, it's not a great rap — even I know that.

But here, this is the transformation. It's not just "let me churn out those features as fast as I can." It's "let me add features as I learn, and then learn as I add features," and that pace is sustainable.

If you look at this trajectory, it looks like the system is getting more features and more options all the time, forever. And I'll settle for that.

That pace, that style, that rhythm is available to everyone. But it requires that you celebrate those moments of restoring options — not just, "Hey, we have a feature and a thousand people are using it," but "we have this recurring problem. You took the time to write a tool for it. Now that problem is just not gonna affect any of us anymore." That's the leadership gesture: to recognize not just the things that are visible on the outside, but recognize that we're cleaning the kitchen as we cook so that we can keep cooking.

One of the things I love about the style of presentation here is Gene's invitation to the presenters to ask you for help. So I would say there are a couple of things that I could use help with.

One is: I have a quarter century of experience in the diffusion of innovation in sociotechnical systems from the Extreme Programming world. A lot of the stuff I see about the diffusion of these innovations in organizations — I just run my fingers through my vestigial hair. I can still feel it, by the way, even if it's not visible to you. I just can't believe that people are making mistakes this fundamental in the leadership of innovation.

I have to take a breath. But I have worked with a lot of people in this situation — I realize it's difficult, it's not easy to meet all the constraints — but I'd be happy to work with you and your team on the diffusion of these ideas into your organizations and the feedback loop that's necessarily involved with that adaptation.

If you're a vendor of these kinds of tools: I've spent decades creating a community of people who I think are really, really smart. If they've chosen to subscribe to my newsletter, that of course puts them in the top 5%. But I have that community, I have a voice in that community. And so to vendors of tools that are going to apply these kinds of innovations, I have sector-exclusive marketing partnerships that are also available.

So those are a couple of things that I can do and could use help with. Because what I'm gonna do right now is go meet a notary and sign the closing documents on a house. That's been a long time coming and I'm looking forward to that. So I'll be doing that just after this — and then I have a couple of hours that I'll be mingling, and I hope I can talk to you guys.

If any of this brings up thoughts or questions, let me know. And with that, I'd like to thank you very much for your time and attention.