Je met AI gebouwde app loopt uit de hand. En nu?

Het begon zo goed. Je team ging bouwen met AI-tools, en ineens ging alles sneller. Een werkend prototype in dagen in plaats van weken. Een nieuwe feature vóór de lunch. Management blij, team blij.

En toen veranderde er langzaam iets. Een kleine fix maakt iets totaal anders kapot. Niemand durft nog aan het deel te komen dat de betalingen afhandelt. Er komt een nieuwe developer bij, en die kan na twee weken nog steeds niet uitleggen hoe alles in elkaar zit. De snelheid waar iedereen zo enthousiast over was, wordt ongemerkt precies datgene wat je afremt.

Herkenbaar? Je bent niet de enige.

Een van mijn klanten bouwde een systeem om hun boekhouding te ondersteunen. Het was zo opgezet dat ze het ook als online dienst aan andere bedrijven konden verkopen. Het begon met een kleine proof of concept, die uitgroeide tot de echte applicatie. Alles werd in heel korte tijd gebouwd. En ze kregen klanten. Iedereen blij, toch? Nou ja, tot de eerste klachten over de performance binnenkwamen. Niemand wist echt waarom, en niemand durfde het systeem nog aan te raken, bang dat het alleen maar erger zou worden. De ontwikkeling kwam zo goed als stil te liggen. Geen nieuwe features, boze klanten.
Die applicatie was niet eens met AI gebouwd, maar op een no-codeplatform. Met AI-assisted development gebeurt precies hetzelfde, alleen sneller. En ik heb vergelijkbare situaties veel te vaak gezien. (Lees de volledige case.)

Vijf signalen dat het uit de hand loopt

Hoe weet je of je met een paar kinderziektes te maken hebt, of met iets groters? Dit zijn de signalen waar ik op let:

1. Niemand kan uitleggen hoe het werkt. Er draait code in productie die geen mens echt heeft geschreven, en geen mens echt heeft beoordeeld. Het werkt, tot het niet meer werkt, en dan weet niemand waar je moet beginnen.
2. Kleine wijzigingen, grote verrassingen. Je verandert één ding, en aan de andere kant van de applicatie gaat iets mis. De onderdelen hangen samen op manieren die niemand zo heeft ontworpen.
3. Dezelfde logica, vijf keer. AI lost het probleem op dat voor zijn neus ligt. Het weet niet meer dat het vorige week bijna hetzelfde probleem op een net iets andere manier heeft opgelost. Zo krijg je meerdere versies van dezelfde berekening, elk met eigen kleine verschillen.
4. Tests ontbreken, of testen niets. Ofwel er zijn er geen, ofwel er zijn heel veel door AI gegenereerde tests die vrolijk slagen, wat de code ook doet.
5. Verrassingen rond security en data. Wachtwoorden of sleutels in de code. Invoer die nooit wordt gecontroleerd. Data die terechtkomt waar die niet hoort. AI-tools die niemand heeft goedgekeurd, met bedrijfsgegevens erin geplakt.

En een bonussignaal, misschien wel het meest veelzeggende: de snelheid gaat omlaag in plaats van omhoog. Elke nieuwe feature kost meer tijd dan de vorige, omdat steeds meer tijd opgaat aan repareren wat onderweg kapotging.

Waarom het gebeurt

Het zit zo: AI veroorzaakt de rommel niet. Snelheid zonder structuur doet dat. AI maakt het alleen mogelijk om die rommel veel sneller op te bouwen dan vroeger.

De oorzaken die ik het vaakst zie:

• Geen architectuurregels. Elke prompt is een nieuwe ontwerpbeslissing. AI maakt lokale keuzes die logisch zijn voor de taak van dat moment, en niemand controleert of ze in het geheel passen.
• Prompts in plaats van specificaties. Wat de software moet doen, staat in een chatgeschiedenis die niemand anders kan zien. Zes maanden later weet niemand meer waarom iets zo is gebouwd.
• Geen review. Gegenereerde code gaat in productie omdat hij werkt. Niemand leest hem eerst kritisch door.
• Druk om op te leveren. De eerste resultaten kwamen zo snel dat de lat omhoogging. Een dag nemen voor structuur voelt nu als achterop raken.
• Bouwers zonder ontwikkelervaring. AI maakt het mogelijk dat mensen zonder softwareachtergrond werkende software bouwen. Prima, tot die software ongemerkt bedrijfskritisch wordt.

Doet dit je denken aan mijn stuk over citizen developers? Dat is geen toeval. Het is hetzelfde verhaal: de technologie is zelden het probleem. De ontbrekende structuur eromheen wel.

Eerlijk is eerlijk: ik bouw deze website op dezelfde manier

Deze website is gebouwd met AI-assisted development. En ik heb deze risico’s van dichtbij gezien, zelfs met alle structuur die ik kon bedenken: een uitgeschreven specificatie, een designdocument, en de regel dat elke wijziging via een beoordeelde pull request gaat voordat die live komt.

Er glipte toch dingen doorheen. Placeholdertekst uit de designmockups belandde in de echte templates; een tijdlang meldde elk artikel trots een leestijd van “[X] min lezen”, in plaats van de echte duur. Kleine inconsistenties slopen erin tussen de specificatie en de code. Niets daarvan was dramatisch, en alles werd gevonden, omdat elke wijziging eerst door een review op een previewsite moest voordat die live ging.

