---
title: "AI-site controleren voor publicatie: 12 checks tegen frontend slop"
date: 2026-06-13
author: "Sam"
categories:
  - name: "Gidsen"
    url: "/category/gidsen.md"
---

# AI-site controleren voor publicatie: 12 checks tegen frontend slop

Een AI-site is niet klaar omdat de knop werkt. Hij is klaar als een bezoeker op mobiel begrijpt wat hij moet doen, foutmeldingen niet vreemd voelen, lange Nederlandse tekst past en de pagina nog steeds vertrouwen wekt zonder demo-content.

Gebruik deze checklist voordat je een site uit Cursor, Lovable, Bolt, Claude Code of Codex live zet. Niet als designexamen, maar als publicatiegate: wat moet je zelf gezien hebben voordat Google en echte bezoekers de pagina zien?

## De snelle diagnose: werkt het scherm alleen in de demo?

AI-gebouwde interfaces falen zelden op één grote fout. Het zit vaker in kleine signalen: een modal die net te hard inspringt, een button met twee regels tekst, een mobile breakpoint waar de hero over de CTA valt, of een formulier dat technisch submit maar geen geruststelling geeft.

Dat is precies waarom “maak het mooier” geen goede prompt is. Een model vult smaakwoorden met gemiddelde patronen: veel cards, paarse glows, te ronde knoppen, vage hero-copy en componenten die afzonderlijk best oké lijken. Je moet de output niet mooier vragen. Je moet hem langs concrete constraints leggen.

## 12 checks voordat je publiceert

1. **Eerste scherm:** staat binnen vijf seconden duidelijk wat de bezoeker hier kan doen?
2. **Mobiel:** test minimaal 390px breed. Geen overlappende hero, menu, CTA of formulierlabels.
3. **Lange Nederlandse tekst:** vervang demo-copy door echte zinnen. Vooral buttons, tabs en cards breken dan snel.
4. **Contrast:** check tekst op beeld, disabled buttons, badges en lichte grijze bodytekst.
5. **Formulieren:** test leeg, fout ingevuld, geldig ingevuld en na submit. Een formulier zonder goede foutstaat is niet klaar.
6. **Loading states:** laat niet alleen een spinner zien. Zeg wat er gebeurt en voorkom dubbele submits.
7. **Error states:** schrijf menselijke foutmeldingen. Geen technische stack of lege rode box.
8. **Empty states:** een leeg dashboard, lege lijst of geen resultaten-pagina moet nog steeds een volgende stap geven.
9. **Modals en drawers:** test openen, sluiten, Escape, scrollen en focus. Janky motion voelt goedkoop.
10. **Consistente spacing:** gebruik een vaste spacing- en radius-schaal. AI maakt anders elk blok lokaal “mooi”.
11. **Beeldtaal:** geen plastic AI-stock, vage glow-achtergronden of nep-screenshots als de gebruiker iets moet beoordelen.
12. **SEO-copy:** haal intro’s weg die alleen het onderwerp aankondigen. De pagina moet direct helpen.

## Wat je beter prompt dan “maak dit professioneel”

Geef de agent regels die je kunt controleren. Bijvoorbeeld:

```
Gebruik een rustige redactionele layout.
Geen cards tenzij items echt naast elkaar vergeleken worden.
Geen gradient-orbs of paarse glow-achtergronden.
Buttontekst mag op mobiel niet afbreken.
Maak states voor loading, empty, error en success.
Test lange Nederlandse labels en 390px mobile viewport.
Leg na afloop uit welke visuele risico's nog handmatig gecontroleerd moeten worden.
```

Dit soort instructies werkt beter omdat je niet om smaak vraagt, maar om gedrag. De agent kan nog steeds fouten maken, maar jij hebt daarna een checklist om tegen te verifiëren.

## Wanneer je niet verder moet prompten

Stop met prompten als de pagina bij elke verbetering elders uit elkaar valt. Dat is meestal geen “nog één prompt”-probleem, maar een systeemprobleem: geen vaste typografie, geen componentregels, geen ontwerpbeslissing over dichtheid, geen mobiele hiërarchie.

Dan is de snelste route vaak handmatig: eerst één scherm goed maken, daaruit componentregels halen, daarna pas de agent verder laten bouwen. Anders train je jezelf om AI-output te poetsen in plaats van een interface te ontwerpen.

## Publicatiegate voor AI-sites

Publiceer pas als je deze vier dingen kunt laten zien:

- desktop- en mobiele screenshots van de belangrijkste flow;
- minimaal één echte foutstaat en één lege staat;
- een korte lijst met handmatige correcties die je na AI-output hebt gedaan;
- een duidelijke canonical: welke pagina ownet deze taak, en welke pagina’s linken ernaartoe?

De beste AI-site voelt niet alsof de agent zijn best heeft gedaan. Hij voelt alsof iemand met smaak en context de laatste beslissing heeft genomen.

## Bronnen en verdere context

- [Slightly reducing the sloppiness of AI generated frontend](https://envs.net/~volpe/blog/posts/reduce-slop.html)
- [Frontend-discussie over AI-slop bij Cursor en Claude Code](https://www.reddit.com/r/Frontend/comments/1ssqj99/how_do_you_avoid_the_generic_ai_slop_look_when/)
- [AI in UI Design Without the Purple Slop](https://www.managed-code.com/blog-post/ai-slop-in-design)
- [How to Avoid AI Code Slop](https://www.aviator.co/blog/how-to-avoid-ai-code-slop/)

Wil je eerst beter leren prompten voordat je een AI-site laat bouwen? Begin dan met [vibe coding](/vibe-coding/), vergelijk [Cursor, Lovable en Bolt](/cursor-vs-lovable-vs-bolt/), en test je output daarna met de checklist hierboven.

## Verder lezen

Werk per use-case. Een beeldprompt, tekstprompt en codeprompt vragen elk om andere controlepunten; bundel ze niet in één generieke opdracht. Lees daarna ook [bekijk de AI-prompt hub](/ai-prompts/) of [gebruik de Prompt Coach](/prompt-coach/).