AI-agent voor CI-foutopsporing en incidentrespons

Een deployment die midden in de nacht faalt, zou niemand meer wakker moeten maken. Toch is het in veel teams nog altijd een engineer met wachtdienst die koudweg de logs opent, de foute commit opzoekt en het Slack-bericht typt dat de rest waarschuwt. Een autonome AI-agent kan die eerste stap overnemen, zonder ooit het menselijk oordeel over de kernoorzaak of de fix te vervangen.

Het probleem

De cijfers over de betrouwbaarheid van CI/CD-pipelines zijn niet goed. Volgens het rapport State of Software Delivery 2026 van CircleCI is het slagingspercentage van builds op de hoofdbranch gezakt naar 70,8 procent, het laagste niveau in vijf jaar en ruim onder de drempel van 90 procent die de leverancier aanbeveelt (CircleCI, 2026). Concreet mislukken ongeveer drie op de tien merge-pogingen nog voor ze in productie komen.

Aan de incidentkant stelt het rapport State of Incident Management van Runframe, gepubliceerd begin 2026, vast dat het aandeel engineeringtijd dat opgaat aan routineus operationeel werk (op meldingen reageren, fouten triëren, informatie doorgeven) weer is gestegen naar 30 procent, voor het eerst in vijf jaar ondanks investeringen in AI (Runframe, 2026). Hetzelfde rapport stelt dat ongeveer twee derde van de dagelijks gegenereerde meldingen zou worden genegeerd bij gebrek aan tijd om ze correct te triëren. Dat is een orde van grootte om met voorzichtigheid te lezen: het rapport bundelt meerdere externe studies en kwalitatieve interviews, het is geen directe, eenduidige meting.

Het DORA-rapport 2025 over AI-ondersteunde softwareontwikkeling wijst in dezelfde richting op een fundamenteel punt: AI versterkt wat al aanwezig is in een organisatie, het corrigeert geen wankel triageproces, het maakt het alleen zichtbaarder, sneller (DORA, 2025). Een slecht bewaakte pipeline blijft dat, met of zonder AI, zolang niemand de fouten continu in de gaten houdt.

Dit laatste punt telt vooral voor teams die met een beperkte wachtdienst draaien, waar één ingezette persoon meerdere services tegelijk bewaakt. Een buildfout die om 3 uur 's nachts binnenkomt, wacht doorgaans niet tot iemand wakker wordt om geclassificeerd te worden: hij blijft ofwel onopgemerkt tot de ochtend, of hij maakt iemand wakker voor een probleem dat, eenmaal getriëerd, klein blijkt te zijn. Beide uitkomsten kosten geld, de ene in oplostijd, de andere in opgebouwde wachtdienstmoeheid.

Wat de agent doet, stap voor stap

Bij Atako wordt deze agent niet één keer geactiveerd om daarna stil te vallen: hij draait continu in zijn eigen geïsoleerde omgeving. Twee invoermechanismen voeden hem: een inkomende webhook die het team configureert om CI/CD-gebeurtenissen te ontvangen, en een cronjob die de agent zelf inplant om periodiek de status van de workflows te controleren, mocht de webhook een gebeurtenis missen.

Zodra een fout binnenkomt, leest de agent de logs en de stack trace van de job om het type probleem te classificeren (compilatie, test, dependency, deployment), en koppelt hij die fout vervolgens aan recente commits en pull requests om de vermoedelijke auteur en de verdachte wijziging te identificeren. Daarna post hij een gestructureerde samenvatting op Slack in het wachtdienstkanaal, met directe links naar de job en de betrokken commit, en opent hij tegelijk een Jira-ticket gekoppeld aan de build. Overschrijdt de ernst een door het team vastgestelde drempel (geblokkeerde deployment, meerdere getroffen services), dan gaat er een extra escalatie naar de juiste mensen. Ten slotte schrijft hij een eerste versie van het incidentrapport: tijdlijn, getroffen services, relevante logs, vermoede oorzaak, bewust open gelaten voor menselijke herlezing in plaats van gepresenteerd als een definitieve conclusie.

