Anti-Vibe-Coding: What Breaks When a Website Is Assembled in One Evening by AI
Assembling a website in one evening by describing what you want to a model is now genuinely possible. The result looks respectable, opens in a browser and even has a contact form. The temptation is understandable: why pay an agency when this works.
The problem is that “works” in a demo and “works” in a business are different things. Below is what actually breaks, and how to tell whether such a site can be left in production.
What generation genuinely does well
It would be dishonest to skip the obvious. Code generation covers these well:
- A prototype to show an idea and test a hypothesis.
- A single-page landing for a one-off campaign.
- Standard markup from a design when the structure is already worked out.
- Routine work: table markup, forms, repeating blocks.
- Explaining unfamiliar code and locating a bug in a specific place.
That is a real saving in hours. The only question is where the zone ends in which skipping review costs nothing.
What breaks
| Area | Typical problem | When you find out |
|---|---|---|
| Security | A form with no validation and no request forgery protection | After the first spam wave from your domain |
| Accessibility | No alt text, no focus order, poor contrast | On a complaint or an audit |
| Performance | Three megabyte images, unnecessary libraries | A month later in Search Console |
| SEO | Empty titles, duplicates, no heading structure | When the traffic never arrives |
| Data | Enquiries go to email and are stored nowhere | When you need the enquiry history |
| Maintenance | Nobody understands how the code is organised | On the very first change request |
Security: the main gap
A model generates what it was asked for. Protection is usually not asked for, so it is not there.
The most frequent omissions: a form with no anti-forgery token, no rate limiting on submissions, form data passed into a database query without escaping, keys and passwords sitting in the code, file uploads with no type checking.
Every one of these has been solved for years by standard framework features. Code generated from scratch simply does not include them, because nobody asked.
The problem noticed later than the rest
A site assembled in an evening usually lacks what makes code maintainable: a consistent structure, reusable components, clear naming, comments where things get complex.
While nothing changes, none of this matters. But the first task like “add a second language” or “change the form on every page” runs into identical code copied into twelve places with small variations. It has to be fixed in twelve, and three will be forgotten.
The comparison in plain terms:
| Task | Structured project | Generated in an evening |
|---|---|---|
| Change the button colour | One line | Search across the whole project |
| Add a language | Built-in mechanism | Copy every page |
| Find the cause of a bug | Follow the structure | Read everything |
| Hand over to another developer | A day to get oriented | Often faster to rewrite |
Where the sensible line runs
The question is not whether to use generation. The question is who reviews the result.
A practical rule: generation is safe where a mistake is immediately visible and cheap. Markup for a block is visible on screen. Payment handling, personal data, authentication – there the mistake is invisible and expensive.
A second rule: the longer the site must live, the more the structure matters. A two-week landing page can be assembled any way at all. A corporate site that will be developed for three years cannot.
A checklist for a generated site
Before putting it into production, check at least this:
- Try submitting the form twenty times in a row. Is there any limit?
- Search the code for passwords, API keys, database credentials. They belong outside the code.
- Check whether enquiries are stored anywhere besides email.
- Open the site on a phone over a slow connection.
- Tab through the page: is focus visible, is every button reachable?
- View the page source: is there a title, a description, exactly one h1?
- Check image sizes. Anything over 300 kilobytes per photo needs rework.
- Ask yourself whether another person could make a change to this in six months.
What to do about it
The sensible approach is not to ban generation but to put it in its place as a tool. The model writes a draft; a person owns the architecture, the security and the question of whether this can be lived with afterwards.
A site assembled in an evening is not a bad site. It is a draft that was never finished into a product. The difference becomes visible not on launch day but in month three, when the first real change request arrives.
