AI-ontwikkeling begint bij de blauwdruk, niet bij de code

Wanneer AI te snel gaat

Projectmeeting, week 6. De demo is morgen. "Kun je uitleggen wat dit doet?" vraagt de klant terwijl ze naar het scherm wijst. De developer kijkt naar zijn scherm, dan naar de Product Owner. "Ehm... dit is een overzichtsscherm voor... wacht, hadden we dit niet anders afgesproken?"

De Product Owner bladert door haar notities. "Volgens mij wel, maar... ik kan het niet terugvinden."

"AI bouwt supersnel," zucht de developer. "Maar ik weet niet meer precies wat we hadden bedacht."

Dit scenario is niet uniek. Vorige maand zag ik vergelijkbare situaties bij drie verschillende teams. Niet omdat ze slecht zijn - integendeel, het waren gedreven mensen die vol enthousiasme met AI aan de slag gingen. Het probleem? Ze begonnen te bouwen zonder eerst te blueprinten. AI versnelt het maken, maar het voorkomt niet dat je de verkeerde kant opgaat. En snel de verkeerde kant op is duurder dan langzaam de goede kant op.

Waarom structuur belangrijker wordt met AI

Tools als Cursor of GitHub Copilot zijn indrukwekkend. Maar ze zijn geen gedachtelezers. Ze reflecteren wat je erin stopt. Een vage prompt als "Maak een app voor zorgplanning"? Dan krijg je code met losse eindjes, inconsistente variabelen of functies die net niet doen wat je bedoelde. Maar een concrete instructie met context uit je blauwdruk? Dan krijg je output die niet alleen draait, maar ook naadloos integreert.

Een bevinding die ik keer op keer zie: teams met goede documentatie hebben veel minder iteraties nodig. Niet omdat de AI beter is, maar omdat de richting duidelijker is. Bij één project zag ik het verschil letterlijk: Team A werkte zonder blauwdruk en had na 3 maanden nog steeds 3 verschillende prototypes die allemaal "bijna werkten". Team B begon met 2 weken plannen, gevolgd door 6 weken bouwen. Resultaat: een werkende pilot, eerste versie direct in productie.

Het punt? AI is krachtig, maar alleen als je eerst denkt als een developer - of beter gezegd: als een team. Plan vooruit, documenteer helder, en laat AI het zware werk doen.

Van idee naar bouwplan: de blauwdruk

Laten we het concreet maken. Stel, je team wil een ECD-systeem bouwen voor de zorg (elektronisch patiëntendossier). Omvangrijk genoeg om te laten zien waar het misgaat zonder structuur, en perfect om de potentie van AI te demonstreren.

Belangrijk: Deze aanpak werkt voor élke app - of je nu een boekingssysteem, dashboard of webshop bouwt. De principes blijven hetzelfde.

Product Requirements Document (PRD): Definieer het 'wat' en 'waarom'

Je PRD is het fundament. Hierin beschrijf je de aanleiding (bijv. "Zorgverleners verliezen 40% van hun tijd aan administratie"), het doel ("Toegang tot patiëntdata in 3 clicks in plaats van 15 minuten zoeken"), de gewenste impact, de doelgroep (zorgverleners, patiënten), must-have features en hoe je succes meet.

Houd het kort en duidelijk - idealiter 2-5 pagina's. Gebruik user stories zoals: "Als arts wil ik snel patiëntgegevens inzien, zodat ik geïnformeerde beslissingen kan nemen tijdens een consult."

Waarom dit cruciaal is voor teams: Zonder PRD praat iedereen langs elkaar heen. De developer denkt aan "patiëntgegevens" als technische data-entries. De zorgverlener denkt aan "een overzichtelijk scherm met de laatste 3 consulten". Zonder PRD bouw je twee verschillende dingen.

Tip voor AI: Schets het in een tekstbestand en gebruik het als context. Prompt: "Genereer user stories op basis van dit PRD." Zonder die context? AI vult de gaten met gokken. Met 3 prototypes die allemaal net iets anders doen als gevolg.

Functional Overview (FO): Schets de flow

Nu duik je in de how: wireframes of flows zoals login → dashboard → patiëntdata-input → rapportage. Figma werkt prima, maar pen en papier met een foto is net zo effectief. Het gaat om het visualiseren van de route die een gebruiker aflegt.

Waarom dit voor teams werkt: Als je naar een wireframe wijst, weet iedereen precies wat "het overzichtsscherm" betekent. Geen veronderstellingen meer, gewoon: "Zie je dit scherm? Hier komen 3 kolommen met deze informatie."

AI-boost: Prompt AI: "Genereer een user flow diagram op basis van dit PRD." Resultaat: een valideerbare blueprint in no-time. Je kunt zelfs direct interface mockups maken met tools als Lovable, Google AI Studio of Claude voor een HTML/CSS prototype. Het duurt een paar minuten en geeft je meteen iets tastbaars om te bespreken.

Technical Overview (TO): Wat heb je nodig?

Kies je techniek: welke tools ga je gebruiken voor de interface? Welke voor de database? Welke voor beveiliging? Denk ook na over risico's zoals privacy (AVG/GDPR in de zorg), koppelingen met bestaande systemen, schaalbaarheid als het aantal gebruikers groeit.

