Hud koppelt AI-code aan gecontroleerde productie-uitrol

Hud lanceert agentic rollouts die AI-geschreven code tijdens productie-uitrol op functieniveau toetsen, door nieuwe backendversies met normaal productiegedrag te vergelijken en via de bestaande CD automatisch of na menselijke goedkeuring terug te draaien.

Wanneer een regressie live verkeer raakt, moet een team anders eerst signalen uit de uitrol, meetgegevens en codewijziging bij elkaar zoeken. Hud wil dat werk naar de releaseketen halen: de controle benoemt welke functie afwijkt en welke uitrol eraan voorafging. Voor Nederlandse softwareteams kan dat de tijd tussen een regressie en terugdraaien verkorten. Of de reactie automatisch doorgaat, blijft instelbaar in de bestaande CD-keten, het systeem dat code test en uitrolt.

Iedere functie krijgt een productieprofiel

Hud bouwt de controle op een sensor die met een softwarebibliotheek in backenddiensten meedraait. De sensor telt iedere functieaanroep en uitzondering, brengt in kaart welke functie een andere aanroept en leert hoe functies zich normaal gedragen voordat een nieuwe versie wordt uitgerold. Duurmetingen worden bemonsterd; het referentiegedrag wordt continu bijgehouden.

Voor een pull request, een voorgestelde codewijziging, laat Hud zien welke functies de wijziging raakt, hoeveel verkeer ze verwerken en welke onderdelen ze aanroepen. Een controle in de CI-keten, de geautomatiseerde tests voor een release, vergelijkt testresultaten met de bestaande versie. Als een functie trager wordt of vaker faalt, verschijnt de afwijking met een hoog, gemiddeld of laag risiconiveau. Hud beoordeelt mee, maar voegt pull requests niet zelfstandig samen.

Tijdens de uitrol vergelijkt Hud het gedrag van functies met hun productieprofiel. Het systeem meldt ook een nieuw soort foutmelding wanneer de code die fout zelf opvangt. Standaard krijgt een functie aandacht wanneer die ongeveer twee keer zo traag wordt of een nieuwe foutsoort veroorzaakt. Een nieuwe functie krijgt binnen enkele minuten nadat die verkeer krijgt een eerste bruikbare referentie. Voor een profiel dat dagelijkse en wekelijkse patronen omvat, kan de volledige referentie binnen een week ontstaan.

De bestaande CD kiest de terugrolroute

Bij een regressie kan Hud de nieuwe versie via de bestaande CD terugdraaien. Een team kan die stap automatisch laten uitvoeren, of Hud kan terugdraaien voorstellen en wachten tot iemand het goedkeurt. De keuze zit in de CD-inrichting. Hud sluit via een automatische koppeling aan op GitHub, CI en CD en draait naast bestaande applicatiemonitoring.

Riverside combineert canary-uitrollen met Hud-controle en automatische terugdraaiing. Hud meldt dat Riverside mislukte uitrollen gemiddeld in ongeveer acht minuten terugdraait. Dat is een klantvoorbeeld, geen onafhankelijke benchmark. De scorecard voor productie-agents meet uitzonderingsratio, menselijke vrijgavetijd en herstel per taaktype.

Een canary stuurt eerst een deel van het verkeer naar de nieuwe versie. Argo Rollouts kan een canary afbreken wanneer de ingestelde analyse niet slaagt. Hud voegt een eigen sensor en een geleerd profiel per functie toe. Teams hoeven daardoor niet voor iedere functie zelf een metriek en drempel te kiezen.

New Relic volgt serviceprestaties na de uitrol

New Relic kijkt naar een ander meetpunt. Change Tracking vergelijkt serviceprestaties op zes momenten na een Copilot-uitrol: na 10 en 30 minuten, één en twee uur, en na 24 en 72 uur. Bij een gemelde regressie plaatst Autopilot bewijs bij de pull request en opent het een GitHub-issue en wijst dat toe aan Copilot. Een voorgesteld codevoorstel moet daarna nog worden beoordeeld; voor automatisch starten is Copilot Enterprise nodig.

De documentatie beschrijft meldingen, een GitHub-issue en een codevoorstel dat eerst beoordeeld moet worden, maar noemt geen automatische terugdraaiing. Hud vergelijkt functies met hun productieprofiel terwijl een versie verkeer krijgt, en kan de bestaande CD laten terugdraaien. De controles kunnen dus naast elkaar staan: de ene volgt serviceprestaties na de uitrol, de andere controleert functieverandering terwijl de nieuwe versie verkeer krijgt.

De sensor bestrijkt niet elke fout

Hud noemt Node.js 16+, Python 3.8+ en Java 8 tot en met 25 voor backenddiensten. Frontendcode, Terraform-code, migraties en code van derden vallen buiten die dekking. De sensor telt iedere functieaanroep en uitzondering, maar meet tijdsduur via steekproeven. Bij fouten of sterke afwijkingen verzamelt Hud extra gegevens, waaronder de aanroepketen en foutdetails, en zegt gevoelige waarden binnen de applicatiecontainer te verwijderen voordat gegevens de omgeving verlaten.

Een normale functieprestatie bewijst niet dat een bestelling, prijs of klantstatus inhoudelijk klopt. Hud zegt zelf dat het geen bedrijfsregels, end-to-endtests of visuele regressies controleert. Die tests moeten de releaseketen dus op een andere plek afvangen. Een groene functiecontrole vertelt welk deel van de code zich anders gedraagt. Ze zegt niet of de verandering ook de bedoeling van het bedrijf uitvoert.

The Next Web publiceerde het artikel op 29 oktober en markeert het als bijdrage die niet door de redactie is geproduceerd. De technische uitleg en Riverside-cijfers komen vooral van Hud zelf, en de pagina geeft geen onafhankelijk cijfer voor minder incidenten of een lager foutpercentage. Voor teams die AI-code naar productie brengen, blijft het beslissende bereik daarom afhankelijk van drie bestaande onderdelen: welke functies de sensor ziet, welke controles de testketen uitvoert en of de CD terugdraaien zelfstandig mag afhandelen.