Proč nikdy nečtu první plán od Claude Code

Ahoj,

mám pravidlo, které lidi překvapuje: nikdy nečtu první plán, který mi Claude Code vygeneruje.

Ne proto, že by byl špatný. On vypadá skvěle. Přesně tak skvěle, že ho chceš okamžitě schválit a nechat AI pracovat. A přesně tohle je problém.

Problém s prvním plánem

Když Claude Code dostane úkol, vygeneruje plán. Rozloží problém na kroky, navrhne, které soubory upravit, jaké funkce zavolat, v jakém pořadí postupovat. Zní to rozumně. Vypadá to profesionálně. A tvůj mozek řekne: „Jo, to sedí.”

Jenže ten plán má skoro vždy díry. Konkrétně:

Odkazuje na věci, které neexistují. AI si vymyslí název funkce, který zní logicky, ale v codebase není. Nebo předpokládá API endpoint, který nikdy nikdo nenapsal. Plán vypadá konzistentně sám se sebou — ale neodpovídá realitě projektu.

Ignoruje konvence projektu. Každý projekt má svůj styl. Pojmenování souborů, strukturu komponent, způsob error handlingu. AI to nemusí vědět, i když má přístup ke codebase. Udělá věci „správně” obecně, ale špatně pro tvůj konkrétní projekt.

Míjí edge casy. První plán řeší happy path. Co když API vrátí 429? Co když uživatel pošle prázdný formulář? Co když je databáze nedostupná? Tohle v prvním plánu nebývá.

Neřeší bezpečnost. Plán přidá nový endpoint, ale nezmíní autentizaci. Uloží data, ale neřeší sanitizaci. Ne proto, že by AI nevěděla, co to je — ale proto, že se soustředí na to, co jsi explicitně zadal.

Proč to schvalujeme

Tady je ta nepříjemná část: my ty plány schvalujeme, protože vypadají dobře. Je to kognitivní zkreslení — když ti někdo (nebo něco) předloží strukturovaný, sebevědomý návrh, tvůj mozek přepne do režimu „validace” místo „kritické analýzy”. Přesně ten samý mechanismus, který způsobuje kognitivní dluh — rychlost bez porozumění.

Čteš plán a hledáš důvody, proč je správný. Ne důvody, proč je špatný.

U lidského kolegy bys to dělal taky — ale kolegu znáš, víš, kde dělá chyby, máš kontext. U AI tohle chybí. AI píše s absolutní jistotou, ať je plán perfektní nebo úplně mimo.

Moje řešení: /replan

Napsal jsem si plugin pro Claude Code, který tohle řeší za mě. Jmenuje se claude-replan a funguje jednoduše:

1. Zadám úkol. Claude Code vygeneruje plán.
2. Místo čtení plánu napíšu /replan.
3. Plugin rozpošle paralelní subagenty, kteří plán zkoumají z různých úhlů.
4. Dostanu zpět revidovaný plán s konkrétními opravami.

Každý subagent se dívá na plán jinak:

• Codebase alignment — existují ty funkce a moduly, na které plán odkazuje? Sedí to s aktuální strukturou projektu?
• Feasibility — dají se ty kroky reálně provést? Nejsou tam závislosti, které by to rozbily?
• Security — chybí autentizace, validace, sanitizace?
• Fresh perspective — je to vůbec nejlepší přístup, nebo existuje jednodušší řešení?

Tihle agenti běží paralelně, takže revize trvá vteřiny, ne minuty.

Jak to vypadá v praxi

# Zadáš úkol v Claude Code
> Přidej endpoint pro export uživatelských dat do CSV

# Claude Code vygeneruje plán...
# Místo schvalování:
> /replan

# Plugin rozpošle agenty, kteří plán prověří
# Za pár vteřin dostaneš revidovaný plán s opravami:
# - "UserService.exportData() neexistuje, použij UserRepository.findAll()"
# - "Chybí rate limiting na novém endpointu"
# - "CSV generování by mělo být async — pro 10k+ uživatelů to zablokuje event loop"

Výsledek: plán, kterému můžu věřit. Ne proto, že je od AI — ale proto, že prošel kritickou revizí z několika úhlů.

Plugin je open source: claude-replan na GitHubu.

Co když nechceš plugin

Rozumím — ne každý chce instalovat další nástroj. Ale princip funguje i bez něj. Stačí, když po vygenerování plánu ručně položíš pár otázek:

1. „Existují všechny funkce a moduly, na které plán odkazuje?” — Tohle odhalí vymyšlené API.
2. „Jaké konvence projektu plán porušuje?” — Claude Code zná codebase, ale nemusí si konvence uvědomovat, dokud se nezeptáš.
3. „Co se stane, když [edge case]?” — Doplň konkrétní scénář: prázdný input, timeout, race condition.
4. „Existuje jednodušší způsob, jak tohle udělat?” — První plán je obvykle nejočividnější, ne nejlepší.

Tohle zabere minutu navíc. A ušetří ti hodinu debugování, když se ukáže, že plán počítal s neexistující funkcí.

Proč na tom záleží

Tohle není jen o plánovacích chybách. Je to o způsobu, jakým s AI pracuješ.

Pokud schvaluješ první plán bez revize, děláš z AI orakulum. Věříš mu, protože zní přesvědčivě. A to je nebezpečný návyk — protože AI bude znít přesvědčivě, i když se mýlí.

Pokud plán reviduješ — ať už ručně, nebo přes plugin — děláš z AI spolupracovníka. Někdo navrhne, někdo zkontroluje. Stejný princip jako code review u lidí. Bez toho vzniká to, čemu se říká workslop — kód, který vypadá hotově, ale nikdo mu nerozumí.

Já používám /replan na každém netriviálním úkolu. Ne proto, že bych AI nevěřil. Ale proto, že vím, jak fungují první drafty — ať už je píše člověk, nebo stroj.

Shrnutí

• První plán od AI vypadá dobře, ale má díry — vymyšlené funkce, chybějící edge casy, porušené konvence.
• Schvalujeme ho příliš snadno — kognitivní zkreslení nás tlačí k validaci místo kritiky.
• Řešení: revize z více úhlů — buď ručně (otázky), nebo automaticky přes claude-replan.
• Princip je důležitější než nástroj — i bez pluginu můžeš plán revidovat. Hlavní je neschvalovat první verzi.

Vyzkoušej to. Příště, když ti Claude Code nabídne plán, neschvaluj ho. Zeptej se: „Co je na tom špatně?” Odpověď tě překvapí.

— Jirka

Mohlo by tě zajímat

• Kognitivní dluh — nová cena za AI rychlost
• Váš tým generuje kód, který nikdo nečte: Problém jménem workslop
• Skills vs. agenti: Kdy ti stačí recept a kdy potřebuješ kuchaře
• Vibe Coding požírá váš codebase