AI-code veilig vrijgeven in bestaande software: tests, canary en herstel

Je reviewt een pull request waarin een AI-codeeragent de betaalstatus van facturen heeft aangepast. De tests zijn groen, maar één verkeerde status kan een klant opnieuw laten betalen. Groen CI is nog geen vrijgavebesluit: weet welke bedrijfsuitkomsten de wijziging moet bewaren en hoe je stopt.

Een release-gate voor AI-geschreven code is een reeks controleerbare voorwaarden tussen pull request en productie. De gate koppelt de wijziging aan bedrijfsregeltests, end-to-endbewijs, een benoemde vrijgever, een beperkte eerste uitrol en een herstelplan voor code, schema en opgeslagen schrijfacties. Groen betekent dat elk onderdeel zijn eigen drempel heeft gehaald, niet dat één dashboard groen kleurt.

Deze gids begint nadat je de code hebt geaccepteerd. Je bepaalt welke bestanden en commando’s een codeeragent kan bereiken met projectgebonden permissies en een geïsoleerde sandbox. Dat beschermt de werkplek tijdens het schrijven. Hier gaat het om de vrijgave van geaccepteerde code: hoe je de bedrijfsuitkomst test, wie de deploy goedkeurt en wat er met data gebeurt als de oude programmaversie terug moet.

Hud ondersteunt backendruns op Node.js 18, 20, 22, 24 en 26, Python 3.8+ en Java 8, 11, 17, 21 en 25; ik heb deze actuele runtimecompatibiliteit op 15 november 2026 gecontroleerd. Hud volgt functies in je backend en vergelijkt hun gedrag tijdens een uitrol. Het dekt geen frontend- of third-partycode. Met setFailure() kun je een mislukte backendflow markeren, ook als de HTTP-respons 200 is. Deployment monitoring kan een webhook met een rollbackadvies versturen; je eigen deploypipeline voert dat advies uit of zet er een menselijke goedkeuring tussen. Hud controleert je bedrijfsregels, browserpad of database-migratie niet vanzelf.

De Linux Foundation-studie meldt dat 58% van de respondenten code sneller ziet verschijnen dan beveiligingsreviews kunnen bijhouden; de primaire meting telde 173 antwoorden. Het is zelfrapportage uit een internationale steekproef, geen meting van Nederlandse teams. Het onderstreept wel waarom een groene CI-run alleen niet genoeg is: de code moet ook door iemand worden beoordeeld die de bedrijfsuitkomst kent.

Wat je nodig hebt

Verzamel dit voordat je de pull request samenvoegt:

• De exacte wijziging en het te deployen bestand. Koppel het pull request aan één commit en één bouwbestand met een onveranderlijke versie of image-digest. Noteer de geraakte functies, endpoints, tabellen, achtergrondtaken en diensten. Een tag als latest bewijst niet dat staging en productie hetzelfde bestand krijgen.
• Een eigenaar van de bedrijfsregel. Laat de proceseigenaar één verwachte uitkomst en minstens één verboden uitkomst opschrijven. Voor een betaalstatus kan dat zijn: een factuur wordt hoogstens eenmaal betaald gemarkeerd, een terugbetaling zet haar niet opnieuw op betaald en een onbekende gebeurtenis verandert geen boekingsstatus.
• Een geïsoleerde testomgeving. Gebruik staging met synthetische of opgeschoonde gegevens, aparte sleutels en een afgeschermde betaalomgeving. Een test mag geen echte betaling, mail, webhook of voorraadmutatie uitvoeren. Zet voor iedere externe dienst vast of die wordt nagebootst of in testmodus draait.
• De tests en productiemeting. De repository heeft een vaste CI-opdracht voor unit-, integratie- en regressietests nodig. Leg vast waar foutpercentage, latency van het 95e percentiel (p95), uitzonderingen, wachtrij-achterstand en bedrijfsuitkomst staan, bijvoorbeeld in Grafana, Datadog, New Relic of CloudWatch. De eigenaar moet die cijfers tijdens de canary kunnen openen.
• Een schema- en schrijfactieplan. Benoem de databases, tabellen en externe mutaties. Voor iedere schrijfactie heb je een stabiele sleutel, terugleesmogelijkheid en eigenaar nodig. Voor iedere schemawijziging heb je een compatibiliteitsplan, een back-up en een geteste herstelroute nodig.
• Een release-eigenaar en een tweede paar ogen. De eigenaar is bereikbaar tijdens de uitrol en mag het verkeer stoppen. Voor betalingen, klantstatus, toegangsrechten of verwijderingen keurt iemand anders dan de pull-requestauteur de bedrijfsregel en herstelroute goed. Bij een AI-agent die externe writes mag uitvoeren, bind je die goedkeuring aan de exacte actie, bestemming en payload.
• Een bruikbaar tijd- en kostenbudget. Mijn planningsregel is één engineer-dag voor de eerste inrichting als staging, tests en meetgegevens al bestaan. Ontbreekt één ervan, plan dat werk apart in voordat je een releasevenster boekt. Als je de bestaande CI/CD gebruikt, kan de extra licentiekost €0 zijn. Nieuwe planprijzen en een vijfpersoonsvergelijking staan in de tabel onderaan.

