You have probably been told two contradictory things this year. One is that AI now writes software and development costs are about to collapse. The other is that AI code is unusable garbage and nothing has really changed. Neither matches what happens in a working development team on a Tuesday.
What follows is a practitioner's account of where AI in web development genuinely changes the work, where it does not, and what that means if you are commissioning a website or an application. We are deliberately not naming model versions or quoting capability claims, because those change monthly and the underlying pattern does not.
Where AI genuinely helps today
The honest summary: AI is very good at producing plausible code for problems that have been solved thousands of times before, and much weaker as novelty increases. That sounds like faint praise, but a large fraction of commercial web development is exactly that kind of well-trodden work.
Boilerplate and scaffolding
Setting up a form with validation, wiring a REST endpoint to a database table, writing a data model, converting a design into responsive markup, generating a migration, writing the seventeenth CRUD screen in an admin panel. These are tasks where the correct answer is well-established and the developer's time was going into typing rather than thinking. AI assistance removes a real amount of that typing.
Test generation
Writing tests is the classic case of work that everyone agrees is valuable and nobody enjoys. AI is genuinely useful at drafting unit tests against existing code — it enumerates cases methodically, including the null and empty ones humans skip when tired. The important caveat: it writes tests that assert what the code currently does, not what it should do. If the function has a bug, you get a test that locks the bug in. A human still has to read the assertions and ask whether each is correct.
First drafts and translation
Converting a component from one framework to another, rewriting a function in a different language, drafting documentation for existing code, explaining an unfamiliar codebase to a new developer, turning a rough specification into a starting structure. The output needs review, but a reviewed draft is faster than a blank file.
Working through unfamiliar libraries
Previously, using an unfamiliar package meant an hour of documentation reading. Now a developer can get a working starting example in minutes and read the documentation to verify it. That is a real change in pace, though it introduces its own risk: developers who ship code from libraries they never actually learned.
Content and copy scaffolding
On the client-facing side, AI drafts product descriptions, alt text, meta descriptions and FAQ content quickly. This is useful for getting a site populated. It is not a substitute for someone who knows the business writing the pages that matter, and search engines have become steadily better at recognising undifferentiated generated text.
Where AI does not reliably help
This is the part vendors skip, and it is the part that determines whether your project succeeds.
Architecture
Deciding how a system should be structured requires holding the whole problem in view: what the business will need in eighteen months, where the load will concentrate, which parts must be replaceable, what the team can maintain, what the budget actually is. AI produces confident architectural suggestions, but they are pattern-matched from common cases rather than reasoned from your constraints. Ask it about a system and it will frequently propose more moving parts than your situation warrants — microservices for an application with 300 users, a message queue where a database table would do.
The failure here is subtle and expensive. Bad architecture does not break on launch day. It breaks in month nine when a change that should take two days takes three weeks.
Security review
AI will catch obvious issues — a raw SQL string concatenation, a missing escape. It is far less reliable on the things that actually cause breaches in web applications: broken access control, where a user can change an ID in a URL and see somebody else's data; business logic flaws, where the checkout can be manipulated to apply a discount twice; misconfigured permissions on file uploads or storage buckets. These require understanding intent, and intent is not visible in the code.
There is a second-order risk too. Generated code tends to look tidy and confident, which makes reviewers less suspicious of it than they would be of a junior developer's messy first attempt. Tidy and wrong is a dangerous combination.
Novel problems and genuine debugging
When the bug is a race condition that appears once a day under load, or an interaction between two libraries that nobody has documented, AI assistance drops off sharply. It will suggest plausible fixes with the same confident tone it uses when it is right, which can send a developer down several wrong paths. Real debugging — forming a hypothesis, instrumenting, narrowing — remains human work.
Knowing what to build
The most valuable conversations in a project are about what not to build: which of the twenty requested features actually matter, which requirement is a symptom of a process problem, what the client means as opposed to what they said. That work has not been touched by AI at all.
What AI in web development means for your project cost
The commercially interesting question. The honest answer is that costs have shifted rather than collapsed, and the shift is uneven.
Where the savings are real
| Type of work | Effect of AI assistance |
|---|---|
| Standard brochure or marketing site | Meaningfully faster; much of it was already templated |
| Admin panels and internal CRUD tools | Noticeably faster — highly repetitive code |
| Test coverage on existing code | Faster to draft, still needs review |
| Standard integrations with well-documented APIs | Somewhat faster |
| Custom business logic and workflow systems | Little change — the hard part is the requirements |
| Architecture, security, performance work | Essentially unchanged |
| Discovery, scoping, stakeholder alignment | Unchanged |
| Long-term maintenance | Unchanged, and possibly worse if code was shipped unreviewed |
Notice the pattern. The tasks that got faster are the ones that were already cheap. The tasks that dominate the cost of a serious project — understanding the problem, designing the system, and keeping it alive for years — are largely untouched.
What this means for quotes you receive
If an agency quotes dramatically below market because "we use AI", ask a specific question: which parts of this project does AI make faster, and who reviews the output. A credible answer names the boilerplate and testing, and describes a review process. A vague answer about AI-powered efficiency usually means the discount is coming out of the review step, and you will pay for that later.
Conversely, if you are being quoted the same as three years ago for a straightforward brochure site, that is worth questioning too.
The maintenance question nobody asks
This is the risk we would most want a client to understand.
Code volume goes up
When writing code becomes cheap, people write more of it. Generated solutions tend toward verbosity — more abstraction layers, more dependencies, more configuration than the problem requires. Every line of that has to be understood by whoever maintains the system in two years, and that person may not be the one who generated it.
Comprehension debt
There is a difference between code that works and code the team understands. A developer who writes a module knows why each decision was made. A developer who accepted a generated module and confirmed it passed tests knows only that it passed tests. When it breaks in production at 11pm, that difference matters enormously.
The practical guard is simple and worth putting in your contract: the delivering team must be able to explain any part of the codebase on request. If they cannot walk you through why a piece of code exists, they do not own it, and neither do you.
Dependency sprawl
AI suggestions often reach for a library where a few lines would do. Each dependency is a future security advisory, a breaking change, and an upgrade someone has to perform. Ask your team to justify additions.
How to work with a team that uses AI — practical questions
Assume your development partner uses AI assistance. Almost all competent teams do now, and a team that claims it uses none is either behind or not telling you the whole story. The useful questions are about process, not tooling.
- Who reviews AI-assisted code, and is that review documented? The answer should be a named human, with pull request review as a required step.
- What is your policy on our proprietary code going into external tools? This matters if your codebase contains business logic that is genuinely confidential. Enterprise tiers of coding tools generally offer no-training guarantees; consumer tiers may not.
- How do you handle security review? The answer should include something other than AI — dependency scanning, a manual review of authorisation logic, ideally a penetration test for anything handling payments or personal data.
- Can any developer on the team explain the whole system? If the answer is that only the original author understands a module, that is a maintenance risk regardless of how the code was produced.
- What did AI actually speed up on this project? A specific answer indicates a team that has thought about it. A marketing answer indicates one that has not.
What about AI features inside your product?
Separate question from AI in the development process, and worth addressing because clients frequently conflate the two.
Where it earns its place
Search that understands intent rather than exact keywords, summarising long free-text input, drafting replies for a support agent to edit, categorising incoming enquiries, extracting structured data from documents or images. These share a shape: the output is a suggestion a human confirms, and being occasionally wrong is tolerable.
Where it does not
Anywhere a confident wrong answer causes harm. A customer-facing chatbot that quotes prices, states policies or confirms availability without a verified data source will eventually state something false, and you will be held to it. If you want a chatbot, constrain it to retrieving from your own documented content, give it a clear route to a human, and test it adversarially before launch.
The cost people forget
AI features have a running cost per use, unlike ordinary application logic. Model that before you build. A feature that costs a small amount per request is fine at a hundred requests a day and a genuine line item at fifty thousand. Also plan for what happens when the provider changes pricing, deprecates a model, or has an outage — your feature needs a defined fallback behaviour.
Our recommendation
Treat AI in web development as a real improvement to a specific part of the work, not as a change in what building software costs or requires. Expect it to speed up boilerplate, tests and first drafts. Do not expect it to reduce the effort of getting requirements right, designing a system that survives, or securing an application that handles other people's money and data.
When you commission work, judge the team the same way you would have three years ago: on the questions they ask before quoting, on whether they push back on your requirements, on their review process, and on whether they can explain what they built. Those signals still separate good work from bad. AI has changed how the code gets typed. It has not changed what makes a project succeed.