September 1, 2025/1416 words/7 min read

The Joy of Keeping Your Hands on the Tools

AI made me faster and I'm still figuring out what I lost in that trade.

A few weeks ago I built a search feature on this site. It was nothing fancy, only a small component that filters posts by title and tags. It's the type of routine thing that takes an hour in the evening if you know what you're doing, maybe two if you're me.

I told Claude what I wanted. About ten minutes later, I had working code. It was good code, too! It was readable and even handled edge cases I hadn't thought of yet. I dropped it into the project and tested it. It worked fine. The whole thing took less time than it would have taken me to set up the file structure by hand. Then I sat there for a bit, looking at this component that worked perfectly, and I felt nothing! It was like I'd ordered a meal instead of cooking one. Sure, the food was fine and I wasn't hungry anymore, but I hadn't had any fun making it or learned anything.

So I deleted it. Writing it myself took the better part of two hours. I got the basic filtering working in the first hour, but the debounce logic was wrong. Then I spent another forty minutes chasing a re-render bug that turned out to be a stale closure, exactly the kind of thing Claude would have avoided entirely. After a few more minutes cleaning it up and adding the tag matching, the whole thing finally felt right.

The result is probably worse than what Claude gave me. It's more verbose and has a few patterns I'd clean up if I had another hour. But I understood every line! I'd made every decision, and I knew why the debounce worked because I'd got it wrong first. When I finished, I felt that familiar click where the thing in your head and the thing on the screen match and you're in sync. That's the feeling I'm trying to protect.

I'm not a programmer! I've never claimed that title. I work as a product manager, and my days revolve around shaping products and making space for engineering rather than being the person inside the IDE. My career grew out of loving the engineering mindset, but I don't live inside it full time. When I write code, it's always for me. Mostly side projects like this site, or small tools that scratch an itch. My interest in this is personal.

I use Claude daily and I'm fully on board with AI. It helps me think through product problems and draft documents. I also use it to explore ideas I wouldn't have reached on my own. When I'm stuck on a coding pattern, I'll ask it to explain what I'm looking at, and the explanation is usually better than anything I'd find on Stack Overflow. It's made me faster at almost everything, and I firmly believe it's one of the most important tools I've ever picked up.

I'm still working out how much thinking I'm willing to let AI skip for me.

Vibe coding has taken over the conversation in my circles, and honestly I understand the excitement! For a lot of people, it gets something on the screen before syntax errors or frustrating documentation kill their momentum. It removes the mechanical friction that made programming feel like a locked door. I've felt the appeal myself.

The first few times I tried it properly, it was super exciting. You describe what you want in plain language and the model gives you something that runs. From there, you can keep adjusting it without leaving the conversation. I built a small data visualisation prototype in an afternoon that would have taken me a week. I showed the missus and she was impressed, which almost never happens with my side projects.

Then I tried to make a small change to how the chart handled empty states and realised I didn't know how the component worked. I could read it, sure, and follow the logic if I squinted. But I hadn't built the mental model that comes from writing it yourself. I didn't know why it was structured that way, which meant I didn't know what would break if I restructured it. I went back to Claude and asked it to make the change. Claude did it and the change worked, so the loop closed again without my brain ever doing the hard part.

When code works too easily, it's tempting to accept it as a finished thought. The tests pass and the UI renders before your brain has done the work that normally happens between "idea" and "implementation". My internal engine goes quiet. I stop tightening my assumptions against reality because the tool has already produced a plausible answer, and I don't rehearse the reasoning that would let me change the design later without fear. The code can be right for reasons I never had to understand.

Writing code by hand, even badly, builds the mental scaffold I missed in that chart component. Getting it wrong forces me to notice what I don't know and remember the decisions that led there. When a bug shows up later, I can trace it instead of regenerating the code and hoping for a small miracle. Vibe coding doesn't build that scaffold yet, and maybe it never will.

For a lot of work, that's the right trade-off! A customer might need new business logic yesterday. The rest of the job could be getting two APIs to talk to each other, with all the scaffolding an integration needs. Nothing important happens when you type every line yourself in that world. If an AI can produce something solid and save a team a week of slog, that's good progress.

I'm glad people who never touched code before are building things they feel proud of. My own position has shifted from scepticism to actual excitement over the past year. If you'd shown me this essay twelve months ago, I probably would have argued with myself about it.

My own coding usually happens after work. After a full day of product work, much of it spent in meetings or staring at roadmaps, I sit down at the computer and have maybe an hour, maybe two if I'm lucky. That time is precious to me and I guard it ruthlessly! Vibe coding would be perfectly rational because I'd get more done in the margins. Sometimes I do exactly that.

Other nights I choose the slow path. I'll pick a small problem and sit with it. I write the function and run it. When it fails, I think about why before trying again. The house is quiet. The missus is reading and the cats are asleep while I'm tightening a loop or chasing down an edge case I missed on the first pass. The output is secondary. I sat down because I wanted to feel my brain work through the problem. Reviewing someone else's solution, even if that someone is an AI, doesn't give me that. The process is the point.

AI makes that joy very, very easy to skip, especially when I'm tired and the hour is short. The tools are good enough that choosing the slow path now takes discipline, and I don't always have it. I've stopped beating myself up about that.

My compromise is to give AI the work where the value is in having it done. When I start a new project, I let Claude handle the folders and config. Thirty seconds beats spending twenty minutes on a setup I've built fifty times before.

I keep the decisions that teach me something, which usually means the architecture and the core logic. I want the friction, bugs included. There's a moment when you've stared at the same function for ten minutes and can feel the answer forming, but it hasn't arrived yet. Claude's immediate answer is useful, but on evenings when understanding is the point, I'd rather spend the ten minutes.

I realise that's a luxury. I can choose the slow path because I code for myself and nobody is waiting on a deliverable. Someone shipping production code on a deadline doesn't have the same freedom, and I'd never tell them they're doing it wrong.

Some nights I want the damn thing to work, and Claude gets me to bed sooner. I still review the output before I ship it. I save the slow path for evenings when I want to understand the code, because then the confusion is part of what I came for.