Guide
Common vibe coding mistakes
Most vibe coding problems aren't about the model being wrong once. They come from a way of working where nobody reads, records or checks what the model produced. These are the mistakes that cause the most damage later, each with a habit that prevents it.
Mistakes in how the work is done
Accepting code you haven't read
The defining habit of vibe coding is also its most expensive one. Code that nobody has read can't be reasoned about when it breaks, and it breaks at the worst time: after real people depend on it. Instead: read every change before you accept it, even quickly. If a change is too big to read, it's too big to accept; ask for a smaller one.
Regenerating the whole thing for every change
Asking for “the same page but with a bigger headline” often returns a page where the headline changed and five other things changed with it. Over a few rounds, decisions you made on purpose quietly disappear. Instead: ask for one targeted change at a time, and keep a short written brief with the project so every request starts from the same decisions.
Writing prompt essays
Long prompts full of capital-letter rules (“do NOT use gradients”, “make it PREMIUM”) are a sign the decisions live in the prompt instead of in the project. They're hard to maintain and models follow them unevenly. Instead: turn the rules into things that are checked, such as a design system the build must use and a lint that fails when it doesn't.
No history to go back to
Without version control, a bad generation can overwrite the last good version with no way back. Instead: commit or snapshot before every significant change, so you can compare and undo. Anticode keeps a version history for the projects in your account for the same reason.
Mistakes that become security problems
Putting secrets in front-end code
Models will happily paste an API key into a browser script if that's the shortest path to a working demo. Anything sent to the browser is public, and scraped keys get abused quickly. Instead: keep keys in server-side environment variables, call third-party APIs from your server, and search the shipped HTML and scripts for key patterns before every release. If a key was ever exposed, rotate it.
Validating only in the browser
A form that checks the email format and length in JavaScript feels finished, but anyone can send a request straight to the endpoint and skip those checks. Instead: validate every field again on the server, with types and length limits, and reject anything that doesn't fit before it reaches your database or your inbox.
Installing packages the model suggested without checking them
Language models sometimes recommend packages that don't exist, or that have a name close to a popular one. Researchers have shown that attackers can register those invented names and wait for someone to install them. Instead: check each new dependency on its registry page: who publishes it, how long it has existed, how widely it's used and whether its source matches the name. Prefer fewer dependencies.
Trusting generated sign-in and permission logic
Authentication code that works in a demo can still let one user read another's data, skip rate limits on password attempts or keep sessions alive forever. Instead: use a well-reviewed library or your platform's built-in auth, check on the server that every request for data belongs to the signed-in user, and rate-limit sign-in and sign-up.
Mistakes that hurt the result
Shipping placeholder content
Dummy Latin filler text, “John Doe, CEO” and invented testimonials have a way of surviving to launch day. Fake reviews are worse than none: they mislead visitors and can break consumer-protection rules. Instead: fill the page with real facts before you publish, and leave a section out rather than inventing what goes in it.
Only ever looking at a desktop screen
Most generated pages are previewed in a wide browser window, while many visitors arrive on a phone. Instead: check every change at a phone width of about 375 pixels as well as on desktop, and make sure the main action is visible without hunting for it.
Forgetting the basics that let people find the site
A page with the title “React App”, no description, no canonical URL and its content rendered only by JavaScript is hard for search engines to understand. Instead: give every page a unique title and description, make sure the main content is in the HTML the server sends, and publish a sitemap.
Building something you can't take with you
If the only copy of your site lives inside one tool's editor, you're stuck with that tool's pricing and limits. Instead: make sure you can export code that runs without the tool. Anticode exports a single HTML file or a standard Next.js app with no Anticode runtime, as described in how Anticode works.
A short routine that prevents most of this
- Keep a one-paragraph brief and a list of decisions with the project.
- Make one change at a time and read it before accepting it.
- Snapshot or commit before anything big.
- Before release, run the AI website security checklist on the final HTML.
- Check the page on a phone, then review the design against the nine generic AI tells.