Skip to main content
MEWA STUDIO

Your AI-generated website: the bill arrives twelve months later

Published on August 14th, 2026|12 min read
strategybusinessdevelopment

Generating a website costs almost nothing. The expense still exists, it is simply deferred. Public data now puts a figure on it, from technical debt to security to platform dependency. A simple criterion then shows when this choice remains perfectly rational.

Abstract digital structure made of overlapping translucent neon panels in pink, green and blue on a black background

Generating a website over a weekend costs almost nothing on Monday morning. The expense still exists, it is simply deferred. In 2026, GitClear measured the highest duplication rate in its history and the lowest rate of code reorganisation, across 623 million code changes analysed since 2023 (opens in a new tab). Code gets written faster than before. It gets tidied far less.

This article is not a case against AI-assisted generation. These tools solve a real problem and there are situations where they are the most rational choice. The useful question lies elsewhere: who pays, when and on what occasion, once the enthusiasm of the first week has passed.

Two very different families of tools sit under the same label. They do not create the same debt. The pages that follow separate those families, measure what public data says about each, then propose a decision framework. The conclusion is not that everything must be hand-coded. It fits in one sentence: a generated website requires an explicit decision about its lifespan, taken before any generating starts.

Two tools, two kinds of debt

On one side, code generators. Lovable, v0, Bolt and Replit Agent produce a real Git repository, React or Next.js code, a database. The code exists, it belongs to you, and so does its maintenance. On the other side, hosted builders. Wix, Squarespace, Framer and Durable assemble a site from templates and publish it on their own infrastructure. There is no code to take over for the simple reason that no code is ever delivered to you.

CriterionCode generatorsHosted builders
ExamplesLovable, v0, Bolt, Replit AgentWix, Squarespace, Framer, Durable
What you get backA Git repository, React or Next.js codeA subscription and a published site
Who can take overAny developer, provided the code stays readableA platform specialist, within the platform's limits
Nature of the debtTechnical, inside code nobody designedContractual, inside a service that is hard to leave
Cost of leavingThe time to understand, then to take overA full rebuild of the site

The two families do not leave the same thing in your hands

This distinction drives everything else. A Wix subscription and a Lovable project have almost nothing in common, beyond both looking free at the start.

Technical debt, finally measured

The phrase "technical debt" circulates widely and is rarely verified. Two bodies of work published since late 2025 make that debt quantifiable.

GitClear tracks how code evolves across 623 million changes analysed between 2023 and 2026 (opens in a new tab). Three indicators deteriorated in step with assistant adoption.

  • Duplication. Duplicated blocks rose from 40.3 per million changed lines in 2023 to 73.0 in 2026, an 81% increase and the highest level ever recorded
  • Tidying. The share of moved code, the signature of proper reorganisation, fell from 21% of changed lines in 2022 to 3.8% in 2026
  • Reuse. Function calls across files dropped 35% since 2023, from 343 to 223 per thousand changed lines

These three curves describe the same thing from three angles. Code produced today gets copied instead of being shared. In practice, changing a phone number, a price or a calculation rule no longer happens in a single place. Five copies have to be found, all five corrected, and the sixth discovered three weeks later in production.

Two further signals from the same report deserve attention. Constructs that mask an error instead of handling it rose 47%. Code rewritten within two weeks of being written rose 15%. A website that swallows its errors in silence does not go down. It produces wrong results without warning anyone.

The second measurement comes from academia. Researchers at Singapore Management University and Huazhong University analysed 302,600 AI-attributed commits across 6,299 public GitHub repositories (opens in a new tab), running static analysers before and after each contribution.

  • 484,366 distinct issues introduced, including 28,931 correctness defects and 22,687 security defects
  • More than 15% of every assistant's commits introduce at least one issue, from 17.4% for the most careful to 29.1% for the least
  • On correctness and security defects, the assistants introduce roughly one and a half times as many as they fix
  • 22.7% of detected issues were still present in the repository's latest version at the time of the study

That last figure says the most. Nearly one issue in four was never fixed, not through negligence but because nobody saw it. A defect introduced into code its owner did not write has no reason to be noticed before it causes something visible.

When the bill arrives

The debt is not paid at generation time. It is paid at the first change requested by someone else, several months later, on code nobody can explain any more.

LinearB compared 8.1 million pull requests from 4,800 teams across 42 countries (opens in a new tab). The gap between human code and AI-assisted code is not about writing speed.

IndicatorHuman codeAI-assisted code
Merge rate84.5 %32.7 %
Size at the 75th percentile157 linesmore than 400 lines
Share of code reorganisationaround 37 %close to zero
Wait before first reviewaround 200 minutesmore than 16 hours

Human code and AI-assisted code, compared across 8.1 million pull requests

Of every three AI-assisted code proposals, two are never merged. They still cost generation time, review time, then the time it takes to abandon them. The speed gained while writing is paid back further down the chain, where nobody counts it.

A controlled trial run by METR in 2025 (opens in a new tab) measured the perception gap that comes with this. Sixteen experienced developers handled 246 real tasks on projects they had known for years. With AI tools, they took 19% longer. Asked afterwards, they estimated they had gained 20%. METR now labels that result as historical, since the tools have changed considerably. The gap between perception and measurement has no particular reason to have vanished.

Developers themselves are not fooled. In the Stack Overflow survey of more than 49,000 respondents (opens in a new tab), 84% use or plan to use AI tools. Only 3.1% report high trust in the accuracy of the answers, against 45.7% who distrust them. The most cited frustration, from 66% of respondents, fits in one phrase: solutions that are almost right, never quite.