Dat is de les die ik eruit heb gehaald: de structuur voorkwam niet elke fout. Ze zorgde ervoor dat de fouten gevonden werden voordat bezoekers ze zagen.

Wat je deze week kunt doen

Het goede nieuws: je hebt geen groot programma nodig om te beginnen. Herken je de signalen hierboven, dan zou ik deze week hier beginnen:

1. Blijf geen nieuwe zaken aan je lijst toevoegen. Je hoeft niet alle ontwikkeling stil te leggen. Maar vanaf vandaag gaat er niets nieuws in productie zonder dat iemand het heeft beoordeeld, iemand die begrijpt wat het doet.
2. Maak een inventarisatie. Wat is er, welke onderdelen zijn kritisch (geld, klantgegevens, alles wat klanten zien), en wie weet wat van elk onderdeel. Je vindt waarschijnlijk een paar onderdelen waar niemand echt eigenaar van is. Dat zijn je grootste risico’s.
3. Begin met het schrijven van specificaties. Leg ze vast, zodat je kunt controleren wat er is ontwikkeld ten opzichte van de specs, en bijhoudt wat je bouwt.
4. Span een vangnet rond de kritische onderdelen. Voordat je iets verandert in de belangrijkste processen, voeg je tests toe die vastleggen hoe ze nu werken. Dan weet je het wanneer je iets kapotmaakt.
5. Schrijf de regels op. Een kort document met je architectuurkeuzes, codeerafspraken en welke AI-tools en modellen zijn goedgekeurd. De meeste AI-codeertools kunnen zo’n bestand lezen en volgen, dus de regels werken voor mensen en AI.
6. Controleer waar je data heen gaat. Welke AI-tools worden gebruikt, en welke bedrijfs- of klantgegevens zijn erin geplakt? Dit is snel gecheckt, en kan duur zijn om te negeren.

Bij de klant die ik eerder noemde, is dit precies wat we hebben gedaan. We namen een stap terug en inventariseerden wat belangrijk was en wie waarvan eigenaar was. We begonnen specs te schrijven en die te vergelijken met wat er al gebouwd was, zodat we wisten waar we aan moesten werken.
En, cruciaal voor dit specifieke project: we begonnen aan een architectuur en alle regels die daarbij moesten gelden.
Allemaal zodat we door konden naar de volgende stap: de ontwikkeling weer onder controle krijgen.

Weer grip krijgen, zonder de oplevering stil te leggen

De eerste week voorkomt dat het erger wordt. Weer echt grip krijgen duurt langer, maar betekent niet dat alles stil moet. Wat werkt:

• Eerst de specificatie, dan de prompt. Schrijf op wat je wilt voordat je AI vraagt het te bouwen. Een paar zinnen zijn vaak genoeg. Het dwingt je om na te denken, en het laat iets achter dat de volgende kan lezen.
• Kleine wijzigingen. Kleine wijzigingen zijn makkelijk te beoordelen, makkelijk te testen en makkelijk terug te draaien. Een enorme door AI gegenereerde wijziging is niets van dat alles.
• Laat het beter achter dan je het aantrof. Elke keer dat iemand een deel van de code aanraakt, ruimt die een beetje op: een dubbeling weg, een test erbij, een duidelijkere naam. Geen groot refactoringproject, gewoon gestaag verbeteren terwijl je oplevert.
• Tests horen bij “klaar”. AI kan tests schrijven, en is daar goed in. Maar een mens controleert wát die tests eigenlijk testen.
• Governance, de lichte versie. Goedgekeurde tools en modellen, duidelijke regels over waar data naartoe mag, en helder eigenaarschap van elk onderdeel van de applicatie. Wie is verantwoordelijk als er iets misgaat? Spreek dat af voordat het gebeurt.

De klant die ik noemde, kreeg weer grip. Het cruciale inzicht: er was geen architectuur vastgelegd. De applicatie begon als proof of concept, waar steeds functionaliteit aan werd toegevoegd. Door het ontbreken van een architectuur kwamen er ernstige problemen in de dataverwerking aan het licht, waardoor het systeem te traag werd om mee te werken.
Dus zetten we een architectuur neer, en vergeleken we stap voor stap de specs met wat er al gebouwd was. We pasten bestaande features aan of voegden nieuwe toe, volledig gecontroleerd en op basis van de juiste architectuur.
Resultaat: de performanceproblemen waren in heel korte tijd opgelost, en de doorlopende ontwikkeling was weer volledig onder controle, mede doordat er governance was ingericht om het team te begeleiden.

Wat je beter niet kunt doen

Drie reacties die ik begrijp, maar niet zou aanraden:

• Helemaal opnieuw beginnen. Verleidelijk, en bijna altijd verkeerd. Zonder nieuwe structuur bouw je dezelfde problemen opnieuw, alleen sneller.
• AI-tools verbieden. Je verliest de snelheid, en mensen gebruiken de tools toch, alleen weet niemand het meer. Dat is shadow IT, opnieuw.
• Het team de schuld geven. Dit is een structuurprobleem, geen mensenprobleem. Het team deed waar iedereen om juichte: snel opleveren.

Houd de snelheid, voeg structuur toe

AI-assisted development is niet het probleem. Bouwen zonder structuur wel. De teams die het meeste uit AI halen, zijn niet de teams die de meeste code genereren; het zijn de teams die die code zes maanden later nog steeds kunnen uitleggen, testen en aanpassen.

Dus: houd de snelheid. Voeg alleen de structuur toe waarmee je die snelheid kunt houden.