Every developer I know is either quietly using an AI coding assistant or loudly insisting they don't. I'm in the first group, and since clients occasionally ask what that means for their project, here is the honest version: where it helps, where it doesn't, and what I never hand over.
First, what this is not
It is not "the AI builds your website." A model given a vague brief produces plausible-looking code that collapses the first time real data hits it. What has actually changed is narrower and more useful: the distance between deciding something and having it working on a real URL got much shorter.
That matters commercially for one reason. The expensive part of a project was never typing. It was the round trips — build a version, show it, learn the brief was slightly wrong, rebuild. Shortening each loop means more loops, and more loops means the thing that ships is closer to the thing you actually needed.
Where it genuinely earns its place
The boring eighty percent
Responsive image variants, form validation, structured data, accessibility attributes, the fourth near-identical service page. This is work that has to be right and rewards nobody for being clever. Handing it over is pure gain — and it's precisely the work that quietly gets skipped on a rushed project, which is why so many sites ship with broken schema and unlabelled inputs.
Exploring before committing
I can now build three real versions of a layout in the time one used to take, put them on a staging URL, and pick with the client looking at actual pages instead of a Figma file. Design decisions made against a real page on a real phone are better decisions.
The unfamiliar corner
Every project has one part I've done less often — a payment edge case, an unusual CMS shape, a browser API I last touched two years ago. The ramp-up there used to be hours of documentation. It's now minutes, and the code that comes out I still read line by line.
Where I don't use it
Anything about what the site should say. Positioning, the order of an argument, which proof point leads — this is judgement about a specific business and its buyers. A model will produce competent, forgettable copy that sounds like every other site in the category, which is the exact problem most sites already have.
Architecture on anything that has to last. Models are agreeable. Ask whether an approach will work and you'll usually be told yes. Deciding what not to build — where the abstraction is premature, which feature is a trap — is the judgement clients are actually paying for.
Anything I can't verify. If I couldn't have written it and can't fully read it, it doesn't ship. Code I don't understand is code I can't fix at 11pm before a launch, and it becomes the next developer's problem too. That standard is also why owning your stack means anything.
What this changes for you, as the client
Mostly it doesn't — and that's the point. You get the same thing: a custom-coded site, reviewed by a person, handed over with the repository and a walkthrough. What changed is that the timeline compressed and the scope you can afford at a given size got larger. The school portal built in seven days against a six-month quote is the shape of that difference.
What has not changed is who is accountable. If something breaks, "the model wrote it" is not an answer any client should accept, and it's not one I'd offer. Every line that ships is mine to defend.
The honest risk
The real danger isn't bad code — bad code shows up in review. It's plausible code: something that works for the demo case and fails quietly on the edge nobody tested. The discipline that matters is not prompting well. It's reading everything, testing the ugly inputs, and staying willing to throw work away.
Which is the same discipline good development always needed. The tool changed. The job didn't.
I'm Divyansh Sood. I build custom-coded websites, stores and web apps, and I ship AI features into production for clients — including my own AI product, WebSeek.ai, which runs on three model providers at once. If you want to know what's genuinely possible for your project versus what just demos well, email me the brief.