19. února 2026

Jak jsme přešli na agentní delivery bez ztráty kontroly

Tahle změna nevznikla proto, že by byl „agent trend“. Vznikla proto, že klasický vývoj narážel na strop: backlog rostl, kontext se ztrácel mezi týmy a dokumentace zaostávala za realitou. Potřebovali jsme model, který dovolí paralelní tempo, ale zároveň zpřesní rozhodování.

A právě to dnes děláme přes agenty, Codex CLI, git worktree a OpenSpec.

Krok 1: Všechno začíná specifikací, ne kódem

Každá změna má OpenSpec artefakt. To znamená: proč změna vzniká, koho ovlivní, jak poznáme úspěch, jaká jsou rizika, co je mimo scope. Dokud tohle není jasné, nejde se do implementace.

Je to tvrdé pravidlo, které šetří obrovské množství přepracování.

OpenSpec nám dává dvě věci. Za prvé: společný jazyk mezi byznysem, produktem a vývojem. Za druhé: dokumentaci, která vzniká průběžně, ne zpětně „když zbyde čas“.

Krok 2: Rozpad na paralelní proudy

Změnu rozdělíme na samostatné proudy: API, UI, datová vrstva, integrační logika, observability, copy/SEO, testovací scénáře. Každý proud má jasný vstup, výstup a ownera. Díky tomu není paralela chaos, ale řízená orchestrace.

• Každý proud má odpovědnost: owner, scope, kritéria dokončení.
• Každý proud má vlastní rytmus: nečekáme na nejpomalejší část delivery.
• Každý proud má audit: jasně víme, proč vznikla změna a jaký má dopad.

Na každý proud zakládáme vlastní git worktree. To je praktický game changer. Můžeme mít více běžících implementací současně bez konfliktů v jednom pracovním stromu. Když jeden proud čeká na rozhodnutí, ostatní jedou dál.

Krok 3: Agent v Codex CLI má jasný kontrakt

Agent nedostává obecné zadání typu „udělej to hezky“. Dostává kontrakt: konkrétní soubory, akceptační kritéria, coding pravidla, omezující podmínky, testovací postup. V Codex CLI pak pracuje jen v definovaném rozsahu.

Tím odstraňujeme nejčastější strach managementu: že agent „udělá něco navíc“. Neudělá, pokud má dobře nastavený rámec. Agent je rychlý, ale pořád je to řízená exekuce, ne samovláda.

Krok 4: Každý proud má vlastní validaci

Každý výstup musí projít buildem, typy, lintem a cílenými testy. U kritických změn přidáváme smoke scénáře a rychlý provozní check. Pokud proud neprojde, nečeká se na „společný release den“. Oprava jde okamžitě.

Co musí projít před mergem

• Technická kvalita: build, TypeScript, lint a cílené testy.
• Produktová kvalita: soulad s akceptačními kritérii ze specifikace.
• Provozní připravenost: observability, rollback plán, známá rizika.

Tento rytmus je důležitý: integrujeme jen to, co je ověřené. Na první pohled přísnější proces, ve skutečnosti rychlejší delivery. Méně rollbacků, méně incidentů, méně nočních zásahů.

Krok 5: Merge orchestrace místo „big-bang“ integrace

Proudy slučujeme podle závislostí. Typicky nejdřív datový základ, pak API, potom UI a nakonec doprovodné vrstvy. Každý merge má jasný diff a jasný dopad. Když se něco pokazí, víme přesně kde.

Tímto krokem zkracujeme čas mezi „hotovo v branchi“ a „hotovo v produkci“. V klasickém modelu se často nejvíc času ztrácí právě v integraci. U nás je integrace průběžná disciplína, ne finální drama.

Krok 6: OpenSpec jako živá dokumentace

Po každé významné změně aktualizujeme OpenSpec: co se dodalo, co se změnilo proti původnímu návrhu, co je známé omezení, co je další krok. Dokumentace tím drží krok s realitou.

Pro management to má obrovskou hodnotu. Místo „slovního reportu“ máte přesný artefakt: rozhodnutí, status, rizika, metriky. To zrychluje steering meetingy a snižuje počet misinterpretací.

Krok 7: Bezpečnost a governance i v delivery

Agentní vývoj musí mít stejnou nebo vyšší kontrolu než klasický. Proto držíme role-based přístupy, audit trail zásahů agentů a jasná pravidla práce s daty. Princip je stejný jako u AI governance v produkci: rychlost ano, ale pod kontrolou.

Jak to vypadá v denním provozu

Ráno otevřeme 3 až 7 paralelních proudů podle priority týdne. Každý má vlastní worktree, vlastního ownera a agenta. V průběhu dne běží krátké synchronizace, ne hodinové porady. Večer máme jasně vidět, co je připravené k merge, co je blokované a proč.

Největší změna je v tom, že ruční operativu převzal systém: kontrola konzistence, opakované kroky, draft patchů, první validace. Vývojáři se více věnují architektuře, edge-case scénářům a rozhodnutí s dopadem na produkt.

Co to přineslo byznysu

Doručujeme více změn paralelně, ale s menším počtem regresí. Méně energie padá na koordinaci, více na reálnou hodnotu pro klienta. Klienti zároveň dostávají lepší dokumentaci, protože nevzniká dodatečně, ale průběžně jako součást procesu.

• Rychlejší release cykly: kratší čas od zadání po produkci.
• Méně regresí: více kontroly před integrací, méně incidentů po release.
• Lepší rozhodování vedení: průběžná dokumentace a jasný stav každé změny.

Důležité je i to, že proces je škálovatelný. Když přidáme nový tým nebo nový proud, nehroutí se systém. Rozšíří se kapacita, protože pravidla jsou jasná a standardizovaná.

Co doporučujeme firmám, které chtějí stejný posun

1. Nejprve definujte pravidla specifikace (OpenSpec), teprve pak nasazujte agenty.

2. Rozdělte práci do nezávislých proudů a používejte worktree, abyste neblokovali celý tým jednou branchí.

3. Každý proud musí mít automatizovanou validaci ještě před merge.

4. Dokumentaci aktualizujte průběžně, jinak vám proces přeroste přes hlavu.

Jednou větou: agentní delivery není o tom „psát víc kódu“. Je o tom rozhodovat lépe, doručovat rychleji a držet kvalitu i při paralelním růstu.