I recently turned 23 years old. If you had sampled how I chose to spend my time at any point in the last decade, you would have found me working on a side project. Spurred on by my lifelong fascination with computers, I have always spent my free time exploring, learning, and building.

Recently, I completed my thesis and started a graduate job. While I had worked near full-time during parts of university, this has been my first role in industry proper and has placed a correspondingly great demand on my time. For the first time in my life, I have been struggling to make time for my side projects.

This change in my life has coincided with the popularisation of LLM-powered code generation tools such as Claude Code and OpenCode. Colleagues and influencers alike began to evangelise these tools, recounting magical “vibe-coding” experiences and claiming not to have written a single line of code in n days. While initially I was sceptical, the pressure on my time made the promise hard to ignore, and I eventually relented.

I began by pointing OpenCode at a relatively simple project I was a few weeks into developing. It was a straightforward full-stack web application with CRUD functionality, trivial for most programmers. Sure enough, it worked pretty well. I would ask it to do something, it would do it, I would review it, and then I’d ship it. As I grew more accustomed to these tools, my productivity surged. All the things I wanted done were happening.

Before long, this loop became the norm: prompt, review, deploy. Quickly, I noticed that I was growing lazier and not correcting mistakes when reviewing the code. So why review it in the first place? Without reviewing code, I could develop more quickly! Prompt, deploy, prompt, deploy, prompt, deploy. At this point, I was using it on some of my more challenging projects. Once again, features were getting shipped faster than ever before. Then, I discovered I could get LLMs to select the next feature to implement, reducing my role in development to that of a spectator.

This swell of productivity continued for the next two months before I began to notice something about a fortnight ago — I couldn’t bring myself to open my laptop and work on these projects. While I may have struggled for time in the past, a lack of motivation was a novel experience. Regardless of this, I pushed through, continuing to develop my software. Then the tiredness set in. A familiar feeling, though one I had never associated with my hobbies: burnout.

I was sitting in this state when I read an excellent post on Bryan Cantrill’s blog: The peril of laziness lost. In this post, Cantrill states:

Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters.

While the author is likely referring to simplicity when he says “at the cost of everything that matters”, this line prompted a deeper reflection. The most palpable feeling was that this new productivity had come at the cost of joy. When you delegate your hobby to an unfeeling machine, the art is lost. Previously, I would select the next feature or function to implement, guided solely by my motivation. This led to projects with character and ensured they followed a path that entertained me. When implementing a feature becomes a monotonous prompt, all features become equally uninteresting to work on. I began to change my criteria for the next feature from personal interest to commercial value. Fundamentally, this shift in how I produced code began to alter the direction of my projects.

Another thought that Cantrill’s essay surfaced was that I have been deprived of learning. I had likely committed more lines of code in the last two months than the six before that, and yet, it wouldn’t be an exaggeration to say that I hadn’t learnt a thing. It is apparent to me that the friction you feel when programming is what teaches you the craft. For example, it was only after spending months building Kubernetes controllers that the elegance of Kubernetes’ reconciliation loop model revealed itself to me. Such convictions are formed through hours of deep thought and the resistance that an improperly designed system inflicts on you. Without this resistance, you cannot develop the scar tissue or the taste required to improve. Rather, through prompting and delegating, they effectively become a middle manager.

Realising this, I have decided to enact an “agentic” ban on my personal projects: no coding agents, no editor integrations, and no use of LLMs beyond the occasional role of an improved Google or boilerplate generation. I would rather produce less and understand it fully than go on producing work in which I can no longer find myself.