MĚŘÍTKO AUDITU — AGENTIC STANDARD

Konkrétní standard, ne obecný dotazník

Audit poměřuje váš vývoj proti Agentic standardu — 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 jsou přesně to, co audit hodnotí.

7

kroků end-to-end průběhu jednoho úkolu

5

oblastí standardu od základů k pokročilým

3

úrovně automatizace: git → session → headless

V kostce

Audit neměří proti sbírce nezávazných tipů, ale proti 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 audit hodnotí

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, proti 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 — víc než 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 Proti čemu auditujeme; 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 se v auditu porovnává váš skutečný tok práce.

Sedm kroků od předání práce po merge. Prvotní posouzení kompletnosti ticketu má na starosti Ticket 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, proti které se poměřuje) a Antipatterny (co audit hledá jako nález).

01

📥 Vstup a spec-driven development

Kvalita výstupu se rovná kvalitě vstupu. Kvalitní zadání je nejlevnější a nejúčinnější zásah do celého AI vývoje.

• Zhodnocení kompletnosti zadání — ještě před vývojem.
• Strukturované zadání — cíl, constraints, očekávaný výsledek a čeho se vyvarovat.
• Kontext mimo repozitář — pokud je pro úkol potřeba.
• Spec vždy — záznam rozhodnutí (decision log): analýza současného kódu, technický návrh a rozpad na úlohy.
• Pokyn „doptej se" — nejúčinnější opatření; zapsané v instrukcích pro agenta, platí automaticky pro každý úkol.

specdecision loginstrukce pro agentaslash command

Spec vzniká vždy — 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 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í — vrací se analytikovi. Spec žije jako Markdown u ticketu, takže je dohledatelná stopa zadání → spec → PR.

📄 Příklad specu (výřez)

# 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

<!-- 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 Ticket Forge.

02

🗂️ Kontext pro agenta a výběr modelu

Agent je tak dobrý, jak dobrý má kontext. Když je know-how zapsané v repozitáři, neopouští firmu s lidmi.

• Instrukce pro agenta v kořeni repozitáře — stack, build/test, konvence, rizika. Jediný zdroj pravdy pro každého agenta i nástroj.
• Vnořené instrukce — u velkých repozitářů (např. platby, autentizace) dostane agent kontext přesně té části, kde pracuje.
• Hlubší technická dokumentace v repozitáři — detaily nad rámec základních instrukcí.
• Opakované postupy jako skill / slash command — verzované a sdílené v repozitáři; tým je nevymýšlí znovu.
• Model podle náročnosti úlohy — silný na přemýšlení, rychlý na rutinu; přiřazení navrhuje už spec.

instrukce pro agentaskillsFableOpusSonnet

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:

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í.

03

🔌 MCP servery a automatizace

Agent musí mít přístup ke stejným nástrojům jako vývojář — a pravidla musí platit automaticky, nikoli nahodile.

• MCP servery — přístup k Jira a git; konfigurace verzovaná v repozitáři, celý tým ji má stejnou.
• Vlastní MCP server — pro interní nástroje bez napojení; jednou postavené, používají všichni.
• Git úroveň — pre-commit hook, generování commit message, lint fix.
• Hooky — vynucují pravidla v definovaných bodech běhu agenta, automaticky a pro všechny stejně.
• Headless běh — agent bez obsluhy: Agent SDK, naplánované joby, agent v CI.

MCPhookyheadlessAgent SDK

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.

04

🛡️ Validace a guardraily

Rychlost od AI nikdy nejde na úkor bezpečnosti ani kvality. Ke kódu od agenta přistupujeme jako ke kódu od juniora.

• AI kód jako od juniora — kontrolujeme logiku, edge cases, styl, a to vše s testy.
• AI code review silnějším modelem — první vrstva kontroly ještě před lidským review běží na silnějším modelu (např. Fable nebo Opus).
• Přísnější CI — kódu vzniká víc a rychleji, kontrola je proto tvrdší.
• Security-citlivé oblasti vždy s lidským review — auth, šifrování, platby, secrets se nikdy nemergují bez člověka.

linterSonarCloudsecrets scanhuman gate

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

05

🎼 Orchestrace a proaktivní agenti

Nejvyšší úroveň standardu — vývojář neorchestruje jednoho agenta, ale tým agentů s různými rolemi, které běží i paralelně.

• Sub-agenti a role — vestavěné role pro průzkum a plánování; vlastní role researcher, implementer, reviewer.
• Paralelní práce — nezávislé úkoly ve více worktree; cílově programatická orchestrace přes Agent SDK.
• Proaktivní agenti — sami identifikují práci: opraví failing test, založí PR na zranitelnost, reagují na monitoring.
• Práce s kontextem — průběžné čištění kontextu a dělení úkolů místo jedné bobtnající session.
• Řízení nákladů — měříme cost per merged PR (cena za dodanou hodnotu, ne za tokeny), volíme model i podle ceny, používáme prompt caching.

sub-agentiworktreeAgent SDKcost per merged PR

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ů

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 — kolize a přepisování změn.
• 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 — viz osa 1 — lidé.

Jak daleko k tomuto standardu máte?

Přesně na to odpovídá audit: obě osy hodnocení proti tomuto měřítku, z faktů a s prioritizovanými zjištěními na konci.

⭐ Cena, rozsah a harmonogram✉️ info@techfides.cz