De gebruikte integraties

Elke integratie wordt toegekend via een precieze grant, die exact begrenst wat de agent mag doen, nooit een generieke toegang tot de hele tool.

GitHub en GitLab leveren het lezen van pipelines, jobs en commits, met optionele schrijftoegang om een issue te openen of te becommentariëren als de grant die scope dekt. Op GitHub gaat het concreet om list_workflow_runs en get_job_logs_download_url aan de leeskant, en create_issue en add_issue_comment aan de schrijfkant.

Slack ontvangt de triagesamenvattingen via post_message, in het door het team gekozen kanaal, met de mogelijkheid om via schedule_message een herinnering in te plannen als een incident te lang open blijft staan.

Jira draagt het incidentticket zelf: create_issue bij opening, update_issue en transition_issue tijdens de afhandeling, tot aan de sluiting.

Datadog laat de agent, zodra het team dit heeft gekoppeld, prestatiemetrieken en applicatietraces kruisen met de CI-fout om zijn hypothese over de kernoorzaak te verfijnen. PagerDuty heeft momenteel geen eigen integratiepagina bij Atako, maar blijft bruikbaar als alarmdoel via een uitgaande webhook, geconfigureerd via Jira of Slack.

Wat bij de mens blijft

De agent beslist nooit zelf om een fix samen te voegen, en dat is geen detail van het ontwerp, het is de manier waarop Atako autonomie structureert. Elke actie die de agent op GitHub, GitLab, Jira of Slack kan uitvoeren, hangt af van een expliciete grant: welke precieze acties zijn toegestaan, met welke reikwijdte (alleen lezen of lezen en schrijven). Die reikwijdte geldt zelfs als een schrijfactie per ongeluk in een als lees-grant gemarkeerde lijst zou belanden, en er wordt nooit standaard iets toegekend door het enkele koppelen van een tool.

Dat laat drie dingen duidelijk bij de mens. Eerst het onderzoek naar de kernoorzaak en de technische beslissing over de fix: de agent levert een startpunt (logs, verdachte commit, geschiedenis), geen definitieve diagnose. Vervolgens het schrijven en samenvoegen van de code, van nature een menselijke actie, buiten het bereik van wat de agent kan doen. Ten slotte de post-mortem: kritiekheidsdrempels aanpassen, het runbook herzien, de triageregels verbeteren, teamwerk dat de agent niet vervangt.

Deze verdeling valt onder wat human-in-the-loop heet: de agent absorbeert het repetitieve en tijdrovende deel van de triage, de mens houdt de controle over de beslissingen die er echt toe doen. Om te controleren wat de agent daadwerkelijk heeft gedaan, wordt elke integratieaanroep vastgelegd, met de betrokken agent, de actie, de status (toegestaan en uitgevoerd, geweigerd door een grantcontrole, of mislukt aan de kant van de leverancier) en de latentie. Dit spoor is zichtbaar in de activiteitentijdlijn van de agent en, voor een beheerder, in het bedrijfsbrede integratielogboek, exporteerbaar als CSV.

Meetbaar resultaat

Het meest directe voordeel is de tijd tussen het falen van de build en het moment waarop de juiste persoon over volledige informatie beschikt om te handelen. Niemand hoeft nog te wachten tot een mens de melding opmerkt, de logs opent en ze handmatig naast recente commits legt: de agent doet dat continu, ook om 3 uur 's nachts, zonder ooit te slapen of van humeur te veranderen naargelang de werkdruk van de week. Dat vervangt de klassieke DORA-metrieken zoals deploymentfrequentie of hersteltijd na een fout niet, maar het vermindert het deel van die metrieken dat uitsluitend afhangt van menselijke beschikbaarheid op een bepaald moment.

De kosten volgen het Standard-plan van Atako: 20 euro per maand per agentslot, met 1000 credits inbegrepen per maand voor de modelaanroepen die worden gebruikt voor de redenering, classificatie en het opstellen van teksten. Om het rendement vooraf te becijferen, staat het detail op de pagina tarieven.