Staying Close, Moving Faster

December 17, 2025 · 1270 words · 6 min read

Warming up to vibe coding without giving up authorship.

A few months ago I wrote The Joy of Keeping Your Hands on the Tools, a reflection on why the slow and deliberate parts of coding still matter to a lot, me even as AI makes everything faster. I meant every word of it, but what I didn't expect was how quickly the follow-through would change once I actually started using these tools on real projects with real constraints, instead of just thinking about them from the outside.

I still like being close to the work. I like knowing how a decision ends up in the code, not just that it passed tests and stopped the linter from yelling. What changed is how quickly I let myself get something on the screen. Personally, I've never treated the first draft as sacred, it's in fact entirely disposable! I like to make aggressive changes until I'm happy with the shape. But I'm also just more comfortable now letting that first draft arrive fast so I can spend my time where the craft actually shows up, in revision, structure, and all the choices you make once you can see the thing.

Vibe coding used to feel like a vibe in the shallow sense, a label people threw around with no meaning behind it, but it has genuinely matured since then, and the tools have matured with it. Now it reads to me like a mode, a way to move through the fog at the start of a problem, when you don't quite know the right shape, and the only move is to touch it first and see what it turns into. The framing that made this click for me (Simon Willison has argued it well) treats vibe coding as accelerated exploration while you keep full responsibility for what you ship. You still read the code, still verify it, still decide what stays. You also still own the consequences when it breaks.

The thing I had to learn was that speed is not one single thing. There's speed that is shallow and impatient, the speed that gets you to "done" while making it almost certain you'll spend the next week fixing the mess the model inevitably makes of the work you give it. And then there's speed that is exploratory, where you move quickly to see more of the space, compare more options, and reach the first real decision sooner. That second kind is where I've landed, I really like using velocity as sort of a flashlight very early on, especially when I can ask for multiple variants and feel the trade-offs in my hands instead of arguing with a model over the right answer in the abstract. It feels more like scouting the terrain while you still hold your hands on the wheel, compared to the feeling of giving control entirely.

The boundary also stays simple, and the trick for me is to not negotiate it with the model. As soon as the code starts to matter, when it becomes something I'll build on, or rely on when things go sideways, I slow down and take the wheel. The work has a specific cadence to it, and I've learned to respect that and move with it, instead of tring to force one tempo from start to finish. Just like product work, early stages need range and movement, while later work needs coherence and restraint, they are different instincts and they want different tools.

My tooling has started to reflect that rhythm, and it has made my stack feel surprisingly sane. I don't want one environment that keeps me in a constant haze of assistance, because my work is not one continuous mode.

When I want quick changes done asynchronously, I use Claude Code on the web, it's great for "go do this and show me what you did" work, where my job is to set intent and constraints, then review the diff like an adult. The scope is rarely more than dependency bumps or small refactors, maybe a rough pass at tests, the first attempt at a migration, a set of UI tweaks I already know I want. That async aspect matters more than people think! It lets me keep momentum without pretending I have to be present for every mechanical step, and it creates a natural pause that makes review sharper because I come back with fresh eyes and a clear sense of what I actually asked for.

And when I want to be close to the code, I use Cursor, though that's simply my current stop and who knows what I'll be using in six months. This is where I get the feeling from Part 1, where the code is not just output but a way of thinking line by line, choice by choice, with assistance that stays in the passenger seat and doesn't get to step out. To me this feels practical immediately because I'm in the editor with context loaded in my head, and the suggestions help me express what I mean faster. I can spot patterns I would've rediscovered anyway, and I keep my attention on the hard parts instead wasting time with syntax and boilerplate. I still have issues with suggestions drifting from my intent, but models are improving fast, and I notice myself fighting the tool less often than I did even a few months ago.

This split between async delegation and hands-on editing has also changed how I think about where all of this is going. Lowering the cost of starting is not a threat to craft, I said that in Part 1 and I believe it even more now. What it actually does is multiply experimentation, and experimentation is how you get better ideas, better systems, and better taste. It also changes who gets to build, which matters a lot. More people can get a working prototype in front of themselves, which means more people can iterate, learn, and develop good taste for a product through contact with reality instead of getting stuck in the forever gap between wanting to make something and actually making it.

There's a gift here for people who already care about quality, because when generation is cheap, the first version stops feeling precious, and in turn that makes it significantly easier to rewrite, simplify, and throw things away, which is what good building looks like most of the time. Cheap drafts increase revision, and revision is where taste actually sharpens. You see the shape, you cut what doesn't belong, you notice what repeats, you learn what you keep choosing, and you start choosing better. I've felt this directly! I prototype faster, which means I also delete faster, and the stuff that survives is better because of it.

The failure mode is real though! Some people will accept whatever comes out and call it building, and they'll accumulate confusion and tech debt, but the counterweight is also real, and it's available to anyone who wants it. Review becomes the act of ownership. Reading with intent, verifying behavior, tracing data flow, understanding error cases, choosing a design on purpose instead of inheriting it by default. The tools don't take that away from you, failure happens when you give it up yourself.

So yeah, I'm not warming up to vibe coding anymore. I've warmed up! I let the first pass be fast, I slow down for the parts that define the system, and the work still feels like mine, which is by far the most critical factor to me. The tools move faster now, and that just means I get to spend more of my limited time on the decisions that matter.