"Almost right" is exactly the most expensive register on a website. A form that fails outright is repaired the same day. A form that sends the message without the attachment goes months before anyone notices. What was lost in the meantime cannot be recovered.

Security does not wait twelve months

Security runs on a different calendar. The bill can arrive the day the site goes live.

In October 2025, the Escape team analysed more than 5,600 publicly deployed applications (opens in a new tab) built on generation platforms, over 4,000 of them from Lovable, alongside applications from Create.xyz, Base44, Bolt.new and Vibe Studio. The sweep covered 14,600 assets in total.

  • More than 2,000 vulnerabilities on production systems
  • More than 400 exposed secrets, API keys and access tokens included
  • 175 cases of accessible personal data, including medical records, bank details and phone numbers

The causes repeat from one application to the next. Misconfigured database integrations, authentication tokens left inside the JavaScript bundle sent to the browser, row-level access rules never switched on. None of these mistakes is exotic. All of them assume knowing that a setting exists. A generator produces an application that works, it does not produce the knowledge of what it left open.

One April 2026 incident illustrates the mechanism. It is documented by the platform itself. In its public response (opens in a new tab), Lovable explains that between 3 February and 20 April 2026, the chat history and source code of public projects could be accessed by any logged-in user. A product change had inadvertently restored access that had been removed months earlier. Researchers had flagged the issue as early as 22 February through the disclosure programme. The reports were closed without being escalated because the internal documentation handed to the triage team still described that visibility as intended.

What followed goes to the vendor's credit. The fix shipped within two hours of the issue being made public, all legacy public projects were switched to private, and the triage procedure was overhauled. The substance remains. For eleven weeks, projects created by people who had no idea that "public" meant "readable by everyone" were readable by everyone.

Whether a given platform is secure matters less than who answers the day it stops being secure. A brochure site with no user accounts risks very little. A booking form at an osteopath's practice, a client area for a law firm or a payment module change the nature of the bet entirely. Obligations around compliance and fairness towards users (opens in a new tab) cannot be delegated to any generator.

The debt you cannot take over

Hosted builders escape technical debt because they deliver no code at all. They create a dependency of another kind, more comfortable day to day and harder to undo.

Wix states in its own documentation that a site built with its editor cannot be exported or hosted elsewhere (opens in a new tab), the architecture relying on its proprietary technology. Squarespace does offer an export. Its official list of exclusions (opens in a new tab) is instructive. Store, portfolio, index and calendar pages are not included, nor are dropdowns, video blocks, style settings or custom CSS. The content leaves, the layout stays.

This dependency costs nothing as long as nothing changes. It makes itself felt the day the business wants a feature the platform does not offer, a level of performance its rendering does not allow, or simply a site that does not look like every other one.

On top of that comes an effect that is harder to quantify. A generator produces what its model has encountered most often. Across thousands of sites built from the same templates and the same training data, layouts converge, page rhythms repeat, the same sections come back in the same order. For a business whose website is the main point of contact before the first meeting, looking like everyone else cancels out precisely what that website was meant to deliver.

When a generated site is the right call

Nothing above condemns these tools. Everything does suggest that the decision rests on the expected lifespan of the site, not on its headline price. A single criterion captures the essential. A generated site is a good choice when nobody will have to take it over.

SituationCoherent choiceWhat has to be accepted
Validating an idea before investingCode generator, over three to eight weeksThe prototype will be thrown away, not improved
Page for a one-off eventHosted builderThe site ends with the event
Internal tool for a small teamCode generator, with no sensitive dataA security audit before any real data
Brochure site for an established businessCustom designA real budget and a real timeline
Customer accounts, payment or health dataSupervised development, whatever the starting toolLegal responsibility that stays whole

The same tool becomes a good or a bad choice depending on what is asked of it

The first two rows are not polite concessions. A business hesitating between two positionings is far better off generating two versions within the week than commissioning a three-month redesign on an untested assumption. The generator then becomes an instrument of decision. It costs little, it settles the question fast, and its output is not meant to survive. What the business is actually building comes next, a question covered in the article on redesign or new website (opens in a new tab).

The classic mistake is not generating. It is letting a prototype become the official site through sheer inertia, because it worked well enough for no decision ever to be taken.

Six questions to ask before letting an AI build your site

  • How many months before this site has to change and who will handle it?
  • Is the code exportable and can an outside developer take it over, without the tool that produced it?
  • What data passes through the site and where is it stored?
  • Who answers in case of a breach, within what timeframe and under what contractual obligation?
  • What is left of the site if the platform changes its pricing, its limits or its terms?
  • Does this site carry the brand's search presence and identity or only an experiment?

None of these six questions requires technical skill. A vague answer to the second or the fourth is enough to rule the option out for a business website.

Code was never the main line item

AI generation has made almost free the part of the work that was never the most expensive. Writing a page has been fast for a long time. Understanding it six months later, making it evolve without breaking the rest, keeping it secure and fast, that is where the money goes.

The return on a website is therefore not calculated on its build cost but on its cost of ownership, a subject already covered from the angle of the budget to defend internally (opens in a new tab). A site generated over a weekend, then taken over twice in a year by successive providers who do not understand the delivered code, ends up more expensive than a site designed properly once.

The website remains the foundation every other channel leans on, the only surface a business controls entirely. Generating it in an hour is perfectly possible. Deciding how long it has to last takes longer than an hour. That decision is the one paid for twelve months later.