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í.
Obsah článku 9 sekcí
V kostce
- Pipeline má pět fází – research, plán, exekuce, review a ship – a každou obstarává vlastní agent s vlastními pravidly a parametry.
- Research subagent vrátí jen shrnutí (max 4000 tokenů výstupu), takže hlavní agent nezahlcuje kontext surovými daty.
- Klíčové parametry: MIN_TEST_COVERAGE typicky 80 %, canary deploy 15 minut a automatický rollback při chybovosti nad 1 %.
- Když agent udělá chybu, neopravuj ji v kontextu, ale rewindni před chybu a pusť ho znovu, protože čistý kontext dává čistý kód.
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:
- Fáze implementace (co se mění, jaké soubory)
- Testy pro každou fázi (unit, integration, e2e)
- Závislosti mezi fázemi (co musí být hotové předtím)
- 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:
- Vytvoření PR s popisem změn, testy a review poznámkami
- CI/CD pipeline spustí testy, lint, security scan
- CANARY_DURATION_MINUTES — jak dlouho běží canary deploy (typicky 10-30 min)
- 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
- Vytvoř CLAUDE.md pro svůj hlavní projekt (60 řádek max)
- Definuj 3 skilly — test generation, code review, PR creation
- Nastav parametry — začni konzervativně (viz tabulka výše)
- Pusť jeden end-to-end workflow — například "meeting → Jira ticket"
- 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.