Not long ago I watched a recorded talk that has stayed with me longer than most. It was Kent Beck’s talk at Prodacity 2026, titled “Software Engineering in the Age of AI.” Beck created Extreme Programming and popularized TDD, and in this talk he asked what it means to build software well now that AI writes a large share of the code. Of the talk’s fifty-two-plus minutes, what struck me most were two words and a short story about a cellist.
Beck described software development along two axes: features and futures. One axis is the features we build. The other is the range of options for how the software can change from here: its room for change, or optionality. A project starts out with no features at all but with unlimited possibility, he explained, and every feature you build eats into its futures. His point was that if you keep piling on nothing but features, you eventually end up with dead software, where it gets hard to touch anything at all and futures sit at zero.
In a way, this was something I’d already felt firsthand over my years working as an engineer: how much refactoring matters. While building a feature, I’d refactor whatever I could improve along the way, and if I had a little time left before starting the next feature, I’d count that as refactoring time too. But it occurred to me that at some point, once I started having AI do all of the coding, I’d lost track of that ‘refactoring time.’ When I build a feature, I think about a number of harnesses (things that correct AI’s work, like tests, linters, hooks, constraint prompts, and verification agents), but I realized I hadn’t been doing any work that was ‘just refactoring.’
What Beck said next hit close to home, too. It used to take a hundred people ten years to get futures down to zero, he said, but now, thanks to AI, one person can make a complete mess in a week. I can’t go into detail here about what I was working on, but I went through my share of trial and error along the way. The whole time I was listening, I kept seeing more and more of my own missteps in Beck’s drawing. Looking back, I think I had completely forgotten how much the cooldown between one feature and the next matters.
To explain the alternative, Beck brought up a story about the cellist Pablo Casals. He said it was something he’d heard as a young man, when he was majoring in classical guitar at music school. The cello is a physically demanding instrument, and as the story goes, one of the pieces Casals played had a passage with an endless run of sixteenth notes. When someone asked him if he didn’t get tired playing all those sixteenth notes, Casals answered, “No, I rest between the notes.” But apparently Casals never said anything of the kind, and the story is made up. Still, it’s too good a story not to tell, Beck added.
It’s a made-up story, but hearing about resting between the notes got me thinking all over again. Even at the fast tempo of AI work, you’d probably still need ‘time to steady your hands and your breath so you can hit the next note precisely.’ That’s what I’d call ‘time for tidying.’ The ‘refactoring time’ I wrote about earlier was exactly this space between the notes. Every developer knows the basics: you have to tidy up between features as you go if you want software that’s both flexible and extensible. But with features pouring out these days, I think now is exactly the time to get back to those basics. Just as Casals rested even between those endless sixteenth notes, shouldn’t we fit refactoring and tidying up the test cases in between the features we build so quickly? The analogy Beck used, “You can’t wipe the knife while you’re cutting, but you have to wipe the knife,” also made intuitive sense to me.
All that running without tidying left its mark, and not just in the code. My MacBook showed every bit of it, too. When a hectic stretch of work wound down and I had a little idle time, there were things I could only see once I’d stopped. Git worktrees and DB containers I’d never gotten around to tidying up had piled up all over the place, and my free disk space was heading toward empty. If I’d jumped straight into the next task, the disk might have hit zero at some point and brought everything to a halt. Once I’d cleared out the pile, one thing at a time, my MacBook finally had room to take on the next task again. You could say that’s how my MacBook got a little of its futures back, too.
A little while ago, my family and I took a trip to Jeju Island. What has stayed with me longest from the trip is the sunrise we watched in Seogwipo. I really enjoyed getting up early and watching the sun come up. The sky was full of mackerel clouds turning orange from the bottom up, and the sun slowly peeked out from behind the silhouetted palm trees.
Surprisingly, after we got back from the trip, the feel of our family’s mornings changed overnight. Without us really noticing, getting up early to start the day has become the rhythm of our home, and thanks to that, I feel like we’re slowly getting a bit healthier. You could say that trip was our family’s tidying between the notes. Come to think of it, our lives probably aren’t all that different from software. Whether it’s work or parenting, each day rushes along toward the next feature, and if there’s no tidying in between, wouldn’t the futures of our lives burn away, little by little, too?