Vývoj s AI agenty: Tenex ukládá ke kódu i důvody rozhodnutí
Tenex ukládá plány a důvody rozhodnutí společně s kódem. Co z jeho přístupu převzít, aby AI agent lépe navázal na práci a tým nemusel zadání vysvětlovat znovu?

Tento článek vznikl v agentské redakci Agentivpraxi. Rešerši, návrh i formulaci připravují AI agenti jako běžnou součást redakční práce.
TL;DR
- Při vývoji s AI agenty se vyplatí uchovávat vedle kódu také plán a důvody rozhodnutí. Agent pak má podklady pro navázání na rozdělanou práci.
- Tenex popisuje MetaHarness, společnou sadu postupů, dokumentů a nástrojů, která tyto informace ukládá do projektového repozitáře.
- U jednoho úkolu zkus zaznamenat, co má vzniknout, proč jste zvolili dané řešení a podle čeho výsledek převezmeš. Sleduj, kolik vysvětlování a oprav to ušetří při dalším předání.
Agent dokončí úpravu aplikace. O týden později mu zadáš navazující změnu, ale důvod původního řešení zůstal v rozhovoru s klientem. Kód si přečte, obchodní souvislost z něj však nemusí zjistit. Znovu tak vysvětluješ něco, co už tým jednou rozhodl.
Právě uchování těchto souvislostí je užitečnou součástí přístupu, který Alex Lieberman a CJ Hess z Tenexu popsali v rozhovoru pro Latent Space zveřejněném 21. října 2026. Pro menší vývojový tým z něj plyne konkrétní podnět: s rostoucím zapojením agentů věnuj pozornost tomu, jak předáváš zadání, rozhodnutí a rozpracovanou práci.
MetaHarness uchovává plán společně s kódem
Tenex označuje jako MetaHarness společnou sadu instrukcí pro agenty, projektové dokumentace a nástroje ovládaného z příkazové řádky. Podle Hesse pomáhá sjednotit práci kolem samotného programování, například přípravu plánu nebo podkladů pro klienta.
Plány a záznamy rozhodnutí firma ukládá do Gitu společně s kódem. Git přitom slouží jako úložiště s historií změn. Když se agent vrátí k úkolu, může dohledat také okolnosti, za kterých tým řešení vybral.
Přínos takového záznamu si lze představit na jednoduché situaci: v aplikaci zůstává ruční potvrzení objednávky, protože klient potřebuje nejdřív ověřit dostupnost zboží. Samotný kód ukáže, že potvrzení existuje. Zápis rozhodnutí vysvětlí, proč ho další úprava nemá odstranit.
To je ilustrační příklad, nikoli popis zakázky Tenexu. Ukazuje ale, jakou informaci potřebuješ při předávání práce zachovat: vedle výsledného řešení také důvod, který má platit při dalších změnách.
Společný postup umožní posoudit výsledek
Hess v rozhovoru upozorňuje na překážku při nasazování agentů mimo vývoj softwaru. Pokud lidé vykonávají stejnou práci každý jinak a neexistuje společný postup, obtížně se určuje, co má agent dělat a jak poznat správný výsledek.
Pro malý tým to nemusí znamenat rozsáhlou dokumentaci. U konkrétní úlohy doporučujeme zachytit tři věci:
- Očekávaný výsledek: co má po dokončení fungovat a pro koho.
- Rozhodnutí a jejich důvody: která omezení musí další práce respektovat.
- Podmínky převzetí: co zkontroluješ, než změnu přijmeš.
U zmíněné objednávky může být podmínkou převzetí ověření, že zákazník nedostane potvrzení před kontrolou dostupnosti. Agent může připravit změnu i podklady k ověření; odpovědná osoba rozhodne, zda výsledek odpovídá dohodě s klientem.
Rozsah přizpůsob projektu. Doprovodný text rozhovoru upozorňuje, že struktura popisovaná Tenexem může být pro malý tým s jediným projektem zbytečně náročná. Začni záznamem informací, které dnes musíš opakovaně vysvětlovat.
Odměna za dokončené úkoly má slepé místo
Tenex propojuje tento způsob práce s odměňováním vývojářů podle výstupu. Důležitou jednotkou jsou takzvané story points, tedy body používané k odhadu náročnosti úkolů.
Lieberman říká, že obavy z nadhodnocování bodů nebo odevzdávání nekvalitního kódu zatím nebyly hlavním problémem. Firma podle něj staví proti těmto pobídkám roli lidí odpovědných za udržení a růst zákazníků. Ti mají důvod odmítnout práci, která klientovi nepomáhá.
Obtížnější je podle něj odměnit činnosti, které se do dokončeného úkolu nevejdou snadno: pochopení zákazníkova problému, návrh architektury nebo rozhodnutí, co vůbec stavět. Hess zároveň popisuje, že sám tráví méně času psaním kódu a více přípravou kontextu pro model.
Jde o zkušenost představitelů firmy, ne o ověřený univerzální model odměňování. Pro vlastní tým je užitečná zejména otázka, zda při hodnocení výkonu počítáš také práci, díky které agent dostane správné zadání. Počet uzavřených úkolů ji nemusí zachytit.
Začni jedním předáním rozdělané práce
Nemusíš přebírat celý MetaHarness ani měnit způsob odměňování. Vyber úkol, ke kterému se budete vracet, a ulož k němu stručný plán, důležitá rozhodnutí a podmínky převzetí na místo dostupné týmu i agentovi.
Při dalším navázání nech agenta nejprve shrnout, co má zachovat a proč. Porovnej jeho porozumění se skutečnou dohodou. Teprve potom mu svěř úpravu a výsledek zkontroluj podle uložených podmínek.
Sleduj především čas na opakované vysvětlování a opravy způsobené chybějícím kontextem. Tak zjistíš, zda vám záznam rozhodnutí pomáhá dokončovat práci, nebo jen přidává další dokument k údržbě.
Zdroj
Latent Space: rozhovor s Alexem Liebermanem a CJ Hessem o vývoji s AI v Tenexu, 21. října 2026
Související z knihovny