Agentická triáž v Astro stlačila backlog z vyše 200 na sedem otvorených issues

Od experimentu k merateľnému výsledku

Cloudflare v auguste opísalo automatizovanú triáž chýb, ktorú niekoľko mesiacov prevádzkovalo v open-source repozitári Astro. Systém číta hlásenia na GitHube, pokúša sa ich reprodukovať, hľadá príčinu, pripravuje opravu a publikuje skúšobný balík. Pôvodný článok AI Feed zachytil tvrdenie firmy, že počet otvorených issues klesol z viac ako 200 na približne 30. Následná kontrola verejného repozitára 1. septembra 2026 ukázala už iba sedem otvorených issues. To samo osebe nedokazuje, že všetky ostatné vyriešil agent, potvrdzuje však, že deklarovaný pokles backlogu pokračoval a neostal iba jednorazovým marketingovým údajom.

Dôležité je, že nejde o jednoduchého bota, ktorý staré hlásenia automaticky zatvára. Cloudflare tvrdí, že nepoužilo „issue bankruptcy“, teda hromadné odpísanie backlogu bez vecného posúdenia. Workflow napodobňuje štyri kroky manuálnej práce správcu: reprodukciu problému, diagnostiku príčiny, overenie, či správanie naozaj odporuje testom alebo dokumentácii, a prípravu opravy. Ak systém riešenie nájde, vytvorí vetvu a náhľadové vydanie balíka. Pull request sa v štandardnom režime otvorí až po tom, čo autor hlásenia potvrdí, že skúšobná verzia problém odstránila.

Verejné údaje z GitHubu umožňujú preveriť aspoň časť tohto procesu nezávisle od blogového opisu. Issue číslo 17848 sa týkalo nesprávne serializovanej domovskej adresy v sitemapách. Bot zaznamenal úspešnú reprodukciu, diagnostiku aj priechod existujúcich testov, zverejnil inštalačný príkaz pre náhľadovú verziu a upozornil, že analýzu vytvoril jazykový model a môže byť chybná. Autor hlásenia následne opravu výslovne potvrdil. Automatizácia potom zmenila stav na „fix verified“, vytvorila pull request 17851 a issue sa po jeho spracovaní uzavrelo. Ide o konkrétnu auditovateľnú stopu, nie iba agregované číslo poskytnuté prevádzkovateľom.

Prečo sú fázy oddelené

Jedným z najzaujímavejších prvkov návrhu je rozdelenie práce medzi izolovaných subagentov. Reprodukcia, diagnostika, kontrola očakávaného správania a oprava neprebiehajú v jednej dlhej konverzácii. Každá fáza dostane užšie zadanie a svoje zistenia odovzdá ďalšej prostredníctvom súboru report.md. Cloudflare tým cieli na známy problém kódovacích modelov: keď model raz prijme hypotézu, že hlásenie opisuje chybu, môže sa snažiť presadiť zmenu aj vtedy, keď ide o zamýšľané správanie alebo nedostatočný reprodukčný príklad. Oddelenie rolí túto tendenciu neodstraňuje, ale vytvára kontrolné body a čitateľné medzivýsledky.

Stav workflowu je uložený prevažne priamo v GitHube. Štítky ako „needs reproduction“, „unable to fix“, „fix pending“, „fix rejected“ alebo „fix verified“ tvoria konečný stavový automat. Komentáre a udalosti určujú, či sa má triáž zopakovať, čakať na doplnenie informácií alebo skončiť. Samostatný repozitár withastro/triagebot-action potvrdzuje, že názvy štítkov možno upraviť a že neúspešné spracovanie sa automaticky neopakuje neobmedzene. Pri stave zlyhania je počet pokusov obmedzený, čím sa znižuje riziko nekonečnej slučky a zbytočnej spotreby výpočtových zdrojov.

