Samenvatting

Deze ai code generator rollout simulator laat zien hoeveel van je foutbudget van 30 dagen een slechte AI-geschreven wijziging verbruikt voordat ze wordt teruggedraaid. Vul verkeer, SLO, uitrolladder, inwerktijd en detectiesnelheid in. De tool vergelijkt een deploy in één keer, een gefaseerde uitrol die door een mens wordt bekeken en een geautomatiseerde SLO-gate, met eenvoudige rekensom die je met de hand kunt controleren.

Gratis uitrolplanner

Simuleer hoe ver een AI-codewijziging zich verspreidt voordat je terugdraait

Gratis ai code generator rollout simulator: plak je verkeer, SLO en ladder erin. De tool toont hoeveel foutbudget een slechte wijziging van een AI code generator verbruikt bij één deploy, bij een mens die een dashboard volgt en bij een geautomatiseerde gate.

Start de simulator Hoe de rekensom werkt

Simulator AI-coderollout

Elk veld verandert het resultaat direct. De standaardwaarden beschrijven een service van 200 requests per seconde met een 99.9% SLO en een wijziging die 20% van de requests laat falen.

Jouw uitrolplan
FaseVerkeerStart omRequests bediend door de nieuwe code
Hoe het werkt

Drie regels rekenwerk, geen verborgen model

Foutbudget

Budget = (1 minus SLO) keer gemiddelde requests per seconde keer 2,592,000 seconden in 30 dagen. Bij 200 req/s en 99.9% is dat 518,400 mislukte requests die je per maand mag verliezen.

Blootstelling over tijd

De ladder geeft per minuut het aandeel verkeer op de nieuwe code. De simulator integreert dat aandeel vanaf het eerste request tot je opmerktijd plus je terugdraaitijd, dus een trage detectie duwt de wijziging naar latere, grotere fasen.

Mislukte requests

Mislukt = requests per seconde keer je faalpercentage keer de blootstellingsintegraal. Delen door het budget geeft het percentage van de maand dat één slechte wijziging kost. Drie detectiemodi worden vergeleken op dezelfde ladder.

Gebruik het op een echte wijziging

Van een AI-gegenereerde diff naar een uitrolplan

  1. 1

    Kies de pessimistische invoer

    Voor een wijziging die een AI code generator schreef en snel is nagekeken, neem je een hoog faalpercentage aan als ze fout is, en een opmerktijd voor mensen die overeenkomt met je traagste recente incident, niet met je beste.

  2. 2

    Vergelijk de drie scenario's

    De deploy in één keer toont het slechtste geval. Het gefaseerde scenario met een mens laat zien wat je ladder je vandaag oplevert. De geautomatiseerde gate laat zien wat een gate op je SLO-metriek zou veranderen.

  3. 3

    Kopieer het plan naar je runbook

    De kopieerknop exporteert de fasen en het slechtste foutbudgetverbruik als platte tekst, klaar om te plakken in een changeticket of een pull request-beschrijving.

Waarom de ladder ertoe doet

In de eerste fase bespaar je het meeste budget

Een wijziging die 20% van de requests laat falen bij 1% verkeer, zorgt voor fouten bij 0.2% van de requests. Dezelfde wijziging op 100% laat één op de vijf requests falen. Het verschil tussen die twee getallen is het hele argument voor een gefaseerde uitrol. Als de code van een generator honderden regels in seconden kan produceren, daalt de reviewtijd per regel, en wordt de eerste fase de plek waar je het ontdekt.

  • Een eerste fase van 1% beperkt de impact met 99% voordat er iets anders wordt gemeten.
  • Inwerktijd helpt alleen als je signaal een regressie binnen dat venster kan tonen.
  • Sneller terugdraaien is net zo waardevol als sneller opmerken: beide tellen op in de blootstellingsintegraal.
Serverrack met één amberkleurig statuslampje tussen groene lampjes
Lees de uitkomst

Wat je met de drie getallen doet

Eén deploy

Als dit getal boven 5% van het maandbudget ligt voor een plausibele fout, is een deploy in één keer een beslissing om je budget aan één wijziging te besteden. Weinig teams maken die keuze bewust.

Gefaseerd, mens

Dit is je huidige realiteit als on-call naar grafieken kijkt. Als de piekblootstelling 100% toont, is je ladder vooral decor: de slechte wijziging bereikt iedereen voordat iemand reageert.

Gefaseerd, geautomatiseerde gate

Dit is het argument voor een gate die je SLO-metriek leest en zonder vragen terugdraait. De waarde is alleen echt als de gate afgaat op hetzelfde signaal als je SLO, dus test hem met een bewust slechte wijziging.

Veelgestelde vragen

Is deze ai code generator rollout simulator gratis?
Ja. Hij draait volledig in je browser, vereist geen registratie en stuurt niets naar een server behalve een anonieme gebruiksmeting. Het is zelf geen AI code generator: hij simuleert hoe ver een slechte wijziging zich verspreidt zodra code van zo'n generator je pipeline bereikt.
Waar komen de getallen vandaan?
Uit rekenwerk dat je met de hand kunt controleren. Het foutbudget is (1 minus je SLO) keer de requests in 30 dagen. Mislukte requests zijn je verkeer keer het faalpercentage keer het verkeersaandeel van de nieuwe code, geïntegreerd over de tijd tot het terugdraaien klaar is. Er zit geen benchmark in; elke aanname is een invoer.
Waarom AI-code anders modelleren dan door mensen geschreven code?
De rekensom is gelijk. Wat verandert is de prior: een grote diff die in minuten is geproduceerd, heeft per regel minder menselijke review gehad, dus het faalpercentage en de opmerktijd verdienen pessimistische waarden. Stel beide in op basis van je eigen incidentgeschiedenis, niet op basis van deze pagina.
Wat neemt de simulator aan wat echt verkeer niet doet?
Hij gaat uit van stabiel verkeer, een regressie die vanaf het eerste request hetzelfde aandeel requests laat falen, en een terugdraaiactie die de schade direct stopt zodra die klaar is. Echte incidenten kennen oploop, gedeeltelijke fouten en trage rollbacks, dus zie het resultaat als een ondergrens van de schade, niet als voorspelling.
Wat is een goede opmerktijd voor een geautomatiseerde SLO-gate?
Dat hangt af van je metriekresolutie en je alertvenster. Een gate die een foutpercentage per minuut tegen een drempel afzet, kan binnen twee tot vijf minuten afslaan. Als je alerting pas na een burn-rate-venster van 30 minuten pagina's stuurt, vul dan die waarde in; de simulator laat dan zien wat het kost.
Helpt een langere inwerktijd altijd?
Nee. Een langere inwerktijd geeft de gate meer data per fase, maar houdt een slechte wijziging ook langer op een bepaald verkeersaandeel. Als de gate binnen twee minuten opmerkt, voegt een inwerktijd van tien minuten vooral wachttijd toe. Duurt het vijftien minuten, dan laat een inwerktijd van vijf minuten de wijziging eerst 25% of meer bereiken.
Kan ik dit ook voor feature flag-uitrol gebruiken en niet alleen voor deploys?
Ja. Een percentage-uitrol van een flag werkt voor deze berekening hetzelfde als een canary-deploy: een verkeersaandeel, een inwerktijd, een detectievertraging en een terugdraaitijd. Vervang de terugdraaitijd door de latentie van je kill-switch voor flags.

Wil je dat de gate het terugdraaien voor je doet?

upstreamapi draait progressieve uitrollen met SLO-gates en automatische rollback, dus de derde kolom is de variant die je in productie zet.

Bekijk upstreamapi