How We Use AI in Our Web Development Workflow: The Honest Version
Ten years of building websites for UK businesses teaches you things that can’t be prompted out of a language model. Pattern recognition for what converts. An instinct for when a page feels wrong before you can articulate why. The practical knowledge that a brief saying “clean and professional” can mean twelve different things to twelve different clients, and how you figure out which version is sitting across from you.
That experience is what makes AI useful to us rather than a liability. We’ve been using AI tools in our workflow for a couple of years now, without particular fanfare, because some of them genuinely speed up the work without degrading the output. This is an honest account of where they help and where we still do everything by hand.
Experience first, tools second
The narrative that AI replaces senior developers gets the order of things wrong. AI produces output. Experienced developers assess whether that output is correct, safe, performant, and appropriate for the specific project in front of them. That judgment is not something you can skip.
We’ve reviewed AI-generated code that looks reasonable at a glance and introduces a layout shift at exactly the viewport width where a client’s primary call to action sits. We’ve seen copy suggestions that pass a grammar check and are tonally wrong for a specific audience in ways only someone familiar with that business and its customers would notice. The tool has no idea any of this is happening. The only way to catch it is to know what good looks like before you run the tool.
Ten years of hand-coded builds, mainly for small and medium businesses across the UK, means we’ve seen most of the ways a site can go wrong. Not all of them. But enough that AI tools accelerate our work rather than introduce a new category of problems.
Code review: a second pair of eyes that doesn’t tire
After a long build session, human attention drifts. Small errors creep in. A heading hierarchy that skips a level. A focus state removed during a refactor that never came back. An aria label referencing an ID that no longer exists. A colour contrast ratio that passes on a bright monitor and fails on a mid-range laptop screen.
Before any site goes live, we run code through AI-assisted review, specifically for accessibility, structural consistency, and semantic correctness. This is not code generation. It’s a systematic pass over things that matter to real users and to search engines, and that are genuinely easy to miss when you’ve been working on the same components for a week.
We make the final call on every flag that comes back. Sometimes the tool raises something we already knew about and had a deliberate reason for. Sometimes it catches a genuine error we’d missed. Either way, the site that ships is more reliable for the check.
Accessible code and performant code overlap more than people realise. Catching structural errors early serves both. The importance of website accessibility for small businesses is something we’ve written about separately, but the short version is that clean semantics help everyone: screen reader users, search crawlers, and the client whose site needs to convert.
Boilerplate: the work that doesn’t need a decade of context
Some parts of a build are structurally important and genuinely repetitive. Schema markup for a local business with multiple service areas. Consistent Open Graph metadata across every page. Sitemap XML generation. These are not places where creative judgment adds much. They’re places where accuracy and consistency matter, and where AI handles the scaffolding efficiently.
Freeing up that time means we can spend it on the parts that do require judgment: the hierarchy of information on a page, the decision about what gets cut because it doesn’t earn its place, and the copy that a specific type of client will actually read before picking up the phone. That’s the work that turns a visit into an enquiry. It can’t be reliably generated from a prompt, and we’re not going to pretend otherwise.
Our Astro components are still written by hand, every one. If you want to understand why that matters for page speed, our post on why studios are choosing Astro explains the reasoning without jargon. The summary: hand-coded components ship only what the page actually needs, which is how we hit LCP under 1.5 seconds on mid-range mobile consistently, rather than as a lucky average.
Research and keeping pace with a moving target
Web development moves quickly. Browser support for CSS features changes. Google updates how it evaluates structured data. An approach that was best practice eighteen months ago becomes unnecessary or, worse, counterproductive. Keeping current used to mean reading a lot of documentation across a lot of sources and cross-referencing conflicting advice.
AI compresses that substantially. We use it to synthesise documentation, verify compatibility of a specific approach across the browsers our clients’ visitors actually use, and get working answers from deep technical documentation in a fraction of the time. We still check primary sources before anything goes into production. The tool accelerates research. It does not replace verification.
The same applies to conversion thinking. We might use AI to quickly cross-reference an approach against current thinking on page structure, then apply our own judgment about whether it fits the specific project. A one-page site for a Burton trades business and a full multi-page build for a Nottingham consultancy share some structural principles and differ in almost everything that actually matters. Context is the whole job. No prompt generates context.
Where AI doesn’t come into it
The judgment calls are ours, without exception.
How to structure a homepage so the right type of client self-qualifies and makes contact, rather than generating enquiries that aren’t a fit. Whether a landing page needs social proof above the fold or whether the offer is strong enough to lead without it. How much copy a particular audience will read before deciding. What a client means when they say they want something “modern but not cold”.
These come from watching real people use real sites, reading actual enquiry data, and understanding the commercial context behind each brief. No language model has that context. Even if we fed it in, the tool would pattern-match against a statistical average rather than applying specific knowledge of what works for different business types and audiences.
We also don’t use AI to write finished client copy. We use it to review our own drafts for clarity and consistency, the way a good editor would. Copy that ends up on a client’s site has been through a human who understands the business, the audience, and what the page needs to achieve commercially. If you’re thinking about where human oversight sits in an AI-assisted workflow, our post on human oversight in AI workflows covers the practical detail.
What you get from all of this
Practically: a faster build that isn’t a less careful one. Repetitive structural work gets done accurately and quickly. Error-checking is more thorough than one person working alone can reasonably maintain across a full project. Research takes a fraction of the time it used to.
The experience still drives every decision. The AI tools handle the weight-bearing work on parts of the process that don’t need ten years of context. They also make it easier to catch the small things that only show up when someone’s attention drifts after a long session.
We’re not going to call this transformational. It’s professional tool use. A good carpenter doesn’t sand by hand when a machine does it better and faster. The machine doesn’t decide the joinery.
If you’re a small business wondering whether the AI tools on your own site are actually pulling their weight, our post on AI website tools for UK small businesses is probably a more useful read than this one. This post is about how we work. That one is about whether the tools you’re paying for are working for you.
Ready to work with a studio that knows what good looks like? Get in touch and we’ll tell you whether we’re the right fit for your project.