GitHub už nepopisuje AI agenta jako chytrý doplněk editoru. Jak jsme shrnuli v dnešní rychlé zprávě o reportu Octoverse, který GitHub zveřejnil v oficiálním reportu, agent stále častěji udělá první krok ke změně kódu, založí práci a připraví výsledek k lidské kontrole. To je mnohem větší změna než rychlejší doplňování řádku.
Podle reportu poslali vývojáři za posledních dvanáct měsíců do GitHubu 17,9 miliardy pushů. U nových repozitářů s agentní konfigurací zaznamenal GitHub v průměru osmkrát více commitů než u nových repozitářů bez ní. Podíl pull requestů vznikajících s pomocí agenta vzrostl ze 17 procent v březnu na více než 40 procent v září.
Čísla pocházejí z vlastních dat GitHubu, takže neříkají, že agenti sami o sobě zvedli produktivitu osmkrát. Říkají ale něco jiného a praktičtějšího: agentní programování se přesouvá z ukázkového dema do běžného provozu. Když se zároveň 61 procent uživatelů GitHub Copilotu v září setkalo s více než jedním modelem, vývojář už nepracuje s jedním pomocníkem, ale s malou sestavou nástrojů.
První návrh už nevzniká u klávesnice
Představme si běžnou úlohu v týmu. Dříve někdo přečetl issue, otevřel editor, napsal první změnu a teprve potom ji poslal dál. Dnes může agent projít repozitář, navrhnout postup, upravit několik souborů, spustit testy a připravit pull request dřív, než člověk otevře první lokální terminál.
Člověk tím z procesu nezmizí, ale mění se místo, kde má největší vliv. Už není nutně autorem každého prvního řádku. Stává se zadavatelem, editorem a poslední kontrolou toho, jestli navržená změna skutečně řeší problém, který měl tým na začátku.
To je důvod, proč samotný počet commitů není dobrá odpověď na otázku, zda se vývoj zrychlil. Commit může být užitečná změna, drobná oprava, automaticky generovaný experiment nebo další kus práce, který bude muset někdo později zahodit. GitHub měří aktivitu a průchod změn systémem; hodnotu výsledku musí posoudit tým.
Na Radyzu jsme podobnou hranici popisovali u testování agentů v kancelářské práci. Agent může správně odpovědět a přesto úkol nedokončit. Ve vývoji softwaru je to stejné: důležitý není jen text v diffu, ale také testy, návaznosti, dokumentace a stav projektu po sloučení.
Osmkrát více commitů může znamenat i osmkrát více práce pro kontrolu
Největší omyl by byl číst report jako příběh o bezpracném násobení výkonu. Každá nová změna má svého příjemce. Někdo ji musí pochopit, spustit, porovnat s požadavkem, zkontrolovat bezpečnostní dopady a rozhodnout, jestli se má dostat do hlavní větve.
Pokud agenti vytvoří více pull requestů, vzniká tlak na review. Tým může mít více hotových návrhů, ale také více míst, kde se schovává chybný předpoklad, zastaralé rozhraní nebo kód napsaný jen proto, že model našel snadnou cestu k zelenému testu. Rychlost výroby bez kapacity na kontrolu není produktivita. Je to fronta.
Tady se vrací starší varování před AI kódem, který roste rychleji než důvěra v jeho kvalitu. GitHub už dříve čelil debatě o zaplavování repozitářů AI generovanými změnami. Nový report tuto otázku nemaže. Jen ukazuje, že problém už není okrajový experiment několika nadšenců.
Rozumný tým proto nebude agentovi měřit pouze počet přijatých návrhů. Bude sledovat, kolik práce skončí po kontrole v produkci, kolik změn se vrací k přepracování, jak dlouho trvá review a jestli se po zavedení agentů nemnoží skryté opravy. Bez těchto metrik je osmkrát více commitů jen velmi působivé číslo.
Agent potřebuje mantinely, ne jen další tokeny
S rostoucím počtem agentů se mění i technická otázka. Neřeší se už jen to, který model píše lepší kód, ale jaké prostředí mu tým připraví, jaké nástroje smí volat a co se stane, když jeho plán narazí na skutečný projekt. Právě tady dává smysl agent harness: obal, který spojuje model s nástroji, stavem úkolu, testy a pravidly pro zastavení.
Dobrý harness nemá agenta pouze rozběhnout. Musí také ukázat, co udělal, proč sáhl na konkrétní soubor, jaké testy opravdu proběhly a kdy už nemá pokračovat bez člověka. Pokud zůstane jen hezký diff a neurčitá věta o úspěšném dokončení, tým si nekoupil autonomii. Koupil si další vrstvu práce, která se hůř kontroluje.
Podobná logika platí pro oprávnění. V článku o řetězení pravomocí mezi agenty jsme řešili, proč nestačí vědět, že nástroj je technicky dostupný. Coding agent může mít přístup k repozitáři, CI i produkčním tajemstvím. To ještě neznamená, že má dostat právo měnit všechno, co dokáže najít.
GitHub mění místo, kde se rozhoduje o kvalitě
Když agent připraví první návrh, kvalita se rozhoduje později a na více místech. U zadání, které dostane. U dat a souborů, ke kterým má přístup. U testů, jež považuje za dostatečné. U review, kde člověk pozná rozdíl mezi skutečným řešením a změnou, která jen uklidila symptomy.
To je méně romantické než představa, že si každý vývojář pořídí digitálního kolegu a práce se sama zrychlí. Ve skutečnosti se z vývoje stává provozní systém pro řízení změn. Kdo nastaví pravidla, rozhoduje také o tom, zda agenti přidají týmu kapacitu, nebo jen zvýší počet věcí, které musí někdo ručně prověřit.
Tím se mění i hodnocení AI agentů. Nejde jen o to, zda model vygeneruje správný kus kódu. Jde o to, jestli ho použije na správná data, zachová záměr úkolu, nepřepíše omylem jinou část projektu a zanechá po sobě kontrolovatelnou stopu.
GitHubův report je proto důležitý hlavně jako záznam posunu, ne jako důkaz vítězství. Agenti už nejsou jen asistenti, kteří našeptávají kód uvnitř editoru. Stále častěji připravují změny, které vstupují do týmového workflow jako první návrh práce.
A právě proto bude v příštích měsících méně důležité, kolik řádků agent vygeneroval. Důležitější bude, jestli tým dokáže rychle poznat, co má cenu přijmout, co vrátit a co vůbec nemělo vzniknout. Kdo zvládne tuto kontrolu, získá z agentů nový výrobní nástroj. Kdo ji přeskočí, bude jen vyrábět software rychleji, než stačí rozpoznat vlastní chyby.
