December 17, 2025/848 words/4 min read

Staying Close, Moving Faster

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 me, even as AI makes everything faster. I meant every word of it. What I didn't expect was how quickly my habits would change once I started using these tools on real projects with real constraints instead of 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. I've never treated the first draft as sacred. It's entirely disposable! I make aggressive changes until I'm happy with the shape. Now I'm more comfortable letting that draft arrive fast because I'd rather spend my time revising something I can see.

Vibe coding used to sound like a shallow label people threw around. The tools can do more now, and I use the term for exploring the start of a problem before I know its shape. Simon Willison describes vibe coding as accelerated exploration while you keep full responsibility for what you ship. You still read the code and verify it before deciding what stays. When it breaks, the consequences are yours too.

Racing to "done" often buys you a week of fixing whatever mess the model made. I still move quickly early on because it lets me compare options and reach the first real decision sooner. Asking for multiple variants lets me compare the trade-offs in the running product instead of arguing with a model over the right answer in the abstract. I can explore more without handing over control.

The boundary stays simple, and I don't negotiate it with the model. Once the code becomes something I'll build on or rely on when things go sideways, I slow down. Product work already taught me not to force one pace from start to finish. I want room to try more options early, but as the work settles I care more about whether the decisions hold together.

My tools now reflect that. I don't want one environment keeping me in a constant haze of assistance because I don't work in 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 stays small enough that I can review it without reconstructing the whole project. A dependency bump or contained refactor fits easily. If I'm working on a migration, I might ask for its first pass and some rough tests. UI tweaks only go there when I already know what I want. The async part matters to me because I can keep working while it handles the mechanical steps, then come back to review with fresh eyes and a clear memory of what I asked for.

When I want to be close to the code, I use Cursor, though that's my current stop and who knows what I'll be using in six months. This is closer to the feeling I described in Part 1. I think through the code line by line, with the context loaded in my head, and the suggestions help me express what I mean faster. They surface patterns I would've rediscovered anyway and save me some boilerplate. I still have issues with suggestions drifting from my intent, but models are improving fast, and I fight the tool less often than I did even a few months ago.

Using both modes has reinforced something I argued in Part 1. Lowering the cost of starting can help the craft because I can put more ideas in front of myself before choosing one. It also gives more people a way to build. Once they have a working prototype, they can learn from the product itself instead of staying stuck between wanting to make something and making it.

I've felt this directly! When the first version costs less to make, I'm less precious about it. I can rewrite it without feeling like I wasted the original effort. Revision is also where my taste sharpens because I can see the choices instead of imagining them. 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, then accumulate confusion and tech debt. Review is how I avoid that. I need to understand where the data goes and why the code is shaped that way. Then I verify the behavior, including what happens when things fail, before I accept the design. If I skip that work, I've given up ownership myself.

So yeah, I've warmed up to vibe coding! It still feels like mine because I'm making the decisions that define it.