Vibe Coding Best Practices: 6 Rules From 7 One-Day Builds

Seven of our published articles are builds: we handed a real coding job to an AI and ran what came back. Five of the seven were wrong or broken on the first pass, and not one got fixed by a better model. The two a briefing did fix were missing information, not phrasing. That's why the vibe coding best practices I actually believe in have almost nothing to do with wording.

This is for anyone who has shipped one AI-built thing and is about to ship a second. Six rules, each attached to an article on this site you can go read, failures included. The honest catch: the two builds that worked first time still fell over, on a login screen and a credit wall.

Where these vibe coding best practices come from

They come from counting our own archive instead of guessing. As I write this in August 2026, this site has 42 published experiments, and seven of them meet a narrow definition of a build: we gave a coding job to an AI and ran the result ourselves. That leaves out the piece where I measured 15 skill files, the one where I audited ten AI-tool sites, and the site I deliberately built by hand. Two of the six rules still come from that left-out set, because the same mistake showed up there without a build attached.

Seven builds is not a lot.

It's seven more than most best-practices lists are written from, and here's where each one first went sideways.

Rule 1: Name the destination before you ask for the feature

Say where the data has to end up in the same breath as what you want built. Twice now I've asked for a form and gotten one that looked finished and went nowhere. In my one-day landing page build the signup form pointed at a placeholder address that answered with a plain HTTP 404, and the fix I asked for next wrote every email to a file on a serverless filesystem that's read-only in production. In the three-route website test the contact form submitted into the void for the same reason.

Both times the agent wrote precisely what I asked for. I just hadn't asked the second question yet. My brief now names the destination before the word "form" appears.

Rule 2: Write the checks before the model runs, and make the test data ugly

Decide what a correct answer looks like before you start, and keep that file where the model can't read it. For the Fable 5 test I handed Claude Sonnet 5 a deliberately horrible invoice CSV: a byte order mark, five date formats, four amount formats, a duplicate line and an empty amount cell, none of it mentioned in the briefing. Nine checks, written first, stored outside the working directory. It passed 9 of 9 on the first attempt.

That score means something only because the checks existed before the output did. A checklist written afterwards is a description, not a test. The same discipline made a colleague's tip-split calculator worth writing up: the finding wasn't the screen, it was that setting the split to zero people returned a readable error instead of an infinity sign, and you only learn that by feeding it the ugly input on purpose.

Rule 3: Be more afraid of the silent pass than the crash

A crash tells you where to look. A confident wrong answer doesn't. In our data-analysis chain a naive pipeline over 457 rows of our own keyword export answered the question and was off by a factor of 205, partly because the language the agent reached for treats a blank cell as zero and sorts numbers as if they were words. In our MCP migration a tool call came back with HTTP 200 and the refusal buried in the response body. And Vercel's one writable folder gets wiped between requests, so moving that signup file there would have meant green light, no data.

Rule 4: Price the second change, not the first build

The AI advantage is biggest on the first version and shrinks on every edit after it. On one small-business brief, I recolored a button and warmed a hero background by hand: a 2-line diff, readable in five seconds. AI builders are documented to regenerate the whole file for that same request. That's why our AI versus hand-built test ended in a near tie instead of the landslide everyone predicts.

The bill follows the same curve. Our July 2026 comparison of Lovable and Bolt found their meters pointing in opposite directions: Lovable charges by how hard your request is, Bolt by how much of your project it has to read. Both paid plans are $25 a month. Only one gets more expensive while you sit still.

Rule 5: Read the meter before you fall for the tool

Check what a tool costs and what it demands from you before you check whether it's any good. Seven more builds we planned never started, each at an account, a login, or a credit balance. Claude Fable 5 asked for pay-as-you-go usage credits before producing a single token on a Pro plan, so my head-to-head became a piece about the wall. v0 and Lovable put a signup in front of the build in that same app contest, so only one contestant got measured. Lovable a second time alongside Bolt, a Gumloop agent and an automated CRM went the same way.

That's the billing model doing its job, not a fault in it. It decides your afternoon more often than model quality does. Fair enough. It's also the thing no best-practices list mentions.

Rule 6: Anything you have typed three times belongs in a file

Move repeated instructions out of the chat window and into your project once you have pasted them a third time. I counted 15 SKILL.md files in a working Claude Code setup: 49,214 characters of instructions, of which only 9,321 sit in the context window when a session opens. That's 18.9%, with the other 81% loading on demand. Anthropic's own skills documentation says to create one "when you keep pasting the same instructions, checklist, or multi-step procedure into chat," and that a skill's body loads only when it's used.

The catch is that the file has to be findable. In the 15 files I measured, 14 of 15 descriptions quote phrasings a person would actually type, because a description that summarizes the feature never fires when you word your request differently.

Isn't this just normal engineering with extra steps?

Mostly yes, and that's the uncomfortable part. Every rule above would have been unremarkable advice ten years ago. What changed is how fast you reach the moment where they matter: a working first version arrives in an afternoon rather than a week, so the gap between "it renders" and "it's correct" opens earlier and wider.

A colleague quit a price audit 13 suppliers into a list of 35 and wrote up what AI still can't do in a day. His line wasn't difficulty. It was whether you can verify the result yourself before the day ends. Vibe coding made the making faster and did nothing for the checking. All six rules above are about that gap.

Would I hand my past self this list?

Yes, and I'd lead with rules 1 and 3, because those two account for the days I actually lost. What still gets me on a reread is what's absent from all seven: nowhere did the answer turn out to be a stronger model. On the messy CSV job the cheap one already scored full marks.

Good enough ships, and these six rules are mostly about being able to tell when it has. So, my question back: which thing you built with AI has never once been handed an ugly input?