Vibecoding není AI adopce
Většina firem, které mi dneska volají, má stejný problém. Někdo si přečetl článek, koupil každému v týmu Cursor licenci, poslal mail "od teď používáme AI" a čekal magii. Za tři měsíce má tým víc bugů, pomalejší code review, rozbité lintery a seniora, který si po půlroce otevře PR a nepozná vlastní codebase.
Tomuhle říkám vibecoding. Agent prompt, commit, push, modlit se. Funguje to na víkendový side projekt. Na produkční systém s reálnými zákazníky ne.
AI adopce není "dostaneme nástroj". AI adopce je změna procesu, do kterého ten nástroj zapadá. CLAUDE.md, hooks, skills, worktrees, review gates — tohle jsou ty nudné, bytové věci, které rozhodují, jestli vám agent ušetří týden, nebo způsobí incident.
Prezentaci "git push --force the future — Viva la revolución v terminálu" pro Yolk Studio jsem postavil přesně kolem tohohle. Tenhle post je rozšířená verze — pro lidi, co řeší to samé a nechtějí si projít stejnou křivkou bolesti jako já.
Proč píšu tenhle post
Yolk Studio mi napsalo, jestli bych neměl zájem ukázat, jak reálně používám AI ve vývoji. Šlo mi o to nedělat další přednášku o tom, že "AI je skvělá". Chtěl jsem ukázat konkrétní workflow — nástroje, které denně používám, patterny, které prošly produkcí.
Jestli jste CTO nebo tech lead, který právě nasadil AI nástroje a ptá se "co dál" — tenhle post je pro vás. Pokud čekáte motivační kecy, radši zavřete tab.
Kód sám o sobě nemá žádnou hodnotu
Tohle byl úvodní statement prezentace a záměrně provokativní. Shipping se zrychlil desetkrát, ale produkt, kterému lidé věří, se pořád buduje stejně — uživatel po uživateli, incident po incidentu, zpětná vazba po zpětné vazbě.
Kód vygeneruje každý model. Rozhoduje kdo a jak s nástroji pracuje. Bez struktury vám agent dodá víc kódu rychleji, což je přesně ten opak toho, co chcete. Víc kódu = víc povrchu, víc bugů, víc technical debtu, víc týdnů strávených údržbou místo rozvoje.
Tohle je první věc, kterou v týmech v rámci školení řeším. Zpomalit, aby se dalo zrychlit pořádně.
Šest stavebních kamenů
Všechno, co ukazuju dál, je odpověď na jednu otázku: co musí být na svém místě, aby agent ve firmě fungoval spolehlivě a bez dozoru? Tady je šest věcí, u kterých dokážu na první pohled poznat, jestli tým AI zvládá, nebo se topí.
1. CLAUDE.md — automatický onboarding pro agenta
Když přijde junior do týmu, dáte mu kontext — jaký stack, jak se testuje, kam se nesmí sahat. CLAUDE.md dělá to samé pro agenta. Přečte si ho automaticky při startu, stejně jako .editorconfig nebo .nvmrc.
Stack: Next.js 15, TypeScript, Tailwind
Vždy spusť testy před PR
Nikdy nemodifikuj: src/auth/, migrations
Payment flow: změny konzultuj s lidmi
Bez CLAUDE.md agent improvizuje. A improvizace v dvaceti PRs týdně znamená, že každý PR vypadá, jako by ho psal někdo jiný — protože ho fakticky psal někdo jiný. Pokaždé zapomenutý junior bez paměti.
2. Hooks — guardrails, které nejdou vypnout
Hooks jsou akce, které se spouštějí před nebo po použití nástroje. Tři hlavní typy:
- PostToolUse — automatický formát po každém zápisu (prettier, black, gofmt)
- PreToolUse — validace před spuštěním příkazu (blok
rm -rf, blok force-push na main) - Notification — upozornění, když agent čeká na vstup
Definují se v settings.json a běží automaticky. Agent si nemůže "zapomenout" formátovat kód, protože to za něj dělá hook. Nemůže si omylem pushnout na main, protože hook ten příkaz zablokuje. Tohle je rozdíl mezi "důvěřuju modelu" a "systém vynucuje invariant".
V týmech, kde hooks nejsou, najdu obvykle do týdne PR, který obchází lint, nebo commit, který porušuje konvenci, kterou ten samý tým má v CONTRIBUTING.md. Lidé ji neporušují naschvál — agent ji prostě neviděl.
3. Skills — sdílené know-how v repu
Skills jsou instrukční soubory s přesnými direktivami pro agenta. Fungují jako recepty — strukturované instrukce zajistí konzistentní výstup nezávisle na "náladě" modelu. Dobrý skill má YAML hlavičku (název, popis, povolené nástroje), markdown instrukce a podpůrné soubory.
Co dělají skills tak zásadní: know-how, které dnes sedí v hlavě seniora nebo roztroušené po Slacku, se přesune do repa. "Jak se dělá migrace" není tribal knowledge, ale soubor skills/db-migration.md. Nový člověk v týmu — lidský i agentský — ho najde a aplikuje.
Skills se dají řetězit. Velký úkol se rozloží na graf menších, subagenti běží paralelně, každý s jasným kontraktem. To je patternů, které v prezentacích zmiňuju nejčastěji, protože odemyká největší skok produktivity.
4. Skillsmith — jeden formát pro všechny nástroje
Skillsmith je open-source nástroj, který jsem napsal, aby skills nemusely být duplikované pro každý editor. Jeden unified formát (Markdown + YAML frontmatter), automatický export do Claude Code, Cursor, Windsurf, Copilot a Codex. npx skillsmith sync aktualizuje všechny exporty, když se změní zdrojový skill.
Důvod existence je jednoduchý: skills jsou týmové aktivum. Vendor-lock-in na konkrétní editor znamená, že když za rok přejdete z Cursor na něco jiného, přepíšete know-how znovu. Otevřený standard na agentskills.io tohle řeší.
Ve firmách, které se mě ptají "na který nástroj vsadit", je odpověď: vsaď na formát, ne na nástroj.
5. Git worktrees — izolovaná prostředí pro subagenty
Worktrees jsou izolované kopie repa. Víc feature větví vedle sebe, žádné stashování, žádné konflikty. Subagent si vytvoří worktree, pracuje v izolované větvi a vrátí výsledky do main workspace.
Bez worktrees má každý experiment cenu — stash, přepnout větev, zjistit, že něco chybí, přepnout zpět. S worktrees běží paralelně tři subagenti na třech úkolech a mě to nic nestojí. Žádný "agent mi rozbil main", protože se k main ani nedostane.
6. Self-review — review agent na vlastní kód
Po dokončení úkolu spustím code-review agenta na vlastní výstup. Reviewer je separátní agent — jiná session, jiný kontext, jiná perspektiva. Chytá edge cases, bezpečnostní problémy a naming issues, které první agent přehlédl, protože byl zacyklený na úkolu.
Tohle je nejlevnější kontrola kvality, jakou znám. Stojí minutu strojového času a zachytí věci, které by jinak prošly do PR review a sežraly půl hodiny seniora.
Case studies — co z tohohle workflow vzniklo
Tohle byla pro mě nejzábavnější část prezentace. Konkrétní věci, které reálně používám a které by bez strukturované práce s agenty nevznikly.
BrowserHawk — autonomní QA
Autonomní QA testovací nástroj. Zvládá Azure MSAL login s 2FA, crawluje aplikaci, najde 50+ routes, kategorizuje je a autonomně testuje. Na reálném CRM systému najde 14–15 bugů na jeden běh — rozbité překlady, padající API cally, tiché selhání v UI.
Nejtěžší část nebyl crawl, ale naučit agenta říct "tohle nejde" místo halucinace workaroundu. MSAL flow s 2FA je komplikovaný a agent má tendenci si vymyslet "asi to zvládnu". Řešení: explicitní skill, který popisuje, kdy má přestat a eskalovat, místo aby improvizoval.
Pro firmu to znamená: autonomní testování je realita, ne sci-fi. Ale jen když agentovi dáte jasné hranice, co smí a nesmí řešit sám.
Tempmail skill
Skill, který vytváří jednorázové emailové schránky přes tempmail.lol API. Agent ho může použít úplně samostatně — potřebuje registraci? Vytvoří inbox, zaregistruje se, přečte verifikační email, pokračuje.
Ukázka, kdy skill dává smysl jako atomická schopnost: jedna věc, jasně definovaná, znovu použitelná napříč úkoly. Všechno, co musíte v týmu dělat opakovaně a co má jasné vstupy a výstupy, by měl být skill.
Tudy — lokální service routing
*.localhost automatické routování na běžící služby. Auto-discovery lokálních procesů a Docker kontejnerů. Malý nástroj, ale vyřešil bod tření, který mě denně štval — pamatovat si porty tří microservices.
Důvod, proč to zmiňuju: nejcennější AI výstupy u mě nejsou velké features, ale malé nástroje, které odstraňují denní frikci. Agent je ideální na tohle — úkoly, které by si člověk neudělal, protože to "není priorita".
Okena — terminálový multiplexer v Rustu
Taby, split panely, session persistence, built-in git worktree podpora. Postavil jsem si ho, protože tmux a iTerm neřešily to, co jsem reálně potřeboval — worktree-heavy workflow se subagenty.
Rust jsem před tím nepsal. S agentem jsem ho napsal za víkend. To není o tom, že Rust umím — je to o tom, že když máte strukturovaný workflow, jazyk je implementační detail.
Claude Profile Manager
Správa více Claude účtů současně. Osobní předplatné, firemní team, Vertex AI — všechno v jednom příkazu. O tom už jsem psal samostatný post.
8 pravidel pro práci s agenty
Tohle jsou pravidla, která v týmech trénuju nejdřív, protože je firmy nejvíc podceňují. Každé jedno si někdo musel zaplatit bolestí — buď já, nebo někdo, komu jsem to pak opravoval.
- Plan Before Code — nejdřív
/plan, agent navrhne, vy schválíte - Fresh Context — nová session = čistý start, nenechte agenta bloudit ve starém kontextu
- Done = Tested — hotovo není hotovo, dokud to neprojde testy
- Rules in Repo — CLAUDE.md, hooks, skills — všechno commitnuté a sdílené
- Ask Before Destroy — agent se ptá před destruktivními akcemi, nevypínejte to
- Human in the Loop — vy rozhodujete, agent navrhuje
- Right Tool, Right Job — ne všechno potřebuje agenta
- No Secrets in Prompts — žádné API klíče v promptech, používejte env soubory
Co si z toho odnést
Nebojte se experimentovat. Napište si vlastní skill. Postavte si vlastní malý nástroj, který odstraní jednu každodenní frikci, co vás štve. Zkuste workflow, který vypadá šíleně, a podívejte se, jestli funguje.
Agent, který vám hraje piškvorky, další AI chatbot do webu, generátor memes — tohle nikam neposouvá. Zajímavé jsou věci, které vám samotným zrychlí práci: skill na onboarding nového repa, hook, který vynutí konvenci, review agent, který chytá vaše typické chyby. Začněte u sebe, u svého workflow, u svých denních bolestí. Když něco funguje vám, má šanci fungovat celému týmu.
Pokud i vy řešíte agentický vývoj a chcete se držet na špičce, napište mi — dělám školení a workshopy přímo u vás na místě. Od úplných základů po složitější implementace. me@jakubkontra.com
Děkuji Yolk Studiu a Peterovi Vidličkovi za možnost odprezentovat tohle téma. Většina nástrojů, o kterých tady píšu, je open source na mém GitHubu.
