Een groene build bewijst alleen wat je hebt laten controleren

Een groene build bewijst één ding: de controles die je hebt geschreven zijn geslaagd. Over de controles die je niet hebt geschreven zegt hij niets. Dat gat was vroeger klein, omdat het schrijven van de code traag genoeg was om het denkwerk onderweg te doen. Klein is het niet meer.

Wanneer een werkend prototype dagen kost in plaats van kwartalen, verschuift de verhouding. De code komt sneller binnen dan het nadenken over wat er mee mis kan gaan. Dat levert geen slechtere engineers op — het zijn dezelfde engineers, met een korter interval tussen een idee en iets dat in productie draait, en evenveel uren om te bepalen of dat verstandig is.

Het patroon in de gedocumenteerde missers

De publiek gedocumenteerde missers in AI-ondersteund bouwen van de afgelopen twee jaar lezen niet als iets exotisch. Sleutels die in client-side code bleven staan. Row-level security die wel was ontworpen maar nooit aangezet. Autorisatie die werd afgedwongen door een knop te verbergen in plaats van door een server-side controle. Een agent die een migratie op productiedata draaide.

Wat ze delen is nuttiger dan wat ze onderscheidt: in elk geval had een simpele, geautomatiseerde controle het probleem gevangen, en die was niet geschreven. Geen geavanceerde. Een test die uitlogt en het endpoint toch probeert. Een test die inlogt als tenant B en om de rij van tenant A vraagt. Een scan die zoekt naar een secret in een bundle.

De vraag die vóór een release de moeite waard is, is niet "zijn de tests groen" maar "welke van de manieren waarop dit kan falen dekt een test werkelijk af, en welke hopen we alleen maar?"

Wat er in een release-poort hoort

Een bruikbare release-poort is kort en concreet. Het is geen document; het is een verzameling dingen die waar moeten zijn en die iemand kan controleren.

Nieuwe kritieke logica heeft positieve, negatieve én grensgevallen. Geen dekking — gevallen. Een percentage vertelt je hoeveel code er tijdens de tests langskwam, niet of het betaalpad, het autorisatiepad of het migratiepad ertussen zaten. Stuur dekking op risico, niet op een getal.

Autorisatie wordt per resource getest, niet afgedekt door een knop te verbergen. Twee tests wegen zwaarder dan de rest: één als uitgelogde gebruiker, één vanuit de verkeerde tenant. Beide horen geen data te krijgen. Bestaat geen van beide, dan is autorisatie een ontwerpintentie en geen eigenschap van het systeem.

Migraties worden gerepeteerd op productieachtige omvang. Locks, doorlooptijd, compatibiliteit en het pad terug. Het terugzetten van de applicatie draait een destructieve datamigratie niet terug — daarom zijn rollback en roll-forward twee aparte plannen en niet één woord.

En de pull request toont het bewijs: wat er is gedraaid, wat er open staat, en wie het resterende risico heeft geaccepteerd. Een bevinding zonder fix of zonder expliciet geaccepteerd risico is niet gesloten; die is vergeten.

Waar AI het dreigingsbeeld verandert, niet alleen de snelheid

Eén categorie controle is werkelijk nieuwer. Zodra een product documenten, webpagina's, e-mails of tooloutput leest, is die inhoud onbetrouwbare invoer — ook wanneer het eruitziet als instructies aan het model. Prompts, bestanden en toolantwoorden blijven data. Modeloutput wordt gevalideerd vóór hij SQL, HTML, een shell of een externe actie bereikt.

De bijbehorende ontwerpregel is eenvoudiger dan hij klinkt: houd buiten het model wat deterministisch kan worden afgedwongen. Autorisatie, bedragen, limieten, statusovergangen en bedrijfsregels horen in code. Interpretatie, classificatie, samenvatten en genereren is waar het model voor is. Alles met echt gevolg — publiceren, geld, verwijderen, persoonsgegevens — krijgt een menselijke poort.

Kleine batches zijn een teststrategie

De minst spectaculaire maatregel is ook de betrouwbaarste. Een wijziging die klein genoeg is om te reviewen, is klein genoeg om terug te draaien. Een taak die eindigt met één draaibare check — een test, een build, een script dat OK teruggeeft — levert bewijs op in plaats van de mededeling dat het goed ging.

Dat weegt zwaarder wanneer een agent de code schrijft, niet lichter. Een agent meldt succes in hetzelfde zelfverzekerde register, of het nu werkt of niet. De check maakt dat verschil zichtbaar, en hij moet iets zijn dat de agent zelf kan draaien — anders zit er geen terugkoppeling in de lus.

Wat dit betekent voor hoe Forenta beoordeelt

Dit is ook de lat waar Forenta zichzelf langs legt. Een review van een fase die over een gebouwd systeem oordeelt, uitgevoerd zonder toegang tot de repository, is gevolgtrekking — geen waarneming. Daarom legt de engine vast wat hij werkelijk kon inspecteren, verlaagt hij zijn eigen confidence wanneer een laag ontbreekt, en weigert hij een controle als geverifieerd te markeren op basis van een projectbeschrijving. Een gereedheidsclaim die nergens op rust is erger dan geen claim, omdat hij eruitziet als een claim.

Niets hiervan maakt bouwen langzamer. Het maakt het verschil tussen "het draaide" en "het werkt" zichtbaar, en dat is het enige waarmee je bewust snel kunt gaan in plaats van per ongeluk.