U většiny týmů zavádějících agentní kódování se úzké hrdlo přesouvá z generování ke kontrole. Bez nápravy celé smyčky je celkové zvýšení tempa téměř nulové.
V rozsáhlých prostředích CI s miliony nočních testů a stovkami vývojářů přinášejí agenti největší hodnotu při určování odpovědnosti a třídění problémů, nikoli při generování kódu.
Užitečný výstup agenta obstojí při důkladné kontrole a vysvětluje příčinné souvislosti, ne pouze odpovídající vzorce.
Návrh vrstvy pro shromažďování důkazů a sestavování kontextu je důležitější než vrstva generování.
Většina debat o agentním kódování stále začíná jednoduchým příslibem: napsat více kódu, a to rychleji.
Někdy se tento příslib rozvine v ambicióznější vizi agentů, kteří plánují práci, otevírají pull requesty a shippují změny s minimální účastí člověka. Pro většinu vývojářských týmů je však nejzřetelnější krátkodobý přínos užší. Spočívá ve snížení nákladů na iterace.
Vývoj a nasazování softwaru není jen generování kódu. Psaní kódu je pouze jednou fází delšího cyklu, který zahrnuje kontrolu, testování, nasazení a také vyšetřování případných problémů. Většina týmů, které zavedou agentní kódování bez přepracování kontrolního cyklu, pouze posune úzké hrdlo do další fáze.
Samotné zrychlení generování automaticky nezrychlí celý tým. Může pouze přesunout více práce do fáze kontroly, ověřování a budování důvěry.
V mnoha vývojářských prostředích není nákladné vytvoření prvního návrhu, ale získání důvěry.
Opravila změna skutečně daný problém nebo systém zlepšila? Nezpůsobila regresi někde jinde? Je chyba v kódu, prostředí, testech, nebo v některé závislosti? Řeší navrhovaná oprava příčinu, nebo jen viditelný příznak?
Právě zde mohou agenti pomoci. Ne proto, že by nahrazovali vývojáře, ale protože dokážou provést strukturovanou prvotní analýzu neuspořádaných podkladů: projít protokoly, porovnat nedávné změny, shrnout relevantní signály, vystopovat pravděpodobné příčiny, provést kontroly a předložit výsledek, který může člověk dále prověřovat.
V mnoha týmech nepřináší agent největší efekt tím, že generuje kód od nuly. Největší přínos spočívá v tom, že zúží prostor okolo problému dříve, než nad ním člověk stráví hodiny ruční práce.
Zvlášť patrné je to u rozsáhlých procesů ladění. Představte si noční běh CI, při němž se napříč kódovými základnami upravovanými stovkami vývojářů spouštějí miliony testů. Pro jednoho z našich klientů je to realita. Když něco selže, je obtížné zjistit, kdo je odpovědný. Problém může být v aplikačním kódu, závislosti, testovacím harnessu nebo kdekoli jinde v technologickém zásobníku. Protokoly mohou mít celé gigabajty a tým, který problém odhalí jako první, za něj nemusí odpovídat.
Takový proces přirozeně nepotřebuje, aby opravu napsal jediný agent. Je jako stvořený pro systém, který rychle zužuje prostor možných příčin problému.
Užitečná pipeline může načíst protokoly, vybrat relevantní důkazy, shrnout podstatné informace, prozkoumat kód v sandboxu a vytvořit strukturovanou analýzu kořenové příčiny včetně hodnocení spolehlivosti, dohledatelnosti a návrhu dalších kroků. Pro stanovení míry spolehlivosti nejprve výstup agenta ohodnotí odborník na danou oblast. Toto hodnocení se poté předá LLM v roli hodnotitele, který automatizuje další hodnocení a zároveň zůstane v souladu s lidským úsudkem.
Cílem není odstranit odborný úsudek vývojářů, ale poskytnout kontrolujícím lepší výchozí bod. Třídění regresí, kontrola pull requestů, opravy testů, ověřování vydání i vyšetřování po nasazení mají stejnou povahu. Vyžadují mnoho podkladů a kontrol a jsou plné nejasností. Nežádají po agentovi, aby nahradil vývojový proces, ale pouze aby jej pomohl posunout dál.
Právě proto by si týmy měly dávat pozor na to, jak tyto systémy hodnotí.
Nesprávná otázka zní, zda agent dokáže sám o sobě vytvořit něco působivého. Lepší je ptát se, zda zlepšuje skutečný pracovní proces, aniž by někde jinde vytvářel překážky.
Je tedy třeba posoudit, zda je výstup dostatečně konkrétní, aby jej bylo možné ověřit, zda vysvětluje příčinné souvislosti, místo aby jen hledal vzorce, a zda kontrolu usnadňuje, namísto aby ji komplikoval. Věrohodná odpověď není totéž co užitečná odpověď. V praxi týmy důvěřují výstupu agenta tehdy, když obstojí při důkladné kontrole a nabídne jim něco konkrétního k ověření.
Hlubší ponaučení zní, že užitečné agentní systémy závisejí nejen na generování – odvíjejí se od toho, jak se shromažďují důkazy, sestavuje kontext, kontrolují výstupy a jak se kontrolujícímu sděluje míra nejistoty.
Proto blízká budoucnost agentního vývoje pravděpodobně nebude spočívat v jediném obřím skoku k plné autonomii. Spíše půjde o soubor pečlivě navržených smyček, v nichž agenti pomáhají týmům zkoumat, kontrolovat, ověřovat a zdokonalovat práci tak, aby se mezi jednotlivými kroky plýtvalo méně úsilím.
Možná to působí méně dramaticky než širší vize autonomie, ale mnohem lépe to odpovídá tomu, jak se užitečné systémy skutečně zavádějí.