Why website development is changing with AI

The change is in the working process

The useful question about AI and website development is not whether a machine can produce a page. It is whether a development team can use new tools to deliver a more useful, reliable website without creating avoidable risk. For a business commissioning work, that means looking beyond demonstrations and asking how requirements, implementation and approval will be handled.

GitHub’s research provides evidence that AI assistance can accelerate a defined coding task, but it does not establish that every website project will become faster or cheaper. Its controlled experiment involved building an HTTP server in JavaScript, rather than delivering a complete business website. Treat that distinction as central to any discussion about productivity. ^[1]

A sensible approach is to treat AI output as a proposal. A developer can accept, adapt or reject it against an agreed brief. The business still needs someone accountable for the finished service, including what happens when a customer submits a form, a payment fails or an editor changes an important page.

Separate useful assistance from business decisions

Consider using AI for tightly bounded work: drafting a component from an established pattern, suggesting test cases or explaining an unfamiliar function. These are candidate uses to evaluate, not promised efficiencies. Give each task a clear definition of completion so the team can assess the result rather than simply admiring how quickly it appeared.

Do not delegate decisions about your audience, commercial priorities or service promises to a tool. Start with the questions your website must answer. Which services need explanation? What makes an enquiry suitable? What information must a customer receive before booking? A technically plausible page is not evidence that these decisions have been made well.

• Define the user task and the business rule before generating an implementation.
• Supply approved design patterns and content, rather than asking the tool to invent them.
• Keep a named person responsible for accepting each change.
• Record assumptions that need confirmation from the business.

Productivity evidence needs careful interpretation

The research does not point in one universal direction. METR’s early-2025 randomised study involved 16 experienced open-source developers completing 246 tasks in familiar repositories. Allowing AI tools increased completion time by 19% in that setting. METR now labels those results out of date and says they no longer reflect the current impact of AI models on open-source developer productivity. Treat this as historical evidence from a particular setting, not proof that AI always slows development. ^[2]

METR’s February 2026 update adds an important qualification. The organisation reported that selection effects and difficulties measuring work with concurrent agents made its newer experiment an unreliable signal of the current productivity effect. It considered greater speed-ups plausible, but said its data was only very weak evidence for their size. ^[3]

For a website buyer, the practical response is to ask for evidence from the proposed workflow. Compare similar tasks and include review, corrections and testing. Avoid converting a laboratory percentage into a discount expectation for a project that also includes research, copy, integration and launch planning. Agree what will be measured before work starts.

Quality checks remain part of development

AI-assisted development should not create a separate, lighter approval route. The NCSC’s secure development principles include producing maintainable code, protecting the development environment and repository, continually testing security and planning for flaws. Those principles provide a better foundation for supplier questions than a list of AI products. ^[4]

Ask the team to show how changes are reviewed and tested before release. For a lead-generation website, specify checks for required fields, failed submissions, duplicate requests and confirmation messages. For a booking journey, include unavailable slots and cancellation handling. These are proposed acceptance checks; choose the ones that match the consequences of failure in your business.

Accessibility also needs explicit attention. W3C’s forms guidance covers labels, instructions, validation and notifications, including helping users understand and correct errors. Use that guidance to review important journeys rather than assuming a generated interface is accessible because it looks tidy. Include keyboard use and understandable feedback in the acceptance discussion. ^[5]

Put privacy boundaries around the tools

Before allowing project information into an AI service, decide what may be shared. Prefer synthetic enquiry examples during development. Keep customer messages, credentials and private documents out of prompts unless the proposed processing has been assessed and authorised. Ask who can access submitted information and what the supplier’s settings and terms permit.

The ICO’s AI and data protection guidance addresses accountability, transparency, fairness, security and data minimisation. It is marked as under review following the Data (Use and Access) Act, so use it as a starting point and check current guidance for the actual deployment. Do not interpret the presence of a human reviewer as a complete privacy assessment. ^[6]

If the website itself will use AI, define a human handover. An assistant proposing answers about services is a different proposition from a system making consequential decisions about customers. Specify what it may answer, which approved material it may use, and when it must stop and refer someone to a member of staff.

Commission for the website’s full life

Ask for an understandable handover, not just a successful launch. Include ownership of accounts, access permissions, deployment instructions, a maintenance plan and a route for reporting faults. Request an explanation of any unfamiliar dependencies. These are sensible commissioning requirements whether code was typed manually, generated with assistance or assembled from existing components.

Keep scope choices separate from tool choices. A smaller, well-defined website may be a better fit than an ambitious platform whose ongoing responsibilities are unclear. Equally, a complex integration should not be described as simple merely because a tool produced a first draft. Price the agreed responsibility and quality standard, not the volume of generated code.

Practical next steps

Before approving an AI-assisted build, ask the supplier to walk through one representative journey from requirement to release. Review the result with someone who handles real customer enquiries. Use that discussion to identify missing rules and agree who can approve changes. Start with a contained piece of work if the process is unfamiliar.

• Write down the website’s essential user journeys and acceptance criteria.
• Agree permitted AI tools, data boundaries and human approval points.
• Include accessibility, security and failure scenarios in testing.
• Measure complete task effort, including review and rework.
• Confirm ownership, maintenance and the handover before launch.