Concrete stappen: van pull request naar productie

1. Bevries de wijziging en benoem haar risico

Begin bij het pull request, niet bij de deployknop. Koppel het aan één ticket, één commit en één bedrijfsdoel. Lees de volledige diff, inclusief gegenereerde bestanden, nieuwe pakketten, configuratie, testfixtures en databasebestanden. Gebruik git diff --check om whitespacefouten te vinden en git diff --name-only om te zien welke delen van de applicatie zijn geraakt. Een onverwachte lockfile, migratie of permissiewijziging is reden om de scope te verkleinen. Een nieuwe dependency verandert ook welke code in het bouwbestand belandt, dus dependencyversies en containerimages vastzetten tegen supply-chainrisico’s hoort bij dezelfde review.

Schrijf bovenaan het pull request wat voor de gebruiker verandert en welke gegevens of externe systemen geraakt worden. Laat de proceseigenaar het risico als laag, middel of hoog vastleggen. Opmaak zonder schrijfacties kan laag zijn. Een wijziging in factuurstatus, voorraad of toegangsrecht is hoog, ook bij een diff van drie regels.

Controleer dat je later exact het geteste bouwbestand uitrolt. Bouw het eenmaal en promoot datzelfde bestand van staging naar productie. Klaar als de commit, diff, getroffen bedrijfsregel, databronnen en beoogde bouwversie bij elkaar staan. Stopt als de agent ongevraagde bestanden of afhankelijkheden heeft aangepast: vraag eerst waarom en verwijder alles wat niet bij de wijziging hoort.

2. Vertaal de bedrijfsregel naar een test die kan falen

Een test met de naam payment_should_work bewijst weinig als hij alleen controleert dat de functie geen fout geeft. Schrijf de regel als invoer, verwachte toestand en verboden toestand. Bijvoorbeeld: een betaald-event zet een open factuur op betaald; hetzelfde event nogmaals verwerkt maakt geen tweede betaling; een terugbetalingsgebeurtenis zet de factuur niet opnieuw op betaald; een onbekend event laat de bestaande status ongemoeid.

Voeg per nieuw pad een positieve en negatieve test toe voor bijvoorbeeld dubbele levering, ontbrekend klantnummer, bedrag nul, oude status of time-out. Controleer de status na de mutatie, niet alleen de HTTP-status. Laat de domeineigenaar de testregel bevestigen.

Draai de tests op de volledige CI-runner die later voor de release wordt gebruikt. Voeg ze toe aan de verplichte checks op de beschermde hoofdbranch. Als er geen test bestaat voor de regel die de wijziging raakt, is de uitkomst nog niet bewezen. Klaar als de nieuwe test faalt op de oude bug en slaagt op de nieuwe code, terwijl de aangrenzende regels groen blijven.

