Eén prompt is geen engineeringproces: zo laten we AI-code nakijken door vier specialisten

Wie vandaag AI gebruikt om software te bouwen, werkt meestal in één lineair gesprek: een prompt schrijven, code terugkrijgen, die overnemen en hopen dat er in productie niets breekt. Voor een tikfout in een footer volstaat dat ruimschoots.

Voor werk waar merk, beveiliging, mobiel gebruiksgemak en data samenkomen, is het een risico. Eén generalistische agent die zich op de vormgeving concentreert, ziet makkelijk iets over het hoofd: een invoerveld dat op een iPhone de pagina laat inzoomen, HTML die niet veilig wordt opgeschoond, of een databasetabel zonder toegangsregels.

Daarom werken we bij For the Dream niet met één agent die alles tegelijk moet bewaken. Grotere wijzigingen lopen door een vaste route: plannen, bouwen en daarna een controle door vier specialisten die elk maar één domein bewaken. Pas als ze alle vier groen geven, gaat de code richting productie.

In dit artikel leggen we uit hoe die route werkt, wie wat doet en waar de grenzen liggen. We illustreren het met een verzonnen maar realistisch scenario: een advocaten- en verzekeringskantoor, dat we hier Vanguard Legal & Indemnity noemen, vraagt een nieuw online intaketraject voor schadeclaims en mandaten.

1. Niet elke taak verdient een commissie

De route start met een eenvoudige vraag: hoe groot is deze wijziging? Een kleine aanpassing gaat rechtstreeks, een grotere krijgt de volledige controle.

Vraagt een partner van ons voorbeeldkantoor om een telefoonnummer in de footer te wijzigen, dan gaat dat direct en is het binnen enkele minuten klaar.

Vraagt hetzelfde kantoor een nieuw intaketraject, met fotografie per praktijkdomein, leesbare tekst over die foto's, een vertrouwelijk formulier om een claim en documenten in te dienen en een automatische onboarding van nieuwe cliënten, dan raakt dat meerdere pagina's, formulieren, opslag en beveiliging. Die opdracht gaat de volledige route in, en er wordt een statusbestand aangemaakt dat de hele tijd bijhoudt waar de taak staat.

2. De route in vijf stappen

De volledige route heeft vijf vaste stappen. Na het bouwen splitst ze zich in vier parallelle controles, die daarna weer samenkomen bij één poortwachter.

Faalt een controle, dan gaat de taak terug naar een gerichte herstelstap en daarna opnieuw langs de controles. Die lus is bewust begrensd: na twee herstelrondes stopt het systeem en neemt een mens het over. De volgorde en de regels liggen vast. Wat de agents binnen een stap schrijven, blijft het werk van een taalmodel en dus niet voorspelbaar tot op de letter. Juist daarom staat er een controle achter.

3. Wat er in elke stap gebeurt

Stap 1: de bestaande code in kaart brengen

Voor er code geschreven wordt, brengt de eerste stap de bestaande code in kaart met een codegraaf: een index die weet welke functie welke andere gebruikt. Dat is betrouwbaarder dan zoeken op tekst. Voor ons voorbeeld vindt deze stap waar de kleuren en lettertypes van het designsysteem staan, waar de kaarten per praktijkdomein worden opgebouwd en welke serverfuncties het formulier verwerken, en welke onderdelen daarvan afhangen.

Stap 2: het plan, en een mens die het goedkeurt

De tweede stap maakt het technische plan. Voor ons voorbeeld zijn dat drie onderdelen. De fotografie bij Procesvoering, Cyberverzekering en Fusies en overnames krijgt een vast brandpunt, zodat gezichten nooit achter tekst verdwijnen of worden weggesneden. Over die foto's komen kleurverlopen die een contrast van minstens 4,5:1 garanderen, de WCAG-norm voor gewone tekst. En het formulier en het databaseschema worden ontworpen.

Bij grote structurele keuzes pauzeert de route hier. Een mens keurt het plan goed of stuurt het terug, en pas daarna wordt er gebouwd.

Stap 3: bouwen

De derde stap schrijft de TypeScript, de React- en Next.js-componenten, de CSS en de serverfuncties. In een gewone AI-werkwijze stopt het proces hier. Bij ons is dit pas halfweg: zodra de code af is, beginnen de vier controles.

4. De vier specialisten

Na het bouwen nemen vier specialisten de wijziging tegelijk onder handen. Ze bewaken elk één domein, werken met een vaste lijst regels en hebben er geen belang bij de bouwer te sparen.

Specialist 1: beveiliging

Bij een juridisch of verzekeringsplatform kan één lek het beroepsgeheim of de gegevens van een polishouder blootleggen. Deze specialist controleert elk gewijzigd bestand op drie punten.

• HTML opschonen met een allowlist, niet met reguliere expressies. Vrije tekst in een claimomschrijving wordt opgeschoond met een bibliotheek als DOMPurify, die alleen toegelaten tags doorlaat en <script>, <iframe>, <object> en inline event handlers verwijdert.
• Botcontrole die echte cliënten niet blokkeert. Een formulier dat te snel wordt ingevuld, wijst vaak op een bot. Loopt de klok van een bezoeker voor op die van de server, dan kan de gemeten tijd negatief uitvallen. De specialist controleert dat zo'n meting niet als bot wordt behandeld.
• Geen persoonsgegevens in logs. De serverlogs bewaren alleen de uitkomst en de reden, nooit namen, polisnummers of dossierinhoud.

