Workflow Codex a multi-agent: pracujte s agenty bez ztráty kontroly

spinny:~/writing $ less codex-multi-agent-workflows.md

1 
2Když za vás kódovací agent poprvé skutečně opraví chybu, reakce je téměř vždy stejná: směs nadšení a podezření. Pěkné, jistě. Ale pak se podíváte na rozdíl a zeptáte se sami sebe: "Dobře, ale čeho přesně se dotkl? Mohu mu věřit? Udělá to zítra znovu stejným způsobem?".
3 
4Tím myslím začíná ta zajímavá část. Ne, když agent napíše funkci, ale až bude dostatečně schopný, aby mohl převzít celou práci: přečíst repozitář, vytvořit opravu, spustit testy, otevřít PR, vrátit se po komentáři k recenzi. Codex se ubírá přesně tímto směrem: práce na pozadí, samostatné pracovní stromy, integrovaný prohlížeč, automatizace, pluginy, paměť a explicitnější ovládací prvky oprávnění.
5 
6Jde o to nepředstavovat si budoucnost, kde už nikdo nečte kód. Byla by to strašná budoucnost a navíc dost naivní. Jde o to vymyslet, jak pracovat s agenty, kteří toho dokážou hodně, aniž by je nechali dělat všechno.
7 
8## Změna zvyku
9 
10S tradičním automatickým doplňováním jste byli vždy za volantem. Umělá inteligence navrhla linii, rozhodli jste se. S agentem se ale vztah změní: dáte mu cíl a on sám projde více kroky.
11 
12Je to mocné, ale posouvá to problém. Otázkou už není jen „umí model programovat?“. Otázka zní:
13 
14- Dal jsem mu dostatečně malý prostor?
15- víte, jak zkontrolovat výsledek?
16- Pracuji v izolovaném prostředí?
17- Je závěrečná recenze stále humánní a pečlivá?
18 
19Zdravý pracovní postup vypadá spíš takto než kouzelná hůlka:
20 
21```mermaid
22flowchart LR
23    Idea[Lidský úkol] --> Scope[Malý, ověřitelný účel]
24    Scope --> Agent[Agent v pracovním stromu izolovaný]
25    Agent --> Checks[Test, lint, build, prohlížeč]
26    Checks --> Review[Lidská recenze]
27    Review --> Merge[Sloučit nebo nová iterace]
28    Review --> Iterate[Přesné komentáře k rozdílu]
29    Iterate --> Agent
30```
31 
32Zní to méně romanticky než „agent vše staví“, ale funguje to mnohem lépe. A také to, jak fungují týmy, které jsou dobré s lidmi: jasné úkoly, rychlá zpětná vazba, explicitní odpovědnost.
33 
34## Dobrá výzva je skoro dobrý lístek
35 
36Nejnebezpečnější výzva je vágní, ale sebevědomá: „opravte stránku s fakturami“, „zlepšete architekturu“, „vyčistěte modul ověřování“. To jsou požadavky, které znějí produktivně a vytvářejí obrovské rozdíly. Ale pak zjistíte, že děláte archeologii.
37 
38Užitečná výzva je nudnější. Například: implementujte export CSV pro stránku faktur s vědomím, že tabulka je v `app/(dashboard)/invoices/page.tsx`, dotazy jsou v `src/server/invoices.ts` a v `app/(dashboard)/reports` již existuje podobný vzor.
39 
40Pak přidejte jasná omezení: neměňte schéma databáze, nepřidávejte závislosti, pokud stačí malý nástroj, ponechte stávající styl uživatelského rozhraní. A zavřete s ověřením: `npm test -- invoices` a `npm run build`.
41 
42Tento typ briefu nemá „lépe vysvětlit AI“. Slouží především k tomu, aby vám bylo jasnější, co delegujete. Pokud to nemůžete napsat konkrétně, možná úkol ještě není připraven pro agenta.
43 
44## Tři práce, které ochotně deleguji
45 
46První je opakující se, ale ověřitelná práce: přidávání testů, migrace volání na nové interní API, aktualizace importů, nahrazování zastaralých komponent, oprava chyb TypeScriptu. Zde může agent ušetřit hodiny a riziko je kontrolovatelné.
47 
48Druhým je průzkumná práce: „najít, kde je tento součet vypočítán“, „vysvětlete mi, proč je tento test křehký“, „zopakujte chybu a řekněte mi, které soubory se zdají být ovlivněny“. I když neprodukuje záplatu hned, může dělat užitečný průzkum.
49 
50Třetí je opakující se údržba: malé aktualizace závislostí, vyčištění starých příznaků funkcí, shrnutí zablokovaných PR, kontrola zapomenutých TODO. Není to okouzlující, ale je to přesně ten druh práce, který má tendenci se hromadit.
51 
52## Tři práce, které udržuji jako lidské
53 
54Rozhodnutí o produktech zůstávají na lidech. Pokud změna změní způsob, jakým uživatel platí, maže data, vidí ceny nebo rozumí oprávnění, chci odpovědnou osobu.
55 
56Lidskou pozornost si zaslouží i hranice zabezpečení: auth, role, tokeny, protokolování citlivých dat, migrace databází. Agent může pomoci s implementací, ale nemusí být jediným, kdo rozhoduje.
57 
58Nakonec vše, co vyžaduje architektonický vkus, ponechávám lidské. Agent může navrhnout refaktor, ale pochopit, zda je abstrakce skutečně nutná, nebo zda jen leštíme neexistující problém, zůstává úkolem.
59 
60## Recenze není volitelná
61 
62Když je agent dobrý, pokušením je důvěřovat zelené CI. Je to pochopitelné. To je také, když problémy začínají.
63 
64Vždy se dívám alespoň na pět věcí:
65 
661. Řeší patch pouze požadovaný úkol?
672. Dotkl se souborů, které s tím neměly nic společného?
683. Zahrnují testy neotřelé chování nebo jen šťastnou náhodu?
694. Řídí se kód místními vzory?
705. Jsou chyby řešeny jako ve zbytku projektu?
71 
72Když je něco špatně, zpětná vazba musí být konkrétní. „Opravit“ je líné. Lepší: tento nástroj duplikuje `parseMoney` do `src/lib/money.ts`; znovu použijte tuto funkci, přidejte test pro případ EUR a neměňte veřejné API fakturačního modulu.
73 
74Agenti mnohem lépe reagují na malé, ověřitelné komentáře. Kupodivu také lidé.
75 
76## Zábradlí stojí za námahu
77 
78Pokud agent umí číst soubory, psát kód a spouštět příkazy, mělo by se s ním zacházet jako s výkonným procesem. Není potřeba paranoia, potřebujete hygienu.
79 
80Použijte samostatné pracovní stromy nebo větve. Můžete tedy porovnat rozdíl, zahodit neúspěšné experimenty a nemíchat práci agenta s tím, co jste dělali.
81 
82Omezit oprávnění. Příkazy jako `rg`, `git diff`, `npm test` a `npm run build` mohou být zcela zdarma. Nasazení, migrace databází, přístup k tajným informacím a destruktivní příkazy musí zůstat explicitní.
83 
84Omezte přístup k síti, když jej nepotřebujete. Pro mnoho úkolů stačí oficiální dokumentace, registr balíčků a specifické interní služby. Menší plocha, méně překvapení.
85 
86Sledujte akce. Když záplata dorazí ke kontrole, měli byste být schopni rekonstruovat výzvy, provedené příkazy, úspěšné testy a upravené soubory. Ne vytvořit byrokracii, ale umět pochopit, co se stalo, když se něco pokazí.
87 
88## Snadný způsob, jak začít jako tým
89 
90Pokud bych měl zavést agenty do malého týmu, začal bych bez velkých revolucí.
91 
92Vytvořil bych štítek `agent-ready` pro problémy s jasným rozsahem. Přidal bych šablonu s kontextem, omezeními a ověřovacími příkazy. Poprosil bych o malé PR, ideálně pod pár stovek řádků. Pro viditelné změny bych vyžadoval testování nebo screenshoty. A především bych ponechal osobu odpovědnou za sloučení.
93 
94Po dvou týdnech jsem se podíval na data: které úkoly byly skutečně zrychleny, které recenze byly těžké, které výzvy byly matoucí, které části kódové základny jsou příliš křehké na delegování.
95 
96Je to méně spektakulární přístup než „ode dnešek budeme dělat všechno s agenty“, ale je to ten, který vám umožní dostat se do třetího týdne bez výčitek.
97 
98## Nejlidštější část
99 
100Legrační je, že čím jsou agenti autonomnější, tím důležitější jsou opět klasické dovednosti: napsat dobrý tiket, dělat malé škrty, vytvářet testy, číst rozdíly, komunikovat kompromisy. Agent zrychluje ty, kteří už umí dobře pracovat. Také umocňuje chaos těch, kteří delegují špatně.
101 
102Takže ne, nevidím multi-agentní pracovní postupy jako zkratku, jak přestat dělat inženýrství. Vnímám je jako způsob, jak přesunout více energie do částí, na kterých záleží: rozhodování, co postavit, zajistit, aby to fungovalo, udržet systém srozumitelný.
103 
104Agenti mohou být skvělými asynchronními kolegy. Ale asynchronní kolega, aby byl užitečný, potřebuje kontext, hranice a přehled. Stejně jako všichni ostatní.
105 
106## Užitečné zdroje
107 
108- [Kodex pro (téměř) všechno – OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Bezpečné provozování Codexu v OpenAI](https://openai.com/index/running-codex-safely/)
110- [Představujeme Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Co je nového s kódovacím agentem GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112

:Workflow Codex a multi-agent: pracujte s agenty bez ztráty kontrolylines 1-112 (END) — press q to close

2Když za vás kódovací agent poprvé skutečně opraví chybu, reakce je téměř vždy stejná: směs nadšení a podezření. Pěkné, jistě. Ale pak se podíváte na rozdíl a zeptáte se sami sebe: "Dobře, ale čeho přesně se dotkl? Mohu mu věřit? Udělá to zítra znovu stejným způsobem?".

4Tím myslím začíná ta zajímavá část. Ne, když agent napíše funkci, ale až bude dostatečně schopný, aby mohl převzít celou práci: přečíst repozitář, vytvořit opravu, spustit testy, otevřít PR, vrátit se po komentáři k recenzi. Codex se ubírá přesně tímto směrem: práce na pozadí, samostatné pracovní stromy, integrovaný prohlížeč, automatizace, pluginy, paměť a explicitnější ovládací prvky oprávnění.

6Jde o to nepředstavovat si budoucnost, kde už nikdo nečte kód. Byla by to strašná budoucnost a navíc dost naivní. Jde o to vymyslet, jak pracovat s agenty, kteří toho dokážou hodně, aniž by je nechali dělat všechno.

8## Změna zvyku

10S tradičním automatickým doplňováním jste byli vždy za volantem. Umělá inteligence navrhla linii, rozhodli jste se. S agentem se ale vztah změní: dáte mu cíl a on sám projde více kroky.

12Je to mocné, ale posouvá to problém. Otázkou už není jen „umí model programovat?“. Otázka zní:

14- Dal jsem mu dostatečně malý prostor?

15- víte, jak zkontrolovat výsledek?

16- Pracuji v izolovaném prostředí?

17- Je závěrečná recenze stále humánní a pečlivá?

19Zdravý pracovní postup vypadá spíš takto než kouzelná hůlka:

21```mermaid

22flowchart LR

23 Idea[Lidský úkol] --> Scope[Malý, ověřitelný účel]

24 Scope --> Agent[Agent v pracovním stromu izolovaný]

25 Agent --> Checks[Test, lint, build, prohlížeč]

26 Checks --> Review[Lidská recenze]

27 Review --> Merge[Sloučit nebo nová iterace]

28 Review --> Iterate[Přesné komentáře k rozdílu]

29 Iterate --> Agent

30```

32Zní to méně romanticky než „agent vše staví“, ale funguje to mnohem lépe. A také to, jak fungují týmy, které jsou dobré s lidmi: jasné úkoly, rychlá zpětná vazba, explicitní odpovědnost.

34## Dobrá výzva je skoro dobrý lístek

36Nejnebezpečnější výzva je vágní, ale sebevědomá: „opravte stránku s fakturami“, „zlepšete architekturu“, „vyčistěte modul ověřování“. To jsou požadavky, které znějí produktivně a vytvářejí obrovské rozdíly. Ale pak zjistíte, že děláte archeologii.

38Užitečná výzva je nudnější. Například: implementujte export CSV pro stránku faktur s vědomím, že tabulka je v `app/(dashboard)/invoices/page.tsx`, dotazy jsou v `src/server/invoices.ts` a v `app/(dashboard)/reports` již existuje podobný vzor.

40Pak přidejte jasná omezení: neměňte schéma databáze, nepřidávejte závislosti, pokud stačí malý nástroj, ponechte stávající styl uživatelského rozhraní. A zavřete s ověřením: `npm test -- invoices` a `npm run build`.

42Tento typ briefu nemá „lépe vysvětlit AI“. Slouží především k tomu, aby vám bylo jasnější, co delegujete. Pokud to nemůžete napsat konkrétně, možná úkol ještě není připraven pro agenta.

44## Tři práce, které ochotně deleguji

46První je opakující se, ale ověřitelná práce: přidávání testů, migrace volání na nové interní API, aktualizace importů, nahrazování zastaralých komponent, oprava chyb TypeScriptu. Zde může agent ušetřit hodiny a riziko je kontrolovatelné.

48Druhým je průzkumná práce: „najít, kde je tento součet vypočítán“, „vysvětlete mi, proč je tento test křehký“, „zopakujte chybu a řekněte mi, které soubory se zdají být ovlivněny“. I když neprodukuje záplatu hned, může dělat užitečný průzkum.

50Třetí je opakující se údržba: malé aktualizace závislostí, vyčištění starých příznaků funkcí, shrnutí zablokovaných PR, kontrola zapomenutých TODO. Není to okouzlující, ale je to přesně ten druh práce, který má tendenci se hromadit.

52## Tři práce, které udržuji jako lidské

54Rozhodnutí o produktech zůstávají na lidech. Pokud změna změní způsob, jakým uživatel platí, maže data, vidí ceny nebo rozumí oprávnění, chci odpovědnou osobu.

56Lidskou pozornost si zaslouží i hranice zabezpečení: auth, role, tokeny, protokolování citlivých dat, migrace databází. Agent může pomoci s implementací, ale nemusí být jediným, kdo rozhoduje.

58Nakonec vše, co vyžaduje architektonický vkus, ponechávám lidské. Agent může navrhnout refaktor, ale pochopit, zda je abstrakce skutečně nutná, nebo zda jen leštíme neexistující problém, zůstává úkolem.

60## Recenze není volitelná

62Když je agent dobrý, pokušením je důvěřovat zelené CI. Je to pochopitelné. To je také, když problémy začínají.

64Vždy se dívám alespoň na pět věcí:

661. Řeší patch pouze požadovaný úkol?

672. Dotkl se souborů, které s tím neměly nic společného?

683. Zahrnují testy neotřelé chování nebo jen šťastnou náhodu?

694. Řídí se kód místními vzory?

705. Jsou chyby řešeny jako ve zbytku projektu?

72Když je něco špatně, zpětná vazba musí být konkrétní. „Opravit“ je líné. Lepší: tento nástroj duplikuje `parseMoney` do `src/lib/money.ts`; znovu použijte tuto funkci, přidejte test pro případ EUR a neměňte veřejné API fakturačního modulu.

74Agenti mnohem lépe reagují na malé, ověřitelné komentáře. Kupodivu také lidé.

76## Zábradlí stojí za námahu

78Pokud agent umí číst soubory, psát kód a spouštět příkazy, mělo by se s ním zacházet jako s výkonným procesem. Není potřeba paranoia, potřebujete hygienu.

80Použijte samostatné pracovní stromy nebo větve. Můžete tedy porovnat rozdíl, zahodit neúspěšné experimenty a nemíchat práci agenta s tím, co jste dělali.

82Omezit oprávnění. Příkazy jako `rg`, `git diff`, `npm test` a `npm run build` mohou být zcela zdarma. Nasazení, migrace databází, přístup k tajným informacím a destruktivní příkazy musí zůstat explicitní.

84Omezte přístup k síti, když jej nepotřebujete. Pro mnoho úkolů stačí oficiální dokumentace, registr balíčků a specifické interní služby. Menší plocha, méně překvapení.

86Sledujte akce. Když záplata dorazí ke kontrole, měli byste být schopni rekonstruovat výzvy, provedené příkazy, úspěšné testy a upravené soubory. Ne vytvořit byrokracii, ale umět pochopit, co se stalo, když se něco pokazí.

88## Snadný způsob, jak začít jako tým

90Pokud bych měl zavést agenty do malého týmu, začal bych bez velkých revolucí.

92Vytvořil bych štítek `agent-ready` pro problémy s jasným rozsahem. Přidal bych šablonu s kontextem, omezeními a ověřovacími příkazy. Poprosil bych o malé PR, ideálně pod pár stovek řádků. Pro viditelné změny bych vyžadoval testování nebo screenshoty. A především bych ponechal osobu odpovědnou za sloučení.

94Po dvou týdnech jsem se podíval na data: které úkoly byly skutečně zrychleny, které recenze byly těžké, které výzvy byly matoucí, které části kódové základny jsou příliš křehké na delegování.

96Je to méně spektakulární přístup než „ode dnešek budeme dělat všechno s agenty“, ale je to ten, který vám umožní dostat se do třetího týdne bez výčitek.

98## Nejlidštější část

100Legrační je, že čím jsou agenti autonomnější, tím důležitější jsou opět klasické dovednosti: napsat dobrý tiket, dělat malé škrty, vytvářet testy, číst rozdíly, komunikovat kompromisy. Agent zrychluje ty, kteří už umí dobře pracovat. Také umocňuje chaos těch, kteří delegují špatně.

101

102Takže ne, nevidím multi-agentní pracovní postupy jako zkratku, jak přestat dělat inženýrství. Vnímám je jako způsob, jak přesunout více energie do částí, na kterých záleží: rozhodování, co postavit, zajistit, aby to fungovalo, udržet systém srozumitelný.

103

104Agenti mohou být skvělými asynchronními kolegy. Ale asynchronní kolega, aby byl užitečný, potřebuje kontext, hranice a přehled. Stejně jako všichni ostatní.

105

106## Užitečné zdroje

107

108- [Kodex pro (téměř) všechno – OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Bezpečné provozování Codexu v OpenAI](https://openai.com/index/running-codex-safely/)

110- [Představujeme Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Co je nového s kódovacím agentem GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112