Agentic Engineering

Ještě relativně nedávno jsem většinu pracovního dne trávil psaním kódu. Dnes ho za mě píšou agenti. A já místo toho řeším architekturu, správně zadanou práci a prostředí, ve kterém jednoduše poznám, že výsledek opravdu funguje. Zároveň se v něm potřebují dobře orientovat agenti i lidé.

Neznamená to, že nepotřebuju rozumět kódu. Spíš naopak. Pořád se setkávám s případy, kdy agent navrhne řešení, které se do dané situace nehodí. Musím to poznat a vývoj usměrnit.

AI totiž dokáže neuvěřitelně rychle vyrobit spoustu kódu. Dobrého, ale i toho špatného. A když je špatné zadání, většinou ho bez odporu splní a ještě odsouhlasí, jak je to prima nápad.

Samotné generování kódu je tedy čím dál méně zajímavé. Mnohem důležitější je všechno kolem něj.

Nechci být chůva agentů

Mým cílem není mít v terminálu dvacet agentů, kterým každé dvě minuty říkám, co mají dělat. To sice budu produkovat víc kódu, ale pořád budu omezený svou pozorností a potřebou spánku. :-)

Chci zadat milestone s rozpracovanými úkoly a nechat agenty, ať je vyřeší, otestují výsledek a rovnou zapracují nutné změny. Pak pustit nezávislé review, samozřejmě dalším modelem, a na konci přijít k dobře otestované práci, kterou můžu bez větších obtíží schválit.

Zní to jednoduše, ale je za tím spousta práce. Nejdřív si musím ujasnit, jak poznám hotový výsledek, jaká má omezení a na čem jednotlivé úkoly závisejí. Nejasnost v zadání nechci zakrýt tím, že agent prostě něco napíše.

Agent může zadání špatně pochopit nebo zvlášť během review ujet na jinou kolej. Může se s jiným modelem zacyklit na nepodstatné chybě. A když nemá možnost všechno dostatečně otestovat, klidně si vymyslí, že výsledek přesně odpovídá zadání. Z jeho pohledu to tak je.

Proto se věnuju nejen agentům, ale hlavně prostředí, ve kterém pracují. Když se začnou točit v kruhu, potřebuju umět běh zastavit, zmenšit úkol nebo se vrátit k analýze. Nekonečné opakování pokusů není strategie; čas, cenu i počet pokusů potřebuju držet pod kontrolou.

Jeden agent, jeden pracovní prostor

Git worktrees jsou skvělá věc, kterou by si měl osvojit každý agentický vývojář. Jedna větev, jeden pracovní adresář. Agenti si pak nelezou do zelí. Přípravu a přepínání těchto adresářů mi zjednodušuje git-wt.

Souběžně můžu nechat běžet třeba průzkum rozhraní a návrh testovacích scénářů. Dva agenti upravující stejné třídy už ale potřebují koordinaci a společný výsledek musím ověřit znovu.

Worktree přitom není sandbox. Odděluje rozpracované změny, ne oprávnění procesů. Aby agent zvládl celý úkol, potřebuje dost volnosti. Harness mu ji ale často nedá a pořád ho zastavuje. Pustit ho úplně bez limitů je zase bezpečnostní riziko.

Řeším proto dva směry sandboxingu: dedikovaný stroj s omezenými přístupy ke kritické infrastruktuře a AgentBox, můj nástroj pro izolaci agentů pomocí konfigurovatelných kontejnerů. Vzniká z potřeby pouštět agenty i s oprávněními typu --dangerously-skip-permissions, aby je jejich harness nemusel neustále zastavovat. Mantinely pak musí zajistit okolní prostředí.

Chci dát agentovi volnost, ale ne přístup k věcem, které pro úkol nepotřebuje. Proto řeším, co v prostředí uvidí a kam se dostane. Přihlašovací údaje nechci v jeho pracovním prostoru ani v logu a víc volnosti pro mě automaticky neznamená přístup do produkce nebo možnost publikovat.

Vývoj AgentBoxu je zatím hodně o pokusech, omylech a reálném testování. Serverový běh je pořád preview, ne hotový orchestrátor libovolných modelů.

Nepotřebuju vždy nejdražší model

Návrh architektury, běžné kódování a kontrola pull requestu nepotřebují nutně stejný a nejdražší dostupný model. Spíš naopak.

Zajímá mě orchestrace, ve které vybírám modely podle schopností, ceny a velikosti kontextu. Architekturu řeším s opravdu chytrým modelem, ale na samotné kódování většinou stačí daleko levnější modely. Dražší model mi sám o sobě správnost nezaručí.

Tohle se snažím zabalit do Coding Worker MCP. Přes něj můžu nechat dražší model zadávat průzkum kódu, implementaci nebo review levnějšímu workeru. Zadávání a posuzování práce tak můžu oddělit od jejího provedení.

