AI-agent voor bewaking en triage van door gebruikers gemelde bugs

Een bug in productie meldt zich nooit op het juiste moment. Hij duikt op als een verloren fout in een logstroom die niemand in real time bekijkt, of als een supportticket geopend door een klant die het symptoom beschrijft zonder de technische oorzaak te kennen. Tussen beide bestaat vaak geen enkele automatische koppeling: het engineeringteam ontdekt het probleem pas wanneer support uiteindelijk escaleert, soms uren nadat de eerste gebruikers het al zijn tegengekomen. Een autonome AI-agent die beide stromen tegelijk bewaakt, dicht die kloof.

Het probleem

De tijd die developers besteden aan het oplossen van bugs, in plaats van aan nieuwe code, blijft een van de best gedocumenteerde productiviteitsverliezen in softwareontwikkeling. Een wereldwijd onderzoek van Rollbar onder 950 developers (via Propeller Insights) toonde al aan dat 32% van de developers tot 10 uur per week besteedt aan het oplossen van bugs in plaats van code te schrijven, en dat 38% er tot een kwart van hun totale werktijd aan besteedt (bron). Dit onderzoek dateert van 2021 en moet eerder als orde van grootte dan als actuele meting worden gelezen, maar de vaststelling die het documenteert, een significant deel van de engineeringtijd dat door correctie in plaats van bouw wordt opgeslokt, keert consequent terug in recentere studies over developerproductiviteit.

De werkelijke uitdaging is niet alleen de correctietijd, maar de vertraging tussen het ontstaan van een probleem en de detectie ervan. Het DORA State of DevOps-rapport 2024 stelt hierover precieze referentiepunten: de best presterende teams herstellen een verslechterde dienst in minder dan een uur, de zeer goed presterende teams in minder dan een dag, de gemiddelde teams tussen een dag en een week, en de zwakst presterende teams kunnen er tussen een week en een maand over doen (bron). Het verschil tussen de top en de onderkant van deze schaal loopt dus in weken, niet in uren, en deze vertraging hangt rechtstreeks af van hoe snel een afwijking wordt gedetecteerd en correct geprioriteerd, nog voordat ze wordt opgelost.

Deze vertraging heeft een directe kost wanneer het probleem de productie raakt. De ITIC 2024-studie, uitgevoerd bij meer dan 1.000 bedrijven wereldwijd tussen november 2023 en maart 2024, geeft aan dat de gemiddelde kost van een uur ontoegankelijkheid voor meer dan 90% van de middelgrote en grote bedrijven boven 300.000 dollar uitkomt, en dat 41% van de grote bedrijven deze uurkost inschat tussen 1 en 5 miljoen dollar (bron). Deze cijfers betreffen grote storingen en gelden niet voor elke geïsoleerde bug, maar ze tonen de orde van grootte van wat op het spel staat wanneer een probleem dat vroeg had kunnen worden gedetecteerd, te lang onzichtbaar blijft, verdronken in een logstroom die niemand continu bewaakt.

Eén punt verdient verduidelijking om twee verwante gebruiksscenario's niet te verwarren. CI-opvolging, die build- en testfouten betreft voordat een deployment de productie bereikt, is een ander probleem dan wat hier wordt behandeld. Deze pagina gaat over bewaking na deployment: fouten die zich werkelijk bij gebruikers voordoen, en de supportickets die zij openen om ze te beschrijven, twee stromen die vaak hetzelfde incident vertellen zonder ooit automatisch te worden gekoppeld.

Dit gebrek aan koppeling heeft een concreet effect op de prioritering. Een bug die vijf discrete technische fouten in de logs genereert maar twintig identieke supportickets veroorzaakt, verdient dringende behandeling, terwijl een bug die honderd technische fouten genereert zonder dat één klant klaagt, vaak kan wachten tot de volgende cyclus. Zonder de twee bronnen te kruisen, prioriteert een engineeringteam blind, enkel op basis van het technische volume, wat niet altijd de werkelijke impact weergeeft die gebruikers ervaren.

