My version of vibe coding looks like managing an engineer. A tireless one who types faster than I ever will, doesn't get offended when I reject their work, and lies to me a little, in the friendliest possible way, several times a day.
I don't write the code anymore. I haven't for a while. But I've never felt more responsible for it, and that's the part I want to write down, because the way I work doesn't match either of the camps arguing about this. One camp prompts and prays. The other camp, currently winning the discourse, says the fix is discipline up front: write a spec, write a plan, make the AI a typist executing your design. I think both camps put control in the wrong place.
A plan can guide the work. It can't prove I'm in control. Verification can.
Plans don't survive contact
Anyone who has shipped anything knows this and we all keep pretending otherwise. You plan a task, you start, and by the second day reality has amended the plan for you. A dependency doesn't do what its docs claim. The feature you thought was the hard part takes an hour, and a thing you didn't know existed eats the week. This was true before AI and an agent doesn't change it. It makes it worse, because now surprises arrive faster.
So I don't run plan mode, and I don't write specs before starting. A spec is a bet on the exact thing that always breaks: my ability to predict the path before walking it. The industry's current answer to AI chaos is spec-driven development, a bigger and more detailed version of the artifact that decays fastest.
What I do instead is deliberately lighter. I keep a list of the features the thing needs, and I pick which one to build first, usually the simplest one, the baseline the rest can stand on. That list is the entire upfront artifact. It says what I want, and it stays silent about how the path there will go, because it doesn't know and neither do I.
You could fairly call that list a one-line spec, and I'll grant the spec camp more than that: a good spec states intended behaviour and acceptance criteria rather than predicting the implementation path, and it can be revised cheaply. The difference I care about is what the artifact gets treated as when reality disagrees with it. My list loses instantly: I update it and move on, because it never made promises about the path. The failure mode I'm avoiding isn't the document, it's the commitment, and the bigger and more detailed the document, the more it invites being treated as one. Sunk cost applies to documents the same way it applies to code. The size of the upfront artifact is the size of your temptation to trust it over what's in front of you.
From there, every step gets decided from what has actually happened so far, never from what was supposed to happen. The agent and I find things out as we go, hit the weird dependency behaviour, adjust, and keep moving. I own the direction the whole way, and the route gets discovered underneath it.
A log, not a roadmap
I do write things down, but only after they become true. When a milestone is reached and tested, it goes in the record. A roadmap written before the work is a document you'll spend the project lying to; a log only records what actually happened. It can still be incomplete, and I can still misread it, but it never carries the specific poison a roadmap does: a claim about the future that reality has already contradicted.
The gate: my hands, on the app
Here's the rule that makes all of it safe enough to run: no milestone is complete until I have manually tested it. Me, clicking through the thing, not the agent telling me tests pass.
And regression is the same gate, re-run. When a new milestone lands, I go back and re-test the old ones by hand. Yes, this is slow, and I haven't automated my way around it. I re-click through things I already verified weeks ago, and it costs real time, and I pay it because it buys an honest picture of where I actually am. My whole method is steering from the current state, which only works if the current state I'm steering from is real.
One study is worth naming here. A METR controlled experiment found experienced developers using AI tools were 19% slower on real tasks while believing they'd been 20% faster. That cuts at every AI-assisted workflow, mine included, and it's why I anchor on the one thing in this loop that isn't a feeling: a bug caught at the gate is a fact. I can't tell you my sense of speed is calibrated. I can tell you what the click showed. To be fair about scope, that gate catches broken behaviour, not vulnerabilities; nobody manually clicks their way to an injection flaw.
The agent agrees with you, which is worse than being wrong
The subtler problem, and the one that took me longest to respect: the model wants to please me. Frame a question with my preferred answer showing and it leans my way. This isn't an occasional glitch, it's the default direction of error, and it means the agent's agreement is nearly worthless as evidence.
Code lies get caught by my hands at the milestone gate. Design lies are worse, because there's no test you can run on an architecture opinion. You find out months later, in production.
So for anything that matters, I attack the idea from angles the agent didn't volunteer:
- "What's wrong with this approach?"
- "Argue the case against it."
- The same question, re-asked, framed for the opposite conclusion.
- And one trick I now use on purpose: push back with an objection I know is wrong. If the model folds, its agreements mean nothing today, and anything important it approved gets re-litigated.
None of this solves the problem, and I want to be precise about that. Interrogating an agreeable model with the same agreeable model is mitigation, not independence. It raises the price of a bad design decision from "free" to "requires surviving cross-examination," which catches real garbage, and it would not catch a mistake the model and I share. For architecture calls that scare me, the honest answer is slower still: sleep on it, or get a fresh read from a model that hasn't seen my framing. That's not real independence either, just less contamination, but less contamination is what's on offer.
Working with agents daily is where I learned that "done, working, tests pass" is a mood, not a report. The agent believes it. The code sometimes agrees. The milestone gate exists because on a real product, with real users on the other end, the gap between those two is not something I'm willing to discover in production.
This is not an argument against the tooling
I should be clear about what I'm not saying, because it would be easy to read this as "keep the AI on a short leash and do everything by hand." I use the heavy machinery. Claude Code, multi-agent workflows, agent teams fanning out over a task in parallel: this is my daily setup, not something I'm warning you away from. When the work has a known shape, a fleet of agents is the right tool, and I'd be a strange person to claim otherwise while running one.
The line I hold is different: whatever I delegate, I need to know what the LLM is going to do before it does it. Which files it will touch, what kind of change it's about to make, and what happens at the edge of the plan, where the rule is simple: when it hits something neither of us predicted, it stops and asks rather than improvising. Not every keystroke, but the shape of the action. I keep an eye on the diffs as they land, and every so often I walk through the codebase itself, not because I catch everything that way, but because the mental map is what makes the next delegation safe. The moment I can't answer "what is it about to do," I've stopped supervising an engineer and started rubbing a lamp, and everything in this post falls apart, because you can't steer from the current state if you don't understand how the state got there.
So the difference between my workflow and the one I'm arguing with was never manual versus automated. I scale the doing as far as the tools allow, and I refuse to scale the not-knowing at all.
Where this leaves me
Karpathy retired his own term this year and now says "agentic engineering": agents plus oversight, aimed at production quality. I'd sign that. Where I differ from most of the writing about it is emphasis: the discourse spends its energy on the artifacts you create before the work, and I spend mine on the gate at the end. Plenty of experienced people already practice pieces of this, small increments, distrust of the model's self-reports, and I'm not claiming to have invented any of it. What I don't often see written down is the price named honestly: the plan reduced to a disposable list, and the slowness of real verification accepted in writing as the cost of the leverage.
Ask developers whether they trust AI output and many will say no. Then look at their workflows, which trust it for them, all day, on their behalf. Every slow, manual, repetitive habit I've described exists because I take my own distrust seriously enough to act on it.
What this doesn't solve
This works for me, solo, on projects where I can hold the whole surface in my head and re-test it by hand. I don't know where the ceiling is. There's a project size where manual regression stops being slow and becomes impossible, and I haven't hit it yet, which means I can't tell you what I'd do there.
I should also name the middle path I've mostly skipped past: tests written as you go, which is where a lot of experienced people live, and reasonably. My hesitation is specific to this setup: when the same agent writes the code and the tests, the tests inherit the code's blind spots, a grader marking its own exam. So I'd want them written adversarially and treated as smoke alarms rather than gates, but I haven't run that at scale, and this post's whole point is that I don't publish things I haven't tested.
I'm also not telling you to work this way. I'm telling you what "still in control, not coding" actually costs, because plenty of posts sell the control without itemising the bill. The bill:
- You go slower, on purpose.
- You re-test old work every time new work lands, and that cost grows with the project.
- You argue with a machine that agrees with you.
- Your plan is a list you expect to lose arguments to reality.
I keep paying it. The alternative is running on confidence, and confidence is the one thing the agent manufactures for free.
Next up: a walkthrough of my actual setup, the tools, the workflows, and how the agent teams are wired together. If you want that when it lands, follow me here.
Top comments (0)