Software laten bouwen met AI: zeven vragen vooraf

Bijna elke softwarebouwer zegt inmiddels dat hij AI gebruikt. Dat zegt op zichzelf niets — het verschil zit in wat er omheen staat. Wij bouwen twee eigen SaaS-producten volledig met AI-coding agents en draaien ze in productie met betalende gebruikers, dus we kennen zowel de winst als de rekening. Dit zijn de zeven vragen die wij zelf zouden stellen, met per vraag hoe een goed antwoord klinkt.

1. Van wie is de code, en waar staat hij?

De code hoort van jou te zijn, in jouw repository, op jouw infrastructuur, met jouw sleutels. Dat is niet vanzelfsprekend bij AI-gedreven bouwers: sommige partijen leveren op hun eigen platform, waar de “AI-versnelling” in zit die je niet mee kunt nemen.

Een goed antwoord is een repository-URL en een lijst met accounts die op jouw naam staan. Een slecht antwoord is dat je het “natuurlijk altijd kunt exporteren”.

2. Wie is verantwoordelijk als de agent een fout maakt?

Er is maar één werkbaar antwoord: de bouwer, precies zoals bij code die met de hand is getikt. Een agent is gereedschap. Wie het gereedschap kiest, draagt het resultaat.

Let op formuleringen waarin het model de schuld krijgt. “Het model heeft dat zo gegenereerd” is geen verklaring maar een verplaatsing van aansprakelijkheid, en het voorspelt hoe het gesprek gaat lopen als er iets misgaat in productie.

3. Hoe weet ik dat de code veilig is?

Dit is de vraag die het hardst nodig is en het minst wordt gesteld. Veracode testte in het 2025 GenAI Code Security Report de uitvoer van meer dan honderd taalmodellen op beveiligingstaken: 45% van de codevoorbeelden zakte voor de beveiligingstoets en introduceerde kwetsbaarheden uit de OWASP Top 10. Voor Java lag dat op 72%. (Bron: veracode.com, gepubliceerd 30 juli 2025, geraadpleegd 7 september 2026.)

Dat cijfer betekent niet dat AI-code onbruikbaar is. Het betekent dat ongereviewde AI-code onbruikbaar is, en dat de vraag niet “gebruiken jullie AI” moet zijn maar “wat staat er tussen de agent en productie”. Een goed antwoord noemt concrete poorten: statische analyse, dependency-scanning, en een mens die elke wijziging leest voordat hij samengevoegd wordt.

4. Hoe wordt er getest, en waarop?

Groene tests bewijzen dat de code doet wat er is opgeschreven, en verder niets. Dat klinkt als een dooddoener tot het je overkomt: bij Pilot-Next bouwden we een snelheidsbegrenzer op de inlogpagina die volledig getest was en in productie niet werkte, omdat het IP-adres via twee proxy-lagen binnenkwam. De agent had precies gebouwd wat er gevraagd was; de vraag was verkeerd. Dat verhaal staat uitgeschreven in wat SaaS bouwen met AI-agents echt kost.

Een goed antwoord gaat daarom over waar de tests zitten, niet over hoeveel het er zijn. Op geld, op rechten en op integraties hoort dekking; op de rest is volledige dekking verspilling. Bij booxx staan bijna vierduizend automatische tests, geconcentreerd op de boekhoudkundige invarianten — een boeking die niet in balans is, mag simpelweg niet kunnen ontstaan.

5. Kan een andere partij het later overnemen?

Dit is de vraag waarmee je de meeste toekomstige kosten afkoopt, en hij wordt bijna nooit gesteld tijdens het kiezen van een bouwer. AI-code kan technisch prima werken en tegelijk zo gestructureerd zijn dat niemand anders er nog wijs uit wordt.

Een goed antwoord is te controleren zonder dat je zelf kunt programmeren: staat er documentatie waarmee een volgende ontwikkelaar begint, draait de deploy-pijplijn op jouw account, en zijn de tests leesbaar genoeg om als beschrijving van het gedrag te dienen? Wij schrijven bij een overname van bestaande software de tests vaak eerst, juist omdat ze de documentatie zijn die er niet was.

6. Wat gaat er níét sneller?

Als een bouwer hierop geen scherp antwoord heeft, heeft hij het nog niet lang genoeg gedaan. Het eerlijke antwoord is: beslissen gaat niet sneller. Het gaat zelfs langzamer, omdat je vaker beslist — als de uitvoering tien keer sneller is, komt de volgende keuze tien keer eerder.

Dat heeft een gevolg voor jou als opdrachtgever, en dat is de belangrijkste zin van dit stuk: het zwaartepunt verschuift van bouwen naar beslissen, en dus van de bouwer naar jou. Een project met AI-agents loopt niet vast op capaciteit maar op een opdrachtgever die er één dag per week voor heeft. Vraag dus ook wat er van jou wordt verwacht en hoe vaak.

7. Wat gebeurt er met onze gegevens?

Spreek vooraf af wat er wél en niet naar een AI-leverancier gaat, en leg vast dat het per functie een keuze is en geen standaardinstelling. Bij documentextractie is de goedkope weg vaak ook de veilige: eerst de tekstlaag uit het bestand halen en alleen bij twijfel een model raadplegen.

Vraag ook of de modelaanroep achter één laag zit. Zit hij dat, dan is overstappen naar een ander model — of naar een model dat in Europa draait — een configuratiewijziging in plaats van een verbouwing.

De zeven vragen in één tabel

Waarom wij dit kunnen opschrijven

Omdat we de rekening zelf hebben betaald. Pilot-Next en booxx zijn geen demo’s maar draaiende producten met betalende gebruikers, gebouwd met agents onder eigen review, inclusief de keren dat het misging. Dat is een ander soort kennis dan een presentatie over AI-versnelling.

Wil je weten of dit past bij wat jij wilt bouwen — stuur een mail. Een half uur is meestal genoeg om te weten of het klopt, en als het niet past zeggen we dat meteen.