{"id":8014,"date":"2026-08-01T01:00:57","date_gmt":"2026-08-01T01:00:57","guid":{"rendered":"https:\/\/dextora.agency\/insights\/anti-vibe-coding-what-breaks-ai-generated-sites\/"},"modified":"2026-08-01T08:35:58","modified_gmt":"2026-08-01T08:35:58","slug":"anti-vibe-coding-what-breaks-ai-generated-sites","status":"publish","type":"insight","link":"https:\/\/dextora.agency\/en\/insights\/anti-vibe-coding-what-breaks-ai-generated-sites\/","title":{"rendered":"Anti-Vibe-Coding: What Breaks When a Website Is Assembled in One Evening by AI"},"content":{"rendered":"<p>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.<\/p>\n<p>The problem is that &#8220;works&#8221; in a demo and &#8220;works&#8221; in a business are different things. Below is what actually breaks, and how to tell whether such a site can be left in production.<\/p>\n<h2>What generation genuinely does well<\/h2>\n<p>It would be dishonest to skip the obvious. Code generation covers these well:<\/p>\n<ul>\n<li>A <a href=\"https:\/\/dextora.agency\/en\/insights\/design-that-sells-screen-logic-not-visuals\/\">prototype<\/a> to show an idea and test a hypothesis.<\/li>\n<li>A single-page landing for a one-off campaign.<\/li>\n<li>Standard markup from a design when the structure is already worked out.<\/li>\n<li>Routine work: table markup, forms, repeating blocks.<\/li>\n<li>Explaining unfamiliar code and locating a bug in a specific place.<\/li>\n<\/ul>\n<p>That is a real saving in hours. The only question is where the zone ends in which skipping review costs nothing.<\/p>\n<h2>What breaks<\/h2>\n<table>\n<thead>\n<tr>\n<th>Area<\/th>\n<th>Typical problem<\/th>\n<th>When you find out<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Security<\/td>\n<td>A form with no validation and no request forgery protection<\/td>\n<td>After the first spam wave from your domain<\/td>\n<\/tr>\n<tr>\n<td>Accessibility<\/td>\n<td>No alt text, no focus order, poor contrast<\/td>\n<td>On a complaint or an audit<\/td>\n<\/tr>\n<tr>\n<td>Performance<\/td>\n<td>Three megabyte images, unnecessary libraries<\/td>\n<td>A month later in Search Console<\/td>\n<\/tr>\n<tr>\n<td>SEO<\/td>\n<td>Empty titles, duplicates, no heading structure<\/td>\n<td>When the traffic never arrives<\/td>\n<\/tr>\n<tr>\n<td>Data<\/td>\n<td>Enquiries go to email and are stored nowhere<\/td>\n<td>When you need the enquiry history<\/td>\n<\/tr>\n<tr>\n<td>Maintenance<\/td>\n<td>Nobody understands how the code is organised<\/td>\n<td>On the very first change request<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Security: the main gap<\/h2>\n<p>A model generates what it was asked for. Protection is usually not asked for, so it is not there.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<h2>The problem noticed later than the rest<\/h2>\n<p>A site assembled in an evening usually lacks what makes code maintainable: a consistent structure, reusable components, clear naming, comments where things get complex.<\/p>\n<p>While nothing changes, none of this matters. But the first task like &#8220;add a second language&#8221; or &#8220;change the form on every page&#8221; runs into identical code copied into twelve places with small variations. It has to be fixed in twelve, and three will be forgotten.<\/p>\n<p>The comparison in plain terms:<\/p>\n<table>\n<thead>\n<tr>\n<th>Task<\/th>\n<th>Structured project<\/th>\n<th>Generated in an evening<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Change the button colour<\/td>\n<td>One line<\/td>\n<td>Search across the whole project<\/td>\n<\/tr>\n<tr>\n<td>Add a language<\/td>\n<td>Built-in mechanism<\/td>\n<td>Copy every page<\/td>\n<\/tr>\n<tr>\n<td>Find the cause of a bug<\/td>\n<td>Follow the structure<\/td>\n<td>Read everything<\/td>\n<\/tr>\n<tr>\n<td>Hand over to another developer<\/td>\n<td>A day to get oriented<\/td>\n<td>Often faster to rewrite<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Where the sensible line runs<\/h2>\n<p>The question is not whether to use generation. The question is who reviews the result.<\/p>\n<p>A practical rule: generation is safe where a mistake is immediately visible and cheap. Markup for a block is visible on screen. Payment handling, <a href=\"https:\/\/dextora.agency\/en\/insights\/personal-data-on-your-website-what-you-can-collect-guide\/\">personal data<\/a>, authentication &#8211; there the mistake is invisible and expensive.<\/p>\n<p>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.<\/p>\n<h2>A checklist for a generated site<\/h2>\n<p>Before putting it into production, check at least this:<\/p>\n<ol>\n<li>Try submitting the form twenty times in a row. Is there any limit?<\/li>\n<li>Search the code for passwords, API keys, database credentials. They belong outside the code.<\/li>\n<li>Check whether enquiries are stored anywhere besides email.<\/li>\n<li>Open the site on a phone over a slow connection.<\/li>\n<li>Tab through the page: is focus visible, is every button reachable?<\/li>\n<li>View the page source: is there a title, a description, exactly one h1?<\/li>\n<li>Check image sizes. Anything over 300 kilobytes per photo needs rework.<\/li>\n<li>Ask yourself whether another person could make a change to this in six months.<\/li>\n<\/ol>\n<h2>What to do about it<\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A generated site looks respectable and opens in a browser. We break down what actually breaks in it &#8211; form security, accessibility, maintainability &#8211; and give an eight-point checklist before going live.<\/p>\n","protected":false},"author":5,"featured_media":8010,"template":"","insight_category":[156],"insight_tag":[174,186,162],"class_list":["post-8014","insight","type-insight","status-publish","has-post-thumbnail","hentry","insight_category-trends","insight_tag-ai-search","insight_tag-security","insight_tag-web-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight\/8014","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight"}],"about":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/types\/insight"}],"author":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/users\/5"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media\/8010"}],"wp:attachment":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media?parent=8014"}],"wp:term":[{"taxonomy":"insight_category","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_category?post=8014"},{"taxonomy":"insight_tag","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_tag?post=8014"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}