3. Test het hele gebruikerspad in staging

Een unit-test raakt één functie. Een end-to-endtest volgt de handeling zoals een medewerker of klant die echt uitvoert. Zet daarom dezelfde gebouwde versie in staging, log in met een aparte testgebruiker en doorloop het volledige pad: invoer, validatie, database, wachtrij, terugmelding en eventuele externe koppeling.

Gebruik bijvoorbeeld Playwright voor de browserstap en de bestaande API-test voor de serverkant. Laat een testbetaling in Stripe-testmodus lopen en stuur e-mail naar een opvangadres. Controleer na de handeling zowel de zichtbare status als het opgeslagen record en de verwachte gebeurtenis in de wachtrij. Een scherm met “Betaald” is niet voldoende als de boekingsregel nog “Open” bevat.

Laat staging de productieconfiguratie volgen zonder productiegeheimen. Gebruik opgeschoonde gegevens en simuleer minstens één onderbreking, zoals een time-out na een schrijfactie of een onbeschikbare API. Vuile invoer, time-outs en stille fouten horen bij normale productieprocessen. Vertaal deze categorieën naar concrete tests van de wijziging. Klaar als de gebruikerstaak, de database-uitkomst en de foutafhandeling overeenkomen.

4. Behandel de databasewijziging als een apart vrijgavebesluit

Een wijziging van code en een wijziging van schema zijn niet één terugrolbare handeling. Gebruik bij een niet-compatibele veldwijziging een expand-and-contract-route. Voeg eerst het nieuwe veld toe zonder het oude te verwijderen. Laat een versie die beide kan lezen en schrijven naast de oude versie werken. Vul gegevens in herhaalbare batches aan, controleer aantallen en waarden, schakel daarna om en verwijder het oude veld in een latere release.

Prisma ORM 8 beschrijft aparte expand- en contractmigraties, dezelfde gecontroleerde bestanden voor productie en een waarschuwing voor dataverlies bij het verwijderen van een veld. Deze migratiegids is gecontroleerd op 15 november 2026. Een mislukte migratie kan database-afhankelijke resten achterlaten en herstel kan een nieuwe migratie vragen; die pagina is bijgewerkt op 9 november 2026.

Test op staging oude code met het nieuwe schema, nieuwe code met dat schema en terugkeer naar oude code. Controleer ook een backfill die halverwege stopt. In PostgreSQL annuleert ROLLBACK een open transactie, terwijl COMMIT de wijzigingen als één geheel opslaat. Klaar als de vorige en nieuwe applicatieversie met het uitgebreide schema kunnen draaien en je weet welke wijziging niet automatisch teruggaat.

5. Maak voor elke schrijfactie een herstelactie

Een code-rollback herstelt geen factuur, betaling, e-mail, webhook of voorraadmutatie die al is uitgevoerd. Maak daarom per schrijfactie een rij in het releaseplan: welke sleutel identificeert de opdracht, hoe lees je terug of die al is verwerkt, wat is de inverse bedrijfsactie en wie mag die goedkeuren?

Gebruik waar een externe API dat ondersteunt dezelfde idempotentiesleutel bij een veilige herhaling. Stripe herkent een API-aanroep met dezelfde sleutel als hetzelfde verzoek en voorkomt zo een tweede object of mutatie na een time-out. Log de sleutel zonder persoonsgegevens. Als het antwoord wegvalt, lees eerst terug met de zakelijke sleutel voordat je opnieuw probeert.

Bij schrijfacties over meerdere databases of diensten is één databasetransactie niet genoeg. AWS beschrijft de saga-aanpak: lokale transacties krijgen vervolg- of compensatieacties. Die compensatie is een nieuwe bedrijfsactie, niet het wissen van de historie. De saga-patronen laten zien hoe een workflow na een gedeeltelijke fout kan compenseren of veilig verdergaan. Bij een time-out of 429 hoort daarnaast een begrensde retry met controle van de eerdere uitkomst; een herstelbare API-orderflow gebruikt daarvoor een ledger, stabiele sleutel en read-back. Klaar als elke productieschrijfactie een stabiele sleutel, terugleesactie en benoemde compensatie heeft. Stopt als niemand kan vaststellen of de schrijfactie al is uitgevoerd.

