"Maak een dashboard met weerdata." Dat is een prompt waar Claude Code prima mee uit de voeten komt. Je krijgt binnen een paar minuten iets werkends. Maar omdat je een dashboard op veel verschillende manieren kunt maken is de kans dat je krijgt wat je voor ogen had erg klein.
Het probleem zit niet in de AI maar in de opdracht. Gelukkig zijn user stories ooit bedacht voor dit probleem.
Drie niveaus van een opdracht
Elke wens die je aan een ontwikkelaar geeft, kun je op drie niveaus formuleren.
Op het eerste niveau staat de functionele wens: wat wil de gebruiker bereiken. Op het tweede de oplossingsrichting: hoe ga je dat realiseren. Op het derde de technische uitwerking: welke code, welke tabel, welke berekening.
Een AI-assistent vult de niveaus die je niet noemt zelf in. Geef je alleen niveau één, dan verzint hij de andere twee. Dat gaat vaak goed, maar ook vaak mis. En je ziet het verschil pas als het resultaat op je scherm staat.
De truc is niet om alle drie de niveaus zelf te bepalen. Dan doe je het werk dat je uit handen wilde geven. De truc is om niveau één scherp op te schrijven en niveau twee te bespreken voordat er code komt.
Wat is een user story?
Een user story heeft een vast formaat: als [rol] wil ik [functionaliteit] zodat [waarde].
Een voorbeeld uit onze training, op een dashboard met historische KNMI-metingen van 27 Nederlandse weerstations:
Als vakantieganger wil ik voor een gekozen maand kunnen zien welk meetstation gemiddeld het warmst was en waar het minste regen viel, zodat ik weet waar ik naartoe kan op vakantie.
Kijk naar wat hier staat en wat niet. Er staat wie het wil, wat hij wil zien en waarom. Er staat niet: maak een tabel, gebruik een kaart, of bereken het gemiddelde per station per maand.
Dat is opzettelijk. Die zin is te controleren zonder dat je iets over de techniek weet. Als het dashboard klaar is, kun je zelf vaststellen of een vakantieganger antwoord krijgt op zijn vraag.
Werken met User Stories & AI
Hier zit de stap die de meeste mensen overslaan. Geef de user story aan Claude, maar vraag nog niet om code:
Als vakantieganger wil ik voor een gekozen maand kunnen zien welk
meetstation gemiddeld het warmst was en waar het minste regen viel,
zodat ik weet waar ik naartoe kan op vakantie.
Bedenk drie mogelijke manieren om dit in het dashboard te tonen
en bespreek met mij welke het beste past.Je krijgt nu bijvoorbeeld: een gesorteerde lijst van stations, een kaart met kleurcodering, of een tabel met twee kolommen die je kunt sorteren. Alle drie zijn goede antwoorden op de user story. Echter, ze zijn niet even goed voor jouw gebruiker.
Dit gesprek kost twee minuten en voorkomt dat je een half uur later naar een kaart kijkt die je niet wilde. Daarnaast maak jij op deze manier de keuze, dus jij kunt achteraf uitleggen waarom het zo is gebouwd.
Acceptatiecriteria: wanneer is een User Story klaar?
Een user story wordt bouwbaar als je erbij zet hoe je gaat controleren of het werkt. Dat zijn de acceptatiecriteria, en die zijn in ons voorbeeld bijvoorbeeld:
- Ik kan een jaar en een maand kiezen.
- Ik zie welk station in die periode de hoogste gemiddelde temperatuur had.
- Ik zie welk station de minste neerslag had.
- Stations zonder metingen in die periode staan niet in de lijst.
Dat laatste criterium is een voorbeeld van iets waar je zelf op moet komen. Historische meetdata heeft gaten: niet elk station meet elk jaar. Zonder dat criterium krijg je misschien een station bovenaan de lijst op basis van één meting uit 1963.
Acceptatiecriteria hebben nog een voordeel dat later terugkomt. Ze zijn de basis voor je tests. Een criterium dat jij handmatig kunt nalopen, kan een AI-assistent omzetten in een test die dat automatisch doet.
Werken met User Stories & AI: Eén feature per keer
De verleiding is groot om vijf user stories in één prompt te gooien. Doe dat alsjeblieft niet.
Begin met een werkende basis, controleer die in de browser, en voeg dan één story toe. Werkt het, dan ga je door naar de volgende. Zo weet je bij een fout altijd waar hij vandaan komt.
Bij vijf stories in één keer krijg je een dashboard waarin drie dingen half werken, en dan moet je gaan zoeken. Eén werkende feature is meer waard dan twee halve.
Deze werkwijze verschilt trouwens niet van goed ontwikkelwerk zonder AI. Wat verandert is het tempo: de bouwstap gaat van dagen naar minuten, waardoor de kwaliteit van je opdracht relatief veel zwaarder weegt. Over die verschuiving lees je meer in wat vibe coding is.
Wil je zelf aan de slag met dit soort dashboards, dan laat eens een Python dashboard maken.
Wil jij dit ook leren?
In onze Vibe Coding Training leer je in twee dagen websites en apps bouwen met AI, zonder programmeerervaring. Wil je specifiek met Claude werken? Bekijk dan de Claude Code Training. En voor een complete basis in AI zonder programmeren is er de 5-daagse AI Opleiding.
Terry is full-stack AI-ontwikkelaar en data scientist. Hij geeft gestudeerd aan de TU Delft. In zijn carrière richt hij zich al 10+ jaar op het optimaal waarde halen uit data door toepassing van machine learning en AI.
