Earlier this week, John Willshire posted on LinkedIn about Claude Code and the sudden proliferation of niche tools people are building with it. He wondered whether this “personal software”—quick, bespoke tools built to solve a very specific problem for a single person or team—might eventually develop into something scalable. Someone else replied that perhaps scaling isn’t the point. If the cost of building software has collapsed, tools no longer need to justify themselves as products. They can exist just because someone finds them useful, interesting, or entertaining to make.

I felt ambivalent about this. I’ve experienced the upside being described. Several of my clients have used AI coding agents to build tools to solve specific internal problems, the kind of lightweight utilities that would never have justified a formal development project before. I’ve done it myself, and had fun doing so. It’s what Paul Ford described in his recent New York Times op-ed as the “billions of software products that don’t exist but should.”

But I also had to admit something slightly uncomfortable: since I started using Claude Code, I’ve spent a non-trivial amount of time building things that were, in hindsight, fairly marginal. They may have been interesting to experiment with, but not always worth the hours. Perhaps if I had been making for the sake of making, it would be different, but the development effort was largely trying to address jobs-to-be-done.

That experience has made me increasingly conscious of a question behind the hype: not whether we can build more things, but whether we should. The real question is whether AI is helping us accelerate the right tasks—or just making the wrong ones cheaper to indulge.

After thinking about this for a few days, I read a piece this evening by Rich Ziade in the Aboard newsletter that came at the same issue from a different angle. He wrote about how organisations respond to disruptive technologies: Kodak, Blockbuster, BlackBerry, the usual Innovator’s Dilemma roll-call. He framed this through the idea of “procedural debt”: the way companies become so good at executing the activities that built their success that they can no longer imagine doing anything fundamentally different. When a new technology arrives, the instinct is to apply it to the existing professional frame of reference. Efficiency improves. The underlying structure doesn’t change. But perhaps it should. His conclusion was pithier than mine: don’t use AI to do shitty things faster.

I wonder if individuals can accumulate procedural debt too—not in processes exactly, but in habits of attention, patterns of what feels like productive work. The tools make building feel like progress. The feedback loop is satisfying. But making something and solving the right problem aren’t the same thing, and it’s surprisingly easy to lose track of that when the friction of making has collapsed so dramatically. Historically, that friction filtered out a lot of bad ideas. Projects had to justify themselves because they required real time, money and coordination. As those barriers fall away, the scarce resource becomes judgement. I don’t think I’ve always found the right answer to that. But I think it’s the right question to keep asking.