6. Wijs een vrijgever aan en beveilig de productiepoort

Maak in GitHub Actions of GitLab CI/CD een productieomgeving met alleen de beschermde hoofdbranch als bron. De release-eigenaar mag het productiebestand vrijgeven, maar niet zijn eigen verandering goedkeuren. Laat de goedkeurder de testuitvoer, diff, databasestappen, canarydrempels en herstelactie zien voordat de poort opengaat.

GitHub Actions kan een productieomgeving beschermen met reviewers, wachttijd en branchregels; je kunt zelfbeoordeling voorkomen en beheerders standaard-bypass uitschakelen. Op Free, Pro en Team zijn verplichte reviewers alleen beschikbaar voor publieke repositories. GitLab heeft deployment approvals in Premium en Ultimate; een goedgekeurde GitLab-deployment start de handmatige taak niet vanzelf.

Geef productiesleutels pas aan de deploytaak na goedkeuring. Schakel beheerder-bypass uit waar dat kan en log uitzonderingen. Wijs een persoon aan die tijdens het releasevenster het verkeer kan stoppen, ook als die niet de auteur is. Klaar als een ongeautoriseerde branch en de PR-auteur zelf de productieomgeving niet kunnen vrijgeven.

7. Begin klein en meet de echte bedrijfsuitkomst

Leg vóór de deploy het normale foutpercentage, p95-latency, queue-achterstand en de bedrijfsuitkomst vast. Vergelijk met hetzelfde tijdstip of dezelfde belastingklasse. Begin met 5 tot 10 procent van het verkeer of één laag-risicoklant. Gebruik een functieschakelaar (feature flag) als je de nieuwe handeling per klant moet kunnen uitschakelen zonder de volledige applicatie terug te draaien.

Stel drempels vast voordat het bouwbestand live gaat. Als startpunt kun je een canary stoppen bij iedere bevestigde fout in een kritieke bedrijfsregel, bij een foutpercentage boven de foutgrens van je service level objective (SLO) of bij p95 die in twee opeenvolgende meetvensters meer dan 20 procent boven de vergelijkbare referentiewaarde ligt. De 100 relevante bedrijfsacties zijn alleen een gekozen startdrempel, geen bewijs van veiligheid, zeker niet voor kritieke writes. Laat risico en dekking van gebeurtenistypen zoals betaling, dubbele levering, terugbetaling en onbekende invoer de steekproefomvang en duur bepalen. Promoveer pas na waarneming van een normale piekperiode. Ontbreken zeldzame maar kritieke gebeurtenistypen, verleng dan de canary en vraag menselijke vrijgave. Deze aantallen zijn operationele startwaarden, geen universele statistische garantie.

Google’s SRE Workbook waarschuwt dat een handvol verzoeken geen bruikbare canary is en dat de steekproef lang en representatief genoeg moet zijn voor de verschillende invoer en belasting. De canary-aanpak koppelt cohort, duur en gekozen meetwaarde aan elkaar. Klaar als de eigenaar weet hoeveel relevante acties nodig zijn, welke meetwaarde de stopknop indrukt en hoe lang de applicatie die meting moet verzamelen.

8. Promoveer, controleer of rol code en data apart terug

Promoveer alleen het bouwbestand dat staging heeft doorlopen en verhoog de canary in vaste stappen. Controleer na elke stap fouten, latency, uitzonderingen, wachtrijen en bedrijfsuitkomst. Houd de release-eigenaar beschikbaar tot de drempels zijn gehaald. Een groen scherm zonder waargenomen bedrijfsactie is geen reden om op te schalen.

