The Joy of Keeping Your Hands on the Tools

September 1, 2025 · 1946 words · 10 min read

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

A few weeks ago I rebuilt the search on this site. Nothing fancy, just a small component that filters posts by title and tags. The kind of 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. 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. Not frustrated, not impressed, just empty. Like I'd ordered a meal instead of cooking one. The food was fine, I just wasn't hungry anymore.

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. The kind of thing Claude would have avoided entirely. Then I 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. A bit more verbose, a few patterns I'd clean up if I had another hour. But I understood every line. I'd made every decision. I knew exactly why the debounce worked the way it did, because I'd gotten it wrong first. When I finished, I felt that familiar click, the one where the thing in your head and the thing on the screen finally match. That's the feeling I'm trying to protect.

I want to be clear about something, because humility matters to me when I talk about craft. I'm not a programmer and 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 code editor. 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. Side projects, this site, small tools that scratch an itch. I mention this because I don't want to pretend I'm defending some professional territory. I'm 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, at work and at home. 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 genuinely 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 altogether. 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 kind of flow that used to be buried behind syntax errors and frustrating documentation. You can get something on the screen fast, keep momentum, and 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 genuinely 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. Not a big thing, 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. And the loop closed again without my brain ever doing the hard part.

That's 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 appears, and 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 stop rehearsing the reasoning that lets me change the design later without fear. The risk isn't that the code is wrong. The risk is that it's right for reasons I never had to understand. I think about this in terms of scaffolding. When you write code by hand, even badly, you're building a mental scaffold. You notice what you don't know. You build a model in your head, then confirm that model by making the machine obey it. When a bug shows up, you can trace it 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 the next change possible. It's what lets you debug under pressure instead of just regenerating and hoping.

Vibe coding skips the scaffold. 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 kind of thing you ship fast because the customer needs it yesterday. In that world, nothing mystical happens when you type every line yourself. If an AI can produce something solid and save a team a week of slog, that's 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 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. It would be perfectly rational to spend it vibe coding, to get more done in less time, to make the most of the margins. Sometimes I do exactly that, and it's fine.

But other nights I choose the slow path. I'll pick a small problem and just sit with it. Write the function, run it, watch it fail, think about why, try again. The house is quiet, the missus is reading, and I'm tightening a loop or chasing down an edge case I missed on the first pass. The output is secondary. 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 here 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. Honestly, nothing could. 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 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 thing to work. I'll ask Claude to write it, review the output, ship it, and go to bed. That's fine. I'm not precious about it. Other nights I want the process. I want to feel the code forming under my fingers, want to sit with the confusion for a bit before the 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 like this. AI handles the boring parts beautifully. Boilerplate, scaffolding, repetitive patterns, things where the value is in having them done rather than in 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. That's not laziness, that's just good defaults.

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, honestly. 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! But it's not the same thing.

I realise that's a luxury. I 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 genuine 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 honestly makes that slower, more intentional space feel even more vital. Some parts of the craft are worth holding onto, even as everything else accelerates.