AI-producten die niet kunnen doen alsof ze af zijn
Bouwen met AI heeft een eigen probleem: werk kan er af uitzien lang voordat er bewijs is dat het af is. Deze methode is ontstaan bij het bouwen van software, want daar zijn de regels het duidelijkst zichtbaar. De discipline eronder reikt verder, en ze staat in drie regels: "scheid het rapport van het bewijs", "loop de echte route af in plaats van de demonstratie", "verander niets op gezag van een overtuigend verhaal over wat er misging". Die gewoonten bepalen nog steeds hoe ik onderzoek, bouw en herzie, wat het eindresultaat ook wordt.
Een door AI gebouwd product zegt dat het werkt. De demo draait. De checklist is groen. Daaronder zit een stillere vraag. Weet ik werkelijk dat het werkt, of weet ik alleen dat iets dat beweert? De meeste AI-code wordt vertrouwd omdat die er af uitziet. Mijn aanname is de omgekeerde.
Die aanname is geen pose. Het is de bril waardoor ik heb leren kijken. In de bestuurskunde, waarin ik mijn master haalde, leerde ik kijken hoe instellingen besluiten omzetten in uitkomsten. In de advieswereld deed ik audits, en daar kwam een tweede reflex bij: het bewijs vertrouwen, nooit de geruststelling. Beide gewoonten kwamen rechtstreeks mee naar het bouwen met AI, in twee stappen: het werk aansturen, en het resultaat daarna controleren los van wat het gemaakt heeft. Aansturen is de makkelijkste helft. De andere helft is bewijzen dat "af" waar is, en dat is de helft die het gemakkelijkst wordt overgeslagen.
Het ding zegt dat het af is. Is het dat ook?
Tijdens het bouwen ontdekte ik iets ongemakkelijks: een AI vragen of het werk klaar is, heeft geen zin. Keer op keer viel dat zelfverzekerde "af" uit elkaar zodra het naast het bewijs werd gelegd. Zo vaak, dat ik het rapport helemaal niet meer als informatie behandel - dat van de AI net zo goed als dat van mijzelf. In mijn werk is "af" geen bewering die iemand doet. Het wordt berekend uit dingen die niet ontstaan doordat iemand ze beweert.
de echte commit, tests die slagen, de echte handeling die via het echte scherm wordt voltooid
Wat het werk beoordeelt is nooit wat het werk heeft gedaan. Daardoor wordt "af" een feit in plaats van een gevoel, en alleen daardoor kon het herhaalde controleren ophouden.
Perfect in de demo, dood zodra er echte gebruikers komen
Het deel van een AI-build dat te demonstreren valt staat soms in een avond en oogt foutloos. Dan komen er echte mensen, en wat de demo oversloeg begint in te storten. In de builds die ik heb uitgeplozen was de oorzaak bijna altijd dezelfde: het werkt als er meteen naar het juiste scherm wordt gesprongen, en dat doet een echte gebruiker nooit. Twee dingen vormen samen de echte eindstreep, en een demo slaat ze allebei over.
de hoofdhandeling die werkt via de echte, gerenderde interface en niet daarbuiten; een gebruiker die er voor het eerst komt en de functie bereikt langs de route die mensen werkelijk volgen
Een sluiproute recht naar het scherm telt niet als bewijs. Ik maak het product zelf stuk zoals zijn gebruikers dat zullen doen, voordat zij het komen doen, want de instorting waar het om gaat gebeurt voor hun ogen.
Repareren, herbouwen of met rust laten. Eerst de waarheid
De duurste zin bij een codebase in de problemen is "schrijf alles opnieuw", uitgesproken door iemand die de code nooit gelezen heeft. Mijn regel is eerst de echte code lezen en dan de waarheid vertellen: wat te repareren valt, wat opnieuw moet, wat met rust gelaten kan worden, en ook "dit is prima" als dat het eerlijke antwoord is. Dat oordeel moet zo opgeschreven zijn dat het zonder mij overeind blijft, als een plan dat elke ontwikkelaar kan uitvoeren, want een diagnose waar alleen de opsteller iets mee kan is niet te onderscheiden van een verkooppraatje. De angst die daarbij hoort - de angst om iemand te vertrouwen die aan de ziekte verdient - is een redelijke angst. Onder de rommel gaat het nooit om het verhelpen van het symptoom. Het gaat erom de heldere architectuur te vinden waar de kapotte versie blind naar tastte, en die te benoemen.
De factuur die het project stilletjes om zeep helpt
AI-gereedschap kan een budget geruisloos opsouperen en een project in een maand beëindigen. In mijn eigen werk heb ik het gemeten: een "goedkope tijdelijke versie, even om het te testen" kostte drie tot vier keer zoveel als het meteen goed bouwen, en er bleef niets van over. De les is niet dat kleine proeven verspilling zijn, want een kleine proef gericht op een echte onbekende is het goedkoopste wat er te koop is. De verspilling zat in de wegwerpversie: een tijdelijke kopie van iets wat al begrepen was, gebouwd om weggegooid te worden. Wat begrepen is bouw ik één keer goed. Wat onzeker is krijgt de kleinste proef die er uitsluitsel over geeft. En de uitgaven blijven beperkt en zichtbaar, in plaats van dat ze aan het eind van de maand opduiken, wanneer de rekening te laat komt om er nog iets aan te doen.
Drie maanden later werd het model bijgewerkt en ging alles stuk
Elke keer dat ik code die zwaar op AI leunt heb zien verouderen, ging dat snel. Er verschijnt een nieuwe model- of toolversie, en de lijm van gisteren houdt niet meer. De bestendigste bescherming die ik heb gevonden is structureel. Daarom splits ik elk product met opzet.
een stabiele kern met de echte logica en regels erin; een dunne buitenlaag die aan het snel veranderende model grenst
Verandert het gereedschap, dan beperkt dat het werk dat herschreven moet worden, meestal tot alleen die buitenlaag.
En als het met overtuiging fout zit?
De duurste fouten zien er niet uit als fouten. Ze zien eruit als een zelfverzekerd, redelijk antwoord dat toevallig niet klopt. AI doet dit voortdurend, en mensen ook. De neiging om "even de voor de hand liggende oorzaak weg te nemen" is precies waardoor een verkeerde gok uitmondt in kapotte data en verloren dagen. Daarom zit er een rem in mijn proces.
er verandert niets op grond van een verhaal over wat er mis is, alleen op grond van het echte bewijs van wat er mis is
Die rem geldt ook voor mijzelf. Meer dan eens ben ik aan een oplossing begonnen die volkomen juist leek, en heb ik die binnen enkele minuten afgeblazen, op het moment dat ze naast het werkelijke verloop werd gelegd. Het proces dat vertrouwen verdient is niet het proces dat nooit fout zit. Het is het proces dat de fout snel opmerkt, voordat een verkeerde gok iets echts kapotmaakt.
Waarom de meeste AI-builds oppervlakkig uitvallen
Iedereen weet dat er meer uit een AI komt door beter te vragen, en daarom sloeg prompt engineering aan. Maar de prompt is de kleine hefboom. Tussen het verzoek en het antwoord zit werk dat niemand te zien krijgt: de mate waarin het model het probleem werkelijk aanpakt voordat het antwoordt. Wat ik al werkend heb ontdekt, is dit: de werkstand waarin het model staat voor de taak die eraan komt, maakt meer uit dan de formulering van het verzoek. Draait het als uitvoerder, dan doet het wat er gezegd is, in de oppervlakkigste lezing die aan de woorden voldoet. Daar komt output vandaan die niet dieper gaat dan de demo en later uit elkaar valt. Voor echt werk draait het als onderzoeker: ingericht om achter het echte probleem aan te gaan in plaats van achter het gestelde, en om met zijn eigen eerste antwoord in discussie te gaan voordat ik het onder ogen krijg.
De twee helften passen in elkaar. Alles wat er te halen valt wordt gehaald uit de manier waarop het model werkt, en niets van wat het beweert wordt vertrouwd.
diepte op de weg naar binnen, bewijs op de weg naar buiten
Die combinatie is het vak. Ze verklaart grotendeels waarom wat hier gemaakt wordt standhoudt terwijl een snelle build dat niet doet, en ze verklaart ook waarom de homepage van deze site zo over onderzoek spreekt.