Bij een stop: laat de vooraf ingestelde drempel het canaryverkeer pauzeren en de applicatiecode naar de laatst gezonde build terugzetten als die met het huidige schema compatibel is. Als de pipeline dit niet automatisch doet, stopt de release-eigenaar het verkeer direct. Laat een compatibele, uitbreidende schemawijziging staan. Voer geen destructieve terugmigratie uit omdat de applicatie is teruggezet. Herstel van schema’s en opgeslagen writes is een apart besluit en kan een afzonderlijke menselijke goedkeuring van de data- of proceseigenaar vereisen. Zoek daarna alle writes met de release-id of idempotentiesleutel terug, vergelijk ze met het bronsysteem en voer alleen de vooraf geteste compensatie uit met een auditregel en benoemde eigenaar.

Na een geslaagde release lees je de hoofdtransactie terug in de applicatie en de bronadministratie. Houd de foutsignalen open tot minstens één normale bedrijfsperiode is verstreken. Sluit het incident pas wanneer de datacontrole klopt, de queue is bijgewerkt en de eigenaar de vrijgave heeft vastgelegd. Klaar als de volledige uitrol is afgerond of de herstelroute is aantoonbaar voltooid, niet wanneer alleen de deploymenttaak groen wordt.

Valkuilen

Groene tests controleren alleen het antwoord van de functie

Een test kan slagen omdat het endpoint HTTP 200 teruggeeft, terwijl een factuur of klantstatus verkeerd is opgeslagen. Dat gebeurt wanneer tests de implementatie controleren maar niet de bedrijfsinvariant. Laat een domeineigenaar voor de wijziging de verwachte status en verboden overgangen formuleren. Controleer na de write het teruggelezen record en voeg de regel aan de vaste regressieset toe.

Een runtime-sensor wordt aangezien voor een acceptatietest

Een sensor kan laten zien dat functies vaker falen of trager worden. Hud bemonstert looptijden en kan met setFailure() een expliciet gemarkeerde zakelijke fout zien, maar dekt geen frontend, migratie of code van derden. Een regel als “een terugbetalingsgebeurtenis zet een betaalde factuur niet opnieuw op betaald” moet je zelf testen en meten. Gebruik de sensor als extra bewijs naast de bedrijfsregeltest, nooit als vervanging ervan.

De canary krijgt te weinig of het verkeerde verkeer

Vijf procent van het verkeer kan nog steeds nul terugbetalingsgebeurtenissen, maandafsluitingen of piekuren bevatten. De fout blijft dan onzichtbaar tot iedereen de nieuwe versie gebruikt. Controleer de aantallen van de relevante handeling, niet alleen het algemene requestvolume. Als je in één normale cyclus geen 100 relevante acties krijgt, verleng de periode, voer tests met productieachtige fixtures uit en laat een mens beslissen voordat de release volledig doorgaat.

De pull-requestauteur keurt zijn eigen deploy goed

Een goedkeuringspoort die met één klik door de auteur kan worden overgeslagen is geen onafhankelijke controle. Dit gebeurt door een niet-ingestelde self-review-beperking, een open beheerder-bypass of een verkeerd branchpatroon. Test met een niet-gemachtigde gebruiker en met de auteur zelf. GitHub laat beheerders standaard beschermingsregels omzeilen tenzij je bypass uitschakelt; leg vast wie uitzonderingen mag uitvoeren en bewaar het auditspoor.

Een code-rollback laat de schemawijziging achter

De oude applicatie kan crashen op een verwijderd veld of de nieuwe code kan bestaande rijen al hebben omgezet. Een deployscript dat code en destructieve migratie als één stap uitvoert, maakt de terugweg onzeker. Houd toevoegen, omschakelen en verwijderen in aparte releases. Bewijs op staging dat de vorige code met het uitgebreide schema blijft werken voordat je die versie op productie als terugvaloptie aanmerkt.

Een time-out wordt een tweede schrijfactie

De verbinding valt weg nadat de betaalprovider of database de opdracht heeft verwerkt, maar vóór je antwoord ontvangt. Een blinde retry kan dan een dubbele terugbetaling, mail of mutatie veroorzaken. Herhaal alleen met dezelfde idempotentiesleutel waar de API dat ondersteunt. Lees anders eerst terug met een stabiele zakelijke sleutel en stuur de onzekere opdracht naar handmatige controle.

