Martin Fowler and Kent Beck on AI: What Carries Over from Agile, and What They Have to Give Up
The Pragmatic Engineer
At the Pragmatic Summit, a conference otherwise full of AI startups, the host brought Martin Fowler and Kent Beck on stage. Both were among the 17 signatories of the Agile Manifesto 25 years ago. The host asked them what they have seen across decades of technology shifts, what the rollout of Agile suggests about the rollout of AI, and what engineers who care about craft should do now. Neither speaker claimed to know how the AI transition will end. Both argued that the habits of verification, skepticism, and good design they have promoted for decades still matter. Beck also admitted that part of what he loved about programming no longer pays off.
What stuck from Agile, TDD, and refactoring
The host opened by asking which of their ideas engineers still thank them for. Fowler said he hadn't really reflected on it. People talk to him about Agile in general or about refactoring, since he wrote that book, but he couldn't name a specific piece that stood out. Beck said he gets "Thank you so much for test-driven development," and also hears that TDD ruined someone's life: their dog left and their house burned down, and it was all his fault. The host said they had personally gone back and forth on TDD, and suggested these practices were meant to be provocative and to push people.
Fowler then described a conversation from the day before with someone pushing hard on AI. That person thanked them for 20 years of promoting TDD, because tests have become very important now that there are AI agents. Fowler said he is suspicious of feedback like this precisely because he wants it to be true, and he tends to ask himself whether he is just making it up. Still, the reasoning made sense to him: with "a big powerful genie" at hand, you have to learn how to verify that it is doing the right thing for you. Beck added that this is what they have been practicing for 25 years. Fowler joked that he isn't a big powerful genie himself, but he still needed tests to check he was doing the right thing.
What they are working on now
The host said someone on LinkedIn had complained that the conference was inviting authors who were out of touch with technology, and asked both speakers what their day-to-day work looks like.
Fowler said that after finishing the second edition of Refactoring, five or six years ago, he considered writing another book. He has several half-written ones. He decided against it and chose instead to work with people who are still doing real work on real projects and writing real code, and to help them publish what they learn. That work is mostly on martinfowler.com, which he likes because he controls it and no big corporation can take it over. Since AI arrived, he has focused on capturing people's workflows in detail. He wants to know what conversations they have with the genies (Beck's term, he noted), what they look for when reviewing output, and above all which decisions humans still make and how that flow of decisions is changing. He stressed that his interest lies in what his colleagues are doing, and his job is spreading it.
Beck described his personal mission as helping geeks feel safe in the world, and said they don't feel safe right now, for some good reasons and some bad ones. For 25 years, he said, they had the answers. If a team had too many bugs, you told them to write tests. If they couldn't write tests, you showed them how to design so they could. It was like pressing play on a recording. That has changed: "at this moment nobody knows the answers to anything." So Beck has gone back into explore mode, partly out of his own curiosity, to find out what makes people effective with the new tools. He then wants to show the next generation, who are used to looking up answers in a book, how that search is done. Looking it up worked for 20 years, he said, but it hasn't worked in the last year and won't for a long time. In his view, seniors owe it to others to show not only how to use the tools effectively but how to figure out how to use them effectively, which he called "a whole different set of skills."
Historical analogies: OO, the internet, Agile, the microprocessor
Asked whether any earlier technology shift felt as unpredictable as AI, Fowler said nothing has hit with this magnitude and called it "a whole size difference." At a smaller scale, he pointed to the growth of object-oriented languages, which scared many people, though not the two of them, since they were part of it. He also named the internet and Agile itself. You could measure Agile's impact, he said, by how hard organizations resisted it. The key difference, in Fowler's view, is that with all those earlier shifts they had to persuade people the change mattered. That was true even of the internet, since some people didn't think it was important. With AI, there is essentially no argument about its importance, and you cannot put blinkers on to deny it.
Beck offered a different analogy: the microprocessor. Before it, computers were big boxes you couldn't move, and buying another one meant mortgaging your house again. He was a kid in Silicon Valley, with a programmer father, when the Intel 4004 came out, and he remembered the reaction: that's a computer? The possibilities suddenly opened up for anyone who could write software or design hardware around it. He sees AI partly as a similar expansion of imagination. He described his own "ridiculously ambitious" projects, including a persistent Smalltalk and library-quality Rust code. He tries anything he can imagine, many attempts fail, and he considers that part of the process. He also stressed that this is not the first time "the heavens have opened" with a flood of new opportunities.
Skepticism about skepticism, and the smallest experiment
The host asked what separated the experienced people who thrived in earlier shifts from those left behind. Fowler said each shift had a mix of people chasing the hype and people insisting it was nothing special. You need a balance of skepticism and curiosity, he said, and you apply it selectively. He has been completely skeptical of some big changes, blockchain for instance, and said that skepticism is well founded after years of watching the industry push snake oil. But he explained his rule: his skepticism has to be "absolute and total," so he must also be skeptical about his skepticism. That takes curiosity, because you have to ask how to probe for signs that something real is emerging.
Beck turned this into a practical question: what is the smallest experiment I can run to verify, to my own satisfaction, whether a claim is true? He noted that everyone's threshold for satisfaction differs. He said that skill has become "a thousand times more valuable" in the last year.
Why first impressions of AI can mislead
Fowler added another caution: early interactions may not be a true signal. About a year to a year and a half earlier, he tried Copilot-style completion. As an Emacs user ("the one true editor," he said), he set Emacs up to prompt and complete automatically. He used it for three or four days and gave up. Sometimes it produced something wonderful, but most of the time the output was garbage he deleted right away. If he had judged AI by that experience, he said, he would have "flipped the bozo switch" on it, as he did with blockchain.
He changed his mind because he kept probing. His most valuable discovery, he said, was Simon Willison's blog (Willison was speaking in the next room). His main takeaway was that using these tools well is a skill you have to learn. He saw a parallel with object orientation: people claimed to be doing objects in C++ or Java, but when you looked at their code they weren't using objects well. Fowler also described how he judges whom to trust. Does someone call everything wonderful, or do they acknowledge real problems and give a straight account? People who present both good and bad, and above all who will say "I don't know," are worth listening to. Besides Willison, he credited ThoughtWorks colleagues including Mike Mason and Birgitta Böckeler with showing him not to rely too much on his first reactions.
Beck said the answer can change week to week. He described trying something with Gemini that failed badly, then with Claude Code, which worked well for a while and then stopped working, then trying Gemini again on the same task and finding it now worked when it hadn't the week before. People want the answer, he said, but the answer keeps changing, so no one can have it in this environment. The bad news is that you can't have the answer. The good news is that nobody else has it either: "you're just as smart as everybody else because you're just as ignorant as everybody else."
Did Agile deliver "better, faster, cheaper"?
The host noted that the Agile Manifesto went up in 2001 with 17 names, Beck's first. Beck explained this was strictly alphabetical, and said it gives him endless joy. The host read the manifesto as promising four simple, relatable principles for building software better, faster, cheaper, and with higher quality. Companies adopting AI seem to expect much the same, so the host asked how Agile actually turned out.
Beck said: "it turns out that people don't want faster, cheaper, better." Inside companies, incentives are badly misaligned with those goals. Geeks who show up saying something is 40% better, 12% cheaper, and "less fattening" can be punished for it if it conflicts with incentives inside the organization. Ideally everyone would care about the same things, but that isn't how organizations work. Beck said this problem remains unsolved, so if AI promises the same benefits, he expects exactly the same reaction.
Similarities and differences between Agile and AI
Asked how AI's adoption might resemble Agile's much slower one, Fowler said the obvious difference is the sheer size and speed of AI's impact. He expects two similarities. First, there will be a large gap between people who use AI well and people who use it badly, and the key is working out how to use it well and putting in the effort to learn. Second, the ideas behind Agile and extreme programming were sound, yet "a huge snake oil industry" grew up around them, which he calls the "Agile industrial complex." He said the same is already happening with AI, and it is often hard to tell snake oil from the real thing, so you need to keep probing and stay wary.
AI as amplifier: juniors, experts, and the middle
Beck called AI an amplifier. For young people who learn quickly, it will, or at least can, amplify that. He said he personally thinks this is "the golden age of the junior programmer." People often tell him their child is in the second year of a CS degree and wants to switch to something "more commercial like art history." His response is an analogy: if you are a carpenter and the circular saw has just been introduced, carpentry isn't over and anyone still can't build a house. You simply have more powerful tools and spend less time on tedious work. In his view, fast-learning young people will learn faster, and effective experienced people will work faster and better.
His concern, which he said he picked up at the previous week's gathering, is the middle. After the dot-com crash, he said, a middle group who had come to programming for the money left, more or less for real estate. He doesn't know where today's middle will go, and he noted it is much larger than it was 25 years ago.
Fowler added that this middle has already been partly flushed out by industry retrenchments at the end of the zero-interest-rate period. The AI boom and the economic headwinds of the last two or three years are happening together, which he called an interesting mix. The 1990s dot-com era was different, he said, because it was "pretty much all solid boom."
"Get rid of the programmers," again
Beck noted that a recurring cycle feeds the current fear: every so often, someone announces that all the programmers can finally be eliminated. It started with COBOL, which was supposed to let business analysts write programs themselves. Agile was explicitly not that, he said. It aimed to make programmers more effective, and because programmers started it, they could push that agenda well. Now the "get rid of the programmers" story is back. Beck said programmers should ask themselves why people keep wanting to get rid of them. Some of the reasons have to do with programmers and some don't, but some do. He added that the recurring story also raises everyone's fear.
Fowler challenged the claim that "no one's going to write code in six months' time" by asking what "code" means. Even people who don't write code by hand are prompting and interacting with the genie, so what is that if not some form of code? He thinks the nature of code may become radically different, but people will still need to produce it and interact with it in some way.
What large enterprises are doing: confusion, panic, and security risk
The host said both speakers have their feet on the ground, unlike AI labs such as OpenAI, which must "talk their book," or others with a small incentive to sell tools. The host asked what they see in companies, including large, skeptical, traditional ones.
Fowler said "large-scale confusion and panic" is the norm across the board. Large enterprises have huge amounts of code and complex systems that fit together in ways that are hard to untangle. People ask whether these tools can handle a million lines of code, and Fowler noted that counts as a smaller codebase for many of those systems. The picture differs sharply from startups. An airline cannot accept the risk of going offline for a day or two.
He also raised other risks. He said he has met several groups, some at surprisingly large companies, who want to give an LLM full control of their email so it can read everything and answer most messages. Fowler and Beck both reacted on stage with an emphatic "NO." Fowler called the security risk "mind-boggling" and said he is very worried there will be some really bad security incidents this year because people aren't paying attention. He described a blind rush to grab attractive tools alongside real concerns.
The "re-soloing" of programming
Beck identified a major trend he called "the re-soloing of programming." A big part of extreme programming, he said, was creating a safe social environment for "basically antisocial people," and he stressed not just asocial but antisocial. On an XP team, people talk to each other for hours a day and are glad to, because the setup makes it a positive experience. Now he hears programmers say, "I've got six agents, so really I'm managing a team." Beck disagrees: you are using six tools at once, which is fine, but that is very different from talking with someone who believes slightly different things than you do, or whose energy level today differs from yours.
He compared this to the old days of individual offices, where you shut the door and pizza got slid underneath. That model was easy to manage and control. Then came a messy, social, complicated, chaotic process that "just happened to produce really good results," and management found it uncomfortable. He described the appeal of the new framing: instead of 50 people, a team of five who don't need to talk to each other, each running ten agents. His verdict: "It's not the same."
One-pizza teams or more capable two-pizza teams?
Fowler brought up a question from the previous week's discussion: will two-pizza teams shrink to one-pizza teams because agents don't eat pizza, or will two-pizza teams stay the same size and become far more effective? (Beck joked that you could build a genie that eats pizza.) Fowler said his bet is on more effective two-pizza teams.
He said they are starting to get interesting feedback about pair programming. Is the pair one human and a genie, or two humans with genies? With two humans, he suggested, you might control the genies somewhat better and keep the human interaction. He said he'd be very interested in reports from people trying pairs that direct genies, and possibly larger groups, such as mob programming combined with genies. He doesn't think one person with many genies is necessarily the right answer.
Beck said one person with many agents is the simplest framing to understand. His own experience pairing with two humans and one or more genies has been very positive, and he likes that the models are fairly slow. Each time a faster model comes out, he thinks there is less time to talk. You give a prompt and it goes off for three minutes, and meanwhile you can discuss your philosophy of naming, how to express conditionals, or what to do next. If it comes back in 15 seconds, there's no time for that conversation.
Advice for people who care about craft
The host closed by asking what engineers and engineering leaders who love the craft should do as they write less code themselves and lose some control.
Fowler cited a remark from the previous week, whose author he couldn't remember: the Venn diagram of developer experience and agent experience is a circle. What is good for agents is good for humans, and vice versa. He said he hears a lot of feedback that well-modularized code makes it easier for agents to work, and that good tests help agents as well as people. He again allowed that this might be wishful thinking because he wants it to be true, but said he will run with it for now. His advice was to keep focusing on craft and to work with the agent, teaching it and finding out how best to express that craft. As an example he described his colleague Unmesh Joshi, who, when working in a domain with an agent, tries to develop a precise language for talking about the domain. That is essentially the model-building, language-building work of domain-driven design, and Joshi finds it makes him more efficient in communicating with the agent. To Fowler, examples like this show a large overlap between what is good in existing practices and what will keep working with AI.
Beck's answer was more personal. He said he takes an "OCD enjoyment" in craft and needs to let go of it, because the satisfaction of getting one function exactly right no longer makes a difference. He said this "with sadness." He described what he loved: getting into the zone with a messy file, taking tiny safe steps without quite knowing where they lead, seeing a glimmer of the shape, and then having it suddenly pop into focus. "I can't do that anymore," he said. He can still build an overall understanding of what he's doing. His task now is to shift his enjoyment toward understanding the domain and how it connects to his program. For him, treating the program itself as the domain and making it better and better "just doesn't have leverage anymore."
Welcome everyone. It's so nice to see all of you. It's so nice to see a lot of friendly faces. A lot of you said hi. And also just really good to meet Martin and Kent. And I was joking a little bit beforehand that I did not expect Martin Fowler and Kent Beck to walk into a place where it's all the kind of the hottest AI startups and all of them. But here we are and we're here for a very very good reason.
What? What the hell is that supposed to mean?
Oh gosh, here we go. So Kent is going to hate me for this cuz today I already called him old furniture once.
I don't think that's fair.
Old furniture. Yeah, you're the old guy in the crowd.
I'm at least a year younger than him.
But I'm psyched that both of you are here. And a week ago, me, Martin, Kent, and a bunch of other people were in Deer Valley, Utah in the Future of Software Engineering conference that Martin pulled together, some very interesting thinkers. And we were talking about, like, it was nice to reflect that 25 years ago the Agile Manifesto was created.
There were 17 people and two of you were there. Since then, you've really helped shape software engineering as you've helped influence and you've had major contributions. Could I ask both of you to recap the feedback you've gotten over these years, these decades, what ideas really stuck with engineers? What do you hear a lot, they tell you like, "Thank you for this. I'm using a lot of this."
That's a really interesting question. I haven't really reflected on that. I mean, a lot of people talk about things in general that we've worked on, whether it's Agile broadly or refactoring particularly in my case because that was a book I worked on. But I don't know anything where any of the pieces of that necessarily.
So, I get "Thank you so much for test-driven development." I also get this: test-driven development "ruined my life. My dog left me. My house burned down and it's all your fault." So, I don't know. Does that answer your question?
I think TDD has been very divisive. I've been a convert at some point and then I hated it, but it's interesting cuz I feel a lot of these are a bit like this, right? They're meant to be provocative. They're meant to push you.
Yeah, I also got... I was actually chatting with somebody yesterday who's really pushing the AI envelope and his comment was, "Well, thank goodness for all of your pushing of TDD for the last 20 years because it's really important that we've got AI agents." And it's interesting to hear that feedback because I'm always suspicious of it cuz I want it to be true. You know, I'm the kind of guy who when I hear something I like, I'm kind of thinking, "Am I just making this up?" But it does make sense to me that, you know, when we've got a big powerful genie, you really have to learn how to verify that it's doing the right thing for you.
Which we've been practicing for 25 years.
Yeah. Well, I mean, I'm not a big powerful genie myself but I still needed the tests to make sure I was doing the right thing.
So, a lot of folks here, they will know you from the podcast that we did together. They probably read some of your books. Martin, you're a really prolific writer, but can you tell us what are you up to these days? What does your day-to-day look like? How do you stay in touch with technology? I got a really rude comment that I'm still... I got into a fight with someone on LinkedIn about this. They said like, "Oh, your conference, you're having authors here who are like out of touch with technology." And I'm like, "Do you even know who Martin Fowler and Kent Beck is?" But I just wanted to ask, like, these days what are you up to? Seriously.
Well, when I finished the second edition of the Refactoring book, which was, you know, five or six years ago, I toyed with the idea of writing another book. I've got several half-written books out there to work on. And I decided I should not do that. Instead, what I should do was work with people who are actually still doing real work on real projects, writing real code, as it were, and get them to get their ideas out and what they learn out. So, that's been my main project ever since, primarily focused on the martinfowler.com website, because hey, I control that. There's no big corporation that's going to sweep in and clobber it, at least not without me selling out and getting lots of money out of it.
And as the AI thing has come, I've been very keen to capture that. And my big focus is on trying to understand details of people's workflow and what exactly they are doing. What are the kind of conversations they're having with the genies, as Kent calls it. And you know, if you're reviewing things, what are you looking for? And in particular, what decisions are we, the humans, still making? And how is that decision flow changing? So, that's my interest: it's not what I'm doing, it's what my colleagues are doing and trying to spread that around, and that's my focus.
Yeah, so my personal mission in life is to help geeks feel safe in the world. And our people do not feel safe right now. For some good reasons and some not good reasons. And one of the things I noticed is for 25 years we've kind of had the answers. Somebody comes to us and says we have too many bugs, like, all right, well, here's how you write tests. Oh, I can't write tests. Well, here's how you design so you can write tests. It's just kind of press play on the recorder. And the thing that's changed is at this moment nobody knows the answers to anything.
And so what I've been trying to do is, both for my own geeky curiosity satisfaction, let me go back into explore mode and find out as well as I can what you can do to be effective with these new tools, and then demonstrate that to the next generation of people who've been used to getting answers. Oh, I'm having some trouble. Let me look up in the book what the solution is. That worked for the last 20 years, and it doesn't work for the last year, and won't work for an extended period. So, as seniors, I figure it behooves us to demonstrate not just how to use these tools effectively, but how to figure out how to use these tools effectively, cuz that's a whole different set of skills.
And you say, all right, we don't know what will come out. No one has it figured out. I want to take you back into your professional journey. You have seen a lot more than a lot of us, myself included, a lot of people in the room as well. Do you remember a time where there was a technology change which looked similarly kind of unpredictable or scary like AI does right now? What was the thing that comes the closest in your career?
Well, nothing has hit with the magnitude of AI. I mean, this is a whole size difference from anything that we've faced before. On a smaller scale, I would say, and we were very much involved in the growth of object-oriented languages. I mean, and that scared a lot of people. It didn't scare us so much cuz we were part of it. I would say that the internet had a huge impact upon us all. And of course, obviously, we were spreading the challenge of Agile software development, and that had a very big impact on a lot of organizations because you could tell by how hard they resisted it.
But the thing about AI is that, you know, many of these things, we were talking about how important they were and how valuable they were and trying to persuade people of the importance of them. Yes, even the internet. That may sound surprising, but there were people who weren't thinking that was important. But AI, there's kind of no argument about how important it is. I mean, you cannot put blinkers on to deny the importance of this thing.
So, the other analogy that I have is to the introduction of the microprocessor. Before that, computers were a big box. You couldn't move them around. If you wanted another one, you'd mortgage your house again. It was a big deal, and I was a kid in Silicon Valley with my dad as a programmer when the Intel 4004 hit, and we went, "Wait a minute. That's a computer? Oh my goodness." The possibilities suddenly expanded. If you can figure out how to write software, if you can figure out how to design hardware around this thing, you can suddenly do things we can't even imagine. And so,
I think part of AI is this expansion of imagination. So, I'm writing projects that are ridiculously ambitious. I'm working on a persistent Smalltalk. I'm writing library-quality code for Rust. I'm just, you know, anything I can imagine that I'm trying to do, I'm going to try and do it and see. Now, a bunch of those fail and that's fine. That's part of this process, but it's not like this is the first time the heavens have opened and we've been brought tons of new opportunities.
Back either with object-oriented spreading or with microprocessors, do you remember what the feeling was in the industry and what was the difference between experienced professionals who, you know, thrived in this new world and ones who were just, honestly, left behind?
Yeah, with all of those, there was that sense of the mix between the people chasing the hype and the people who were saying, "No, this is nothing special." I think you've always got to have that balance of skepticism and curiosity in order to be able to do that. And you are selective about it. I mean, I have been completely skeptical about some big changes. Blockchain, for instance. I was extremely skeptical about that. But as I like to say about my skepticism about technologies, which is well rooted cuz I've seen so much snake oil projected out by the industry over the years, my skepticism has to be absolute and total, which means I have to be skeptical about my skepticism. And that requires that curiosity. And I think that's where the thing is. You've got to be curious enough to say, "This looks like it, but maybe it isn't. How do I probe in order to detect the signs of something coming out there?"
Yeah, what's the smallest experiment I can run to verify to my own satisfaction, and everybody's level of satisfaction is going to be different, whether or not this claim is true. That's the skill that has suddenly in the last year become a thousand times more valuable: that skill of saying, "What's the least I can do to validate to my own satisfaction whether this claim is true?"
But there's also another step in there, that you also got to be aware that your early interactions may not actually be a true signal. I mean, when I started playing around with AI, I guess it was the Copilot-y like stuff about a year, year and a half ago, I was pretty unimpressed, right? I mean, I'm an Emacs guy. I set up Emacs. Yeah, the one true editor. I set up Emacs so that I could just have it prompt and complete automatically, cuz you know, Emacs is capable of doing that. And I used it for maybe three or four days before I just got... Cuz sometimes it would give you something wonderful, but most of the time it gave you such garbage that you would just Control-K right away. And if that had been my impression of AI and I had said, "That's what I think of AI," I would have just immediately flipped the bozo switch on it just like I did with blockchain.
But on the other hand, I'm also probing out there. So, my most valuable discovery in all of this is, in the room next door, Simon Willison's blog, which I read, and one of the things that I took from that was to use this tool well, you have to learn how to use it well, which was also something very true of object orientation. People would say, "Oh, objects, we're doing..." and you'd look at what they were doing, and you're not using objects very well. Kent and I were kind of at... Yeah, they were using C++ and Java. They didn't actually do the real stuff.
But the point was you have to be also listening to the folks out there and being able to read with a critical eye and getting a sense of, okay, if you do run across a Simon Willison, is he hyping everything as wonderful or does he seem to be recognizing real problems at the same time and giving me straight stuff? And that I found was really... I mean, when people give you that balance of good and bad and also, most importantly, are prepared to say "I don't know," then that's something to listen to. So, him and also some of my colleagues at Thoughtworks, like Mike Mason and Birgitta Böckeler, they really kind of showed me that, oh, I shouldn't be relying too much on my initial reactions.
Yeah, and it can change week to week. I'll try something with Gemini one week, fails miserably. This Gemini thing, Claude Code, then that works pretty well, then it doesn't work well, and then I tried Gemini for the same thing, and it works this week, and it didn't work last week. You know, people want the answer, and the answer is changing. So, you can't possibly in this environment have the answer. Now, that's the bad news. The good news is nobody else has the answer either. So, you're just as smart as everybody else because you're just as ignorant as everybody else.
Is that reassuring?
Is that reassuring? By show of hands.
One thing that struck me as a bit of a similarity is back in 2001, almost exactly 25 years ago, when the Agile Manifesto came out with that website with all the 17 names listed and Kent Beck being the first one. Why were you the first one?
Alphabetical. Strictly alphabetical. But it is a source of unending joy.
You can very much like it that.
That kicked off some really interesting things in the industry, because my interpretation was like, well, use this Agile, here's these four pretty simple, easy to understand, and easy to identify with things to build better software, faster, cheaper, higher quality, you name it. Now, when I think of why so many companies are adopting AI, they're kind of expecting the same thing: better, faster, cheaper, and so on. And so, can you reflect on how Agile actually went, speaking of snake oil?
Well, it turns out that people don't want faster, cheaper, better.
Tell me more.
Inside a company, the incentives are so misaligned with actually achieving that. And so as geeks trying to achieve that and say, well, it's 40% better and it's 12% cheaper and it's less fattening, people will punish you for that if that doesn't align with their incentives inside of organizations. Yeah, in the ideal organization, everybody would care about the same things and that's just not the way it works.
But I...
So, and we haven't touched that problem. So, if AI is coming along to promise the same things, we're going to see exactly the same reaction.
And this is what I wanted to ask. Looking back from what you've seen for Agile, now 25 years, and it played out at a lot slower pace, what similarities do you see right now with AI? How do you think the curve could fit? And also, what is very different between that Agile movement, which took the industry by a very slow storm, and now with AI?
Well, what's obviously very different is the sheer magnitude and speed that is hitting with AI. So, that is definitely different. I think there will still be some similarities. One of them, I think, is there will be a big difference between people who use it well and people who use it badly. And the trick is figuring out how to use it well and putting the effort in to learn to use it well. I think there will be a big distinction between those two groups.
I think another similarity is, I mean, the core notions behind Agile and Extreme Programming are solid and good, but a huge snake oil industry appeared around it, the Agile industrial complex
as I like to refer to it. And that will happen. That is happening with AI right now, and it's often hard to see the difference between where is the snake oil and where is the real stuff. And so, that's another thing that you've got to be constantly probing and be aware of and be wary of as you're looking at it.
Yeah, AI is an amplifier. And if you're young and learning quickly, AI is going to amplify that or can amplify that. So, I personally think this is the golden age of the junior programmer. I get people coming to me all the time. Oh, my son had started his second year in CS and he wants to go into something more commercial like art history.
And I'd say well, this is like if you're a carpenter and they just introduced the circular saw and you think, oh well, carpentry is over. Anybody can build a house now. Well, no, you have more powerful tools. You have less time that you have to do, you know, kind of the crummy work.
So, I think that the young people who are learning faster are going to learn faster. The experienced people who are working effectively are going to work more quickly and more effectively.
And my concern, and this is something I learned last week, that middle: if we look back at the dot-com crash, there was a middle of people who'd gotten into programming because it was a way to make money, and those people went into real estate more or less. And I don't know where the middle's going to go now cuz that middle is much bigger now than it was 25 years ago.
But that middle has also been flushed out to some degree by the retrenchments in the software industry at the end of the zero interest rate period. So, that's an interesting difference because we've had these two things occurring at once, the AI boom and the economic headwinds that we've had in the last two or three years. Which is an interesting kind of mix of things that wasn't the case back in the '90s with the dot-com boom cuz that was pretty much all solid boom.
Yeah. So, another interesting confluence of factors is we have these periodic "we get to get rid of all the programmers, woohoo."
COBOL, the end of programming.
Starting with COBOL, right? When the business analysts were going to be able to write the programs and we didn't have to have programmers anymore.
And so that comes back repeatedly. Agile was definitely not that. We wanted programmers to be more effective in their jobs. And since we started it and we're programmers, we were able to push that agenda pretty effectively.
But now we have this repeating, "Hey, we get to get rid of all the programmers." Which it behooves us as programmers to think about why they keep wanting to get rid of us. Some of that's about us and some of it's not, but some of it is. So we should think about that. But also that amps up the fear factor that everybody is experiencing.
And also one of the interesting things is when people will say, "Oh, we're getting rid of code." I mean, you hear people saying in sessions, "Oh, no one's going to write code in 6 months' time." I go to myself, "Well, yeah, but what do you mean by code?"
Because that kind of implies nobody's writing anything. Well, we're at least doing some prompting. We're having some interaction with the genie. What's that going to be if it's not some form of code in some way? I think the nature of what code is is going to be quite possibly very radically different. But I think there is still a need to produce it and be able to interact with it in some way.
One thing I really like and respect about both of you is you are two feet on the ground. We've heard from OpenAI, who are a leading lab, and of course they're building amazing technology, but they also have to talk their book. We've heard from Laura, who talks with so many people and so has so many good insights. In the end, you know, she will have a small bias to help sell some of the tools that help do this. Martin, you're talking with so many companies, especially large skeptical companies as well as startups, at ThoughtWorks consulting, advising, and so do you, Kent. What do you see on the ground? What is interesting and what is surprising you about how these smaller and larger companies, often the more enterprise ones, the more traditional ones, what are they doing with the technology and how are they thinking about it?
At the moment large-scale confusion and panic is pretty much the order of the day right across the board.
So if that is your strategy, you're right in the middle.
I mean large enterprises have this thing where they just have enormous amounts of code and complex systems that fit together in difficult to get over ways. Where someone says, you know, can these tools handle a million lines of code, because that's a smaller code base as far as many of these systems are concerned. And it's a very different picture to the startup world because no, you do not want to take a risk that's going to cause your airline to go offline for a day or two. That's not an acceptable thing to consider.
And also there are other risks involved. I mean I've now run into several different groups, including some at surprisingly large companies, that are talking about let's have the LLM have complete control over my email. It can read all my emails and it can reply to most of the emails. And I'm going
No.
What?
No.
I mean the security risk of that is, you know, mind-boggling. But, you know, it's a very... I am very much concerned we're going to have some really bad security incidents over this year because people are just not paying attention. And those are the kinds of things that are out there as well. So, there's a kind of blind rush to say, "Let's grab these nice looking things," at the same time as some real concerns that are coming across it as well.
So, I see a big trend is the re-soloing of programming. Where a big part of extreme programming is creating a safe social environment for basically antisocial people. Not just asocial, antisocial.
And when I think about the degree of interaction on an XP team, people are talking to each other hours a day and happy to be doing so because it's set up for that to be a positive experience.
What I see now is, well, "I'm a programmer and I've got six agents. So, really I'm managing a team." No, you're not. You're using six tools at once, which is fine. But that's very different than having a conversation with somebody who believes things that are a little different than what you believe. Or somebody who's got a different energy level today than you have.
But I see the trend is, "Oh, good. We used to have programmers, you remember individual offices? We had offices and doors and you shut the door and you slide the pizza under."
It was a thing.
And that was easy to manage and easy to control. And then along came this messy, social, complicated, chaotic process that just happened to produce really good results. And that was uncomfortable. "Oh, good. You know, instead of having 50 people on my team, I have five people on my team. They don't have to talk to each other. And they can each have 10 agents and that's the same." It's not the same.
Yeah, I mean, it's part of the question that, and again, it's something that was discussed last week, you know, are we seeing that two pizza teams are going to become one pizza teams because agents don't eat pizza? Or do we see two pizza teams staying, but just being able to be much more effective and capable? My
Or do you create a genie that can eat pizza? That's the one that
My bet is on the more effective two pizza teams. And it's also some interesting, you know, feedback we're beginning to get in terms of pair programming. I mean, with pair programming, do you say pair programming is the human and the genie? Or is it two humans and genies? Because if it's two of us, we can control the genies perhaps a little bit better. And we also have that same interaction.
And I'm going to find it very interesting to hear reports of people trying that kind of route where they're saying, "Yes, we have those pairs controlling genies." And possibly beyond pairs. I mean, there's also the whole mob programming thing and whether that will go a route with that combined with the genies, that combination. But I don't necessarily think one person, many genies is necessarily the right answer.
It's the simplest thing to understand. It's the simplest framing. But my experience pairing with two humans and a genie or multiple genies has been very positive. And the fact that they're kind of slow is really nice. So, every time the models come out and they're faster, I'm like, "Oh, there's less time to talk." You give a prompt and it's like, "Oh, well, blah blah blah," and then it's gone for 3 minutes and we can talk about our philosophy of naming or, you know, how do we express conditionals or, you know, what should we be doing next? And if it pops back in 15 seconds, you don't have time to have that conversation.
So, a lot of things are changing. As a closing question before we head over to a Q&A, for software engineers who really care about the craft and engineering leaders who care about the craft and, you know, they've learned to love this industry, they're seeing a lot of things are shifting. For example, you're not writing the code, you're losing a lot of control. What advice would you give to them to, you know, stay afloat and hopefully come out thriving from this change in abstraction, basically?
I like to think of a comment, again, that came up last week and I can't remember who I should attribute it to, which is that the Venn diagram of developer experience and agent experience is a circle. And the point here is that, you know, what we do that's good for the agents is good for the humans and vice versa. I'm hearing a lot of feedback saying, "Yeah, actually, if you have well-modularized code, that actually makes it easy for the agents to work with." And we're already getting, you know, lots of reinforcement saying, "Actually, focusing on tests, good tests, helps the agents as well as helps us." So, I think there's a good bit of potential overlap here. And again, this could be me, again, just wishful thinking cuz I want it to be true, but I'm going to run with it for a bit, at least. So, focus on those craft things. And focus on using that and teaching the agent, as it were, and working with the agent to find out how best to express that.
One of the things that I found really fascinating was talking with another colleague of mine, Unmesh Joshi, about how he was working in domains, and he says the way he finds working often with an agent is to try and develop a language, a precise language to communicate about the domain with the agent, which is basically the kind of model building, language building, domain-driven design stuff that we're used to doing, but it makes him more efficient to talk to the agent. So those kinds of things give me a sense of this: there's definitely a huge overlap between what is good about our practices and what will be good continuing to drive with AI.
So I think for me, I take a kind of OCD enjoyment in the craft. And I need to let go of that. Because that satisfaction of getting this one function just right just doesn't make a difference anymore. Getting an overall understanding of what's going on, and I say this with sadness.
Because I really enjoyed getting in the zone and you've got some file and it's a big mess and you make tiny little safe steps and you don't know quite where it's going and then you start to get a glimmering and then it's there and then, oh, pop, it just pops into focus and, oh, that feels so good, and I can't do that anymore.
But I can still develop an overall understanding of what I'm doing. And I need to shift my focus to enjoying understanding the domain and its connection to my program, in a way that I used to be focused on the program as the domain, and I could make that better and better; that just doesn't have leverage anymore.
Article published