Waarom je AI-appbouwer je eerst nepdata toont (en waarom dat de juiste zet is)

Je beschrijft een app aan je AI-appbouwer. Een minuut later kijk je naar een werkende interface — pagina’s, knoppen, een tabel met gebruikers genaamd dingen als “Alex Rivera” en “Priya Shah”, prijzen die geen hout snijden, een “Pro Plan” waar je niet om vroeg. Niets is opgeslagen. Als je ververst, is de data er nog steeds. Als je een nieuwe gebruiker toevoegt, verdwijnt hij.

Het ziet eruit als een goocheltruc die op het punt staat uit elkaar te vallen. Dat is het niet. Dat is het goede deel van de build. De nepdata op je scherm is een doelbewuste eerste stap, en het is de reden dat de database die hierna komt echt zal overeenkomen met de app die je wilde.

Wat “eerst nepdata” echt betekent

Wanneer een AI-appbouwer je briefing neemt, gaat hij niet rechtstreeks naar de database. Een goede schrijft eerst de schermen, vult ze met plausibele plaatshouderdata, en ontwerpt dan — en pas dan — de database om overeen te komen.

De plaatshouderdata is geen decoratie. Het is een contract. Zodra je app zegt “elke bestelling heeft een klantnaam, drie regelitems, een totaal en een status”, moet de database die hierna wordt gebouwd precies die dingen hebben, in precies die vormen. De schermen beslissen hoe de data eruitziet, niet andersom.

Dit is achterstevoren ten opzichte van hoe een menselijke ontwikkelaar gewoonlijk zou beginnen. Een traditionele ontwikkelaar ontwerpt eerst de database, bouwt dan schermen ertegen. AI-bouwers draaiden dat om, en de meeste mensen merken het niet — ze zien gewoon de nepgebruikers en nemen aan dat de bouwer het faket.

Waarom deze volgorde beter werkt met AI

We probeerden de database en de schermen tegelijk te bouwen. Het werkte niet. Hier is de korte versie van waarom.

Wanneer twee AI-agents aan verschillende delen van een app werken zonder elkaars output te zien, maken ze incompatibele gissingen. De interface-agent beslist dat gebruikers een “name”-veld hebben. De database-agent beslist dat gebruikers een “fullName”-veld hebben. Ze zien er allebei correct uit. Samen werkt niets. Een derde agent wordt erbij gehaald om de mismatch te lappen. Hij gist ook. Nu zijn er drie gissingen op de loop, en de app die je previewt is een soort Frankenstein van allemaal.

De fix is bijna gênant: doe eerst één ding, dan het andere. De interface wordt gebouwd. Hij schrijft op welke data hij nodig heeft als een enkel bestand met nepgebruikers, nepbestellingen, nep-waar-je-app-ook-over-gaat. De database-agent leest dat bestand en matcht het veld voor veld. Geen gissingen. Geen onderhandeling. Geen mismatch.

Daarom kan je AI-appbouwer je in een minuut een afgewerkt ogende app tonen. Hij heeft de build niet gefaket. Hij heeft een kwart van de build gedaan — het deel dat al het andere beslist — en de database is de volgende tien seconden werk, niet de volgende tien uur.

Waar je op moet letten wanneer de nepdata op het scherm staat

Dit is het moment dat de meeste mensen overslaan. Ze zien de plaatshouderdata en beginnen om kleurveranderingen te vragen. Maar de plaatshouderdata is een vraag die aan jou wordt gesteld. Lees hem.

Een paar voorbeelden van waar je op moet letten:

• Verkeerd vocabulaire. De app die je wilde, volgt “zendingen”. De plaatshouderdata noemt ze “bestellingen”. Vertel het de bouwer. Als je het nu laat glippen, gebruiken elk scherm, elk databaseveld, elk rapport het verkeerde woord — en later hernoemen is geen operatie van één klik in welke tool dan ook, wat de marketing ook zegt.
• Ontbrekende velden. De nepfactuur heeft een totaal en een datum. Je hebt ook een PO-nummer nodig. Beter om het nu toe te voegen, wanneer er vijf nepfacturen op een scherm staan, dan nadat de database is gebouwd en gevuld met echte klantdata.
• Verkeerde vormen. De nepdata toont “1 klant, 1 adres”. Je echte klanten hebben meerdere adressen. De bouwer kan dat niet afleiden uit je briefing. Vertel het hem nu, terwijl het veranderen van de vorm niets kost.
• Verrassende entiteiten. De bouwer verzon een “team”-concept waar je niet om vroeg, omdat hij een multi-user-app aannam. Misschien wilde je het. Misschien niet. Hoe dan ook, beslis voordat de database eromheen wordt gebouwd.

Een nuttige regel: als je app een zelfstandig naamwoord bevat dat niet is vertegenwoordigd in de plaatshouderdata op het scherm, weet de bouwer er nog niet van. Noem het voordat je op “opslaan” klikt bij de eerste preview.

Waarom de volgorde ertoe doet voor wat erna komt

Zodra de plaatshouderdata juist is, is de databasebuild mechanisch. De bouwer leest je nepdata, genereert een schema dat overeenkomt, schrijft de queries die de schermen al proberen aan te roepen, en verwisselt ten slotte de plaatshouder-imports voor echte. Dezelfde schermen die nepgebruikers toonden, tonen nu wat je er echt in zet.

Je kunt de verwisseling meestal in realtime zien gebeuren. Een pagina die meteen laadde omdat hij een lokaal bestand las, heeft nu een laadstaat van een halve seconde — dat is het scherm dat voor het eerst met een echte database praat. De meeste mensen missen dit en beseffen niet dat de app zojuist de lijn van “demo” naar “ding dat echte data kan opslaan” heeft overschreden.

De reden dat dit überhaupt werkt, is dat alles stroomafwaarts — het databaseontwerp, de queries, de laadstaten, de lege staten — werd beslist door wat je op het scherm zag tijdens de plaatshouderfase. Als je drie kolommen goedkeurde, krijg je drie kolommen. Als je een “status”-veld goedkeurde met waarden “concept” en “verzonden”, is dat precies wat de database accepteert. Er is geen tweede vertaalstap waar een ontwerper-ontwikkelaar-overdracht dingen verknoeit.

Een kleine test die je kunt uitvoeren

De volgende keer dat je iets bouwt, probeer dit: wanneer de plaatshouderdata opduikt, verander één ding eraan voordat je om iets anders vraagt. Hernoem een veld. Voeg een kolom toe. Vervang “gebruikers” door “leden”. Kijk dan wat er gebeurt wanneer de database wordt gebouwd.

Je zult de verandering overal zien opduiken — in het databaseontwerp, in de queries, in de seed-data die de bouwer erin zet wanneer de app klaar is. Eén woord in de plaatshouderfase rimpelde door de hele app. Dat is de hefboom die je tijdens deze fase hebt, en het is de reden dat “eerst nepdata” geen hoeken-afsnijden-truc is. Het is waar de app echt wordt beslist.

Als je dieper wilt gaan, loopt onze laatste post over wat er echt in een met AI gebouwde app zit door de andere bewegende delen die je in eerste instantie niet kunt zien. Het patroon is hetzelfde: de meeste hefboomwerking zit in de delen die eruitzien alsof ze er niet toe doen.