Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again
Martin Fowler and Kent Beck explore how agile principles, rigorous testing, and domain-driven design prepare developers for navigating the unprecedented disruption of AI coding tools.
Highlights
4 clips · 4 min of 33 min-
- TDD habits build the exact verification skills needed for powerful AI agents.
- Verifying AI output requires the same rigorous mindset as writing unit tests.
-
- The most valuable skill is finding the smallest experiment to test tool claims.
- Initial impressions can be deceiving without learning proper usage patterns first.
-
- Extreme programming emphasizes rich human social environments and debate.
- Managing multiple agents alone replaces teamwork with solitary tool usage.
-
- The deep satisfaction of crafting individual functions no longer has leverage.
- Developers must pivot focus toward understanding the domain and expressing it clearly to agents.
That’s all the highlights.
Questions this video answers
8 · every answer cites the moment it was said01 How do my old TDD habits help me work with AI agents? 2 sources · 3:05
Test-driven development practices provide the necessary framework for verifying whether AI-generated code is actually correct. Since powerful AI models act like unpredictable genies, having strict tests ensures you can catch mistakes and make sure the tool is doing the right thing.
02 How should senior engineers approach the current wave of AI tools? 2 sources · 11:41
Senior engineers need to maintain absolute skepticism combined with relentless curiosity to properly evaluate new technologies. Instead of accepting hype or rejecting tech outright, you should run the smallest experiments possible to validate claims to your own satisfaction.
03 Will AI replace programmers or how will it affect different career stages? 2 sources · 18:55
AI acts as an amplifier rather than a wholesale replacement for developers. It creates a golden age for junior programmers who learn fast, while putting pressure on the middle tier who may struggle to find their footing amid broader economic headwinds.
04 What are the major risks enterprises face when adopting AI agents? 2 sources · 24:03
Large enterprises face massive security risks when blindly granting AI models autonomous control over sensitive systems like email. The rush to deploy unvetted agents in complex legacy codebases invites catastrophic failures that could easily take critical infrastructure offline.
05 How does the shift to AI impact team structures and collaboration? 2 sources · 25:48
There is a dangerous trend toward resoloing programming where individuals manage multiple agents in isolation rather than communicating with peers. However, maintaining collaborative structures like pairs or teams interacting with genies yields far better results than one person managing many agents alone.
06 How does good developer experience relate to agent experience? 2 sources · 29:40
The Venn diagram of developer experience and agent experience is effectively a circle. Practices like well-modularized code and strong testing make it significantly easier for both human developers and AI agents to work effectively.
07 How should I adapt my day-to-day coding habits given the rise of AI? 2 sources · 30:45
Developers must let go of the micro-satisfaction of writing individual functions by hand and shift focus toward domain understanding. Building a precise language to communicate domain models with agents provides much higher leverage than manually crafting code.
08 What historical tech shifts compare closest to the rise of AI? 2 sources · 7:54
The introduction of the microprocessor serves as the closest historical analogy to AI's disruptive magnitude. It fundamentally expanded human imagination by making computing cheap and enabling ridiculously ambitious projects.
Section-by-section summary
6 parts
TDD habits provide the blueprint for verifying AI code
While test-driven development remains divisive, its core discipline of writing tests provides the exact verification skills needed to handle powerful AI models. Developers must learn to rigorously check whether the AI is producing correct behavior.
Guiding developers through a period without clear answers
Software engineering is shifting from an era where answers were looked up in books to an exploratory phase where no one knows the solutions. Senior engineers must demonstrate not just tool usage, but how to figure out effective practices in real time.
Balancing absolute skepticism with relentless curiosity
Navigating major technology shifts requires absolute skepticism toward industry hype combined with deep curiosity to probe reality. Initial negative impressions of tools can be misleading if developers do not learn how to use them properly from experienced peers.
AI amplifies junior learning speed while middle tiers face pressure
AI acts as a powerful amplifier, making this a golden age for junior developers learning quickly with advanced tools. However, organizational incentives often misalign with efficiency gains, creating unique pressures across different experience levels.
Enterprise confusion and the danger of unvetted agent automation
Large enterprises face massive confusion and panic when attempting to apply AI to complex, legacy codebases. Giving LLMs autonomous control over critical workflows creates severe security risks that organizations are largely ignoring.
Good developer experience aligns with good agent experience
Practices like clean modularization and robust testing benefit both human developers and AI agents alike. As low-level coding satisfaction fades, developers must pivot their focus toward domain-driven design and understanding the overall problem space.
n next · p previous clip · t highlights/full
< > slower/faster · / search what was said
-
Test-driven development2× · first 2:22
A software development practice where automated tests are written before the code itself.
-
Refactoring2× · first 2:10
The process of restructuring existing computer code without changing its external behavior.
-
Agile8× · first 1:18
An iterative approach to software development emphasizing collaboration, feedback, and flexibility.
-
Domain-driven design1× · first 30:53
An approach to software development that centers on modeling domain concepts and specialized language.
-
Emacs1× · first 12:49
A highly extensible and customizable text editor favored by some experienced developers.
-
Pair programming1× · first 27:39
A practice where two programmers share a workstation to collaborate on writing and reviewing code.
-
Smalltalk1× · first 10:03
An object-oriented, dynamically typed programming language with live development environments.
-
Rust1× · first 10:09
A systems programming language focused on memory safety, concurrency, and high performance.
5,454 words · about 22 min to read
Welcome everyone. It's it's it's so nice to see all of you. It's so nice to see lot lot of friendly faces. A lot a lot of you said hi and also just really good to to meet Martin and Kent. And I was joking a little bit beforehand that I did not expect Martin and 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? What the hell is that supposed to mean?
Oh. 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. Uh but we're I I I'm psyched that both of you are 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 engine conference that Martin pulled together some 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 and two of you and you were two of you were there. Since then, you've really helped shape software engineering as you've helped
TDD habits provide the blueprint for verifying AI code
influence and and you've had major contributions. Could I ask both of you to like recap what the feedback you've gotten over over these these years, these decades, what ideas really stuck with engineers? what what 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 um whether it's agile broadly or refactoring particularly in my case because that was a book I worked on um 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 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 I think TDD has has been very divisive. I I've been a I' I've been a convert at some point and then I I hated it. But it's interesting because I feel a lot of a lot of the are like this, right? They're meant to be provocative.
They're meant to push you.
1 Highlight · Why TDD training prepares developers for AI verification
Yeah. I also got uh was actually chatting with somebody uh 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 now we've got AI agents. And uh it it's interesting to hear that feedback because um I'm always suspicious of it cuz I want it to be true. You know, I'm the kind of guy who when when I hear something I like, I'm I'm kind of thinking, am I just making this up? But uh 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 a lot of folks here, they will know you from the podcast that we did together. They might have they probably
read some of your books. Barton, you're really perfect 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 to fight into someone on LinkedIn about this. They said like, "Oh, your your conference like you're having authors here who are like out of touch with technology." And I'm like, "Do you even know who Martin Valer and Kemp Beck is?" But I just want wanted to to ask like these days, how what are what are you up to? Seriously?
Well, my I when I finished the second edition of 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. Um, 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 martinfaller.com website because, hey, I control that. There's no big corporation that's going to sweep in and and clobber it. At least not without my um me selling out and getting lots of money out of it. Um and um as the AI thing has come, I've been very keen to capture that. And what my big focus is on is trying to re understand details of people's workflow and what exactly they are doing. what
are the kind of conversations they're having with the genie as as Kent um calls it and you know what if you're reviewing things what are you looking for if and particularly what decisions are you are we the humans still making and how is that decision flow changing um so that's my interest is it's not what I'm doing it's what my colleagues
Guiding developers through a period without clear answers
are doing and trying to spread that around and that's that's my focus
and so I've been uh my personal mission in life is to help geeks feel safe in the world. And uh 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. Or 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 and 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 uh 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 that worked for the last 20 years and it doesn't work for the last year and won't work for the an extended period. So, as seniors, I figure it be behooves us to demonstrate not just how to use these
tools effectively, but how to figure out how to use these tools effectively because that's a whole different set of skills and you say all right we don't know what what will come how no one has to figure it out. I wanted to take you back into your professional journey. One thing that you share here you have seen a lot more than a lot of us myself included a lot of people in 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. That's I mean this is a a whole size difference from anything that we've faced before. um on a smaller scale um I would say and we were very much involved in the the growth of object-oriented languages I mean and that scared a lot of people it didn't scare us so much because we were part of it um I would say that the impact of the internet um had a huge impact upon us all um and of course obviously we were spreading the the 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. Um, but the thing about AI is that you know all of these things we were talking about how important they were and how valuable were and trying to persuade people of the importance of them. Yes, even the internet that may sound surprising but there were people who would weren't thinking that was important. Um, but AI there's kind of no
argument about how important it is. People can't I mean you cannot put blinkers on to deny the importance of this thing. So the 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 it was a big it was a big deal. And I was a kid in Silicon Valley with my dad as a programmer when the Intel 404 hit and we went, "Wait a minute, that's a computer." Oh my goodness, the 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, uh, I think part of AI is this expansion expansion of imagination. So, I'm writing projects
that are ridiculously ambitious. I'm uh working on a persistent small talk. I I'm writing library quality code for Rust. I'm just, you know, anything I can imagine to 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 um it it's not like this is the first time the heavens have
Balancing absolute skepticism with relentless curiosity
opened and and we've been brought tons of new opportunities
and back either with with object-oriented spreading or with microprocessors. Do you remember what the the feeling was in the industry and what was the difference between experienced professionals who you know just got thrived in this new world and ones who were just honestly left behind? Yeah, there with all of those there was that sense of the mix between the the the people chasing the hype and the the people who were saying no this is nothing special. Um I think it you've always got to have that balance of skepticism and curiosity um in order to be able to do that and you are selective about it. I mean I have been completely skeptical about some big um changes. I mean um blockchain for instance I was extremely skeptical about that um and but as I like to say you know about about my skepticism about technologies which is well rooted because I've seen so much
snake oil projected out by the industry um 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 may this looks like but maybe it isn't. How do I probe in order to detect that there's signs of of something coming out there?
Yeah. What what's the smallest
2 Highlight · Running small experiments to validate AI claims
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 that's the skill that has suddenly in the last year become a thousand times more valuable is that skill of saying what's the least I can do to validate for my to my own satisfaction whether this claim is true or not.
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 co-piloty like stuff about a year, year and a half ago, I was pretty unimpressed, right? I mean, I I set up I'm an Emacs guy. I set up Emacs. The one true editor. Um, I set it I set up Emacs so that I could just have it prompt and complete automatically because, you know, Emacs is capable of doing that. And I used it for maybe three or four days before I just got because 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 have said that's what I think of AI, I would have just immediately flip the bozo switch on it just like I did with blockchain. But on the other hand, I'm also probing out there. So my my most valuable discovery in all of this is in the room next door Simon Willis'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 you know and I you look at what they were doing you're not using objects very well in fact we kind of mckent I were kind of at yeah they were using C++ and Java they didn't actually do the real stuff. Um, but the 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 Willis, is he hyping everything wonderful or does he seem to be recognizing real problems at the same time and giving me straight stuff? And that I found was a 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 that involves something to listen to. So him and also some of my colleagues in
Fort Works like Mike Mason and Bit Berkel they really kind of showed me that oh I've shouldn't be relying too much on my initial reactions.
Yeah and it can change week to week. I I'll I'll I'll I'll try something with Gemini one week fails miserably. This Gemini thing cloud code then that works pretty well and then it's doesn't work well and then I tried Gemini for the same thing and it works this week and it didn't work la last week. That's a 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 a show of hands. One thing that struck me as like a bit of a similarity is back in 2001 when the 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 we the first one?
Alphabetical strictly alphabetical but it is a source of unending joy. You can very much take of that.
That that that kicked off some really interesting things in the indust industry because what what 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, I wanted to can you reflect on how agile actually went? Speaking of snake oil,
well, it 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 so as as geeks trying to achieve that and say, "Well, it's 40% better and it's 12% cheaper and it's less fattening." Uh people will punish you for that if that doesn't in 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 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 and this is what I I wanted to ask like looking back from what you've seen for agile now 25 years and it played out at a lot lot slow 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 about that agile movement and and that took the industry by like a very slow storm and now with AI.
Well, what's obviously very different is the sheer magnitude and speed that h that is hitting with AI. So that is definitely different. I suspect one thing I think there will still be some similarities. Um 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. Um I think there will be a big distinction between those two groups. Um I think another similarity is I mean the core notions uh behind agile and extreme programming are solid and good but a huge snake industry appeared around it.
The agile industrial complex as I like to refer to it. Um, 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 got to be
AI amplifies junior learning speed while middle tiers face pressure
constantly probing and be aware of and be wary of as as you're looking at it.
Yeah. A AI is an amplifier. And if uh if you're young and learning quickly, AI is going to amplify that or can amplify that. So I I personally think this is this is the golden age of the junior programmer. I get people coming to me all the time, oh my son started his second year in CS and he wants to go into something more commercial like art history.
And I I'd say this is like if you're a carpenter and they just introduced the the circular saw and you think ah well carpentry is over. anybody can build a house now. Well, no, you have more powerful tools. You you have less time that you have to do, you know, kind of the crummy work.
So, I think that that's a the young people who are learning fast 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.com crash, there was a there was um also 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, because 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 retrenchment in the software industry, the end of the zero interest rate period. Um, 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. Um, so which is an interesting kind of mix of things that wasn't the case back in the '9s with the dotcom boom because that was pretty much all solid boom.
Yeah. So, another interesting uh confluence of factors is we have these periodic we get to get rid of all the programmers. Woohoo.
Cobalt programming
starting with Cobalt, 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 were programmers, we were able to push that agenda pretty effectively. But now, now we have this repeating 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 amps up the fear factor that everybody is experiencing
and also one of the interesting things is when people are say oh we're getting rid of code I mean the you hear people saying sessions oh no one's going to write code in six 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 about 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 to help sell some of the tools that that help do this. Martin, you're talking with so many companies especially like large skeptical companies as well as well as startups as through thought works uh consulting advising. So do you Kent, what do you
Enterprise confusion and the danger of unvetted agent automation
see on the ground? What is interest and and what is surprising you about how these smaller and larger companies often the the more enterprisey ones the more traditional ones what are they doing with the technology and how are they thinking about it
um at the moment large scale confusion and panic is pretty much the order of the day right across the board
so so if that is your strategy you're right in the middle
I mean enterprise I mean large enterprises have this thing where they just have enormous amounts of code in complex systems that fit together in difficult to together ways. Um where someone says you know can can these tools handle a million lines of code because that 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 cause going to cause your airline to go offline for a day or two. That's not an acceptable um thing to consider. Um, and also, um, there are other risks involved. I mean, I 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, mindboggling. Um but you know it's a very it's I I am very much concerned we're going to have some really bad security incidents um over this year because people are just not paying attention and um those are the kinds of things that are out there as well. So there's a kind of blind rush to uh say let's let's let's grab these nicel lookinging things at the same time as some real concerns that are coming
3 Highlight · Why managing multiple agents is not team collaboration
across it as well. So I see a a a big trend is the resoloing of programming where a big part of extreme programming is creating a safe social environment for basically antisocial people. Not just asocial, antisocial.
And the 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 it's 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. And but I I see the the the trend
is Oh, good. We used to have programmers, you remember individual offices? We we'd have offices and doors and you shut the door and you slide the pizza under.
It was a thing
and and that was 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 oh, that was uncomfortable. Oh, good. I can, 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, that's the uh I mean it's part of the question that that uh and again I think something that was discussed last week, you know, are we seeing that you know 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 much be much more effective and capable and my
or or do you create a genie that can't eat pizza? That's the one.
My bet is on the more effective two pizza teams. Um, and it 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 n 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 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 um and possibly beyond pairs. I mean we we there's also the whole mob programming thing and whether that will go a route with that com combined with the genies that combination I but I don't necessarily think one person many genies is necessarily the right answer.
It's the simplest thing to to understand. It's the simplest framing,
but my my experience pairing with a 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 what other 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.
Good developer experience aligns with good agent experience
So, a lot of things are are changing as as a closing question before we we head over to Q&A for software engineers who really care about the craft and engine leaders who care about the craft and you know they they've learned to love this industry. They're seeing a lot of things. You're 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 stay afloat and and hopefully come out thriving from this this change in abstraction? Basically,
I I like to think of a comment again that came up last week and I can't remember who to who I shouldn't attribute it to. Um, which is that the uh the ven diagram of developer experience and agent experience is a circle. And the point here is that you know what we do that 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've 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 there's a good bit of potential overlap here. And again, this could be me again just wishful thinking because I want it to be true. Um, but uh I'm going to run with it for a bit at least. And I think so focus on those craft things and focus on um using that and teaching the agent as it were and working with the agent to find find out how best to express that.
One of the things that I found really fascinating was talking with another colleague of mine, Unashi, 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
4 Highlight · Shifting developer joy from coding to domain understanding
agent. So those kinds of things give me a sense of there's 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 I take a kind of uh OCD enjoyment in the in the craft and I need to let go of that because that that satisfaction of getting this one function just right just doesn't make a difference anymore.
Uh getting an overall understanding of what's going on. And and I say this with sadness because I really enjoyed getting in the zone and you 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 it 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. It just doesn't have leverage anymore.