Specialist 2: mobiel en frontend

Een advocaat of bedrijfsjurist die een dringende claim op een iPhone bekijkt, heeft niets aan een verschoven layout of een pagina die plots inzoomt.

• Minstens 16 pixels in formuliervelden. Elk <input>, <select> en <textarea> heeft op schermen smaller dan 768 pixels een lettergrootte van minstens 16 pixels. Kleiner, en Safari op iOS zoomt in zodra iemand een veld aantikt.
• Sticky header die blijft staan. overflow-x: hidden op een bovenliggend element maakt er een scrollcontainer van, waardoor een sticky header niet meer blijft kleven. De specialist eist overflow-x: clip, dat horizontale overloop afsnijdt zonder die bijwerking.
• Compacte header en vlotte knoppen. De mobiele header blijft één rij hoog, en knoppen krijgen touch-action: manipulation, zodat een snelle dubbele tik niet als zoombeweging wordt gelezen.
• Leesbare tekst over foto's op elk scherm. Het contrast van minstens 4,5:1 wordt nagemeten op 320, 390, 768, 1024 en 1440 pixels breed, zonder horizontale overloop.

Specialist 3: backend en data

Wanneer een polishouder een schade meldt of een bedrijfsjurist een belangenconflict laat nakijken, moeten de gegevens kloppen en afgeschermd zijn.

• Sleutels en relaties. Records krijgen UUID's als sleutel, en tussen claims, mandaten en polishouders gelden strikte foreign keys.
• Toegang per rij. Row-Level Security in PostgreSQL zorgt dat elk record alleen zichtbaar is voor de organisatie en de rol die er recht op heeft.
• Inloglinks die een virusscanner overleven. Bedrijfsmailfilters openen links vaak automatisch om ze te scannen. Een inloglink die bij dat eerste openen al wordt verbruikt, werkt daarna niet meer voor de echte ontvanger. De specialist controleert dat de link eerst een pagina toont waarop de gebruiker zelf bevestigt.

Specialist 4: QA en runtime

Code lezen is niet genoeg; ze moet ook draaien. Deze specialist bouwt het project echt en test het in een browser.

• Hij voert de typecontrole, de linter en een volledige productiebuild van Next.js uit.
• Hij laat een geautomatiseerde browser (Playwright) de pagina's openen op mobiel, tablet, laptop en desktop, en controleert contrast, de tabvolgorde met het toetsenbord, de rustige variant voor wie minder beweging wil (prefers-reduced-motion) en het ontbreken van fouten in de console en het netwerk.

5. Herstellen zonder eindeloze lus

Wat gebeurt er als een specialist iets vindt? Stel dat in ons voorbeeld beveiliging en data groen geven, maar de mobiele specialist twee problemen meldt: het veld voor het polisnummer staat op mobiel op 14 pixels, waardoor iOS inzoomt, en op de kaart van Cyberverzekering zakt het contrast op een scherm van 390 pixels naar 3,6:1.

De poortwachter verzamelt alleen wat faalde, met het exacte bestand en de regel, bijvoorbeeld ClaimForm.tsx regel 42 en practice-card.module.css regel 18.

De herstelstap past precies die twee punten aan: het lettertype van het veld gaat naar 16 pixels, en het kleurverloop op de kaart wordt onderaan donkerder.

Daarna lopen alleen de controles opnieuw die faalden, plus de QA-specialist, die altijd meedraait. Beveiliging en data behouden hun groene status, tenzij de herstelling hun bestanden raakte.

Na maximaal twee herstelrondes is het klaar of stopt het systeem. Blijft een probleem na de tweede ronde bestaan, dan neemt de verantwoordelijke ontwikkelaar het over met een rapport dat per bestand en per regel zegt wat er nog misloopt. Zo blijft een agent niet eindeloos proberen en tokens verbranden.

6. Altijd zichtbaar waar de taak staat

Tijdens de hele route houdt het systeem een statusbestand bij. Op elk moment kan een ontwikkelaar zien welke stap loopt, welke controles groen zijn en wat er nog openstaat. Voor ons verzonnen voorbeeld zou de eindstand er na één herstelronde zo uitzien:

Wat dit wel en niet oplevert

Deze werkwijze maakt software niet foutloos. Ze verkleint wel de kans dat een heel domein over het hoofd wordt gezien omdat één agent op iets anders gefocust was. Elke specialist kijkt alleen naar zijn eigen lijst, de herstellus is begrensd en bij twijfel beslist een mens.

Het verschil tussen een prototype en een platform waar een organisatie op kan bouwen, zit in de regels waar je niet van afwijkt. Door die regels vast te leggen en elke wijziging er door vier specialisten tegelijk aan te laten toetsen, maken we ze afdwingbaar in plaats van afhankelijk van wie er die dag aan werkte.