AI site builders got very good at the part you can see

There is a specific moment when a new tool stops being a toy. For AI site builders it happened somewhere in the last eighteen months: you describe a page, and a working page appears. Not a wireframe, not a template to fill in. A deployed URL, with a layout, with animation, with a form that submits.

That is a genuine achievement and it deserves to be said plainly, because most of what is written about these tools is either sales copy or defensive grumbling from people whose job they threaten.

The interesting question is not whether they work. It is which half of the problem they solved.

The number that frames everything

Veracode publishes a recurring study of the security of AI-generated code. The spring 2026 edition tested 80 coding tasks across four languages and four vulnerability classes, run against more than 150 models, with the output scanned by a static analysis tool.

Two curves come out of it, and they point in different directions.

The share of generated code that compiles and runs climbed from roughly 50% to about 95% over the period they have been measuring. That is the curve everyone feels. It is why the tools stopped being toys.

The share of generated code that is free of known vulnerabilities sat at 55%. Not falling, not climbing. Flat.

Read those together and you have the whole story of this generation of tools. They got better at the part you can see, at a rate that felt like magic, and they did not get better at the part you cannot see, at all.

The breakdown is worse than the average suggests. Cross-site scripting, which is a browser problem and therefore a website problem, came out 15% secure. Log injection, 13%. The categories that did well, SQL injection at 82% and weak cryptography at 86%, are the ones with a single obvious right answer that appears in every tutorial.

That pattern is not random. These models are excellent at reproducing the answer that appears most often in their training data, and security is the domain where the most common answer is usually the insecure one, because most code ever written was written before anyone was looking.

Generating HTML is the worst case, not the best

If you build websites, the security numbers should worry you less than the accessibility ones, because a marketing site rarely touches a database and always touches a human.

The GAAD Foundation runs a benchmark called AIMAC that asks models to generate HTML and then checks the output against accessibility criteria. In their 2026 run, 35 of 37 current models produced multiple critical or serious issues by default. Not edge cases. Defaults.

This shows up in the wider web too. WebAIM audits the home pages of the top one million sites every year, and their 2026 report found detected errors up 10.1% over 2025, reversing several years of slow improvement. One year of data is not causation, and WebAIM does not claim it is. But it is the first reversal in a long time, and it arrives exactly as AI-generated markup becomes a meaningful share of what ships.

The most uncomfortable finding is not about the machines. Deque surveyed software engineering leaders in July 2026 and found that 88% report high or very high trust in the accessibility of their AI-generated code, while 64% name accessibility as a top driver of post-production rework. The same people, in the same survey, trust the output and pay to fix it.

That gap is the actual risk. Not that the tools produce inaccessible markup, but that they produce inaccessible markup that looks finished.

The bill arrives in year two

The third measurement is about what happens after launch, which is the part nobody demos.

GitClear analysed 623 million code changes across 2023 to 2026, tracking signals of reuse against signals of duplication. Over that window: duplicated code blocks up 81%, within-commit copy and paste up 41%, error-masking constructs up 47%. In the other direction, refactoring line moves down 70% and cross-file function calls, which indicate that code is being reused rather than regenerated, down 35%.

In plain terms: more of the same logic exists in more places, and less of it is being consolidated. That is a description of a codebase that is cheap to add to and expensive to change.

The same research contains the fairest number in this article, and it cuts against the hype rather than for it. Heavy AI users do out-produce non-users by a wide margin, but most of that gap existed before AI. Compared with their own past output, heavy users gained about 25%. Real, meaningful, and about an order of magnitude below what the category sells.

Our position

We build sites in code, so read the next three paragraphs knowing that.

We think these tools are the right answer more often than our industry admits. A campaign page with a three week life, an internal tool, a prototype that exists to settle an argument in a meeting: the correct amount of engineering for those is close to zero, and paying a studio for them is waste. If nobody will maintain it and nothing depends on it being found, generate it.

We think the decision changes completely the moment the page has to be found. Everything measured above is invisible in a screenshot. Whether a crawler that does not execute JavaScript can read your text, whether every image carries a description a screen reader can use, whether each page has its own title and description instead of sixteen copies of one, whether the markup says what the content means. None of that shows up in the demo, and all of it decides whether the page does its job.

And we think the first version was never the expensive part. The cost of a website is concentrated in the years after launch: the redesign that has to keep the URLs, the third language, the person who has to edit it without calling anyone. The duplication numbers above are a direct measurement of that cost being deferred rather than avoided.

The honest summary is that these tools moved the floor up and left the ceiling where it was. A worse first version is now rare. A good second year is exactly as hard as it always was.