09 jul 2025·8 min
Hoe AI tekstuele specificaties omzet in echte features en schermen
Leer hoe AI instructies in gewone taal interpreteert, UX-flows plant, UI en code genereert en met feedback iterereert om werkende features en schermen te leveren.
Leer hoe AI instructies in gewone taal interpreteert, UX-flows plant, UI en code genereert en met feedback iterereert om werkende features en schermen te leveren.
"Geschreven instructies" zijn de woorden die je al gebruikt om uit te leggen wat je gebouwd wilt hebben—vastgelegd in een vorm waarop een AI (en een team) kan handelen.
In de praktijk is het doel niet perfecte proza. Het is duidelijke intentie (welk resultaat je wilt) plus duidelijke grenzen (wat is toegestaan, wat niet), zodat het systeem niet hoeft te gokken.
Deze kunnen formeel of informeel zijn:
De kern is dat de tekst uitkomsten en beperkingen beschrijft. Als beide aanwezig zijn, kan AI betrouwbaar schermen, flows en implementatiedetails voorstellen zonder bedrijfsregels te verzinnen.
Een werkende feature is meer dan een mockup. Gewoonlijk bevat het:
Bijvoorbeeld, “opgeslagen adressen” is niet alleen een pagina—het is een set schermen (lijst, toevoegen/bewerken), regels (vereiste velden, standaardadres) en aansluiting (API-aanroepen, state-updates).
De meeste teams belanden in een eenvoudig rondje:
Beschrijf → genereer → review → verfijn
Je levert de specificatie, de AI stelt UI/UX en implementatie voor, je reviewt op juistheid en productfit, en je verfijnt de eisen totdat het resultaat overeenkomt met wat je bedoelde.
Als je een vibe-coding platform gebruikt zoals Koder.ai, wordt deze cyclus vaak nog strakker omdat je op één plek kunt blijven: beschrijf de feature in chat, genereer de app-wijzigingen en iterateer snel met gerichte vervolgvragen (en herstel indien nodig).
AI kan het opstellen van schermen versnellen, flows voorstellen en code produceren, maar mensen blijven verantwoordelijk om:
Zie AI als een versneller om tekst om te zetten in een eerste (en tweede) draft—mensen blijven verantwoordelijk voor het eindresultaat.
AI is flexibel qua formaten, maar kieskeurig over duidelijkheid. Het kan werken vanaf een alinea, een opsomming, een PRD-fragment of een set user stories—zolang intentie en beperkingen expliciet zijn.
De meest bruikbare startpunten bevatten meestal:
Deze elementen vertellen de AI wat je bouwt en wat ‘goed’ is, wat het aantal terugvragen vermindert.
Wanneer eisen ontbreken, vult de AI de gaten met defaults die mogelijk niet overeenkomen met je bedrijfsregels. Neem op:
Vaag: “Voeg een checkout-scherm toe en maak het simpel.”
Concreet: “Voeg een checkout-flow toe voor ingelogde gebruikers. Stappen: Adres → Verzending → Betaling → Review. Ondersteun kaart + Apple Pay. Sla maximaal 3 adressen per gebruiker op. Toon belasting en verzending vóór betaling. Als betaling faalt, bewaar de winkelwagen en toon een retry-optie. Succes = bestelling aangemaakt, ontvangstbevestiging gemaild en voorraad verminderd.”
Duidelijke inputs helpen de AI schermen, copy, validatie en logica te produceren die aansluiten op echte beperkingen. Je krijgt minder mismatchende aannames, minder redesign-cycli en een snellere weg van een eerste draft naar iets dat je team daadwerkelijk kan reviewen, testen en opleveren.
Voordat AI schermen kan genereren of code kan schrijven, moet het uitvinden wat je bedoelt, niet alleen wat je schreef. Deze stap is in wezen het ‘lezen’ van je spec zoals een productmanager: doelen, betrokken personen en de regels die de feature correct maken eruit halen.
De meeste specificaties bevatten een paar terugkerende bouwstenen:
Als deze elementen duidelijk zijn, kan AI tekst vertalen naar een gestructureerd begrip dat latere stappen kan omzetten in flows, schermen, data en logica.
AI herkent ook veelvoorkomende productpatronen en koppelt alledaagse bewoordingen aan implementatieconcepten. Bijvoorbeeld:
Deze mapping is nuttig omdat het vage zelfstandige naamwoorden verandert in concrete bouwstenen die ontwerpers en engineers gebruiken.
Zelfs goede specs laten gaten. AI kan aangeven wat ontbreekt en verduidelijkingsvragen voorstellen zoals:
Soms wil je vooruit zonder alle antwoorden. AI kan redelijke defaults kiezen (bijv. standaard wachtwoordregels, typische dashboard-widgets) terwijl het aannames voor review markeert.
Belangrijk is zichtbaarheid: aannames moeten duidelijk worden opgesomd zodat een mens ze kan bevestigen of corrigeren voordat iets wordt opgeleverd.
Zodra de intentie duidelijk is, is de volgende stap om de geschreven specificatie te vertalen naar iets dat je daadwerkelijk kunt bouwen: een featureplan. Je zoekt nog geen code—je zoekt structuur.
Een goed plan begint met zinnen te vertalen in schermen, navigatie en gebruikersreizen.
Bijvoorbeeld: “Gebruikers kunnen items opslaan in een verlanglijst en later bekijken” impliceert doorgaans (1) een interactie op de productdetailpagina, (2) een verlanglijstscherm en (3) een manier om daar vanuit de hoofdnav te komen.
Vraag de AI om de schermen op te sommen en daarna het “happy path” te beschrijven, plus een paar veelvoorkomende omwegen (niet ingelogd, item is verwijderd, lege lijst).
Vervolgens laat je de AI de feature opsplitsen in taken die teams herkennen:
Hier komen ook vage eisen naar boven. Als de spec niet zegt wat er gebeurt als een gebruiker hetzelfde item twee keer wil opslaan, moet het plan die vraag opsommen.
Houd acceptatiecriteria in gewone taal. Voorbeeld:
Vraag de AI items te labelen als must-have vs nice-to-have (bijv. “deel verlanglijst” kan nice-to-have zijn). Dit voorkomt dat het plan ongemerkt uitloopt voorbij de oorspronkelijke scope.
Met een featureplan in handen kan AI helpen tekst om te zetten in een concreet “schermkaart” en een vroege UI-draft. Het doel is geen pixel-perfect ontwerp in de eerste ronde—het doel is een gedeeld, inspecteerbaar model van wat gebruikers zien en doen.
Begin met het beschrijven van het happy path als een kort verhaal: wat de gebruiker wil, waar ze beginnen, waarop ze tikken en wat succes is. Vanuit dat verhaal kan AI het minimale aantal schermen voorstellen (en wat op elk scherm hoort).
Vraag daarna om veelvoorkomende alternatieven: “Wat als ze niet ingelogd zijn?”, “Wat als er geen resultaten zijn?”, “Wat als ze halverwege afhaken?”. Zo voorkom je een UI die alleen in demo’s werkt.
Als je spec layout-hints bevat (bijv. “header met zoekveld, resultatenlijst met filters, primaire CTA onderaan”), kan AI een gestructureerde draft produceren zoals:
De beste prompts bevatten inhoudsprioriteiten (“toon prijs en beschikbaarheid boven de omschrijving”), interactie-regels (“filters blijven behouden tussen sessies”) en beperkingen (“mobile-first; werkt met één duim”).
Een werkend product heeft meer nodig dan het “normale” scherm. Laat AI de staten opsommen en definiëren die je gaat implementeren:
Deze state-beslissingen beïnvloeden direct ontwikkelingsinspanningen en gebruikersvertrouwen.
AI kan helpen consistentie af te dwingen door herbruikbare componenten en regels voor te stellen: typografieschaal, spacing-tokens, knopstijlen en formulierpatronen.
Als je al componenten hebt, verwijs naar je interne richtlijnen (bijv. /design-system) en vraag de AI ze te hergebruiken in plaats van nieuwe patronen te verzinnen.
Vervolgens vertaal je “wat de app moet doen” naar wat de app moet opslaan en wat de app mag doen. Dit is waar geschreven specificaties veranderen in een concreet datamodel en een set businessregels.
AI begint meestal met de zelfstandige naamwoorden in je tekst te halen en behandelt ze als entiteiten. Bijvoorbeeld, “Gebruikers kunnen Projects aanmaken en Tasks toevoegen, en managers keuren urenbonnen goed” suggereert entiteiten zoals User, Project, Task en TimeEntry.
Voor elke entiteit stelt AI de velden voor die je nodig hebt (en markeert wat ontbreekt):
Het moet ook impliciete randgevallen noemen, zoals “Slechts één actieve subscription per account” (een uniciteitsconstraint) of “Ordertotaal moet gelijk zijn aan som van line items” (een berekende validatie).
Goede output houdt regels leesbaar en niet verborgen in code. Voorbeelden:
Kaart uiteindelijk hoe records in de tijd veranderen: create, update, delete, en wat je in plaats van verwijderen doet (soft delete). AI kan ook audit trails voorstellen (wie heeft wat veranderd en wanneer) en geschiedenis/versioning waar traceerbaarheid nodig is.
Nu kun je de “eerste werkende draft” van code genereren: de UI waar mensen op klikken en de logica die het correct laat gedragen.
Als je Koder.ai gebruikt, betekent dit doorgaans dat het platform een samenhangende full-stack implementatie (web, backend, database) genereert vanuit je chatgestuurde spec, met de optie om broncode te exporteren wanneer je verder wilt werken in een traditionele workflow.
Van een spec zoals “Voeg een ‘Create Project’-scherm toe met naam, eigenaar en zichtbaarheid” kan AI scaffolden:
Het kan ook herbruikbare bouwstenen genereren (bijv. een \u003cProjectForm /\u003e die zowel voor aanmaken als bewerken wordt gebruikt), zodat de code consistent blijft.
Aan de serverkant kan AI het basiscontract voor de feature schetsen:
Het belangrijkste is dat de backendlogica gekoppeld is aan de regels in de spec (“Alleen admins mogen zichtbaarheid op private zetten”) in plaats van zomaar op te slaan wat de UI verzendt.
AI kan de UI verbinden met je API-client (fetch/Axios/React Query, enz.), inclusief caching en retries waar nodig. Het moet ook gebruikersvriendelijke foutafhandeling genereren: veldniveau-meldingen voor validatiefouten en een duidelijke fallback voor netwerkfouten.
// Example: submit handler with loading + error state
async function onSubmit(values) {
setStatus({ loading: true, error: null });
try {
await api.post('/api/projects', values);
router.push('/projects');
} catch (e) {
setStatus({ loading: false, error: 'Could not create project. Try again.' });
}
}
Gegenereerde code is het meest bruikbaar wanneer het je conventies volgt: duidelijke naamgeving, voorspelbare mappenstructuur, kleine functies en gedeelde utilities (validators, API-clients, permissie-helpers).
Als je een styleguide of voorkeurspatronen hebt, verwijs er expliciet naar en noem interne docs zoals /engineering/frontend of /engineering/api-guidelines.
Op dit punt heb je schermen, UI-componenten, datavormen en businessregels. “Wiring” is waar die onderdelen daadwerkelijk met elkaar praten: knoppen activeren acties, acties roepen backend-endpoints aan, responses updaten de UI en permissies bepalen wat mensen zien.
AI kan schermen met elkaar verbinden volgens de geschreven spec door routes (URLs of app-paden) te maken, te definiëren wat er gebeurt na belangrijke acties en de juiste context tussen pagina’s door te geven.
Bijvoorbeeld: “Na opslaan, terug naar de lijst en het nieuwe item markeren” wordt een concreet flow—formulier verzenden → wachten op succes → navigeren naar lijst → toast tonen en de nieuwe rij focussen.
Specs noemen vaak rollen (“Admin kan bewerken, Viewer kan alleen lezen”). Wiring betekent dat op meer dan één plek afdwingen:
AI is nuttig omdat het consistente checks over de app kan genereren (niet alleen voor één scherm), wat het risico vermindert dat iets er geblokkeerd uitziet maar de endpoint nog wel werkt.
De meeste features hangen af van configuratie: API-base URLs, analytics keys, feature flags, storage buckets, enz. AI kan aparte instellingen voor dev/staging/prod opzetten terwijl secrets uit de code blijven.
Typische outputs zijn:
.env-templates (veilige placeholders)Het doel is een volledige lus: “klik → request → response → UI-update.” AI kan de ontbrekende glue-code toevoegen (loading states, foutafhandeling, retries) en eenvoudige checks genereren zoals:
Hier stopt een feature met een mock te zijn en begint het zich te gedragen als een echt product.
Als een feature “werkt”, test het zoals een echte gebruiker (en zoals de rommelige echte wereld). AI helpt door acceptatiecriteria om te zetten in concrete checks—en door saaie debuggingtaken te versnellen.
Als je spec zegt: “Een gebruiker kan hun wachtwoord resetten en ziet een bevestiging,” kan AI testcases voorstellen die overeenkomen met die uitspraak op meerdere niveaus:
De truc is de AI de exacte acceptatiecriteria plus minimale context te geven: feature-naam, sleutel-schermen en bestaande testconventies in je codebase.
Specs beschrijven meestal het happy path. AI is nuttig om de “wat als” scenario’s te bedenken die supporttickets veroorzaken:
Je hoeft niet elk randgeval meteen te implementeren, maar beslis welke belangrijk zijn voor het risiconiveau van je product.
Wanneer een test faalt, geef AI wat een ontwikkelaar ook zou vragen: de falende assertie, relevante logs, stacktraces en exacte reproductiestappen.
AI kan dan:
Behandel deze suggesties als hypothesen. Bevestig ze door de test opnieuw uit te voeren en gedrag in de UI te controleren.
Voor snelle review-cycli, houd een korte checklist:
De eerste AI-gegenereerde draft is meestal “goed genoeg om op te reageren”, niet “klaar om te releasen.” Iteratie is waar je van een plausibele feature een betrouwbare maakt—door eisen aan te scherpen, randgevallen te corrigeren en veranderingen in kleine, reviewbare stappen door te voeren.
Een gezonde loop ziet er zo uit: genereer → review → vraag een specifieke wijziging → vergelijk wat er veranderd is → herhaal.
In plaats van de hele app opnieuw te prompten, mik op gerichte updates. Vraag de AI alleen één onderdeel aan te passen (een scherm, een component, een validatieregel, een query) en een diff of duidelijk gemarkeerde “voor/na” terug te geven. Dit maakt het makkelijker te bevestigen dat de wijziging het probleem oplost zonder per ongeluk iets anders te breken.
Als je workflow het ondersteunt, houd wijzigingen in kleine commits en review ze zoals je de PR van een collega zou reviewen: scan de diff, draai de app en verifieer gedrag.
Platforms zoals Koder.ai profiteren ook van deze aanpak: gebruik een “planning mode” (of een gelijkwaardige stap) om scope en flows eerst af te stemmen, genereer dan en iterateer in smalle slices—en vertrouw op snapshots/rollback als experimenten verkeerd uitpakken.
Vage verzoeken (“maak het mooier”, “fix de flow”) geven vage resultaten. Sterke wijzigingsverzoeken verwijzen naar:
Voeg acceptatiecriteria toe waar mogelijk: “De ‘Betaal’-knop is uitgeschakeld totdat verplichte velden geldig zijn” of “Als het verzendland verandert, herbereken belasting direct.”
Behandel AI-output als code die je bezit. Vereis korte changenotes bij updates: wat is veranderd, waarom het veranderde en wat te testen.
Als een AI refactors voorstelt, vraag om uitleg van het doel en een lijst met potentiële risico’s (bijv. “dit verandert validatietiming” of “dit wijzigt API-response-handling”).
Iteratie stopt wanneer je duidelijke releasecriteria haalt. Definieer grenzen:
Op dat punt bevries je de spec, releaset en plan je de volgende iteratie als een nieuw, afgebakend wijzigingsverzoek.
AI kan geschreven specificaties omzetten naar opmerkelijk complete features, maar het is geen vervanging voor oordeel. Behandel AI-uitvoer als een draft die review nodig heeft—vooral als het gaat om gebruikersdata, betalingen of permissies.
Ga ervan uit dat alles wat je in een prompt plakt mogelijk kan worden opgeslagen of bekeken. Plak geen:
Als je realisme nodig hebt, anonimiseer: vervang namen door placeholders, scramble ID's en beschrijf patronen (“10k users, 3 rollen”) in plaats van raw exports.
AI is nuttig om basis securitychecks te genereren, maar je moet ze nog zelf verifiëren.
Voordat je om code of schermen vraagt, voeg toe:
Als je een conceptprototype hebt, plan een korte review: vergelijk met je roadmap, beslis wat nu shipt vs later en documenteer wijzigingen.
Als je hulp wilt bij het omzetten van drafts naar een plan, zie /pricing of blader door gerelateerde gidsen in /blog. Als je chatgestuurd ontwikkelen onderzoekt, is Koder.ai ontworpen voor deze workflow: zet geschreven specificaties om in werkende web-, backend- en mobiele features, iterateer snel en exporteer de broncode wanneer je er klaar voor bent.
"Geschreven instructies" zijn elke tekst die duidelijk intent (het gewenste resultaat) en grenzen (beperkingen, regels en wat niet is toegestaan) aangeeft. Dat kan een snelle Slack-bericht zijn, een PRD-fragment, user stories, acceptatiecriteria of een lijst met randgevallen — belangrijk is duidelijkheid, niet formaliteit.
Een “werkende” feature bevat meestal meer dan visuals:
Een mockup laat zien hoe iets eruitziet; een werkende feature gedraagt zich correct end-to-end.
De meeste teams gebruiken een simpele iteratieve cyclus:
De snelheid komt van snelle drafts; de kwaliteit van gedisciplineerde review en iteratie.
AI kan snel werken, maar zal gokken als je niet specificeert:
Deze punten vooraf opnemen vermindert herwerk en voorkomt dat AI redelijke, maar onjuiste aannames maakt.
Begin met vier elementen:
Dit geeft de AI richting én een kwaliteitsnorm, niet alleen een idee voor een feature.
Concrete specificaties definiëren:
Deze specificaties vertalen direct naar schermen, regels en API-gedrag.
Vraag de AI eerst om een featureplan voordat je code genereert:
Dit legt ontbrekende eisen vroeg bloot, wanneer veranderen goedkoop is.
Vraag expliciete definities voor elke belangrijke schermstaat:
De meeste productbugs en UX-problemen komen voort uit ontbrekende state-afhandeling, niet uit de happy path.
AI haalt meestal entiteiten (de "zelfstandige naamwoorden") uit de tekst en stelt dan voor:
Laat het ook de datalifecycle beschrijven: create/update/soft-delete en of je audit trails of versiegeschiedenis nodig hebt.
Beschouw AI-uitvoer als een concept en leg grenzen vast:
Gebruik AI om iteratie te versnellen, maar laat mensen verantwoordelijk blijven voor correctheid, beveiliging en kwaliteit.