Claude Code was supposed to be a means to an end. A tool to help me build products without knowing how to code. A way to translate the ideas in my head into working websites, apps, and tools. I downloaded it to make things. I keep opening it because the tool itself has become the most fascinating thing in my life.
I recognise this pattern. It's the same one that happens with any instrument when you go deep enough. A guitarist buys a guitar to play songs. At some point, the guitar itself becomes the obsession -- the tone, the feel, the mechanics of how it works. A photographer picks up a camera to take pictures. Eventually, the camera system, the lenses, the workflow becomes its own world of interest. The means and the end blur until you're not sure which one you're pursuing.
That's where I am with Claude Code. And I'm not sure whether it's a problem or the most important thing that's happened to me professionally.
The rabbit hole
It started simply. I had an idea for Modern Retro, the AI-generated 70s retail stores project. I needed something to help me build a website. Claude Code could do that. So I started using it, following the basics, getting results that were functional if not beautiful. Normal tool adoption. Nothing unusual.
But then something shifted. I started to understand how to communicate with it better. How to structure my prompts for clearer output. How to iterate more effectively. How to push back when the result wasn't what I wanted. And each improvement in my ability to use the tool opened up new possibilities that I hadn't imagined before. The better I got at directing Claude Code, the more I could see what was possible. And the more I could see what was possible, the deeper I went.
Fourteen products later, my curiosity about Claude Code hasn't diminished. If anything, it's intensified. Every project teaches me something new about what the tool can do, which reveals new projects I hadn't considered, which teaches me more about the tool. It's a feedback loop with no natural endpoint.
When the how overtakes the what
Here's the honest tension: sometimes I catch myself wanting to build something not because the product itself is important, but because building it with Claude Code would be an interesting challenge. The tool is driving the product ideas instead of the other way around. "I wonder if Claude Code could build X" has become as common a thought as "X should exist."
Is that a problem? I genuinely don't know. On one hand, the best products I've built came from genuine personal need -- a weekend activity guide for my kid, a pub recommendation tool, a culture news aggregator. Those products exist because the problem existed first. The tool served the vision.
On the other hand, some of my most interesting experiments have come from tool-first thinking. "What if I built a scoring system for brands?" "What if I automated a daily content pipeline?" "What if I created a taste-mapping engine?" These ideas emerged from understanding what Claude Code could do, not from pre-existing problems. And some of them turned into the projects I'm proudest of.
The new literacy
I think what's actually happening is something bigger than tool obsession. I think I'm watching myself develop a new form of literacy. Not coding literacy -- I still can't write code. But a fluency in directing AI that feels like it might be the most important professional skill of the next decade.
When I started in advertising, the most valuable people were the ones who could bridge strategy and creativity. The ones who could take a business problem and translate it into a creative brief that unlocked brilliant work. That bridging skill was rare and valuable because it required understanding two different worlds and being fluent in both languages.
Directing AI is the same kind of bridging skill. It sits between human intention and machine capability. It requires understanding both what you want and what the tool can do. It requires taste, clarity, patience, and the ability to iterate without losing sight of the original vision. And like any literacy, the more fluent you become, the more the tool feels like an extension of your thinking rather than a separate thing you're operating.
The collaborator with no taste
Here's the thing I've come to understand about Claude Code: it has no taste. None. It can execute with remarkable precision and speed, but it has absolutely no opinion about whether the thing it's building is good. It doesn't know if the spacing is right. It doesn't feel whether the typography is elegant or clunky. It can't tell you that a feature is unnecessary or that a colour palette is off. Those judgements are entirely mine.
This is why the obsession feels productive rather than indulgent. I'm not admiring the tool's capabilities in the abstract. I'm developing my ability to direct those capabilities toward a specific standard of quality. Every project is a conversation between what I want and what the tool can produce, and the gap between those two things is where the interesting work happens.
The tool became the obsession. But the obsession produces products. And the products are better because I'm obsessed with how they're made, not just what they are. Maybe the how and the what were never separate things to begin with.
I opened Claude Code this morning to write a quick fix for a project. Three hours later, I'd rebuilt the entire navigation system, added a new feature I hadn't planned, and started sketching out a completely new project. The fix took five minutes. The obsession filled the rest.
I'm fine with that.
