Waarom AI-code stukgaat in productie
Apps die met AI gebouwd zijn gaan in productie meestal stuk om één structurele reden: ze zijn geverifieerd doordat ze er af uitzagen, niet doordat bewezen is dat ze af waren. De demo slaagt omdat hij de route doorloopt waarop alles goed gaat en die de bouwer al kent. Echte gebruikers nemen die route niet, en de app gaat stuk in precies de situaties die de demo nooit heeft getest. De oplossing is niet om de demo nog meer te testen, maar om te veranderen wat "af" mag betekenen.
De instorting na de demo
Het deel van een AI-build dat te demonstreren valt komt snel en ziet er compleet uit. Wat daarna komt is het deel dat echte gebruikers moet overleven, en daar valt het uit elkaar. Die rest is niet "meer van hetzelfde werk". Het is een ander soort correctheid: de rommelige echte paden, de koude start, de schermen zonder inhoud, de invoer die niemand heeft gedemonstreerd. Door AI gegenereerde code is sterk in het deel dat een demo kan laten zien en, zonder dat het opvalt, zwak in het deel dat buiten beeld blijft. Het gat is onzichtbaar tot gebruikers het vinden.
"werkt als je meteen naar het scherm springt" is niet werken
De storing die in productie veruit het vaakst voorkomt is deze: de functie werkt alleen wanneer ze los wordt geladen, recht naar het juiste scherm, met de juiste toestand al aanwezig. Een echte gebruiker komt koud binnen, van voren af aan, en het pad dat hem daarheen zou moeten brengen was nooit echt aangelegd. Daarom telt een sluiproute naar het scherm niet als bewijs van wat dan ook. Twee controles bepalen "af".
de hoofdhandeling die wordt voltooid via de echte, gerenderde interface; een gebruiker die er voor het eerst komt en de functie bereikt via de route die echte mensen nemen
Allebei zijn het dingen die een demo overslaat en die productie eist.
Een build vragen of hij af is, heeft geen zin
De diepere reden dat deze gaten meegaan naar productie is dat het rapport wordt vertrouwd. Een build die "af" rapporteert, of de AI die hem maakte, zegt bijna niets. Keer op keer valt die zekerheid uit elkaar zodra ze aan de werkelijkheid wordt getoetst. Het enige betrouwbare signaal is bewijs dat niet ontstaat doordat iemand het beweert.
de commit; de test die slaagt; de handeling die wordt voltooid via de echte interface
Wordt "af" daaruit berekend in plaats van beweerd, dan wordt het gat tussen demo en productie zichtbaar voordat gebruikers het vinden, want wat er af uitzag moet het nu bewijzen.
Wat ik eraan doe
Wat na de demo komt behandel ik als het eigenlijke werk, niet als opruimen. Ik maak het product zelf stuk zoals zijn gebruikers dat zullen doen - koude starts, echte navigatie, de invoer die niemand heeft gedemonstreerd - voordat zij het komen doen. Wat het werk beoordeelt houd ik gescheiden van wat het gebouwd heeft, zodat "af" een oordeel uit bewijs is en geen zelfrapportage. Is een build perfect in de demo en sterft hij bij echte gebruikers, dan is dat gat het eerste wat ik lees.