Většina lidí, co dneska „vibecoduje", dělá tu samou chybu. Otevřou agenta, napíšou „udělej mi appku" a čekají zázrak. Chvíli to vypadá kouzelně. Pak se to v produkci sype a kód je svinčík.
Já to dělám obráceně. Než agent napíše první řádek, mám za sebou většinu práce. Není to o promptování. Je to o stavění kolejí, po kterých pak agent jede sám. Takhle to u mě vypadá.
1. Nezačínám u kódu. Začínám u problému.
První věc není „napiš mi X". Sednu si s Claudem a rozsekáme, co vlastně řeším a proč. Reálný problém, možnosti, rizika. Teprve když je jasný záměr, řeším jak. Agent je tak dobrý, jak dobré dostane zadání. Vágní prompt = vágní výsledek.
2. Specifikace a guardrails, ne „nějak to vymysli"
Tady trávím nejvíc času a je to nejdůležitější část. Mantinely držím takhle:
- jazyk a verzi frameworku (jedu top of the top, ale funkční, ne hype, co se za měsíc rozsype),
- architekturu a konvence (u mě tvrdě: max 300 řádků na soubor, KISS, DRY, žádný chytračení),
- co se nesmí měnit a kde má agent zastavit a zeptat se.
CLAUDE.md držím krátký a věcný. Žádný magický limit na řádky neexistuje, ale dlouhý přebobtnalý soubor si pořádně nepřečte ani agent, tak ho dělím. Můj setup vypadá zhruba takhle:
CLAUDE.md # krátký kontext projektu
.claude/
rules/
testing.md # jak a kdy se testuje
conventions.md # styl, hranice souborů
agents/
reviewer.md # subagent na reviewA klíčový rozdíl, co spousta lidí nechápe: CLAUDE.md je doporučení, command hook je pojistka. Věci, co fakt nesmí selhat (spustit testy před commitem, nepsat mimo src/, nezahájit migraci bez potvrzení), nepatří do instrukcí. Agent je totiž může „přemýšlením" obejít. Patří do command hooku, což je obyčejný shell příkaz, co se spustí deterministicky mimo agentův rozum. Konkrétně třeba checkpoint po každé session:
// .claude/settings.json
{
"hooks": {
"Stop": [{
"hooks": [{ "type": "command", "command": "bash scripts/auto-commit.sh" }]
}]
}
}Agent dokončí práci, hook deterministicky zazálohuje stav do gitu. Nikdy nepřijdeš o rozdělanou práci. CLAUDE.md je paměť projektu, hook je reflex.
3. Plán, a nech ho roztrhat
Než se kóduje, jedu plan mode (režim pouze pro čtení, kde agent jen analyzuje a nesahá na nic) a nechám si napsat plán.
Pak dělám věc, kterou většina vynechává. Ten plán hodím na víc modelů a nechám každý, ať ho zkritizuje. U mě Claude Opus, Sonet i Haiku, a na to pustím ještě Codex. Každý najde jinou díru: jeden architekturu, druhý edge case, třetí bezpečnost. Z připomínek plán přepíšu. Teprve potom první řádek kódu.
A že to není teorie? Tenhle článek prošel přesně tímhle. Hodil jsem ho na víc modelů a dva z nich mi nezávisle a shodně chytly faktickou chybu, kterou bych jinak vydal. To samý dělám s plánem kódu. Hodina nad plánem mi ušetří den oprav.
4. Teprve teď kód, a ne jeden agent
Když koleje stojí, samotné psaní kódu je skoro nuda. A o to jde. Nejedu jeden agent: při soustředěném kódění mi běží cca tři projekty naráz, na některém i víc agentů, co řídím jak dispečer. Složitý úkol se nevejde do jednoho okna kontextu, tak ho rozsekám mezi víc agentů, každý s vlastním kontextem.
Co to drží pohromadě, jsou rychlé feedback loopy: rychlé testy, rychlá kompilace. Když agent dostane odezvu za vteřiny, jede. Když čeká minuty, rozbije se to o trpělivost.
Co se mi naopak nevyplatilo
Žádný hype bez druhé strany. Nacpat agentovi kontext až po okraj je cesta do pekla, radši míň a přesně. A vibecoding bez znalosti kódu je past. Nejvíc z agentů vytřískne ten, kdo umí stavět i bez nich. Když nevíš, jak má výsledek vypadat, nepoznáš, že ti agent vrátil osekanou verzi.
Můj checklist, než pustím agenta na kód
- Vím, jaký problém řeším (ne jen „co chci postavit")
- Stack a verze zafixované
CLAUDE.mdkrátký, pravidla rozdělená do.claude/rules/- Command hooky na to, co nesmí selhat (testy, hranice zápisu)
- Plán prošel kritikou víc modelů
- Rychlé testy běží
Vyhraje ten, kdo umí postavit prostředí, ve kterým agent nemůže nadělat škodu a má jasno, co po něm chceš. Promptovat umí každej. Tohle ne.