Shift+Tab je past: Proč váš AI plán ignoruje polovinu codebase

Minule jsem psal o tom, proč nikdy nečtu první plán. Dnes jdu dál: i plán, který vypadá dobře, může být výrazně lepší. Záleží na tom, jak vznikl.

Co dělá Shift+Tab

Stisknete Shift+Tab, Claude Code přepne do plan mode. Napíšete úkol, Claude vygeneruje plán. Kroky, soubory, pořadí. Vypadá to profesionálně.

A plan mode rozhodně není špatný. Claude se dívá do kódu, čte relevantní soubory, snaží se pochopit kontext. Ale je tu rozdíl mezi dívat se a systematicky analyzovat. Plan mode udělá rozumný plán na základě toho, co stihne přečíst. Ale neprojde si codebase metodicky — nehledá cíleně existující abstrakce, netestuje konvence, nemapuje závislosti.

Je to jako rozdíl mezi tím, když se kolega letmo podívá na váš kód, a když ho projde s checklistem.

Příklad, který to ukazuje

Řekněme, že chcete přidat notifikační systém. Shift+Tab vám vygeneruje plán:

1. Vytvoř NotificationService
2. Přidej tabulku notifications do databáze
3. Vytvoř API endpoint /api/notifications
4. Přidej frontend komponentu NotificationBell
5. Napoj na WebSocket pro real-time updates

Vypadá to rozumně. Claude si přečetl pár souborů, pochopil základní strukturu. Schválíte. Claude začne kódit. A pak:

• Zjistí, že máte EventBus, který by mohl notifikace řešit — ale v plánu se s ním nepočítá, protože ho Claude při letmém průzkumu minul.
• Vytvoří nový NotificationService, i když máte BaseService s hotovým error handlingem — protože ho systematicky nehledal.
• Pojmenuje endpointy trochu jinak než zbytek API — protože neprošel všechny routy, jen pár vzorových.
• Přidá migraci v mírně jiném formátu — protože nenašel váš migrační pattern.

Nic z toho není katastrofa. Ale každý takový problém stojí iteraci. A iterace stojí čas a kontext. Plan mode dá rozumný plán. Ale “rozumný” a “nejlepší možný” je velký rozdíl.

Co dělá /feature-dev jinak

/feature-dev z pluginu feature-dev je úplně jiný přístup. Než vám dá plán, projde 7 fází:

1. Průzkum codebase — přečte relevantní soubory, pochopí strukturu projektu.
2. Mapování existujícího kódu — najde utilities, services, patterns, které můžete znovupoužít.
3. Identifikace konvencí — jak pojmenováváte soubory, jak strukturujete komponenty, jak řešíte chyby.
4. Analýza závislostí — co závisí na čem, kde hrozí, že změna rozbije něco jiného.
5. Návrh architektury — teprve teď navrhne řešení, ale s plným kontextem vašeho kódu.
6. Implementace — kóduje podle plánu, který respektuje realitu projektu.
7. Validace — ověří, že výsledek sedí s existujícím kódem.

Ten samý notifikační systém s /feature-dev:

1. Rozšiř existující EventBus o notification channel
2. Přidej NotificationHandler extends BaseService
   (využij logování a error handling z BaseService)
3. Přidej migraci ve formátu Knex (jako existující migrace)
4. Přidej endpoint POST /api/v2/notifications
   (zachovej naming konvenci z routes/v2/)
5. Rozšiř existující HeaderBar o NotificationBell
   (využij useWebSocket composable)

Vidíte ten rozdíl? Není to plán z hlavy. Je to plán, který vychází z vašeho kódu.

/writing-plans: Plán, který počítá s tím, co se může pokazit

/writing-plans je druhý skill ze superpowers, zaměřený na strukturované plánování. Místo toho, aby napsal seznam kroků a doufal, že to vyjde:

• Automaticky zvažuje edge cases — co když tahle operace selže? Co když jsou data nekonzistentní?
• Vytváří checkpointy — po každém kroku definuje, jak ověřit, že je vše v pořádku.
• Definuje akceptační kritéria — ne vágní “hotovo”, ale konkrétní: “endpoint vrací 200, test pokrývá happy path i error case”.
• Mapuje rizika — kde je největší šance, že se něco rozbije.

Tohle je rozdíl mezi plánem a wishlistem. Shift+Tab vám dá wishlist. /writing-plans vám dá plán.

”Ale Shift+Tab mi stačí”

A často stačí! Na jednoduché až střední úkoly je plan mode výborný. Přidej komponentu, oprav bug, přidej endpoint — Shift+Tab to zvládne.

Ale jakmile úkol překročí 3 soubory nebo se týká více vrstev (API + databáze + frontend), rozdíl mezi “podíval se” a “systematicky prozkoumal” začne být vidět. Poznáte to tak, že Claude v polovině implementace předělává vlastní kód, protože narazil na existující abstrakci, o které v plánu nepočítal.

Každá iterace navíc stojí tokeny, čas a kontext. A kontext je vzácný. Plní se zbytečnými pokusy místo užitečnou prací. Pak spustíte /compact, Claude zapomene polovinu kontextu, a kvalita klesne. Investice do lepšího plánu na začátku se vrátí mnohonásobně.

Kompletní workflow

Takhle dnes pracuju na každém netriviálním úkolu:

# 1. Plán — ne z hlavy, z kódu
/feature-dev Přidej notifikační systém pro...
# nebo
/writing-plans Potřebuju plán pro migraci z...

# 2. Validace — paralelní agenti prověří plán
/replan

# 3. Implementace — Ralph to dodá
/ralph-loop:ralph-loop "Implementuj podle plánu..."
  --max-iterations 20

# 4. Ověření — agenti porovnají výsledek s plánem
/recheck

Čtyři kroky. Plán vychází z kódu (/feature-dev), je validovaný (/replan), implementovaný (/ralph-loop) a ověřený (/recheck). Žádné slepé uličky, žádné iterace navíc, žádné “aha, tahle funkce neexistuje”.

Ale to je hodně pluginů…

Ano. Potřebujete tři pluginy: feature-dev (pro /feature-dev), superpowers (pro /writing-plans) a claude-replan (pro /replan a /recheck). Instalace:

/plugin install feature-dev
/plugin install superpowers
/plugin marketplace add kojott/claude-replan
/plugin install claude-replan

Čtyři příkazy, jednou. A pak máte workflow, který dává konzistentně lepší výsledky. Ne o 10 % lepší. Dramaticky lepší. Rozdíl mezi plánem, kde se Claude letmo podíval, a plánem, kde si dal záležet.

Shrnutí

• Shift+Tab dává rozumný plán — Claude se dívá do kódu, ale nedělá systematickou analýzu.
• /feature-dev dává důkladný plán — 7 fází průzkumu codebase před prvním řádkem kódu.
• /writing-plans přidává strukturu — edge cases, checkpointy, akceptační kritéria, rizika.
• Kombinace s /replan a /recheck — plán je validovaný před implementací a ověřený po ní.
• Na jednoduché úkoly stačí Shift+Tab. Na cokoliv netriviálního se ten upgrade vyplatí.

Příště, když stisknete Shift+Tab na větším úkolu, zastavte se. Zkuste místo toho /feature-dev. Rozdíl v kvalitě první verze vás překvapí.

— Jirka

Mohlo by tě zajímat

• Proč nikdy nečtu první plán od Claude Code
• Kognitivní dluh — nová cena za AI rychlost
• Skills vs. agenti: Kdy ti stačí recept a kdy potřebuješ kuchaře
• Workslop: kód, který nikdo nečte