Een herstelplan beschrijft alleen de knop

“Rol terug” zegt niet wat er met een verkeerd opgeslagen status, verzonden bericht of mislukte migratie gebeurt. Maak voor elke foutklasse een eigenaar, stopactie en datacontrole. Prisma’s actuele rollback-uitleg laat zien dat een gedeeltelijk mislukte migratie afhankelijk van de database resten kan achterlaten. Herstel eerst de werkelijke toestand en probeer niet automatisch dezelfde down-migratie opnieuw.

Beslis-kader: welke vrijgave past bij deze wijziging?

Kies op drie assen: hoeveel bedrijfsrisico de wijziging draagt, hoeveel representatief verkeer je in een canary kunt meten en hoe goed je effect omkeerbaar is. Een beschermde omgeving regelt wie mag deployen. Een canary beperkt hoeveel klanten de wijziging raken. Een compensatieplan herstelt wat al in een database of externe dienst is veranderd. Geen van die drie vervangt de andere.

Bestaande CI/CD met een vrijgave-eigenaar past bij één applicatie, een team tot ongeveer vijf ontwikkelaars en minder dan vijf productie-uitrollen per week, zolang de wijziging geen destructieve migratie of onomkeerbare write bevat. Gebruik GitHub Actions of GitLab CI/CD met verplichte tests, een beschermde hoofdbranch en een benoemde release-eigenaar. Begin hiermee als je huidige pipeline de test en deploy al uitvoert. Een nieuwe releasecontroller kopen voor een handmatige vrijgave die je tweemaal per week doet, voegt vooral beheer toe.

AWS CodeDeploy-canary voor Lambda of ECS past als je deze diensten al gebruikt, Application Load Balancer-verkeer kunt routeren en CloudWatch-alarmen hebt. CodeDeploy kan daar verkeer in canary- of lineaire stappen verschuiven; de standaard ECS-canary kan bijvoorbeeld 10 procent eerst en 90 procent na 5 of 15 minuten sturen. Een korte stap bewijst niet dat een zeldzame bedrijfsactie goed gaat. Voor EC2/On-Premises stuurt CodeDeploy op minimum gezonde hosts; een blue-green-uitrol kan verkeer naar de vervangende groep in één keer omzetten. Het biedt daar geen procentuele canary voor klantverkeer. Heb je die op EC2 nodig, koppel dan een aparte verkeersrouter, zoals een Application Load Balancer.

Argo Rollouts op Kubernetes past als je Kubernetes al gebruikt, verkeer door een ondersteunde ingress of service mesh kan sturen en je bruikbare metrics hebt. De analyse kan de uitrol afbreken als een meetwaarde faalt. De configuratie en metricsbeheer vragen wel een eigenaar. Zet het niet neer voor één applicatie die al voldoende is afgedekt met de huidige pipeline en een eenvoudige handmatige goedkeuring.

Maatwerk rond bedrijfsregels en compensatie is nodig zodra een release meer dan één onafhankelijk systeem wijzigt, een betaling of verwijdering kan uitvoeren of geen standaarddashboard de juiste bedrijfsuitkomst ziet. Leg dan één controletabel vast met bronrecord, idempotency key, uitkomst, compensatie en eigenaar. Verdeel het werk in kleine compatibele wijzigingen. Een extra knop in GitHub of GitLab lost een verschil tussen twee boekhoudsystemen niet op.

Gebruik deze drempels als startbeleid, niet als universele wet:

