The Joy of Keeping Your Hands on the Tools

September 1, 2025 · 2023 words · 10 min read

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. Nothing fancy at all, it's just 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 opened Claude, described what I wanted, and had working code in about ten minutes. It was good code, too! Clean, readable, handled edge cases I hadn't thought of yet. I dropped it into the project, tested it, and 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! Just empty. Like I'd ordered a meal instead of cooking one. Sure, the food was fine, I wasn't hungry anymore, but I hadn't had any fun making it, nor had I learned anything.

So I deleted it and wrote it myself, took me the better part of two hours. The first hour I got the basic filtering working but the debounce logic was wrong, then I spent forty minutes more chasing a re-render bug that turned out to be a stale closure. It's just the thing that Claude would have avoided entirely. Then I also spent a few more minutes to clean it up, added the tag matching, and finally got the whole thing feeling right. The result is probably worse than what Claude gave me. It's a bit more verbose, with 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 exactly why the debounce worked the way it did, because I'd gotten it wrong first. When I finished, I also felt that familiar click, the one where the thing in your head and the thing on the screen match and you're in sync. And that is exactly the feeling I'm trying to protect.

I also need to be clear about something, because humility matters to me when I talk about craft. If it's not already obvious, 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 definitely grew out of loving the engineering mindset, but I just don't live inside it full time. So when I write code, it's always for me. Mostly side projects, like this site, or small tools that scratch an itch. I mention this because I don't want to pretend I'm defending some professional territory, I am defending something more personal than that.

I'm fully on board with AI, let me just say that now so the rest of this doesn't read like a complaint. I use Claude daily, it helps me think through product problems, draft documents, 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.

But there's a difference between using AI to think better and using AI to skip thinking entirely. That difference is where this whole post lives, and it's one I'm still working out in real time.

Vibe coding has taken over the conversation in my circles in a way that's impossible to ignore. Everyone's doing it, everyone's excited about it, and honestly they should be! For a lot of people it unlocks a flow that used to be buried behind syntax errors and frustrating documentation. You can get something on the screen fast, keep your momentum, and just skip a lot of the mechanical friction that used to make programming feel like a locked door. I see the appeal. I've felt it myself.

The first few times I tried it properly, it was super exciting. You describe what you want in plain language, the model gives you something that runs, you adjust, you iterate. The feedback loop is incredibly tight. 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.

But then I tried to change something, just a small adjustment to how the chart handled empty states, and I realised I didn't know how the component worked. I could read it, sure, I could 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. So I went back to Claude and asked it to make the change for me. And it did and it worked! So the loop closed again without my brain ever doing the hard part.

But that's exactly the thing that bothers me. When code works too easily, it's tempting to accept it as a finished thought. The tests pass, the UI renders, then the loop closes before your brain has done the work that normally happens in the gap 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. I also stop rehearsing the reasoning that lets me change the design later without fear. The risk isn't that the code is wrong, but rather that it's right for reasons I never had to understand. I like to think about this in terms of scaffolding. When you write code by hand, even badly, you're still building a mental scaffold. You can then notice what you don't know, and you build a model in your head, then confirm that model. When a bug shows up, you can trace it easily because you remember the decisions that led to it. That scaffolding is what turns "I got it to work" into "I know what this does". It's what makes iteration possible and what lets you debug under pressure instead of just regenerating and hoping for a small miracle. AI is not there yet, and maybe it never will be.

Right now, vibe coding skips the scaffold entirely, that's the whole point of it, and for a lot of contexts that's the right trade-off! Most code written in production is business logic, API glue, integration scaffolding, the thing you have to ship fast because the customer needs it yesterday. In that world, nothing important really happens when you type every line yourself, so if an AI can produce something solid and save a team a week of slog, that's good progress! Speed is the job, and chasing it makes total sense.

The space I care about lives before all of that. It's the slower, quieter mental place where coding is a way of thinking instead of a way of hitting a deadline. After a full day of product work, meetings, roadmaps, all of it, I sit down at the computer and I have maybe an hour, maybe two if I'm lucky. That time is precious to me and I am guarding it ruthlessly! It would be perfectly rational to spend it vibe coding, I'd get more done in less time and make the most of the margins. Sometimes I do exactly that.

But other nights I choose the slow path. I'll pick a small problem and just sit with it. I start to write the function, run it, watch it fail, think about why, try again. The house is quiet, the missus is reading, the cats are sleeping, and I'm tightening a loop or chasing down an edge case I missed on the first pass. The output is secondary to me. The feeling of my brain working through a problem, actually engaging with it instead of reviewing someone else's solution (even if that someone is an AI), that's the thing I'm there for. That's the joy. It's the same reason people cook from scratch when takeaway exists, or keep a journal when they could just think. The process is the point.

AI doesn't threaten that joy. To me, nothing really could, because you can't automate the feeling of understanding something you built. What AI does is make it very, very easy to skip past it, and when you're tired and busy and the hour is short, skipping is very tempting. That's the real tension I keep circling back to. The tools are so good now that choosing the slow path requires actual discipline, and I don't always have it. Some nights the discipline wins and some nights it doesn't, and I've stopped beating myself up about the nights it doesn't.

Some nights I just want the damn thing to work. I'll ask Claude to write it, review the output, ship it, then go to bed. That's fine, I'm not precious about it. But other nights I want the process, I want to feel the code forming under my fingers, and I want to sit with the confusion for a bit before the spark of clarity arrives. Both modes are real and both are me, and I don't think I need to pick one.

What I've settled into, at least for now, is something of a compromise. AI handles the boring parts beautifully, it eats through boilerplate, scaffolding, repetitive patterns, things where the value is in having them done rather than me doing them. That's where the speed matters and where I'm happy to take it. When I'm setting up a new project and need the config files, the folder structure, the basic wiring, I'll let Claude do it in thirty seconds rather than spending twenty minutes on something I've done fifty times before.

But the interesting parts, the architecture decisions, the core logic, the bits where I'm actually learning something, those I want to keep. I want to feel the friction, I want the bugs, I want the slow satisfaction of making it work myself. Even the frustration is part of it! The moment right before something clicks, when you've been staring at the same function for ten minutes and you can feel the answer forming but it hasn't arrived yet, that's a feeling AI can't give you. It just gives you the answer. Which is useful, sure! But it's not the same thing.

I realise that's a luxury. I only have the option of choosing the slow path because I code for myself, not for a team 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. The landscape is wide enough for all of it. People who race, people who wander, people who take their time sharpening a thought before they write a single line.

I'm glad the barriers are lower. I'm glad people who never touched code before are building things they feel proud of. I'm glad AI is as good as it is, and I expect it'll only get better. My position has shifted a lot over the past year, from scepticism to actual excitement, and I don't think that shift is done yet. If you'd shown me this essay twelve months ago I probably would have argued with myself about it.

But I'll keep wandering at my own pace. The tools will keep evolving, the workflows will keep bending toward whatever feels effortless, and the conversation will keep chasing the fastest path forward. Somewhere off to the side, there'll still be people like me, tapping away at something they could have generated in ten minutes, choosing the long way around because that's where the thinking happens. The rise of all this velocity makes that slower, more intentional space feel even more vital for the love of the craft. Some parts are worth holding onto, even as everything else accelerates.