Před rokem jsi AI napsal "doplň funkci" a doufal, že autocomplete trefí tvůj záměr. Dneska tomu řekneš úkol, zavřeš notebook a za hodinu máš v repozitáři pull request s testama, proběhlým CI a checklistem, co je hotové. Coding agenti přestali být doplňkem editoru — stali se členy týmu, kterým deleguješ backlog.
Posun je zásadní: unitou práce už není řádek kódu, ale ticket. A to mění i to, jak musíš psát úkoly.
Co dnes agent zvládne celé
Moderní coding agent (Copilot coding agent na GitHubu, Codex, Claude Code) funguje v tomhle cyklu:
- Přiřadíš mu issue — na GitHubu doslova klikneš na Assignees a vybereš Copilota, jako bys přiřazoval kolegu.
- Agent si rozplánuje práci — rozloží issue na checklist, vytvoří branch a rovnou otevře pull request, který se před tvýma očima plní.
- Napíše kód i testy — pustí build, iteruje, dokud testy neprojdou.
- Požádá o review — až je hotový, označí tě jako reviewera. Ty schválíš, komentuješ, nebo pošleš zpět na opravu. Úplně jako s člověkem, jen rychleji.
Data z praxe to potvrzují. OpenAI zveřejnil čísla z vlastního nasazení Codexu: přes 70 % uživatelů mu zadalo úkol, který by člověka stál víc než hodinu, a čtvrtina dokonce úkol přesahující osm hodin práce. Zároveň agenti neskončili u vývojářů — právní, finance i HR je používají na automatizace, transformace dat a tooling. To je důležitý signál: delegování na agenta není developer-only skill, je to pracovní dovednost.
Jak napsat issue, které agent skutečně splní
Nejčastější chyba je zadat agentovi úkol jako člověku — vágně. "Oprav ten bug v objednávkách" nestačí. Agent funguje nejlépe, když ho onboarduješ jako chytrého juniora, který ale nic neví o tvém kontextu. Dobrý ticket má:
- Kontext: co úkol znamená, kterých souborů se týká, proč to vůbec děláme.
- Definici "hotovo": acceptance criteria jako konkrétní, testovatelné body. "Po kliknutí na tlačítko se zobrazí modal s formulářem" místo "vylepšit UI".
- Omezení: jaké knihovny používat, čeho se vyvarovat, kde je hranice zásahu.
Druhá zásada: dej vše do issue hned na začátku. Agent dostane titulek, popis a komentáře, které existují v momentě přiřazení — další diskusi pod issue už nesleduje. Pokud chceš něco dodat, piš do pull requestu, ne do issue.
A třetí: specifikuj výstup. Chceš testy? Napiš to. Chceš aktualizovanou dokumentaci? Napiš to. Agent jinak optimalizuje na to, co si vybere sám.
Ukázka: špatně vs. dobře
Špatně:
Opravit filtrování v e-shopu, někdy to nefunguje.
Dobře:
Kontext: V katalogu produktů filtr podle ceny občas ignoruje nastavenou dolní hranici, pokud uživatel předtím použil fulltextové hledání. Chyba je nejspíš v
ProductFilterService, kde se spojují podmínky.Hotovo znamená:
- Filtr podle cenového rozsahu funguje vždy, i v kombinaci s fulltextem
- Přibyvou unit testy pro kombinaci filtr + fulltext (min. 3 scénáře: jen cena, jen fulltext, obojí)
- Nemění se veřejné API controlleru
Omezení: Bez zásahu do databázové vrstvy. Pokud oprava vyžaduje změnu schématu, zastav se a napiš to do PR popisu.
Rozdíl je jasný: u prvního zadání dostaneš náhodný výsledek a strávíš review vysvětlováním, cos vlastně chtěl. U druhého zadání dostaneš přesně to, co je napsané — a proto je tak důležité, aby tam bylo všechno.
Co delegovat a co si nechat
Deleguj bez výčitek:
- Drobné bugy s jasnou reprodukcí a očekávaným chováním
- Testy — zvýšení pokrytí, doplnění testů k existující logice. Batch-assign několika issue najednou a nech agenta pracovat paralelně
- Dokumentaci — aktualizace README, generování JSDoc/docblocks
- Mechanické refaktory — přejmenování, extract metody, migrace utility funkcí
- Aktualizace závislostí a opravy drobných deprecations
Nechej si:
- Architekturu — rozhodnutí o struktuře systému, výběru patterns, hranicích modulů. Agent implementuje, nerozhoduje o směru.
- Bezpečnostní změny — auth, oprávnění, práce s tajnými klíči. Tady chyba stojí víc než ušetřený čas.
- Databázové migrace a cokoli nevratného. Špatná migrace je důvod k nočnímu budíčku.
- Vše, co má nejasnou definici "hotovo". Pokud nedokážeš napsat acceptance criteria, úkol není ready pro agenta ani pro člověka.
Přesná hranice se posouvá — to, co loni vyžadovalo dohled, dnes agent zvládne samo. Ale vzorec zůstává: čím je rozhodnutí nevratnější, tím víc musí zůstat u tebe.
Kontrolní vrstva: review není formalita
Nejdůležitější pravidlo celého workflow: review musí být skutečná kontrola, ne podpis. GitHub to řeší systémově — autor issue nemůže být schvalovatelem vlastního pull requestu, takže se do procesu automaticky dostane druhá osoba. U sólových projektů si aspoň nastav proces, kdy merge děláš "s čistou hlavou", ne hned po zadání.
Prakticky:
- CI je tvůj kolega-reviewer. Nastav kvalitní pipeline — testy, lint, type check, build. Agent iteruje, dokud CI neprojde, takže každá brzda, kterou do CI dáš, je brzda, kterou agent respektuje bez dohledu.
- Čti diff celý. U agenta platí dvojnásob: umí napsat kód, který vypadá správně, ale řeší jen to, co doslova četl v issue.
- Iteruj přes komentáře v PR. "Změn to tady na service class, ať to zůstane testovatelné" — agent vezme feedback a dotáhne opravu. Není potřeba psát nové issue.
- Měj auditní stopu. Každá změna má issue, PR, review a session log. Když se něco rozbije, dohledáš, proč a kdo (co) to schválil.
Co se tím změní v tvém dni
Pointa není "ušetřím si psaní kódu". Pointa je, že se tvůj čas přesouvá tam, kde má vyšší hodnotu: specifikace a review místo mechanické implementace. Píšeš méně kódu, ale víc přesných úkolů. Čteš víc cizího kódu — jen toho "cizího" je čím dál víc od agentů.
Paralelní delegování je tichý superpower: zatímco jeden agent doplňuje testy, druhý opravuje bug z minulého sprintu a ty mezitím řešíš architekturu nové feature. Jeden člověk najednou vede víc workstreamů — a limitem není tvá rychlost psaní, ale tvoje kapacita na review.
S čím začít tento týden
- Vyber si jeden drobný, dobře popsaný ticket z backlogu — ideálně testy nebo dokumentaci.
- Přepiš ho do pořádného issue: kontext, acceptance criteria, omezení, požadovaný výstup.
- Přiřaď agentovi a nezírej na to. Nech ho pracovat asynchronně.
- Proveď pořádný review, schval a mergni.
- Zopakuj a pozoruj, kde hranice delegování tvého projektu skutečně je.
Začni malé, měř si, kolik času ti to vrátilo, a škáluj. A pokud chceš agenta nejdřív naučit pravidlům tvého projektu — soubor [AGENTS.md](/content/agents-md-jak-nastavit-ai-coding-agenta) s konvencemi, příkazy pro build a testy a zákazy — mám o tom samostatný návod. Delegování totiž funguje nejlíp, když agent ví, v jakém domě bydlí.
Chceš delegovat víc a líp? Mrkni na Claude Code návody a další praktické workflow s AI pro tvou práci.