Výběr modelu mi ale neřeší, kam smí worker sáhnout. To pořád musím ohlídat prostředím, ve kterém běží.

Dokončení úlohy není totéž co její přijetí. Potřebuju dostat zpátky dohledatelné podklady a rozlišit dokončení běhu od toho, že změna splnila zadání. Výběr modelu je jedna část, předání kontextu a kontrola výsledku další.

A když zavřu notebook?

Nechci být vázaný na otevřený notebook, který byl ještě donedávna mým hlavním pracovním strojem. Chci na něm dál interaktivně probírat detaily implementace, napsat RFC nebo rozpadnout milestone na úkoly. Pak už ale musí AI pracovat sama. Za mě a ideálně nonstop.

Rutinní práci proto deleguju na samostatný stroj a snažím se na něj přesunout co nejvíc úkolů. Ještě to bohužel není úplná autonomní dark factory, ale myslím, že se tím směrem velmi rychle posouvám. Jednotlivé části fungují a zkouším další, které je doplní a propojí.

Experimentuju s Hermesem, Kandevem, Codexem, Claude Code s Remote Control a dalšími nástroji pro správu milestonů a automatické přidělování úkolů agentům.

Nechci ale jen na dálku ovládat terminál. Potřebuju mít přehled o práci, umět ji zastavit a po výpadku zjistit, co z ní zůstalo. Samotný přesun na server mi spolehlivý autonomní provoz nezajistí. Tohle propojení ještě dávám dohromady.

Reálná zkušenost: Keboola

Přibližně půl roku jsme pilovali pravidla pro agenty ve velkém repozitáři, kde podstatná část systému vznikla v Zend Frameworku 1 a postupně se přepisuje do Symfony.

Dostali jsme se do situace, kdy může přijít i vývojář, který projekt nezná, zadat agentovi úkol a agent dokáže upravit správný kód nebo přidat nový do odpovídajícího frameworku. Tady je dobře vidět, proč mi nestačí jen model, který umí psát kód. Potřebuje se v projektu vyznat.

Máme řadu skillů včetně automatizovaného zpracování úkolů a code review. Review používáme jak pro vlastní kontrolu agenta, tak pro nezávislou kontrolu dalšími agenty. Součástí prostředí jsou tisíce E2E testů a statická analýza pomocí PHPStan a kontroly stylu kódu pomocí PHPCS a ECS.

S kolegou jsme také vytvořili CLI tooling, který vývojářům i agentům usnadňuje složitější operace nad kódem a spouštění testů, včetně těch nad BigQuery a Snowflake.

Kód musí nakonec hlavně fungovat

I kdybych vynechal všechno předchozí, nejdůležitější je, jestli se na výsledný kód můžu spolehnout já a moji klienti. Zajímá mě funkční změna, proč se který kus změnil a jaké testy proběhly.

V agentickém vývoji pro mě unit testy ztrácejí na významu. Agent je obvykle snadno napíše tak, aby pro jeho vlastní implementaci procházely, a samotný zelený výsledek pak ještě neznamená správné řešení. Jejich psaní navíc stojí čas i kontext a přidává další kód k údržbě. Větší hodnotu vidím v integračních a E2E testech, které ověřují skutečné chování systému a spolupráci jeho částí. Unit testy tím nezakazuju; u kryptografie, bezpečnostně citlivého kódu, algoritmů nebo složité izolované logiky pořád dávají smysl. Potřebuju ale ověřovat implementaci proti zadání, ne jen předpoklady, které si agent sám vytvořil. K tomu patří i statická analýza a CI nad stejným commitem, který se bude schvalovat.

Nezávislé review potřebuje diff, původní zadání a relevantní kontext. Oddělená session a jiný model přidají další pohled, ale pořád můžou mít stejné slepé místo. Nález potřebuju reprodukovat, opravu ověřit a nechat znovu posoudit.

Finální schvalování zatím nechávám na člověku. Agenti by mu ale měli všechno naservírovat jako na zlatém podnose: změny, výsledky kontrol i zbývající nejistoty a důkazy, proč schválit. Agentická automatizace má práci zjednodušovat, ne schovávat problémy za zelená tlačítka.

Tohle všechno je proces, který průběžně stavím, upravuju a vylepšuju. Diagram pod textem ukazuje, jak do sebe jednotlivé kroky zapadají, ne že už mám každý z nich všude plně automatizovaný. Některé nástroje zveřejňuju, jiné si nechávám pro sebe a občas o tom píšu na blogu — třeba o převodu webu do WordPressu s pomocí agenta nebo přesunu CI/CD do GitHub Actions.

A samozřejmě se pořád učím, co můžu s agenty dělat. Každý měsíc mě překvapují tím, co nového mi umožňují dělat líp a rychleji.