AI website builders can generate working sites from prompts in minutes, which makes them useful for non-technical modules and rapid prototyping — and risky for assessment in modules where building the site is the learning outcome. The practical approach is to be explicit per module about what may be generated, what must be hand-built, and what must be declared.
What AI builders are genuinely good for
- Non-technical modules (marketing, business) where a live site is the medium, not the lesson
- Rapid prototyping and layout exploration before hand-building
- Content scaffolding students then customise and justify
- Lowering the barrier for group members with less technical background
The teaching and assessment risks
In modules that assess the craft — HTML, CSS, JavaScript, accessibility, performance — a generated site can hollow out the learning outcome and complicate academic integrity. Builder output also tends toward platform lock-in and markup students cannot explain, which surfaces badly in vivas.
The answer is rarely a ban; it is per-module clarity, the same as with AI code assistants: what may be generated, what must be original, and how use is declared.
Builders inside institutional hosting
Site-builder tooling increasingly ships inside standard hosting control panels — cPanel-based platforms commonly bundle builders (Sitejet Builder being a widespread example), available to students where an institution's hosting setup enables them. Running builders inside institution-provided hosting keeps the resulting sites governed, assessable and inside the usual account lifecycle, unlike work scattered across third-party builder accounts.
A sensible module policy in four lines
- State per assignment whether builders/AI generation are permitted
- Where permitted, require a short declaration of what was generated
- Assess understanding (walkthroughs, vivas) alongside the artefact
- Keep all student sites on institution-provided hosting for visibility
