How We Actually Use AI in Web Development

Every agency now claims to be AI-powered, which has made the phrase meaningless. Here is a plain account of where we use it, where we do not, and what difference it makes to a client.

Where it genuinely helps

Repetitive code. Form validation, data transformations, API wrappers, test scaffolding, the fourth variant of a component you have already written three times. This is the bulk of the gain and it is real. Work that used to take an afternoon often takes an hour.

Translations, as a first pass. This site exists in Dutch, English and Spanish, and keeping three versions in step by hand is where multilingual projects usually rot. A machine first draft followed by a human edit is dramatically faster than translating from scratch, and — this is the important part — it is only acceptable because someone who speaks the language reads every line afterwards. Published raw, it produces exactly the stilted, slightly-wrong text that makes a company look careless in its second market.

Understanding unfamiliar code. When a client arrives with a site built by someone else five years ago, having something read the codebase and summarise how it fits together saves hours of archaeology.

Refactoring with a clear specification. "Rename this concept everywhere, update the call sites, keep behaviour identical" is a task machines are good at and humans find tedious and error-prone.

Accessibility and code review as a second pair of eyes. Not a replacement for testing, but it reliably catches the missing label, the unlabelled button, the heading that skipped a level.

Where it does not help

Deciding what to build. The hardest part of most projects is working out what the client actually needs, which is frequently not what they first asked for. That requires asking uncomfortable questions and understanding a business. No tool does it.

Design judgement. It will produce something competent and generic. Competent and generic is exactly what a business trying to look different does not want.

Anything where being wrong is expensive. Payment logic, access control, data handling under GDPR. We use assistance to draft and then read every line carefully, because a plausible-looking mistake in those areas is worse than no help at all.

Copy that has to sound like you. It writes fluent, forgettable marketing prose. Every business we have worked with has a way of talking about itself that matters, and it does not survive being generated.

The honest downside

Two costs that get glossed over.

The first is plausible wrongness. Generated code often looks right and is subtly not: an edge case unhandled, a deprecated API, a library invented outright. Reviewing that carefully is real work, and on complex tasks it can eat the time the generation saved. The tool is fast at producing; it is not fast at being certain.

The second is skill erosion, which is a longer-term concern for anyone in this trade. If you accept suggestions without understanding them, you gradually lose the ability to judge them. We treat generated code the same way we would treat a junior colleague's pull request: read it, question it, and be willing to throw it away.

What it means for what you pay

Fair question, and the answer is not "everything is cheaper now".

Where it does show up is in the routine parts of a build, and that shows up in timelines more than in the hourly rate. Projects that would have taken eight weeks often take five or six. The parts that did not get faster — discovery, design, testing on real devices, the conversations where you work out what the site needs to do — are the parts that determined the quality of the outcome anyway.

Be sceptical of anyone advertising dramatic discounts because of AI. In practice it compresses the middle of a project, not the ends, and the ends are where projects succeed or fail.

What we will not do

Three commitments worth stating plainly, because they are the ones clients ask about.

We do not publish generated text without a human editing it, in any of the three languages.

We do not put client data into third-party tools without knowing where it goes and having a lawful basis. That is a GDPR question before it is a preference.

We do not ship code nobody on our side understands. If we cannot explain why a piece of your site works the way it does, we have not finished.

For your own business

If you are wondering whether AI belongs on your website, the honest answer for most small companies is: probably not yet, and not as a feature. A chatbot on a five-page brochure site solves a problem you do not have and adds one you did not have — namely a system that can confidently tell your customers something untrue.

Where it does earn its place is behind the scenes: drafting content you then edit, summarising enquiries, translating a first pass, sorting incoming messages. Useful, unglamorous, and it does not require your visitors to trust a robot.

The interesting question for most businesses is not "how do we add AI" but "are we findable when someone asks an assistant a question in our field". That one is worth attention, and it is mostly answered by clean HTML, clear structure and honest content — which is a separate article.