Building websites with AI: what it is good at and where it breaks
AI is good at producing a page that renders: valid HTML, valid CSS, a layout that matches a spec, in minutes, and the eighth page as consistent as the first. It breaks where nothing fails loudly, and a site has a lot of places where "broken" and "working" look the same to the tool that built it. Everything below comes from our own build log, our own sites and showrooms, in September 2026. We name no clients.
What it does well
Given a written spec and a set of facts, an AI builder drafts a full site faster than a person can type it. It holds a style system across every page. It writes the markup for a tabbed section, a review grid or a pricing table correctly the first time, most of the time. When we change a rule, "no label above a heading," "every drawing carries a caption," it applies the rule everywhere in one pass. For a trade site, where the pages are known and the facts come from the owner, that is most of the labor.
Where it breaks: nothing fails loudly
Each of these shipped, or nearly shipped, in our shop. Each is now a check.
1. A script that exits early is indistinguishable from a page with no script. A tab script looked for an element that a header rebuild had removed, returned silently, and every tab panel rendered stacked on top of each other for days. Nothing errored, because "script off" is a valid state by design. The check now asserts the enhanced state: the script ran and exactly one panel is visible.
2. Two stylesheets, one class name. A template used .split for a two-column hero. A component library also defined .split as a grid on the element itself. Both files were valid; the page rendered; the headline ran to thirteen lines and a word broke in the middle (Source: our build log, September 2026). The rule now is that every class a new section emits is grepped against the template stylesheet before it ships; a scripted check is proposed, not built.
3. An attribute name is a class name too. A pricing component marked its list data-count="3" for the column count. A motion script on the same page counts up every data-count element when it scrolls into view. The whole price list became the text "3." The component's own proof never scrolled, so it passed. The attribute is now forbidden by name in the build prompt.
4. A date that defaults to today is a claim nobody made. An accessibility page printed "last checked" with the day the page was rendered, with no check performed. A terms page did the same with its effective date. Dates now print only from a recorded event, or the page says "not yet recorded."
5. A default is a promise. A FAQ default told every visitor "you get a call back the same business day," a promise no client had made. Defaults may carry no time, count or figure now; the answer prints the client's own stated response time or says to ask.
6. A sentence that names a check nobody ran. Our own accessibility statement claimed contrast testing at tablet width. No command did it. The rule since: before a sentence names a check, find the command that runs it on every page and every width the sentence covers; if none exists, build it or cut the claim.
7. A hard-coded colour on a dark scheme. A quote band's text was fixed near-white; on the dark colour scheme the band itself turned light, and the text sat at a 1.01 to 1 contrast ratio (Source: our build log, September 2026). The automated checker filed it as "incomplete," not a violation, and the gate counted only violations. Incomplete is now treated as a finding.
8. A sticky bar covering the field you are typing in. A phone-width call bar fixed to the bottom of the screen hid two form fields whenever they received focus. That is WCAG 2.2 Success Criterion 2.4.11: "When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content," and the W3C names "sticky footers, sticky headers, and non-modal dialogs" as the usual culprits (Source: W3C WAI). No automated tool caught it. A person tabbing through the form did.
9. A nav link to a page that was never written. A folder command failed, the page never got built, and three places linked to it anyway. Every nav and footer link is now requested after a build and must answer.
What makes it safe: a gate, and planted defects
The pattern in all nine is the same. The tool did what it was told, the page looked fine, and the defect was invisible to the thing that made it. So the fix is never "prompt better." The fix is a check that runs on the served page, and a planted defect that proves the check can fail. Our build log's rule is one line: a lesson with no mechanism is not learned yet. The planted-defect run that proves the gate caught 61 of 61 planted defects in its last full pass (Source: our build log, 27 September 2026).
Two more mechanisms do a lot of the work. A strict Content Security Policy, "a series of instructions from a website to a browser, which instruct the browser to place restrictions on the things that the code comprising the site is allowed to do" (Source: MDN), means an inline script or style an AI slips into a page fails loudly instead of running quietly. And we treat the automated accessibility check as a floor, not a pass: its maker says it finds "on average 57% of WCAG issues automatically" (Source: Deque, axe-core). The rest is a keyboard and a person.
How to check an AI-built site yourself
- Tap every tab and every accordion. Does each one open to its own content?
- From a deep page, tap the logo. Does it go home?
- Read every date on the site. Does each one mark something that actually happened?
- Read the FAQ for promises you did not make: callback times, warranties, licences.
- Switch your phone to dark mode and read the form. Is the small print still visible?
- On a laptop, tab through the contact form. Can you always see which field you are in?
The rule we work by
A claim about a check is only as true as the command that runs it. An AI-built site is finished when a gate has read the served pages, a planted defect has proven the gate, and a person has walked the forms. That is how every package we sell is built, Starter included. See what the gate covers at /build.
Sources
- Understanding SC 2.4.11 Focus Not Obscured (Minimum): the WCAG 2.2 rule a sticky bar broke on our own form
- Content Security Policy (CSP): what a CSP is and what it restricts
- axe-core README: automated checks find on average 57 percent of WCAG issues
- How the studio works, the gate every site passes: the studio's own records, summarized on the process page