Michael JohnsonAgentovi lze zadat úkol, počkat na změny v repozitáři a získat koncept pull requestu ke kontrole. Spolu s kódem se ale objevuje otázka: odpovídá výsledek zadání a neunikl testům nějaký důležitý problém?
Dne 4. února 2026 GitHub oznámil veřejné preview Claude a Codex jako kódovacích agentů. Společnost uvedla, že agentům lze zadávat úkoly z issues a pull requestů a poté kontrolovat jejich připravený koncept PR. To potvrzuje, že se tento scénář objevil v prostředí pro vývoj, nedokazuje to však ani úsporu času, ani vyšší kvalitu kódu.
Otázkou tedy není jen to, zda agent dokáže napsat kód. Důležité je, jakou práci musí člověk vykonávat kolem delegovaného úkolu: stanovit omezení, sledovat průběh práce a vyhodnotit výsledek.
Dohled není jen závěrečná kontrola
V preprintu zveřejněném na arXivu 21. září 2026 navrhují výzkumníci chápat dohled nad kódovacím agentem jako průběžný proces. Studie The Work Behind Delegation vychází z pozorování a schémat pracovních postupů 19 zkušených vývojářů. Autoři popisují sedm fází dohledu a tento rámec uplatňují na veřejné diskuse vývojářů na Redditu.
Mezi přístupy popsanými autory patří věnovat více pozornosti plánování, svěřit část úkolů spojených s dohledem jiným agentům a převádět opakované pokyny na materiály k opětovnému použití. Jde o analytický rámec, nikoli o měření časových nákladů: studie nestanovuje, kolik času vývojáři věnují kontrole ani zda je tento proces rychlejší než ruční práce. Na stránce arXivu je preprint označen jako recenzovaný, jeho závěry je proto třeba považovat za předběžné.
V praxi je užitečné rozlišovat tři činnosti. Zadání úkolu stanovuje cíl a omezení. Sledování pomáhá zjistit, zda se agent neodchýlil od záměru. Kontrola umožňuje posoudit, zda lze výsledek přijmout s ohledem na požadavky, kód a testy. Úspěch v jedné fázi nezaručuje úspěch v další: patch může vypadat věrohodně, ale řešit nesprávný úkol nebo vyžadovat zásadní přepracování.
Zkušenosti komunity nejsou statistika
V diskusi na r/LocalLLaMA jeden účastník napsal, že jeho zkušenost s lokálními modely a agenty byla zklamáním: podle jeho slov musel opravovat výsledek a agentům připomínat pokyny. Jiní účastníci stejného vlákna popsali postup, který jim připadal užitečnější: omezovat rozsah úkolů, pracovat po etapách a kód pečlivě kontrolovat. Jde o jednotlivá uživatelská pozorování, nikoli o srovnávací test modelů nebo měření produktivity týmů.
Takto rozdílné ohlasy ukazují, že zkušenost může záviset na úkolu, modelu, prostředí a způsobu práce. Z jediné diskuse však nelze určit, které postupy jsou v průměru účinnější a jak často se problémy objevují. Vlákno se věnuje lokálním modelům, a jeho pozorování proto nelze automaticky vztahovat na všechny agentní nástroje.
Zapojení člověka samo o sobě neznamená, že delegování nemá smysl. Vývojář může rozdělit úkol na části, kontrolovat změny a upřesňovat požadavky, a přitom zůstat odpovědný za výsledek. Bez započtení času na zadání úkolu, opravy a revizi však nelze říci, zda se celkový objem práce snížil.
Koncept PR ještě není přijatý PR
V popsaném scénáři GitHubu lze agentovi zadat issue a získat koncept pull requestu. Mezi jeho vytvořením a přijetím zůstává několik samostatných otázek: odpovídá změna požadavkům, zohledňuje okrajové případy, obsahuje dostatek testů a hodí se do architektury projektu?
Tato kritéria nelze zredukovat na jedinou metriku. Počet vytvořených změn se nerovná počtu použitelných změn a úspěšné projití testy nemusí potvrzovat všechny důležité vlastnosti patche. Ani výsledek, který na první pohled působí kvalitně, sám o sobě neukazuje, kolik práce si vyžádala jeho příprava a kontrola.
Pro vyhodnocení celkového efektu je třeba zohlednit celý cyklus: zadání úkolu, čekání na výsledek, revizi, opravy a následnou údržbu kódu. Zkoumané zdroje takové celkové srovnání neposkytují.
Co lze vyvodit
Preprint nabízí rámec pro debatu o dohledu a GitHub informoval o scénáři, v němž se agentovi zadá úkol a kontroluje se připravený PR. Diskuse na Redditu ukazuje, že jednotliví uživatelé popisují jak potíže, tak užitečné způsoby práce s lokálními modely. Tyto materiály společně umožňují položit otázku, jak organizovat kontrolu delegovaného kódu, neposkytují však odpověď ohledně čisté produktivity.
Nelze z nich vyvodit, že vývojáři obecně už přešli od psaní kódu k dohledu, že agenti vždy vytvářejí práci navíc nebo že zvyšují produktivitu celého odvětví. K takovým závěrům jsou potřeba srovnatelná měření času a kvality u různých úkolů a v různých týmech.
Praktická otázka pro tým je konkrétnější: jaké změny může agent připravit samostatně, co je třeba zkontrolovat před sloučením a kdo odpovídá za to, že výsledek řeší původní úkol? Delegování tuto inženýrskou práci neruší — mění, kde začíná a na co se soustředí.