Recently, I ran a small experiment: I spent a day building for myself a small, self-hostable read-it-later app. As part of this experiment I intentionally wrote no code, instead relying 100% on AI to create it. I figured this project would be of significant enough scope and complexity that it would challenge what I might be able to pull of purely conversationally with an LLM, but not so novel or full of unsolved problems that it couldn’t be done. It was something I could build on my own with enough time and dedication, but I wanted to see if I could create something as good, or even better, in a fraction of the time it would have take me otherwise. The result: of course I pulled it off. In fact, it was surprisingly too easy.

After about 40 minutes of back-and-forth in Copilot using “Claude 3.7 Thinking (preview)” I had a working app using Go, SQLite, HTMX, Tailwind and, most importantly, Mozilla’s Readability library. Another couple hours brought me the full suite of features I had in mind: highlighting, search, tagging, and authentication. It’s a nice little home-grown app that could easily replace most of a service I might otherwise pay for, like Pocket or Readwise. I probably never would have made time to build this any other way. Simon Willison has said, AI tools allow us to be far “more ambitious” in our projects and, for me, this was very ambitious for a couple hours of work.

Any programmer who has experimented seriously with AI coding tools has probably already had this experience. I admit I’m kind of late to the game. But, at the end of this experiment, I have to admit something didn’t feel right. While I was astonished and happy with what I was able to produce in such a short amount of time, the end product didn’t feel like it was truly mine.

Programming is an activity, but it’s also a feeling. For those of us who actually enjoy programming, there is a deep satisfaction that comes from solving problems through well-written code, a kind of ineffable joy found in the elegant expression of a system through our favorite syntax. It is akin to the same satisfaction a craftsperson might find at the end of the day after toiling away on well-made piece of furniture, the culmination of small dopamine hits that come from sweating the details on something and getting them just right. Maybe nobody will notice those details, but it doesn’t matter. We care, we notice, we get joy from the aesthetics of the craft.

Tim O’Reilly recently proclaimed that AI tools mean the end of programming as we know it. He’s not entirely wrong, but for those who have long enjoyed the art of programming without the aid of AI, these changes threaten the end of this particular kind feeling, or at least how frequently we have the opportunity to experience it.

Sure, there will always be a need for humans to hand-write code. LLMs may allow us to tap into the accumulated knowledge of millions of other programmers, but that also means they’re not so great at helping solve truly novel problems. That said, I think we must also admit, the number of truly novel problems that the average programmer encounters on a regular basis are small. So, as programming becomes less an act of hands-on craft or in-the-weeds problem solving, and more an act akin to the art of management, the ways in which we experience satisfaction and happiness in our daily activity will also have to change.

I have to admit I’m not totally unfamiliar with the pain of this transition. Three times in my 20+ year software engineering career I have made the shift from individual contributor to manager. Each time I was forced to reckon with how this also meant I had to change the ways in which I derived satisfaction from a day’s labor. No longer could I point to a series of git commits before closing my laptop lid at the end of the day and say, “Yep, that was me. I did that!” But, at least as a manager of human beings, I soon remembered that I could always find an even deeper satisfaction on a longer time horizon: At the end of a sprint or a month or a quarter, I was able to point at something that shipped and say, “Yep, that was us. We did that.”

Working alone with AI, there is no “we.” But there also isn’t just an “I” either. This is something else, something new, and since it’s clearly the momentum of things for the entire industry—both for better and for worse—figuring out what this means for human happiness at work is going to matter.

I am no “stubborn developer” but stubborn developers exist and I sympathize with their reasons for being stubborn—beyond lamenting the ethical challenges or the climate impact of AI, there’s also simply this: the grieving of the loss of that “programming feeling.”