Can you trust code written by AI?

The idea of letting an AI tool build the site produces the same reaction in anyone who can read code: is this any good underneath? The worry is legitimate, and waving it away with “models are very good now” is not an answer. Let us count the risks one by one, then look at where they come from — because the real issue is not how clever the model is, but how much room it was given.

The real risks

• Hallucination: calling a function or package that does not exist
• Security: unvalidated input, an exposed key, wrong authorisation
• Inconsistency: solving the same problem two different ways on two pages
• Maintenance debt: code that works, nobody understands, and nobody dares touch
• Silent regression: fixing one thing and breaking another

Not one item on that list is exaggerated. Anyone working with blank-page generation has hit at least three of them. Does that mean AI cannot write code? No — look at the list again: every item is a by-product of degrees of freedom.

The risk comes from the blank page, not the model

When you tell a model “build me a restaurant site”, you are asking it to make thousands of decisions at once: folder structure, component architecture, styling approach, state management, breakpoints, accessibility, form behaviour. Every decision is a gamble. Even if ninety-five out of a hundred are right, the remaining five sit inside the site as small timers scattered through it.

And those decisions bind each other. Writing the second page, it has to remember exactly what it did on the first; if it does not, inconsistency starts. That is precisely why blank-page generation behaves the way it does: the first output is excellent and by the third page it falls apart.

A template narrows the gamble

This is where the template-first approach comes from. The template solves the folder structure, the component architecture, the styling system and the breakpoints in advance and by human hand. What is left for the AI is filling known gaps inside that skeleton and making the change you asked for in the right file.

The difference: the model is no longer the architect, it is the tradesperson. When the architectural decisions are fixed, the surface hallucination can grip shrinks. The chance of “calling a component that does not exist” drops when the component list is fixed. The chance of “two different solutions on two pages” drops when the solution is already defined in the template.

AI-written code is not risky; unbounded AI-written code is risky. The question is not how good the model is, but how wide the space is where you let it roam.

Two different questions

The trust argument usually stalls on the first question: can the model write correct code? But a designer’s real worry is the second: will I be able to own this code in six months?

Those are very different. Correct but unreadable code can be more dangerous than incorrect code — because it works, so nobody looks at it, and when it finally has to be touched nobody dares. Software people call that technical debt, and AI can produce it at a rate never seen before. Five times more code an hour is five times more debt an hour — unless you are the one deciding the shape of that code.

The difference between “it works” and “it is right”

The insidious thing about AI-written code is that when it is wrong it usually does not explode. You notice code that breaks; you do not notice code that is quietly wrong. The form appears to submit but the email never arrives. The image loads but it is four megabytes. The page opens but cannot be navigated with a screen reader.

So “does it work?” is the wrong question. The right one is: did I actually look at what happened? As a designer you already do this — AI does not make the habit unnecessary, it makes it more necessary. Because you did not write the code, you can no longer assume what is in there.

What if something breaks?

Real confidence does not come from never making a mistake; it comes from being able to undo one. The question is not “does the model ever get it wrong?” — it does. The question is: when it does, how long does it take me to get back?

Whatever tool you choose, ask that question. Does every change exist as a version you can revert? Does the live site stay untouched until you approve? This is less a technical feature than a design philosophy: you should not have to trust the model, you should be able to trust the undo button. If a tool has no answer here, do not put client work on it.

Lock-in: the other question worth asking

The under-discussed side of the trust argument is dependence not on the code but on the tool. A platform you like today can change its pricing tomorrow, change direction, or shut down. If your client’s site lives there, that is your risk.

So ask every tool you evaluate one question: can I leave? Can I take my files, is the domain mine, is my content held hostage? If the answer is not clear, the argument about code quality is beside the point.

Whose responsibility is it?

Underneath the technical argument sits a practical question: if something goes wrong, who answers for it? The answer is uncomfortable but clear — you. Your client is not going to ring a model provider or a platform; they are going to ring you. You chose the tool and you delivered the work.

That is not an argument against using AI. The same was always true: when a plugin you installed turned out to have a security hole, the bill came to you. The only thing that changed is that production speed can now outrun the speed of oversight. If you are producing five times faster, you have to tighten your checking habits by the same factor — otherwise speed gets ahead of control.

Keep control anyway

No architecture replaces review. Whatever tool you use, keep these habits:

• See the change in a preview first, not on the live site
• Ask for one thing per instruction; batched requests produce side effects you will miss
• Always test forms and contact paths yourself
• Walk the site on a phone before delivering — the overflow you cannot see on a desktop is there
• “Works” and “right” are not the same: measure speed and accessibility

These are the habits of a good designer anyway. AI does not make them unnecessary — it frees up the time to actually do them.

What if you cannot read code?

An honest question deserves an honest answer: if you cannot read code, the thing protecting you cannot be your ability to review. It has to be the limits of the tool. That reveals the real distinction between two categories of tool.

With a blank-page generator, your safety depends on being able to judge the output. If you cannot judge it, you are gambling and you cannot even tell whether you won. With a template-based tool the architecture was built by humans, and the surface the model can touch is narrow. For someone who cannot read code, the difference in risk between those two is enormous.

So “you do not need to know how to code” is an honest sentence only on the right architecture. Said about a blank page, it actually means “you do not need to know what you are accepting” — which is not advice, it is a wish.

What do you tell the client?

Sooner or later a corporate client will ask: “did AI write this site?” Do not get defensive. The true answer is already strong: human designers built the architecture, the AI worked inside it, I reviewed what came out, and the responsibility is mine.

That sentence does three things at once: it is honest, it is technically accurate, and it answers the client’s real question. Because they are not asking about the tool — they are asking “if something goes wrong, who do I call?”. As long as that person is you, the tool is nobody’s concern.

In short: the question is not “can AI write code?” — it can. The question is how wide a space you let it roam in. As the space narrows, trust rises. That is the argument for working on top of a proven template: the trust is placed in the architecture rather than in the intelligence.