Waarom AI-code stukgaat in productie
AI-gebouwde apps gaan in productie meestal stuk om één structurele reden: ze zijn geverifieerd door er af uit te zien, niet door bewezen af te zijn. De demo slaagt omdat hij het gelukkige pad draait dat de bouwer al kent. Echte gebruikers nemen dat pad niet. En de gaten die de demo nooit heeft beproefd, zijn precies waar het misgaat. De oplossing is niet meer testen van de demo; het is veranderen wat "af" mag betekenen.
De 80/20-instorting
De eerste 80% van een AI-build komt snel en ziet er compleet uit. De laatste 20%, het deel dat echte gebruikers overleeft, is waar het uit elkaar valt. Dat laatste stuk is niet "meer van hetzelfde werk". Het is een ander soort correctheid: de rommelige echte paden, de koude start, de lege toestanden, de invoer die niemand heeft gedemo't. AI-generatie is sterk in de eerste 80% en stilletjes zwak in de laatste 20%, en het gat is onzichtbaar tot gebruikers het vinden.
"Werkt als je meteen naar het scherm springt" is niet werken
Veruit de meest voorkomende productiebreuk: de functie werkt alleen wanneer je haar los laadt, 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 dragen was nooit echt aangelegd. Dus ik weiger een sluiproute-naar-het-scherm als bewijs van wat dan ook. Twee controles bepalen "af":
de hoofdhandeling die wordt voltooid door de echte, gerenderde interface, en een gloednieuwe gebruiker die de functie bereikt via de route die echte mensen nemen.
Beide zijn dingen die een demo overslaat en die productie eist.
Je kunt de build niet vragen of hij af is
De diepere reden dat deze gaten worden uitgeleverd, is dat het rapport wordt vertrouwd. Een build (of de AI die hem maakte) die "af" rapporteert, vertelt je bijna niets. Dat vertrouwen volgt de werkelijkheid slechter dan kop of munt. Het enige betrouwbare signaal is bewijs dat je niet kunt praten tot het bestaat:
de commit, de slagende test, de handeling die wordt voltooid door de echte UI.
Wanneer "af" daaruit wordt berekend in plaats van beweerd, sluit het gat tussen demo en productie, omdat het ding dat er af uitzag het nu moet bewijzen.
Wat ik eraan doe
Ik behandel de laatste 20% als het eigenlijke werk, niet als het opruimen. Ik breek het product op de manier waarop jouw gebruikers dat zullen doen (koude starts, echte navigatie, de invoer die niemand heeft gedemo't) voordat zij komen om het voor jou te breken. En ik scheid het ding dat het werk beoordeelt van het ding dat het bouwde, zodat "af" een oordeel uit bewijs is, geen zelfrapportage. Als jouw AI-gebouwde app perfect is in de demo en sterft bij echte gebruikers, is dat gat het symptoom dat ik als eerste lees.