Menu
Přihlásit
Domů / Obsah / Prompty / Jak postavit 5fázový AI pipeli...
Prompty 12.06.2026 Tutorial

Jak postavit 5fázový AI pipeline: Od researchu po deploy bez chaosu

Nauč se postavit 5fázový AI pipeline, který tvůj tým dostane z nápadu do produkce bez chaosu. Konkrétní parametry, reálné příklady a checklist ke stažení.

Kompletní návod

Každý tým, který začal používat AI agenty, zažil stejný moment: agent vygeneroval kód, všechno vypadalo skvěle, a pak se to v produkci rozpadlo. Ne proto, že by AI byla hloupá, ale protože chyběl proces. Žádná kontrola kvality, žádný review, žádný staging. Jen čistá entropie.

V tomhle článku si postavíme 5fázový AI pipeline, který tohle řeší. Research, plánování, exekuce, review a deploy. Každá fáze má svého agenta, svá pravidla a své parametry. Po přečtení budeš vědět, jak nastavit HUMAN_APPROVAL_THRESHOLD, proč je lepší "rewind > correct" a jak přejít od "backend engineer agenta" k "migration agentovi".

Fáze 1: Research — subagent čte, shrnuje, neplýtvá kontextem

První fáze je o sběru informací. Ne o tom, aby hlavní agent pročítal 200 stránek dokumentace a zaplnil kontextové okno nesmysly.

Jak to funguje v praxi:

  • Subagent dostane přístup k relevantním souborům, databázím nebo API
  • Přečte, shrne a vrátí strukturovaný výstup (max 2-3 odstavce + klíčové tabulky)
  • Hlavní agent dostane jen summary, ne surová data

Příklad:

Máš meeting transcript o nové funkci. Research subagent ho přečte, vytáhne akční položky, identifikuje závislosti na stávajícím kódu a vrátí ti tohle:

SUMMARY:
- Nová funkce: export reportů do PDF
- Závislosti: report-service.ts, pdf-generator.ts (legacy)
- Riziko: legacy PDF generátor nemá testy
- Doporučení: refactor před implementací

Hlavní agent teď pracuje s čistým kontextem a ví, na co si dát pozor. Žádné 40 stránek transcriptu v promptu.

Tip: Nastav research subagentovi limit na max 4000 tokenů výstupu. Delší summary už není summary, je to noise.

Fáze 2: Plan — plánovací mód navrhne fáze s testy

Když máš data z researchu, přichází plánování. Ne chaotické "udělej to", ale strukturovaný plán s fázemi a testy.

Plánovací mód navrhuje:

  1. Fáze implementace (co se mění, jaké soubory)
  2. Testy pro každou fázi (unit, integration, e2e)
  3. Závislosti mezi fázemi (co musí být hotové předtím)
  4. Odhad rizika (low / medium / high)

Příklad plánu pro ten PDF export:

PHASE 1: Refactor legacy PDF generátor
- Test: unit testy pro všechny formáty
- Riziko: medium (legacy kód)

PHASE 2: Implementace export endpointu
- Test: integration test API response
- Závislost: Phase 1

PHASE 3: Frontend integrace
- Test: e2e test export flow
- Závislost: Phase 2

Klíčový parametr: HUMAN_APPROVAL_THRESHOLD. Pokud je riziko fáze >= medium, plánovací mód vyžaduje lidské schválení před exekucí. Nastav si ho podle velikosti týmu — pro 3 lidi doporučuji "medium", pro 10+ "high".

Fáze 3: Execute — agent běží s guardrails, ne na volnoběh

Exekuce je fáze, kde většina týmů selže. Pustí agenta a doufají. Správný pipeline má guardrails — kontrolní body, které zastaví běh, když něco nesedí.

Co musí být nastaveno:

  • MIN_TEST_COVERAGE — typicky 80%. Agent nesmí označit fázi jako hotovou, pokud testy nepokrývají dostatek kódu.
  • AUTO_DEPLOY_TO_STAGING — true/false. Pro experimenty true, pro kritické systémy false.
  • Hooks — kontrolní body před každým git commitem, po každém testu, před deployem

Příklad guardrails v praxi:

Agent implementuje PDF export. Po dokončení kódu automaticky spustí testy. Pokrytí je 75% — pod limit. Agent zastaví, upozorní tě a čeká na instrukce. Necommituje polotovar.

Důležitá praxe: "Rewind > Correct"

Když agent udělá chybu, neopravuj ji v aktuálním kontextu. Rewindni se před chybu a pusť ho znovu. Proč? Každá oprava v kontextu zanechává stopu. Po 5 opravách je kontext plný workaroundů a agent začne generovat kód, který reflektuje chyby, ne záměr. Čistý kontext = čistý kód.

Fáze 4: Review — druhý AI agent kontroluje diff

Review není jen lidská činnost. Druhý AI agent (s jiným system promptem) může kontrolovat diff rychleji a konzistentněji než člověk.

Review agent kontroluje:

  • Bezpečnostní problémy (SQL injection, XSS, hardcoded secrets)
  • Dodržení konvencí (naming, struktura, formátování)
  • Logiku (edge cases, error handling)
  • Výkon (N+1 queries, zbytečné re-rendery)

Příklad review výstupu:

REVIEW RESULT:
- OK: Test coverage 85%
- WARNING: Funkce generatePDF() nemá timeout — riziko zablokování
- OK: Žádné hardcoded secrets
- FIX REQUIRED: Chybí error handling pro neplatný HTML input

