Wat een SaaS-product bouwen met AI-agents echt kost

Er wordt veel geschreven over hoe snel je met AI-agents kunt bouwen. Er wordt weinig geschreven over wat het kost. We hebben er twee producten mee gebouwd — Pilot-Next voor vliegclubs en booxx voor de Nederlandse boekhouding — allebei in productie, allebei met echte gebruikers. Dit is de rekening.

Wat er echt sneller ging

De eerste versie van iets is niet drie keer sneller. Hij is ongeveer tien keer sneller. Een compleet scherm met formulier, validatie, foutafhandeling en tests staat er in een uur in plaats van in een dag. Dat is geen marginale winst en het verandert wat je durft te proberen: als een idee een uur kost in plaats van een dag, gooi je het ook een uur later weer weg.

Het tweede dat echt sneller ging is het saaie werk waar je normaal omheen loopt. Foutafhandeling op alle paden. Vertalingen bijhouden in vijf talen. Tests op randgevallen die je zelf wel ziet maar niet zou opschrijven. Dat werk is niet moeilijk, het is alleen vervelend, en precies dat soort werk doet een agent zonder morren.

Wat er niet sneller ging

Beslissen. Elke keuze over het datamodel, elke afweging tussen twee manieren om iets te doen, elke vraag of iets er überhaupt in hoort — dat gaat niet sneller, want dat gaat over jouw begrip van het probleem en niet over typewerk.

Sterker: het gaat langzamer, omdat je vaker beslist. Als de uitvoering tien keer sneller is, komt de volgende beslissing tien keer eerder. We hebben dagen gehad waarin het voelde alsof er niets gebeurd was omdat er alleen maar gekozen was — en waarin er wel drie schermen bij waren gekomen. Het zwaartepunt van het werk is verschoven van maken naar besluiten, en dat is vermoeiender dan het klinkt.

De rekening: waar het misging

Het interessantste is niet wat er werkte. Hier zijn drie dingen die fout gingen, allemaal op een manier die je met een menselijk team ook zou hebben — alleen sneller en dus vaker.

1. Een oplossing die er goed uitzag en niets deed

Pilot-Next kreeg een snelheidsbegrenzer op de inlogpagina. De code klopte, de tests waren groen, de header zei netjes limit: 5. In productie werkte hij niet: het aantal resterende pogingen sprong heen en weer — 3, 4, 4, 3, 2 — in plaats van af te tellen.

De oorzaak zat niet in de code maar eronder. De begrenzer telde per IP-adres, en dat adres kwam via twee proxy-lagen binnen, zodat elk verzoek een ander adres leek te hebben. De agent had precies gebouwd wat er gevraagd was; de vraag was alleen verkeerd.

Wat we ervan hebben geleerd is niet “AI maakt fouten”. Het is dat een groene testsuite bewijst dat de code doet wat je hebt opgeschreven, en verder niets. De enige manier waarop dit aan het licht kwam, is door de echte site vijf keer achter elkaar een verkeerd wachtwoord te geven en naar de antwoorden te kijken. Meten in productie is geen luxe, het is de enige plek waar de aannames van je code op de werkelijkheid stuiten.

De verleiding daarna was om terug te vallen op de X-Forwarded-For-header. Dat hebben we niet gedaan: een aanvaller mag die zelf invullen, dus dat is een rem die je met liegen kunt resetten. Zo’n rem is slechter dan geen rem, want hij geeft je het gevoel dat je beschermd bent.

2. Een configuratiebestand dat loog

In dezelfde repo staat een render.yaml waarin voor drie diensten autoDeploy: true staat. We hebben daar maandenlang op vertrouwd, in de veronderstelling dat een merge naar master de site publiceert.

Dat was niet zo. Bij één van de drie diensten stond het in de hostingomgeving zelf op uit. Het bestand in de repo is een blauwdruk voor het aanmaken van een dienst en geen levende weergave van de instellingen; wie er daarna in het dashboard iets wijzigt, laat het bestand achter als een keurig gedocumenteerde onwaarheid.

Dit is geen AI-fout, maar hij wordt door AI-tempo wel gevaarlijker: als er tien keer zoveel wijzigingen langskomen, is de vraag “staat dit eigenlijk wel live” tien keer zo vaak relevant. Sindsdien controleren we de werkelijke instelling via de API en niet het bestand dat erover gaat.

3. Een cijfer dat nergens vandaan kwam

Op de site van Pilot-Next stond jarenlang een waardering van 4,9 uit 5. In de structured data stonden negen echte reviews. Toen die eindelijk ook op de pagina zichtbaar werden, bleek het gemiddelde 5,0 te zijn — alle negen stonden op vijf sterren. De 4,9 was uit niets af te leiden.

Het was geen leugen die iemand bedacht had; het was een getal dat er ooit was ingezet en waar niemand meer naar terugkeek. Dat is precies het type fout dat schaalt als je snel bouwt: niet de spectaculaire, maar de kleine bewering die niemand meer natrekt. Sindsdien komen het gemiddelde en het aantal uit dezelfde lijst reviews, berekend bij het bouwen. Er is geen plek meer waar je het cijfer met de hand kunt zetten.

Wat het onder de streep betekent

Bouwen met AI-agents is geen kwestie van minder werk. Het is een kwestie van ánder werk. Het typewerk verdwijnt grotendeels; wat overblijft is architectuur, oordeel en verificatie — en dat is precies het deel waar seniority voor bestaat.

De drie dingen die het verschil maken:

1. Poorten die niet te omzeilen zijn. Tests, typecheck en build groen vóór er iets samengevoegd wordt. Een agent die een test aanpast zodat hij slaagt, hoort er niet doorheen te komen.
2. Meten in productie. Elke aanname over gedrag buiten je eigen machine is een hypothese tot je hem hebt nagekeken op de echte site.
3. Eén bron per feit. Elk getal dat je toont, hoort berekend te worden uit de plek waar het vandaan komt. Een cijfer dat je met de hand kunt zetten, gaat een keer afwijken.

Wat het níét is, is een manier om zonder senior kennis software te maken. De agents zijn buitengewoon goed in het uitvoeren van een instructie. De prijs van een verkeerde instructie is alleen gedaald van een week naar een uur — en dat maakt het belangrijker, niet minder belangrijk, dat er iemand is die weet welke instructie de juiste is.