Almost everything written about AI and web development is written by people who don't build websites. It arrives as a list of tools, a prediction that developers are finished, and a call to action for an agency that will sell you the future. I've read a lot of it and recognised very little of my own work in it.
So here is the version from inside. I run a one-person studio and I've shipped client sites with AI assistance every week for over a year. I also built and run WebSeek.ai, an AI website generator that turns one prompt into a deployed site, with a model picker for Claude, GPT and Gemini. Running the same product on three providers at once means the differences between them are things I've debugged at 2am, not things I've read in a comparison table.
That leaves me in an odd position for this topic: I sell custom development, and I also built the machine that's supposed to make it obsolete. This post is what I actually think, which is more interesting than either sales pitch.
The short version
AI has substantially changed how fast the mechanical parts of a build go. It has changed almost nothing about the parts that decide whether a website works.
That sentence sounds like a hedge. It isn't — it's a description of where the time goes. When I look at a finished project honestly, the typing was never the expensive part. The expensive parts were working out what the site needed to say, getting content out of a client who is busy running their business, and the hundred small decisions about what to cut. AI is extraordinary at the first thing and useless at the other two.
What actually changed
Four things, and they're real. I'd have been sceptical about all four two years ago.
The scaffolding cost collapsed
Starting a project used to have a tax on it. Config, build setup, the boilerplate every site needs and nobody enjoys writing — a day, sometimes two, before anything visible existed. That tax is now close to zero. I describe the shape of the thing and get a working skeleton back in minutes.
This matters more than it sounds, because the tax was heaviest on small projects. A one-page site carried nearly the same setup cost as a ten-page one, which is why so many developers push small clients onto templates — the economics didn't work otherwise. They work now.
Translation between formats became free
A surprising share of web development is moving information between shapes. A client's spreadsheet becomes structured data. A PDF menu becomes a page. Design tokens become CSS. A hand-written list becomes JSON.
This was tedious, error-prone, and impossible to charge properly for. It's now something I hand off and check. On the school project, a genuinely large amount of the work was information architecture of exactly this kind — turning what a school knows into what a website can show. That's the sort of thing that used to eat a week.
Debugging became a conversation
The old loop was: hit an error, search it, read three forum threads from 2019, find that the answer applies to a different version, try something. The new loop is: paste the error and the surrounding code, get a hypothesis, test it.
The hypothesis is wrong reasonably often. But a wrong hypothesis you can test in thirty seconds is worth more than a correct forum post you spend twenty minutes finding — and this is the change I'd least want to give back.
The research phase compressed
"How do other people solve this?" used to be an afternoon. Now it's a few minutes of conversation, followed by verification. The verification part is not optional, and I'll come back to that, because this is also where AI does the most damage.
Where the time actually goes now
This is my honest before-and-after for a typical small business site. The point isn't the exact proportions — it's the shape of the change.
| Phase | Before | With AI | Real change |
|---|---|---|---|
| Scoping & discovery | Days | Days | None. Still conversations with a human. |
| Content gathering | Weeks | Weeks | None — and it's still the top cause of delay. |
| Setup & scaffolding | 1–2 days | Under an hour | Very large. |
| Layout & components | Days | Roughly half | Large, but first drafts need work. |
| Content & data wiring | Days | Hours | Large. |
| Debugging | Unpredictable | Faster, still unpredictable | Moderate. |
| Review & correction | Modest | Substantially more | Larger — this is the new cost. |
| Judgment & decisions | Constant | Constant | None whatsoever. |
Two rows deserve attention. Content gathering hasn't moved at all — the bottleneck on most projects was never engineering, and no model fixes a client who hasn't sent their photos. And review went up. That's the trade nobody puts in the pitch deck: you spend less time producing and more time checking, and if you skip the checking you have simply moved the cost somewhere more expensive. I've written about where that goes wrong in detail.
What didn't change at all
Deciding what to build
A model will happily build whatever you describe. It will not tell you that the thing you described is the wrong thing — that your homepage leads with your company history when your customers care about whether you deliver on time, or that the form asking for nine fields is why nobody completes it.
Nearly every website that fails, fails here. It's rarely built badly. It's built well and pointed at nothing.
Knowing when something is subtly wrong
This is the skill AI has made more valuable, not less. Model output is plausible by construction — it's optimised to look like a correct answer. Which means the failure mode isn't obviously broken code, it's code that runs, looks reasonable, and is wrong in a way you'll discover in production.
Spotting that requires knowing what correct looks like. You cannot supervise work you couldn't have done.
Taste
AI-generated design converges on the average of everything it has seen, which is precisely what a brand is trying not to be. It produces competent, familiar, forgettable layouts. For a creator with 600,000 subscribers, competent and familiar was the entire problem — her store needed to feel like her, and average is the opposite of that.
Accountability
When a booking form silently drops enquiries, the client calls a person. No model is on the hook. That asymmetry hasn't shifted at all, and it's most of what a client is actually buying.
What I learned building the generator
Building an AI website generator taught me more about the limits of AI website generation than building sites by hand ever did.
WebSeek does the thing it says: one prompt, a working custom-coded site, in any language. It's genuinely useful and people ship real pages with it. But every hard problem in it turned out to be a problem of knowing what the user meant, not generating code. Someone types "website for my restaurant" and the model has to invent a hundred decisions nobody made — how many dishes to show, whether bookings matter more than the menu, whether the location or the food is the reason people come.
It invents them plausibly. Sometimes it invents them well. It never invents them knowingly, and the difference shows up exactly where the money is.
Running it on three providers made a second thing obvious: the model is the least interesting variable. Swapping between Claude, GPT and Gemini changes the texture of the output and very little else. What actually decided quality was the structure around the model — what context it got, how the output was validated, what happened when it failed. I've written that comparison up in more detail.
Where AI shows up in a build besides writing code
"AI in web development" gets read as "AI writes the code", and that's the least of it now. On a current project it turns up in six places, and the code is only one.
First drafts of content. Not final copy — clients don't want a website that sounds like everyone else's, and models default to exactly that. But the blank page is the real enemy on most projects. A rough draft a client can react to gets content out of them ten times faster than an empty document and a polite reminder, because reacting is easier than creating.
Structured data and schema. Marking up a business properly — the entity, the services, the location, the FAQs — is fiddly, repetitive and easy to get subtly wrong. It's a good fit for generation plus validation. On the Baglamukhi Travels build the schema graph is a real part of why it averages position 5.7 in Search Console, and building that by hand would have been an afternoon of tedium.
Accessibility and edge-case review. Asking a model to go through a component looking for missing labels, contrast problems and keyboard traps catches a useful proportion of the obvious ones. It doesn't replace real testing, and it won't tell you a flow is confusing. It's a first pass, not an audit.
Test cases. Enumerating what could go wrong with a form is a job models are unreasonably good at, because it's a breadth problem rather than a judgment one.
Explaining code to clients. Turning an architecture decision into something a non-technical owner can follow used to take real effort. It's now a rewrite request.
The features themselves. Distinct from all of the above: AI inside the finished site — search that understands a question, support that answers from real documentation. That's a different discipline with different failure modes, and I've covered which of those actually earn their place separately.
What a week of this actually looks like
Abstractions are easy to argue with, so here's the concrete version — a typical week on a small business site, and where the tool does and doesn't appear.
Monday is a call and no AI at all. What does the business do, who buys, what's the one action the site needs to produce, what's gone wrong with the current site. Nothing here is a model's job. This is also where most of the project's real decisions get made.
Tuesday is structure — pages, URLs, headings, what each page is for. I'll think out loud against a model here, mostly to argue with it. It suggests the conventional structure, which is genuinely useful as a baseline to deviate from. The deviations are where the value is, and it never proposes those.
Wednesday is the heaviest AI day: scaffolding, components, first-draft layouts, wiring content. This is the day that used to take three and now takes one. It's also the day I review the most, because volume of output is exactly when things slip through.
Thursday is the parts that are mine — the specific interaction that makes the site feel like the brand rather than a template, the performance work, the bits where "average of everything seen" is the wrong answer.
Friday is checking: real devices, real network throttling, forms actually submitting, redirects mapped if we're replacing something, Search Console wired up. Little AI, high stakes. A broken form on a site that looks perfect is worse than an ugly site that works.
Add it up and the tool is heavily involved in about a day and a half of five. That day and a half used to be three or four days, which is a genuine transformation. It is also not the same story as "AI builds websites now".
The change nobody planned for: being found
There's a second transformation running alongside the building one, and for most business owners it will matter more.
People increasingly ask an assistant for a recommendation instead of scrolling a results page. That's a different game with a different referee: search rewards the page that earns the click, assistants reward the source that's easiest to quote accurately. Being quotable means clear factual claims, real structured data, and content that answers a question in a self-contained way rather than teasing it.
The practical consequence is that AI has changed what a website is for at the margins. It's no longer only a destination — it's also the training and retrieval surface that determines how you get described when you're not in the room. I've written about the difference between optimising for a click and optimising to be the answer, and the concrete steps for getting recommended by ChatGPT.
This one is genuinely new. It isn't a faster version of something we already did.
If you're commissioning a website
Three practical consequences.
The floor rose, so a bad website is now inexcusable. Slow, ugly and broken used to have a budget defence. It doesn't any more — the baseline is cheap to reach. If a developer is charging real money, what you're paying for is everything above that floor.
Ask about supervision, not tools. "Do you use AI?" is a dead question; nearly everyone does. Ask what they wrote by hand and why. Ask what they've rejected from a model's output recently. Someone who can answer specifically is supervising the tool. Someone who says "we use the latest AI" is being supervised by it.
Speed claims deserve more scepticism, not less. AI compresses the build, not the project. If someone promises a week, ask what happens to discovery, content and review — because those didn't get faster, and the school portal we shipped in seven days only worked because the client answered questions the same day, every day. That was a scheduling achievement as much as an engineering one.
If you want the fuller decision framework, AI builders versus a developer covers where each one genuinely wins.
If you're a developer
The uncomfortable part first: if your value was knowing syntax, that value is gone. Not declining — gone. The same is true of assembling standard layouts slowly.
What's worth more now is everything that was previously hard to charge for. Understanding a business well enough to argue with the brief. Recognising when generated code is subtly wrong. Knowing which corner is safe to cut. Owning the outcome when it breaks.
The practical risk is skill atrophy in the middle. Junior developers can now produce code far beyond their ability to debug it, which is fine until something breaks in production and there's no mental model to fall back on. If you're early in this, the discipline worth keeping is simple: don't ship what you couldn't have written. My own workflow, including where I deliberately don't use it, is written up in how I build client sites with Claude Code.
The honest summary
AI has been transformative for web development in the way electric tools were transformative for carpentry. The work is faster, the floor is higher, fewer people are needed for the same output, and none of it made the design decisions for anybody.
The carpenters who did well weren't the ones who refused the tools or the ones who believed the tools would do the thinking. They were the ones who got faster at the boring parts and spent the time saved on the parts that were always the point.
That's where this is. The benefits are real and worth taking, the limitations are real and worth respecting, and what comes next is more of the same, faster. Anyone telling you it's simpler than that is selling something.