Review agent neřekne "je to dobrý" nebo "špatný". Dá strukturovaný checklist. Člověk se rozhodne, jestli se má opravit, nebo jestli je to acceptable risk.

Tip: Review agent by měl mít přístup k codebase, ne jen k diffu. Kontext je klíčový — funkce, která vypadá bezpečně izolovaně, může být kritická v širším kontextu.

Fáze 5: Ship — automatický PR s CI/CD integrací

Poslední fáze je o dostání kódu do produkce bez manuálního klikání.

Automatizovaný ship proces:

  1. Vytvoření PR s popisem změn, testy a review poznámkami
  2. CI/CD pipeline spustí testy, lint, security scan
  3. CANARY_DURATION_MINUTES — jak dlouho běží canary deploy (typicky 10-30 min)
  4. ROLLBACK_ERROR_RATE — automatický threshold pro rollback (typicky 1% error rate)

Příklad konfigurace:

ship:
  auto_deploy_to_staging: true
  canary_duration_minutes: 15
  rollback_error_rate: 0.01
  require_human_approval_for_production: true

Staging jde automaticky, produkce čeká na zelené tlačítko. Canary běží 15 minut a sleduje error rate. Pokud překročí 1%, automatický rollback. Žádné 3 hodiny pátrání v logách ve 2 ráno.

Konfigurace, kterou musíš vyladit

Tady jsou parametry, které reálné týmy ladí nejvíc:

Parametr Typická hodnota Kdy zvýšit / snížit
HUMAN_APPROVAL_THRESHOLD medium Zvýšit pro kritické systémy, snížit pro interní nástroje
MIN_TEST_COVERAGE 80% Zvýšit pro finanční systémy, snížit pro prototypy
AUTO_DEPLOY_TO_STAGING true False, pokud staging sdílí databázi s produkcí
CANARY_DURATION_MINUTES 15 Zvýšit pro komplexní změny, snížit pro hotfixy
ROLLBACK_ERROR_RATE 1% Zvýšit pro tolerantní systémy, snížit pro platby

Pravidlo: Začni konzervativně. První týden nastav všechno na "přehnaně bezpečné". Až uvidíš, kde to zpomaluje, uvolni jeden parametr po druhém. Ne všechny najednou.

Best practices, které to drží pohromadě

CLAUDE.md — project-specific instrukce

Každý projekt by měl mít soubor CLAUDE.md v rootu. Max ~60 řádek. Obsahuje:

  • Architektura projektu (co kde žije)
  • Konvence (naming, struktura)
  • Časté chyby (co agent dělá špatně opakovaně)
  • Kontakty (koho pingnout, když něco hoří)

Agent si ho přečte na začátku každé session. Nemusíš opakovat pravidla v každém promptu.

Skills jako reusable workflows

Místo "napiš mi testy" použij skill "test-generation". Je to markdown soubor s kroky, verzovaný v Gitu. Agent ho vezme, postupuje podle něj, výsledek je konzistentní.

Příklad skill:

# Test Generation Skill
1. Identifikuj edge cases ze specifikace
2. Napiš unit testy pro každý edge case
3. Napiš integration test pro happy path
4. Spusť testy, oprav failující
5. Report coverage

Feature-specific agenti, ne role

Ne "backend engineer agent". Místo toho "migration agent", "API layer agent", "auth refactor agent". Konkrétní úkol = konkrétní kontext = lepší výsledek.

Reálné workflowy, které tímhle pipelinem běží

Meeting transcripts → Jira + Slack

Research agent přečte transcript, vytáhne akční položky. Plan agent je rozřadí do Jira ticketů s priority. Execute agent vytvoří tickety přes API. Review agent zkontroluje, že nic nechybí. Ship agent pošle summary do Slacku.

Customer feedback PDFs → Insights + competitor comparison

Research agent extrahuje text z PDF. Plan agent navrhne strukturu reportu. Execute agent vygeneruje tabulky s insights a competitor comparison. Review agent zkontroluje faktickou přesnost. Ship agent vytvoří Notion page a pošle link týmu.

Figma designs + codebase → Prototyp + PR

Research agent analyzuje Figma (přes API nebo export) a identifikuje komponenty, které už existují. Plan agent navrhne, co znovu použít a co nově napsat. Execute agent generuje kód a testy. Review agent kontroluje, že design odpovídá Figmě. Ship agent vytvoří PR s preview deployem.

Začni dnes: Checklist pro první pipeline

  1. Vytvoř CLAUDE.md pro svůj hlavní projekt (60 řádek max)
  2. Definuj 3 skilly — test generation, code review, PR creation
  3. Nastav parametry — začni konzervativně (viz tabulka výše)
  4. Pusť jeden end-to-end workflow — například "meeting → Jira ticket"
  5. Změř čas — kolik to ušetří oproti manuálnímu procesu?

Nečekej na dokonalý systém. Začni s jedním workflowem, vylad ho, přidej další. 5fázový pipeline není o tom mít všechno hned. Je o tom mít proces, který se zlepšuje s každým během.


Chceš vidět konkrétní CLAUDE.md příklad nebo skill template? Napiš do komentářů, připravím follow-up článek s copy-paste šablonami.

Začínáte s AI?

Navštivte zacinamsai.cz — průvodce světem AI pro úplné začátečníky.

Přejít na Začínáme s AI →

// Další články, které by tě mohly zajímat

Potřebujete pomoct s AI automatizací?

Domluvte si nezávaznou konzultaci →