• Verkeer en bedrijfsuitkomsten: 100 relevante bedrijfsacties is een gekozen startdrempel, geen bewijs dat de wijziging veilig is. Bepaal de steekproef en duur op basis van risico en dekking van de relevante gebeurtenistypen, zoals betaling, dubbele levering, terugbetaling en onbekende invoer. Honderd gewone betalingen bewijzen niets over een kritieke terugbetaling die niet voorkwam. Promoveer pas nadat ook een normale piekperiode is waargenomen. Als zeldzame gebeurtenissen ontbreken of de steekproef de kritieke writes niet dekt, verleng de canary en houd menselijke vrijgave verplicht.
• Technische signalen: stop zodra een vooraf gekozen SLO wordt overschreden of p95 gedurende twee opeenvolgende meetvensters meer dan 20 procent boven de vergelijkbare baseline ligt. Pas de grens aan op je eigen SLO, maar verander haar niet terwijl de canary loopt.
• Data-integriteit: nul bevestigde foutieve geld-, toegangs- of statuswijzigingen is de promotieregel. Eén fout is genoeg om de uitrol te stoppen, ook als het totale foutpercentage klein lijkt.
• Team en frequentie: tot vijf ontwikkelaars en minder dan vijf productie-uitrollen per week is de bestaande CI/CD met één vrijgave-eigenaar meestal de kleinste werkbare route. Bij dagelijks uitrollen of wachtrijen die langer dan één werkdag op goedkeuring wachten, automatiseer herhaalbare lage-risicocontroles en reserveer menselijke goedkeuring voor wijzigingen met schrijfacties, migraties of klantimpact.
• Kosten: als de bestaande pipeline voldoet, begin met €0 extra licentiekosten. Betaal pas voor een planupgrade als je de private-repositorygoedkeuring of extra beheerfunctie echt nodig hebt. Houd licenties, CI-minuten, metrics en benodigde clusterinfrastructuur als aparte posten.

Martin Fowler beschrijft expand-and-contract als drie fasen: eerst uitbreiden, daarna gebruikers of data migreren en pas als laatste de oude vorm verwijderen. De parallel-change-aanpak verlaagt het risico van database- en code-uitrol doordat oud en nieuw tijdelijk naast elkaar bestaan. Kant-en-klaar wint als je bestaande platform de branchbescherming, goedkeuring en meetbare stopknop al levert. Maatwerk wint wanneer een zakelijke regel over systemen heen loopt of de verkeerde write niet met één technische rollback kan worden hersteld. Een drempel doet pas iets automatisch wanneer je hem aan een stop- of rollbackactie hebt gekoppeld. De matrix maakt dat onderscheid expliciet.

Uitgewerkt voorbeeld: betalingsevents in bestaande software

Neem het fictieve SaaS-bedrijf Noordlicht. Het verwerkt 24.000 betalingsevents per maand van 30 dagen, gemiddeld 800 per dag. Een AI-codeeragent past de bestaande Stripe-webhookverwerking aan. Het pull request moet dubbele gebeurtenissen veilig verwerken en voorkomen dat een terugbetalingsgebeurtenis een factuur opnieuw als betaald markeert.

De wijziging voegt in PostgreSQL een optioneel veld voor de provider-gebeurtenis-ID toe. Er worden geen bestaande waarden verwijderd of herschreven. De codeversie die nu draait, negeert dat nieuwe veld; de nieuwe versie schrijft de ID mee en gebruikt een unieke sleutel om hetzelfde event niet tweemaal te verwerken. Daardoor kan de oude code terug zonder dat de schema-uitbreiding eerst ongedaan moet worden gemaakt.

De eigenaar van de factuurregel schrijft vier tests: betaling op een open factuur, hetzelfde betaal-event tweemaal, een betaling zonder factuur-ID en een onbekend event dat de bestaande status ongemoeid laat. De tests bevatten nog geen terugbetalingsgebeurtenis. In staging draait de nieuwe gebouwde versie met Stripe test mode. Playwright doorloopt het betaalpad, maar niet het retourpad. De API-test leest de factuur en de eventtabel na afloop terug. De release-eigenaar ziet dezelfde build-id en commit als in het pull request.

