Kódovací agenti: kdy rozšířit zadání a kdy zjednodušit práci

TL;DR

• Rozšiřovat práci kódovacích agentů má smysl tam, kde dokážeš ověřit výsledek a zvládnout jeho kontrolu. Samotný objem vytvořeného kódu přínos neukáže.
• Program AIE CODE staví vedle sebe tři témata: růst bez nekvalitních výstupů, modely System One a odvážnější softwarové projekty. Jde o směr vybraný pořadateli, nikoli o doložený recept na lepší vývoj.
• U příští změny rozliš, kde potřebuješ otevřené hledání řešení a kde stačí úzké rozhodnutí nebo pevný postup. Sleduj i čas na kontrolu a opravy.

Agent dokončí úpravu aplikace a ty dostaneš tolik změn, že jejich kontrola zabere zbytek dne. Při dalším zadání proto potřebuješ rozhodnout, zda mu svěřit větší celek, nebo práci rozdělit jinak. Pro malý vývojový tým je to podstatnější otázka než počet současně spuštěných agentů.

Právě toto napětí vystihují tři témata připravované konference AIE CODE, která Latent Space představil 30. října 2026: rozšiřování práce bez nekvalitních výstupů, modely System One a rostoucí ambice softwarových projektů. Pořadatelský text zároveň propaguje konferenci. Jeho výběr témat proto čteme jako pohled na směřování oboru, ne jako měření toho, co už funguje v běžném týmu.

Více kódu znamená také více práce k převzetí

První téma pořadatelé nazývají „Scaling without Slop“. Míří tím na problém, jak zvyšovat rozsah práce a přitom neprodukovat nekvalitní výstupy. Autor uvádí, že se mu tento přístup převážně osvědčil, ale v dodaném textu nepopisuje postup ani výsledky, podle kterých by šlo jeho úspěch posoudit.

Pro vlastní vývoj z toho můžeme odvodit konkrétní otázku: kolik práce po agentovi zbývá, než můžeš změnu přijmout?

Představ si například doplnění exportu objednávek. Agent může rychle připravit kód, ale někdo ještě musí ověřit správná pole, přístupová práva a chování při prázdném výsledku. Pokud měříš jen čas do odevzdání návrhu, tato část práce ti z hodnocení vypadne.

Naše doporučení je počítat společně čas agenta, lidskou kontrolu a opravy. Tak poznáš, zda širší zadání skutečně pomohlo, nebo jen přesunulo práci k člověku, který změnu přebírá.

System One otevírá otázku, kolik rozhodování úloha potřebuje

Druhé téma se věnuje modelům System One, které pořadatelé představují jako jiný směr než stále větší a dražší skupiny kódovacích agentů. Tým TypeSafe má ukázat jejich použití u svých uživatelů.

Text zároveň výslovně rozlišuje mezi „Decision Models“ a „System One models“. Dostatečné technické vysvětlení tohoto rozdílu ale neobsahuje. Nelze z něj proto dělat závěr, že jde o zaměnitelné názvy nebo že takový model automaticky nahradí běžného kódovacího agenta.

Užitečná návrhová otázka přesto zůstává: musí agent při každém kroku hledat nové řešení?

Při opravě neznámé chyby může potřebovat prozkoumat kód a zkoušet různé příčiny. Spuštění známé sady testů už může zajistit pevný postup. Volba mezi několika předem určenými akcemi zase představuje užší rozhodovací úlohu. Toto rozdělení je naše doporučení pro návrh agentské práce, nikoli popis konkrétní implementace System One.

Ambiciózní přepis potřebuje konkrétní důvod

Třetí téma konference tvoří odvážnější softwarové projekty. Pořadatelé zmiňují přepisy prohlížečů, grafických aplikací i firemního softwaru. Jarred Sumner má vyjít z přepisu Bun do Rustu a představit Bun AOT a další kompilátorové funkce.

Jde o avizovaný obsah vystoupení. Samotná pozvánka nedokládá, jak velkou část práce provedli agenti ani jaké úspory přinesli.

Pro menší tým je důležitý důvod přepisu. Pokud chceš nahradit interní aplikaci, pojmenuj nejdřív omezení, které tím odstraníš: obtížnou údržbu, chybějící funkci nebo konkrétní provozní problém. Pak vyber jednu ucelenou část, na které lze ověřit chování nové verze. Schopnost vygenerovat rozsáhlou náhradu ještě neodpovídá na otázku, zda se vyplatí ji převzít a dál udržovat.

Příští zadání posuzuj podle převzaté změny

Tři konferenční témata nabízejí užitečný rámec: hlídat kvalitu při růstu, přizpůsobit způsob rozhodování úloze a rozšiřovat ambice tam, kde mají konkrétní přínos. Nedokládají jeden vítězný způsob vývoje.

U příští změny si předem napiš, podle čeho ji přijmeš. Po dokončení zaznamenej, kolik zabrala kontrola a co bylo nutné opravit. Teprve podle toho rozšiř další zadání. Pokud většinu času spotřebuješ na rozplétání změn, začni zpřesněním rozsahu a rozdělením práce.

Zdroj

Latent Space: Building AIE CODE: The top Coding Agent Conference, 30. října 2026