Atomic Vibe Coding - by Harsh Joshi - Unengineered
Unengineered
SubscribeSign in
Atomic Vibe Coding<br>There’s no good vibe coding. Or is there?
Harsh Joshi<br>Aug 04, 2026
Share
The usual explanation is that coding agents derail because models aren’t there yet. Twitter keeps prescribing waiting for the next model, bigger context, better tool use, new protocols. It really is a comfortable story because it makes it someone else’s problem.<br>What broke it for me is that the same model on the same repo on the same afternoon nailed a task phrased one way and produced AI Slop when I phrased it otherwise. And this should not be a new thing for any of you reading this. What’s new is what is going to follow.<br>In b/w those runs what changed was only my sentence(s). So I realised the bottleneck isn’t capability but It is the handoff.<br>We do carry a lot of intention and unspoken structure in our head. Template of the design doc, some personal preferences, some over time acquired habits of typing git command. What “clean” means in this particular repo , the three edge cases we would actually be annoyed about, the two files we absolutely don’t want to get touched . But then we squeeze all this in a 11 worded prompt and hit Enter.<br>11 words go in and four hundred decisions come out. To make up for the lost words we were supposed to say, something has to invent the difference, and it is the coding agent.<br>Picture a contractor who has read every renovation magazine ever printed and has never set foot in your house. You tell him to redo the kitche and he redoes a kitchen. Open shelving, subway tile, a pot filler that you didn’t even ask for. It’s competent and it’s on budget & and it is the statistical average of every kitchen on the internet. This means it is nobody’s kitchen in particular.<br>There’s research on this and this has a grim name: detrimental semantic collapse. The model locks onto one coherent reading of an ambiguous task. It generates internally consistent code that’s confidently misaligned with what you wanted.
The Atom
The actual argument in Atomic Habits isn’t “set smaller goals” but that the unit of change is the rep and not the resolution. Same idea applies with atomic vibe coding too. The feature is the goal. It was never the unit.<br>An atom is the smallest piece of work where you can define & convey the intent of in ~1 sentence and check the result in one go.<br>Both halves matter. If you can’t say it in a sentence, the model will invent the rest of the sentence for you. If you can’t check it with a command, you won’t find out that it did.
Seven Habits
1. If the prompt has an “and” in it, it’s two atoms. “Add the endpoint and wire up the UI and write tests” is three coin flips you’re resolving at once. Splitting it costs twenty seconds and saves you the ninety-minute unwind.<br>2. Name only the decisions you’d be annoyed to get wrong. Not a spec. Two or three constraints. Usually a file path, a library, and the one behaviour you care about. Anything you don’t name gets filled in with the median, and anything you over-name is context rot you paid for yourself, so this is a real trade and not a “more detail is better” situation.<br>3. Point instead of describing. “Follow the pattern in useCart.ts“ beats four sentences describing that pattern, because your codebase is a far better spec than your prompt and it’s already sitting in the context window.<br>4. Make it write the plan, and edit the plan yourself. Editing a plan is cheap. Reviewing a diff is not. Plan mode isn’t ceremony, it just moves the argument to the point where it costs three lines instead of three hundred. This is also the whole premise behind spec-driven toolkits like GitHub’s Spec Kit: specify, plan, break into small testable tasks, then implement.<br>5. End every atom on a command that can fail.<br>pytest tests/cart_test.py.<br>curl localhost:3000/api/feed | jq.<br>Load the page.<br>“Looks good” is a feeling, not a check.<br>6. Commit per atom. Not for the history, for the blast radius. A cheap undo is what lets you be genuinely reckless inside the atom, which is the fun part and the actual vibe part. Vibes are great when rollback is one command.<br>7. Kill it, don’t nurse it. When a run derails, don’t patch inside the same thread. The context that produced the wrong answer is now actively arguing for the wrong answer, and you’ll spend an hour negotiating with it. Clear the thread, rewrite the sentence using whatever you just learned, run it again. Ninety seconds.<br>What This Isn’t
I’m not telling you to write a PRD before every function. Nobody has ever shipped faster by producing documents, and if your version of this takes twenty minutes you’ve reinvented waterfall and I want no part of it.<br>An atom is a sentence and a check. Call it twenty seconds.<br>It is a real trade, though. Decomposed workflows measure slower per pass than one-shotting it. You’re giving up peak throughput in exchange for actually finishing.<br>Which, if you’re honest, is a trade you’re already making....