Ask a model to build you a landing page and you will get a landing page. It will have a hero, three feature cards, a testimonial and a call to action. It will be competent, it will be responsive, and it will look like every other page produced the same way that week.
That is not a failure of the tool. It is a failure of the question. The model answered the brief it was given, and the brief was “build me a landing page.” Nobody had decided what the page was for.
The work AI is genuinely good at
We use AI on every build, and it earns its place. It is faster than a human at the parts of web development that are mechanical rather than considered:
- Production. Turning an approved design into clean, responsive markup — the part that used to eat days.
- Consistency. Applying a token change across forty components without missing three of them.
- First drafts. Getting a section from nothing to something you can react to, which is far easier than reacting to a blank page.
- The boring passes. Alt text, meta descriptions, schema markup, responsive edge cases — the work that gets skipped when a deadline tightens.
The work it is not good at
Every one of these requires knowing something the model was never told:
- What the site is actually for. A site that needs to book consultations is a different object from one that needs to reduce support tickets, even when they look identical in a screenshot.
- What to leave out. AI adds. Asked to improve a page, it will give you another section. The best edit on most pages is a deletion, and nothing in the training data rewards that.
- Which objection to answer first. Ordering a page is a sales decision informed by what real prospects hesitate over. That knowledge lives in your inbox, not in a model.
- What it will cost you in two years. A structure that is quick to generate is not always cheap to maintain. Someone has to be accountable for the second year.
What goes wrong without an architect
The failure mode is rarely dramatic. The site launches, it looks fine, and it quietly underperforms. There is no single broken thing to point at — just a page that talks about features when the buyer needed reassurance, a form asking for nine fields when three would do, and a structure nobody can extend without a rebuild.
These are not bugs. No test catches them. They are decisions that were never consciously made, because the tool was happy to make them by default.
How we actually split the work
Humans decide, AI produces, humans verify. The decisions — what the site is for, what each page has to do, what the structure needs to survive — are made before anything gets generated. Production is where the speed comes from. Then every section is checked against the goal it was supposed to serve, not just against whether it renders.
That division is why an AI-native build is faster without being thinner. The hours saved come out of production, not out of thinking.
If you are weighing up an AI-assisted build, the question worth asking any agency is not which models they use. It is who on the team is accountable for the decisions the model cannot make.
Leave a Reply