Waarom essentieel voor AI: Het beschrijven van het TO helpt je om vroeg na te denken over wat technisch mogelijk is. Het helpt bij het kiezen van de juiste tools die passen bij je eisen (bijvoorbeeld privacy-eisen in de zorg), identificeert mogelijke problemen voordat je code schrijft, en zorgt ervoor dat AI code maakt die ook echt werkt voor jouw situatie.

Bij één project zag ik dit misgaan: team bouwde 3 weken lang met AI, om in week 4 te ontdekken dat de gekozen database niet AVG-compliant kon worden ingericht. Alles opnieuw. Als ze een TO hadden gemaakt, was dit in dag 2 boven water gekomen.

Techstack: Kies je tools slim

Selecteer wat bij je past, rekening houdend met je skills, projecteisen, en wat je wilt bereiken. Voor een prototype ECD-project kies ik meestal moderne webtools voor de interface, een betrouwbare database-oplossing, en Cursor met Claude als AI-assistent om te bouwen.

💡Pro-tip: Maak een simpele tabel met voor- en nadelen - AI kan die zelfs voor je uitwerken. Dit helpt om bewuste keuzes te maken en zorgt dat je techniek aansluit bij wat je wilt bouwen.

Praktijkvoorbeeld:

Buildplan: De roadmap

Op basis van de documentatie (PRD, FO, TO en techstack) maak je een buildplan, gericht op de implementatiefase. Ik doe dit vaak in een simpel tekstbestand: start met een korte aanleiding en doel, verdeel het in fases met duidelijke stappen, en voeg een overzichtstabel toe per fase om de voortgang bij te houden.

Focus op wat er moet gebeuren, niet op hoe de techniek precies werkt - dat doet AI voor je. Houd het simpel en overzichtelijk, dan blijft het bruikbaar. Voor teams is dit cruciaal: iedereen ziet in één oogopslag waar jullie staan en wat er nog komt.

💡AI-integratie: Prompt: "Maak een sprintplan op basis van deze TO en techstack." AI stelt een planning voor, jij past het aan naar je team-realiteit.

Voorbeeld in actie: Bouwen met blueprint

Hoe werkt dit in de praktijk? In plaats van direct een opdracht te geven zoals "Genereer een ECD met functie x, y en z", heb je nu een blauwdruk met PRD-onderdelen, flows en TO-overzichten die je AI-tooling als context krijgt. Daarnaast heb je een bouwplan met prioritering en afhankelijkheden per fase.

Het resultaat? Code die niet alleen draait, maar ook naadloos integreert met de rest van de app. Zonder die blueprint had AI waarschijnlijk een generieke form gegenereerd, zonder de specifieke zorg-validaties zoals checks op dubbele entries of privacy-filters die nodig zijn voor AVG-compliance.

Concreet voorbeeld uit een recent project:

Week 1: We maakten samen de blauwdruk. PRD met 8 user stories, FO met 5 hoofdflows, TO met tech-keuzes en AVG-checklist.

Week 2-3: Developer prompts Cursor met context uit de blauwdruk. "Bouw een inlogscherm volgens ons TO. Email/wachtwoord login, geen social login. Houd het simpel en toegankelijk voor zorgverleners." Cursor bouwt het correct in één keer.

Week 4: Intake-formulier. Zonder context genereerde AI een samenvatting in Engels, vol medisch jargon. Met PRD-context ("Samenvatting moet begrijpelijk zijn voor Nederlandse zorgverleners, geen medisch jargon") was de tweede versie meteen goed.

Week 6: Demo met klant. Alles werkt, geen verrassingen. Klant vroeg: "Jullie hebben dit snel gedaan, hoe?" Antwoord: "AI bouwde het. Wij maakten de blauwdruk."

De key takeaway: AI fungeert als een ervaren co-piloot die accelereert, maar jij bepaalt de route. Door eerst te blueprinten, voorkom je trial-and-error en til je de output naar professioneel niveau.

Start met je eigen blauwdruk

Je hoeft geen ECD te bouwen om deze aanpak te gebruiken. Elke app wordt beter met een blauwdruk. Of je nu een boekingssysteem, dashboard of interne tool maakt.

Begin hier:

1. Deze week: Pak je volgende project. Schrijf in 1-2 pagina's: wat wil je bereiken en waarom? (dat is je PRD-kern)
2. Volgende week: Schets de hoofdflows op papier of in een tool. Waar begint de gebruiker, waar eindigt de flow?
3. Week 3: Bepaal je techstack. Welke tools passen bij je team en project-eisen?
4. Daarna: Start met bouwen. Gebruik je blauwdruk als context voor AI.

Voor teams: plan 1-2 dagen in om dit samen te doen. De investering betaalt zich terug in week 1 van bouwen, wanneer iedereen weet wat er gebouwd moet worden en waarom.

"AI werkt niet magisch. Het werkt methodisch."

Versie 1 hoeft niet perfect te zijn. Het moet goed genoeg zijn om feedback te krijgen en te itereren. Begin vandaag.

---

📥 Start met de PRD Template Lite

Zie zelf hoe 2 uur planning je 20 uur debugging scheelt.

Download de PRD Template Lite (gratis) - de basis structuur waarmee ik elk AI-project start. Genoeg om direct te beginnen en het framework te ervaren.

Ready voor de volledige toolkit? De Pro versie met 10+ praktijkvoorbeelden, 20+ AI-prompts en video walkthroughs is onderdeel van Framework Access (€1.500/jaar).

---

Volgende: Mission Control: Je GPS voor bouwen met AI →