The Rise of AI in Web Development

AI is now part of everyday web development, but the useful conversation is smaller and more practical than the usual headlines suggest.

I am not especially interested in whether AI will "change everything". The more useful question is what it changes on a real project with an existing codebase, production users, deadlines, tests, analytics, accessibility needs, performance constraints and other developers who have to maintain the result later.

Used well, AI can remove some friction. It can produce a first pass at a component, explain an unfamiliar API, sketch a test case, help with repetitive refactoring and make documentation less painful to start. Used badly, it makes poor code cheaper to create. That is the part that gets missed when the discussion stays at the level of productivity demos.

AI is Fastest Before the Work Becomes Accountable

AI tools are good at producing plausible drafts. ChatGPT can outline an implementation. GitHub Copilot can complete boilerplate quickly. Image and design tools can produce placeholder assets for early prototypes. None of that is trivial.

The problem starts when a draft is treated as delivery.

Production code has to fit the conventions of the project. It has to work with the existing routing model, test setup, data fetching pattern, error handling, accessibility expectations and deployment environment. The AI output may look fine in isolation and still be wrong for the codebase in front of you.

That is why I tend to think about AI as acceleration at the edge of the work, not ownership of the work. It can help a developer get unstuck, but it cannot be the reason a change is accepted.

The Review Burden Moves, It Does Not Disappear

One risk I have seen in code review is a developer using AI to fill a gap they have not understood. The review then stops being a normal discussion about trade‑offs and becomes archaeology. Why is this abstraction here? Why does the component duplicate an existing pattern? Why has the function changed shape? Why are there three different ways to do the same thing in one pull request?

Sometimes the answer is effectively: "That is what Copilot suggested."

That is not a delivery standard. It is a prompt transcript with a pull request attached.

Generated code still needs to be read as code. It needs the same questions I would ask of any other change:

• Does this fit the existing architecture?
• Is the behaviour covered by a useful test?
• Has it copied a pattern from another part of the app without understanding why that pattern exists?
• Does it add a dependency, abstraction or state model the project does not need?
• Could a later developer explain and modify it without asking the original prompt?

This is where fractional technical leadership and embedded technical leadership matter. The question is not whether a team is allowed to use AI. The question is whether the team still has review discipline, architectural memory and enough senior judgement to keep the codebase coherent.

Where AI Helps in Real Web Work

I use AI most comfortably where the cost of checking the output is lower than the cost of producing the first draft manually.

That can include:

• drafting small utility functions
• generating test cases for behaviour I have already defined
• explaining unfamiliar library APIs
• summarising logs or error output
• proposing edge cases for a debugging path
• turning notes into a first documentation pass
• helping compare two implementation options

Those uses still need review, but they are bounded. The AI is not designing the system. It is helping with a defined task where the developer can check the result against known constraints.

The weaker uses are broader. "Build this feature" can create a lot of code that looks active but has no strong relationship with the codebase. "Refactor this module" can introduce new shapes without understanding the production reason for the old ones. "Fix this bug" can produce a patch that handles the visible symptom while missing the underlying state, data or deployment problem.

For commercial sites and web applications, that distinction matters. More code is not the same as more progress.

Context Quality Decides Most of the Value

AI output improves when the tool has the right context, but context is not just a prompt. It is the existing codebase, tests, design system, content model, routing decisions, service boundaries, deployment model and the team's own standards.

A Next.js project using Pages Router needs different advice from an App Router project. A Gatsby site with Contentful has different publishing constraints from a Sanity‑backed Next.js app. A Shopify theme issue may not need a headless rebuild. A performance problem may sit in scripts, data fetching, images, fonts or commercial journey design.

Without that context, AI can produce answers that are technically plausible and locally tidy but strategically wrong.

That is why I do not treat generated code as neutral. It has a bias towards the most common public examples it can infer from. Those examples may be outdated, over‑generalised or mismatched to the project. They may also skip the awkward bits: error states, accessibility, caching, deployment behaviour, analytics, editorial workflow and test coverage.

For a messy React or Next.js estate, platform consulting often starts with exactly that problem: what should change, what should stay and which local conventions are doing useful work.

The Mistake to Avoid

The biggest mistake is treating AI‑generated code as evidence that the work is done.

It is evidence that a possible route exists. That is all.

The next step is still engineering. Read it. Compare it with the current code. Run the tests. Add the missing tests. Check the rendered output. Check the failure path. Check the browser behaviour. Remove the abstraction if it does not earn its place. Rename the confusing variables. Delete the clever helper if a simpler local pattern already exists.

AI makes it easy to create code that would once have taken longer to write. That does not make the code easier to own. I wrote more about that specific risk in AI makes technical debt cheaper to create and the related problem of more output producing less value.

Security, Privacy and Ownership Still Matter

There are also dull but important constraints.

Do not paste a client's private source code, production data, credentials or commercially sensitive roadmap into a tool without understanding the policy, retention model and contractual risk. Do not accept generated authentication, payment, SQL, sanitisation or permission code because it looks conventional. Do not rely on an answer about framework behaviour without checking the version and the project context.

AI tools can suggest insecure patterns, stale APIs and incomplete edge‑case handling. They can also produce code that looks more confident than it deserves to be. That confidence is part of the risk.

Good AI use narrows the review surface. Poor AI use expands it.

Sustainability is Part of the Judgement

The environmental and financial cost of large AI systems is not a side issue. Running and training large models requires significant infrastructure. That cost may be justified for some work, but it should make us more selective rather than less.

I have written separately about web development and the environment. The same principle applies here: a tool being clever does not mean every use is automatically worthwhile.

There is a practical sustainability angle inside the codebase too. If AI creates duplicated components, unnecessary dependencies and extra review churn, the project pays for that later in maintenance, onboarding and deployment risk.

How I Would Use AI on a Production Web Project

My preference is controlled use:

• keep prompts narrow
• provide the relevant local context
• ask for a small change rather than a whole feature
• require tests where behaviour changes
• review generated code line by line
• compare the output with existing project patterns
• delete anything that looks clever but unnecessary
• make the developer explain the final decision in their own words

That last point matters. If the person shipping the change cannot explain it, the code is not ready.

I experimented with neural networks long before the current wave of tooling. My 2008 dissertation included a browser‑based racing game where computer‑controlled contestants learned from human players. That early work was crude compared with today's tools, but it left me with a useful bias: the interesting part is not whether the machine can produce behaviour. The interesting part is whether the behaviour is useful, explainable and safe in the system around it.

A Practical Position

AI in web development is useful. It can speed up drafts, improve exploration and help developers get through low‑value friction. I use it, and I expect most teams will keep using it.

The sensible position is neither panic nor worship. Treat AI as a powerful assistant with no accountability. Give it good context. Keep the work small enough to review. Test the result. Preserve the standards of the codebase.

The teams that benefit most will not be the ones that generate the most code. They will be the ones that keep the strongest judgement while the cost of generating code keeps falling.