Noordlicht stuurt eerst 10 procent van de gebeurtenissen naar de nieuwe code. Dat is gemiddeld 80 gebeurtenissen per dag. Na één dag zijn er nog niet genoeg gegevens voor de afgesproken minimumsteekproef van 100. Na twee dagen zijn er ongeveer 160 gebeurtenissen door de canary gegaan. Daar komt terugbetalingsgebeurtenis R-1042 voor factuur NW-2026-087 binnen; de wijziging classificeert die als een gewone betaling. Dat is 1 van de 160 gebeurtenissen, dus 0,625 procent. De factuurstatus is fout, ook al blijven de algemene foutpercentages en latency binnen hun grenzen.

De uitrol stopt bij 10 procent. De eigenaar schakelt de nieuwe functie uit en rolt de applicatie terug van versie 2.14.1 naar 2.14.0. Het optionele veld blijft staan, omdat de oude versie het negeert. De foutieve factuurstatus wordt niet met een databasetransactie teruggedraaid: de transactie is al gecommit. De eigenaar leest het Stripe-event terug, herstelt de status met een gecontroleerde compensatie en legt de correctie vast in het auditspoor. Het event wordt niet blind opnieuw verstuurd. De eigenaar voegt nu de ontbrekende regressietest toe: een terugbetaling na betaling mag de factuur niet opnieuw op betaald zetten. Die test faalt eerst op de foutieve code. Na de statuspadcorrectie slagen alle vijf tests en het volledige stagingpad.

De verse canary verwerkt 160 relevante gebeurtenissen, waaronder 12 terugbetalingen en dubbele leveringen, en omvat de vooraf vastgelegde normale piek op de eerste werkdag tussen 09.00 en 11.00 uur. Geen van de gecontroleerde facturen krijgt de verkeerde status. Die steekproef is voor Noordlicht een gekozen startbewijs, geen universeel veiligheidsbewijs. Omdat de wijziging financiële writes raakt, beoordeelt de onafhankelijke vrijgever de terugbetalingsuitkomsten en keurt die de promotie naar het overige verkeer apart goed. De eerste mislukte groep blijft 1 van 160, of 0,625 procent; de tweede groep hoort bij een andere codeversie en blijft apart in de rapportage. De cijfers in dit voorbeeld zijn bewust samenhangend: 24.000 gedeeld door 30 is 800 per dag, 10 procent daarvan is 80 per dag en twee dagen levert 160 gebeurtenissen op. Eén fout in de eerste groep is 1/160 = 0,625 procent.

Vergelijkingstabel: vier manieren om een release te beheersen

De leverancierspagina’s en documentatie zijn voor deze gids op 15 november 2026 gecontroleerd. GitHub Team kost $4 en Enterprise $21 per gebruiker per maand, dus voor vijf gebruikers respectievelijk $20 en $105. GitLab Premium kost $29 per gebruiker per maand bij jaarlijkse facturering, dus $145 per maand-equivalent of $1.740 per jaar voor vijf gebruikers. De grafiek vergelijkt alleen deze per-gebruiker SaaS-licenties. AWS CodeDeploy heeft geen maandbedrag per gebruiker en Argo Rollouts is onder Apache 2.0 beschikbaar; AWS-verbruik en Kubernetes-infrastructuur staan apart en zijn niet in de grafiek opgeteld.

De grafiek telt geen AWS- en Kubernetes-kosten op bij gebruikerslicenties. Voor CodeDeploy en Argo staan de service- of projectkosten en de benodigde infrastructuur daarom apart in de tabel. De technische keuze draait verder om de juiste stopknop: GitHub en GitLab zetten een menselijke poort voor de deploy; CodeDeploy voor Lambda of ECS en Argo Rollouts kunnen verkeer gefaseerd verschuiven en op technische alarmen reageren. Elk pad heeft nog eigen tests nodig voor bedrijfsregels en een herstelplan voor writes die al zijn opgeslagen.

De release is van jou zodra je kunt aanwijzen welke bedrijfsregel is getest, wie de stopknop bedient en hoe iedere opgeslagen wijziging wordt hersteld. Een AI-agent kan de code schrijven. Alleen jouw bewijs bepaalt of die code een klant mag raken.