Appearance
AGENTIC STANDARD
Konkrétní standard, ne obecný dotazník
AI Readiness poměřuje váš vývoj vůči Agentic standardu, tedy závaznému způsobu práce, podle kterého v TechFides vývojáři orchestrují AI agenty. Vývojář drží směr, zadává a schvaluje, rutinu (kód, testy, PR) odvádí agent. Kompetence popsané na této stránce tvoří konkrétní měřítko hodnocení.
7kroků end-to-end průběhu jednoho úkolu
5oblastí standardu od základů k pokročilým
3úrovně automatizace: git → session → headless
V kostce
Připravenost neměříme vůči sbírce nezávazných tipů, ale vůči závaznému standardu, který napříč TechFides platí pro každého vývojáře. Vývojář se v něm posouvá do role orchestrátora agentů. Soustředí se na rozhodnutí, která stroj neudělá lépe, a zbytek předá agentovi. Kvalitu přitom hlídají guardraily a přísnější CI, člověk dělá final gate. Jako referenční nástroj používáme Claude Code.
🎯 Co standard řeší a co z něj hodnotíme
Standard dává celému týmu jeden závazný způsob práce s AI. Místo individuálních experimentů společná laťka napříč projekty. Právě proto je použitelný jako měřítko: nabízí konkrétní laťku, vůči které se dá poměřovat, ne obecné best practices. Jednotlivé oblasti jsou seřazené od základů k pokročilým a navazují na sebe, od kvality vstupu přes kontext a modely, napojení na nástroje a validaci až po orchestraci agentů. Těžištěm práce vývojáře je dnes kvalita zadání a správně nastavené mantinely (guardraily) pro AI, nikoli samotné psaní kódu. Klíčový narativ je posun role vývojáře:
| Dříve | Dnes: vývojář jako orchestrátor agentů |
|---|---|
| Vývojář píše každý řádek | Rutinu (kód, testy, PR) dělá agent |
| Kontext drží v hlavě | Kontext je zapsaný v instrukcích pro agenta přímo v repozitáři |
| Kvalitu hlídá jen člověk | Kvalitu hlídají guardraily + přísnější CI, člověk dělá final gate |
Claude Codeinstrukce pro agentaspec-drivenMCPhookyguardrailyAgent SDK
ℹ️ Cílový stav, ze kterého standard vychází, popisuje sekce Metodika AI Readiness; jak se podle tohoto měřítka boduje zralost lidí, najdete v ose 1: lidé.
⚙️ Modelový průběh jednoho úkolu (end-to-end)
Nejlepší způsob, jak měřítko pochopit, je projít jeden reálný úkol od zadání po merge na příkladu „přidat filtrování objednávek podle stavu". Tímto průběhem porovnáváme váš skutečný tok práce při vyhodnocení.
Sedm kroků od předání práce po merge. Prvotní posouzení kompletnosti ticketu má na starosti Forge, proto tady začínáme až předáním práce agentovi. Jádrem standardu jsou kroky 2–3: sepsání a schválení zadání.
Vývojář předá agentovi podklady přes MCP (číslo ticketu, potřebné přístupy) s jediným klíčovým pokynem: vytvoř plán a doptej se. Agent se ptá, iterativně upřesní zadání a sepíše ho do souboru .md. Tomuto průběžnému záznamu rozhodnutí (decision logu) říkáme spec: je to popis změny podle zadání a kódu. Po schválení specu vývojářem agent implementuje autonomně: exekuce běží paralelně (u větších úkolů se práce rozdělí mezi víc agentů) a pro daný úkol se vybere vhodný model. Odevzdává hotové: MR se zelenou CI.
👤 Rozdělení práce člověk / agent
Podstata posunu je v tom, že člověk se soustředí na rozhodnutí, která stroj neudělá lépe, a zbytek předá agentovi.
| Krok | Kdo |
|---|---|
| 1. Start práce a předání podkladů | člověk (zadává), agent (tvoří plán, ptá se) |
| 2. Sepsání zadání (spec) | agent (píše), člověk (usměrňuje) |
| 3. Schválení zadání | člověk |
| 4. Autonomní exekuce (paralelně) | agent |
| 5. Zelené MR | agent |
| 6. Manuální ověření | člověk |
| 7. Final review a merge | člověk |
ℹ️ Vývojář usměrnil a schválil zadání (kroky 2, 3), sám ověřil výsledek (krok 6) a rozhodl o mergi (krok 7). Zbytek odvedl agent. To je podstata posunu od psaní kódu k orchestraci.
🧭 Oblasti standardu: pět oblastí hodnocení
Následujících pět oblastí tvoří jádro standardu, a tedy i jádro měřítka. Každá má svůj Standard (laťka, vůči které se poměřuje) a Antipatterny (co při vyhodnocení identifikujeme jako zjištění).
Spec vzniká vždy, tedy u každého ticketu. U triviálních změn (oprava překlepu, aktualizace závislosti, změna konfigurace) je krátký, u zásahů do logiky podrobný. Spec vychází z kombinace analýzy ticketu, současné implementace a dokumentace a vstupů podle typu úkolu (FE: Storybook, design; BE: DB schéma, API kontrakty; infra: pipeline, prostředí). U každé dílčí úlohy navíc doporučí model podle náročnosti úlohy. Na architekturu zvolí nejsilnější model (Fable), na plánování a složitou logiku silný (Opus), na přímočarou implementaci střední (Sonnet), na mechanickou úpravu levný. Volba modelu tak není nahodilá, ale zapsaná už v návrhu. Nejasnosti se v specu nedomýšlejí, ale vrací se analytikovi. Spec žije jako Markdown u ticketu, takže je dohledatelná stopa zadání → spec → PR.
📄 Příklad specu (výřez)
markdown
# Spec: Filtrování objednávek podle stavu (PROJ-1234)
## Výchozí stav (analýza kódu)
- Endpoint: `GET /api/orders` (OrderController.list)
- Repository: `OrderRepository.findAll`, dnes bez filtru stavu
- Stavy dle enumu `OrderStatus`: NEW, PAID, SHIPPED, CANCELLED
## Technický návrh
- Přidat query param `status` (volitelný), validace proti `OrderStatus`
- Filtr aplikovat v repository vrstvě, ne v paměti
## Rozpad na úlohy
| # | Úloha | Model |
| --- | ---------------------------------- | ------- |
| 1 | Rozšířit repository o filtr stavu | střední |
| 2 | Validace a mapování query paramu | střední |
| 3 | Testy: prázdný filtr, neznámý stav | levný |
## Otevřené otázky
- Má neznámý stav vracet 400, nebo prázdný seznam? → dotaz na analytika💬 Pokyn „doptej se" v instrukcích pro agenta
markdown
<!-- instrukce pro agenta (výřez) -->
## Před začátkem práce
Před začátkem projdi zadání i všechny vstupy a vznes dotaz ke všemu,
co je nejednoznačné nebo chybí. Nedomýšlej si chybějící informace.
Raději se zeptej.⛔ Antipatterny: vstup
Bez pokynu „doptej se" má agent tendenci mezery „rozumně" domyslet. Explicitní „doptej se" je levná pojistka proti chybnému směru celé implementace. Jak se tato disciplína promítá do plně automatizovaného zhodnocení ticketu, popisuje Forge.
Standard odmítá jeden model jako default na všechno. Model se volí podle náročnosti úlohy:
| Náročnost úlohy | Model |
|---|---|
| architektura, návrh systému | Fable (nejsilnější) |
| plánování, složitá logika | Opus (silný) |
| přímočará implementace | Sonnet (rychlejší) |
U složitých úkolů se modely kombinují. Jeden plánuje, druhý implementuje:
text
Fable → architektura a systémový návrh (nejnáročnější rozhodnutí)
Opus → vytvoří plán a spec (přemýšlení, návrh)
Sonnet → podle plánu implementuje jednotlivé úlohy (rychlá rutina)⛔ Antipatterny: kontext a modely
- Secrets nebo interní URL v instrukcích pro agenta: instrukce jsou součástí repozitáře, citlivé údaje do nich nepatří.
- Instrukce delší než ~200 řádků: bobtnající instrukce přestávají být čitelné; detaily patří do hlubší dokumentace.
- Opakované vysvětlování téhož v každém promptu místo jednoho zápisu do instrukcí pro agenta nebo skillu.
- Jednotný default na všechno: jeden model bez ohledu na náročnost znamená buď platit silný model za rutinu, nebo pouštět slabý na úkol, který vyžaduje přemýšlení.
Hooky se spouští v definovaných bodech běhu agenta. Pravidla tak platí automaticky, nikoli nahodile:
| Bod běhu agenta | Typické využití |
|---|---|
| před akcí agenta | zablokovat nepovolenou operaci |
| po změně souboru | lint + dotčené testy hned po změně |
| při odeslání zadání | doplnit či validovat pravidla vstupu |
Právě hook „po změně souboru" v modelovém průběhu spouští lint a dotčené testy po každé změně. Napojení na Jiru přes MCP zase umožní načíst ticket i akceptační kritéria bez ručního kopírování.
⛔ Antipatterny: MCP a automatizace
- Neomezená práva: MCP server nesmí mít víc oprávnění, než úkol potřebuje.
- Neaktualizovaný allowlist: seznam povolených operací zastará a povoluje víc, než má.
- Destruktivní automatizace bez guardrailů nebo logu: akce, kterou nelze dohledat ani zastavit.
- Headless zápis do main bez review gate: bezobslužný agent nesmí obejít lidské review.
Kód od agenta může obsahovat chybnou logiku, přehlédnutý edge case, stylový nesoulad a v krajním případě i bezpečnostní problém, včetně pokusu vložit secrets do kódu. Zelené CI samo o sobě neznamená, že je kód správný. CI je proto záměrně přísnější:
| Kontrola | K čemu slouží |
|---|---|
| linter | styl a základní chyby |
| SonarCloud | kvalita kódu, code smells, chyby |
| secrets scan | odhalení secrets, které se nemají v kódu |
U oblastí auth / šifrování / platby / secrets platí review jako tvrdá podmínka bez ohledu na výsledek CI. Zelená pipeline nenahrazuje člověka. Toto review odpovídá kroku 7 modelového průběhu.
⛔ Antipatterny: validace
| Antipattern | Proč je nebezpečný |
|---|---|
| merge naslepo po zelené CI | zelené CI neověří byznysovou logiku ani soulad se systémem |
--dangerously-skip-permissions (YOLO mode) v ostrém repu | vypnutí guardrailů v produkčním repozitáři |
| secrets v kódu | únik citlivých údajů; přesně to má odhalit secrets scan |
Nejvyzrálejší posun je od „agent řeší zadané" k „agent sám identifikuje práci a navrhuje řešení". Spouští ho triggery a hooky:
| Trigger | Reakce agenta |
|---|---|
| failing test | návrh fixu |
| dependency vulnerability | PR s fixem |
| monitoring (CI, Sentry) | založení ticketu / PR k review |
🤖 Vlastní role agentů: dělba práce v týmu agentů
text
researcher → zjistí kontext a souvislosti
implementer → napíše kód podle plánu
reviewer → zkontroluje výstup (first-pass review)⛔ Antipatterny: orchestrace a náklady
- Víc nesouvisejících úkolů v jednom kontextu: kontext se zamlží a kvalita klesá.
- Paralelní agenti nad týmž souborem: vznikají kolize a změny se přepisují.
- Samostatný merge proaktivního agenta bez human gate: i proaktivní agent končí u lidského review, nikdy nemerguje sám.
- Provoz bez kontroly nákladů: agenti na pozadí spotřebovávají kredity i bez dohledu.
- Jeden nepřetržitý chat celý den: kontext se zaplní balastem, kvalita klesá a náklady rostou.
ℹ️ Metrika cost per merged PR je součástí toho, jak se podle tohoto měřítka boduje zralost práce s AI. Podrobnosti najdete v ose 1: lidé.