Když 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?".

Tí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í.

Jde 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.

Změna zvyku

S 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.

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

• Dal jsem mu dostatečně malý prostor?
• víte, jak zkontrolovat výsledek?
• Pracuji v izolovaném prostředí?
• Je závěrečná recenze stále humánní a pečlivá?

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

Zní 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.

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

Nejnebezpeč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.

Už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.

Pak 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.

Tento 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.

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

První 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é.

Druhý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.

Tř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.

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

Rozhodnutí 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.

Lidskou 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.

Nakonec 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.

Recenze není volitelná

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

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

1. Řeší patch pouze požadovaný úkol?
2. Dotkl se souborů, které s tím neměly nic společného?
3. Zahrnují testy neotřelé chování nebo jen šťastnou náhodu?
4. Řídí se kód místními vzory?
5. Jsou chyby řešeny jako ve zbytku projektu?

Když 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.

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

Zábradlí stojí za námahu

Pokud 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.

Použ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.

Omezit 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í.

Omezte 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í.

Sledujte 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í.

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

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

Vytvoř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í.

Po 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í.

Je 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.

Nejlidštější část

Legrač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ě.

Takž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ý.

Agenti 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í.

Užitečné zdroje

• Kodex pro (téměř) všechno – OpenAI
• Bezpečné provozování Codexu v OpenAI
• Představujeme Codex - OpenAI
• Co je nového s kódovacím agentem GitHub Copilot