Zverejnená implementácia zároveň ukazuje dôležité rozdelenie zodpovednosti. Samotná GitHub Action spravuje udalosti, štítky, volania modelov, vetvy a pull requesty, zatiaľ čo projekt dodáva vlastné zručnosti pre reprodukciu, diagnostiku, verifikáciu a opravu. Nástroj teda nie je univerzálny opravár, ktorý možno bez prípravy nasadiť na ľubovoľný repozitár. Potrebuje projektové pokyny, funkčný build, testy a dostatočne zrozumiteľnú architektúru. Podporuje viac poskytovateľov modelov, no kvalita výsledku bude závisieť aj od zvoleného modelu a od toho, aké oprávnenia a kontext dostane.

Praktická hodnota aj nové riziká

Pre správcov open-source projektov môže byť najväčším prínosom automatizovaná reprodukcia. Vytvorenie issue je dnes lacné, no overenie prostredia, verzie závislostí a minimálneho príkladu môže zabrať hodiny. Agent vie pripraviť pracovný priestor, spustiť testy a vrátiť štruktúrovaný technický záznam ešte predtým, než sa problému venuje správca. Človek sa potom môže sústrediť na architektonické rozhodnutie, riziko regresie a konečné posúdenie zmeny. Verejný zoznam uzavretých issues v Astro obsahuje viacero augustových prípadov označených „fix verified“, takže nejde iba o jednu demonštráciu vybranú pre blog.

Automatizácia však pracuje s nedôveryhodným vstupom. Text issue, priložený repozitár aj skripty závislostí môžu obsahovať škodlivý obsah. Izolované subagenty riešia najmä kvalitu uvažovania, nie automaticky bezpečnosť vykonávania. Produkčné nasadenie preto potrebuje dočasné prostredia, minimálne oprávnenia tokenov, oddelenie čítacieho a zapisovacieho prístupu, obmedzený sieťový prístup, časové limity a kontrolu toho, čo môže workflow publikovať. Verejná dokumentácia akcie používa osobitný token na čítanie a osobitný zapisovací token; to je dobrý základ, nie úplná ochrana pred kompromitovaným buildom alebo prompt injection v hlásení.

Dôležitá je aj kvalita výstupov. Pokles počtu otvorených issues nie je rovnaký ako pokles počtu regresií, času správcov alebo celkových nákladov. Verejné dáta neuvádzajú presnú mieru chybných diagnóz, počet zásahov ľudí, spotrebu tokenov ani podiel opráv, ktoré neskôr vyžadovali zmenu. Aktuálny zoznam obsahuje aj stavy „fix rejected“, „unable to fix“, „skipped“ či „failed“. Práve ich viditeľnosť je užitočná: ukazuje, že pipeline nepriraďuje každému behu úspech a že spätná väzba používateľa môže navrhnuté riešenie odmietnuť.

Čo si z toho môžu vziať slovenské tímy

Pre slovenské a európske vývojárske tímy je tento príklad relevantný najmä ako vzor kontrolovanej automatizácie, nie ako návod na úplne autonómnu údržbu. Organizácia môže začať iba reprodukciou a klasifikáciou chýb, bez práva agenta zapisovať do hlavnej vetvy. Až po meraní presnosti môže pridať tvorbu náhľadových balíkov alebo pull requestov. Pri firemných repozitároch treba navyše posúdiť, kam sa odosiela zdrojový kód, logy a osobné údaje prispievateľov, ako dlho ich poskytovateľ modelu uchováva a či zvolený región spracovania zodpovedá interným pravidlám a GDPR.

Prípad Astro ukazuje, že agentický workflow môže priniesť reálny prevádzkový výsledok, keď je úloha úzka, stav explicitný a človek zostáva v rozhodovacej slučke. Najsilnejším dôkazom nie je samotný údaj o poklese backlogu, ale verejná postupnosť reprodukcie, návrhu, skúšobného vydania, potvrdenia reportérom a pull requestu. Otvorenou otázkou zostáva ekonomika vo väčšom meradle a prenositeľnosť na projekty so slabými testami či zložitými natívnymi závislosťami. Namiesto predstavy neomylného „softvérového závodu“ tak Astro ponúka praktickejší model: auditovateľnú automatizáciu, ktorá zrýchľuje rutinnú prácu, no svoje zlyhania neskrýva.