What is anti-vibecoding?

Where “vibe coding” comes from

The phrase “vibe coding” was popularised by Andrej Karpathy in February 2025 to describe a way of working where you describe what you want, accept whatever the model produces and keep going without really reading the code. It caught on quickly because it named something real: for a prototype or a weekend project, you can get remarkably far that way. The Wikipedia article on vibe coding tracks how the term spread.

The trouble starts when the prototype becomes the product. A page nobody has read is a page nobody has checked, and the problems that a designer or a security reviewer would have caught on day one are still there on launch day.

What vibe-coded sites tend to get wrong

• They look like each other. Left to its defaults, a model reaches for the most common patterns it has seen: a purple gradient hero, three identical feature cards, emoji as icons and a centred layout. The result is recognisable at a glance as AI-made.
• The copy could be about anything. “Revolutionize your workflow” and “unlock your potential” fit a barbershop and a database company equally well, which means they say nothing about either.
• Security is an afterthought. Common slips include API keys in front-end code, forms that post to third-party endpoints, missing Content-Security-Policy headers and links that open new tabs without noopener.
• Accessibility is uneven. Inputs without labels, images without alt text and body text below 16px are easy to generate and easy to miss.
• Nobody owns the decisions. When each change is a fresh prompt, the reasons behind the colours, the layout and the copy aren't written down anywhere, so the next prompt quietly undoes them.

The anti-vibecode principles

Anti-vibecoding isn't a rejection of AI. It keeps the speed and puts back the checks a professional team would run. In practice that comes down to six habits:

1. Decide the design system before the first section. Pick one type family, one action colour, a spacing scale and a rule for corner radius, then hold every section to it.
2. Write about the actual subject. Real services, real prices, real opening hours and the words the business's customers use. If a sentence would fit any company, cut it.
3. Lint the output for known tells. Generic AI design has recognisable habits, so check for them the way a code linter checks for common bugs.
4. Scan the exact code that ships. Review the final HTML, not the prompt or an earlier draft, and block the release when a check fails.
5. Keep the code readable and yours. Plain HTML and CSS, or a standard framework project, that you can read, edit and host anywhere.
6. Keep short prompts and written decisions. Store the brief and the choices with the project, so the next change can be a single line instead of a new essay.

What anti-vibecoding is not

It isn't hand-coding everything, and it isn't a purity test about whether AI was involved. A site can be written almost entirely by a model and still be anti-vibecoded, as long as the output has been held to a design system, reviewed for generic patterns and checked for security problems. Equally, a hand-written site full of stock phrases and missing labels has the same problems as a vibe-coded one.

A five-minute test for any AI-built site

You can run this on your own site or on any page you're about to ship:

1. Cover the logo. Could the headline belong to a competitor, or to a business in a different industry?
2. Count the typefaces and the accent colours. More than one of each usually means nobody chose.
3. Look for emoji standing in for icons, and for a purple-to-blue gradient behind the hero.
4. Open the page source and search for key, token and sk-. Then check the response headers for a Content-Security-Policy.
5. Tab through the page with the keyboard. Every control should be reachable, visibly focused and labelled.

For the full list of design habits and what to do instead, read why so many AI websites look the same. For the security side, use the AI website security checklist.

How Anticode applies it

Anticode is built around these principles. An Architect writes the spec, a Designer locks the build to one of seven design systems, a Builder writes plain HTML and CSS, a Critic checks for nine generic design tells and Sentinel runs twelve security checks on the exact page that ships. You can read the full flow in how Anticode works.