Wat de agent doet, stap voor stap

De agent bewaakt continu de productiefoutenstromen, de latentiemetrieken en de applicatielogs, hetzelfde ruwe materiaal als een klassieke monitoringtool. Het verschil begint bij de volgende stap: hij bewaakt tegelijk de door gebruikers geopende supportickets, om meldingen te signaleren die een technische afwijking in gewone taal beschrijven in plaats van in stack trace. Vervolgens groepeert hij de fouten en tickets die hetzelfde probleem beschrijven, in plaats van elk voorval afzonderlijk te behandelen zoals een ruw alertingsysteem zou doen. Op basis van deze groepering beoordeelt hij de frequentie, de geschatte gebruikersimpact en de ernst van de afwijking. Hij maakt een gestructureerde issue aan in GitHub of Linear met de probleembeschrijving, de stack trace, een impactinschatting en een al bepaald prioriteitsniveau. Hij meldt het betrokken team op Slack met deze al verzamelde context, en escaleert naar de wachtdienst alleen als de vooraf bepaalde ernstdrempels worden overschreden.

De gebruikte integraties

De detectie steunt op Datadog, of op Sentry voor teams die de voorkeur geven aan een tool gespecialiseerd in het opvolgen van fouten en stack traces. De koppeling met de gebruikerservaring loopt via Intercom, of Zendesk naargelang de al gebruikte supporttool, om geopende tickets te kruisen met de technisch gedetecteerde fouten. Het aanmaken van issues gebeurt in GitHub of Linear naargelang de opvolgingstool van het team, met de beschrijving, de stack trace en het prioriteitsniveau al ingevuld. Slack draagt de teammeldingen, en een escalatie naar PagerDuty kan worden geactiveerd voor incidenten waarvan de ernst de bepaalde drempel overschrijdt.

Wat bij de mens blijft

Het engineeringteam bepaalt de ernstdrempels en de escalatieregels bij de configuratie van de agent, een initiële afstemming die vervolgens bepaalt wat al dan niet een alert naar de wachtdienst activeert. Het ontvangt al getrieerde en gecontextualiseerde issues, inclusief stack trace en impactinschatting, en hoeft alleen nog de fix te schrijven in plaats van de context vanuit ruwe logs te herbouwen. Het past de prioriteringsregels aan naarmate het product evolueert, een nieuwe module of een nieuwe integratie verandert onvermijdelijk wat op een bepaald moment als kritiek geldt. De fix zelf, de afweging tussen wat een onmiddellijke hotfix verdient en wat een geplande correctie kan wachten, blijft volledig een menselijke beslissing.

Meetbaar resultaat

Het meest directe voordeel is een kortere vertraging tussen het ontstaan van een probleem in productie en de omzetting ervan naar een bruikbare issue, in plaats van verdronken in een logstroom of verspreid over meerdere supportickets die hetzelfde symptoom beschrijven zonder gekoppeld te worden. Gezien het door het DORA-rapport gedocumenteerde verschil tussen een servicehersteltijd van minder dan een uur voor de best presterende teams en meerdere dagen voor de gemiddelde teams, werkt een kortere detectie- en triagetijd rechtstreeks in op het vermogen van een team om richting de top van deze schaal op te schuiven in plaats van in het gemiddelde vast te blijven zitten. Het tweede voordeel is minder ruis voor de wachtdienst: door alleen afwijkingen te laten doorstromen waarvan de ernst een bepaalde drempel overschrijdt, vermindert de agent onnodige onderbrekingen voor kleine fouten, een bijzonder gevoelig punt voor kleine teams zonder uitgebreide wachtdienstrotatie, waar elke nachtelijke oproep rechtstreeks weegt op de beschikbaarheid en concentratie de volgende dag, met een cumulatief effect over meerdere weken als de ruis slecht gefilterd blijft.