AI in web development: what to automate and what you never outsource

We use AI every working day. Not as an ideological position, but because a share of web development work is simply repetitive, and there the gain is measured in hours rather than in manifestos.

The short list of places where it honestly helps:

• Scaffolding: the shape of a form, a set of routes, a typed client over an already documented API.
• Mechanical refactors: renames across dozens of files, extracting a hook, moving a component from one layer to another.
• Tests: especially the obvious cases you would write anyway but keep postponing.
• Migrations: from one major framework version to the next, from one styling convention to another.
• First content drafts: a draft the editor cuts in half and rewrites into something of their own.
• Alt text and translations: a decent starting point for a gallery with two hundred images.
• The first pass of code review: unused variables, missing error handling, types that are far too permissive.

What all of these share is a quickly verifiable answer. When you can tell within ten seconds whether the output is correct, AI is a serious multiplier. When verification costs more than execution did, there is nothing left to multiply.

AI does not save you thinking. It saves you typing. The gap between those two decides whether a project turns out well or merely turns out fast.

The uncomfortable part is that weak AI output does not look weak. It looks plausible. The code compiles, the page loads, the copy sounds like copy. The damage shows up precisely where you have no test that can fail.

• Taste. A model produces the average of what it has seen. The average has never won a pitch.
• Information architecture. What goes on the homepage and what gets cut is a business decision, not a generation task. A model does not know which of your six services carries eighty percent of the margin.
• Brand voice. It erodes quietly: one adjective too many, a generic turn of phrase, a brochure tone. Thirty pages later the brand is gone.
• Edge-case judgment. What happens when the payment clears but the webhook never arrives. What happens on the second click of Submit. That is where real money is lost.
• Accessibility nuance. An ARIA attribute that is syntactically perfect can still make the experience worse for someone using a screen reader.
• Performance trade-offs. What renders on the server, what ships to the client, what you cache and for how long — see also server components architecture. A model hands you a version that works, not the version that suits your traffic.

The pattern repeats on nearly every project: eighty percent of the functionality appears in ten minutes, and the remaining twenty percent takes longer than writing the whole thing yourself would have.

The reason is mundane. Generated code arrives carrying assumptions you never made: a data structure you did not choose, an error convention that is not yours, one extra dependency. To finish the job you first have to mentally reconstruct decisions nobody on your team made. That is archaeology, not engineering.

Hence our rule: AI proposes, a human owns the architecture. If a generated block does not sit cleanly on top of a structure we chose deliberately, it gets thrown away. We do not negotiate with it.

Because they are drawn from the same distribution. The same centred hero, the same three icon cards, the same gradient, the same testimonial band, the same agreeable start-up tone. Individually each one looks clean. Side by side, they are one site wearing different logos.

For a business this is not an aesthetic problem, it is a commercial one. A site that resembles five hundred others cannot support a higher price. Visual differentiation is the only thing a prospect perceives before learning anything about the quality of your work — and it goes well beyond a logo. Remove it and all that remains is competing on price.

Two different things get confused here: AI as a production tool, and AI as a feature shipped to users. The second only earns its place when it answers a concrete question.

Usually worth it:

• Semantic search over a large catalogue, where visitors do not know your internal vocabulary.
• An assistant that genuinely reads your data — stock, hours, prices, availability — and says plainly when it does not know.
• Classification and routing behind the scenes: leads, tickets, form submissions. Invisible to the visitor, valuable to the team.

Usually not worth it:

• A chatbot on a five-page site where the answer sits two scrolls away regardless.
• Personalization on traffic too thin to produce the data that would make personalization mean anything.
• Runtime text generation where one well-written page, written once, would have been better and free.

The test is brutally simple: replace the AI feature with a good link or a well-written page, and if nobody notices the absence, the feature was theatre.

• Nothing reaches production without being read line by line by someone who can explain why it is there.
• Small diffs. A three-hundred-line generated diff cannot be reviewed honestly, so it is not accepted.
• Architecture, data schema and navigation structure are decided upfront, by a human, in writing.
• Brand copy is written or rewritten by a person. A generated draft is raw material, never a deliverable.
• No figure, no claim about a client and no legal reference ships without checking the source.
• Accountability does not get distributed. If something breaks at three in the morning, the explanation cannot be that the model wrote it that way.
• One active project at a time, however fast the tooling feels — the reasoning is here.

The useful question is not whether they use AI. Everyone does. Ask instead:

• What exactly do you generate and what do you write by hand, specifically on my project.
• Who reviews the generated code, and how long does that review take.
• Does my data reach any external service. Which one, under what terms.
• Are the copy and the design original, or the average of what already exists online.
• Who is answerable if a security flaw turns up in code nobody on your team wrote.

A serious provider answers all five without flinching. Look at our work to judge the outcome rather than the process.

AI has raised the floor considerably. A genuinely bad website is harder to produce today than it was three years ago, and the distance from idea to prototype has changed for good.

The ceiling has not moved. A product that wins a market still demands decisions nobody can delegate: what you leave out, who you are speaking to, what you promise and what you are prepared to stand behind. There, the tool goes quiet. Everything else is execution — and execution deserves to be automated without sentimentality.