„Planificarea e cea mai utilă când nu ești sigur de abordare, când schimbarea atinge mai multe fișiere sau când nu cunoști codul modificat. Dacă poți descrie diff-ul într-o propoziție, sari peste plan.”Anthropic (documentația Claude Code) · Best practices for Claude Code · 2026 · Best practices for Claude Code (code.claude.com, 2026) — secțiunea «Explore first, then plan, then code»
Dacă poți descrie diff-ul într-o propoziție, sari peste plan; altfel, explorează și planifică întâi.
Fluxul recomandat are patru faze. Explorează: în plan mode (Shift+Tab până apare «plan mode on», sau --permission-mode plan la pornire) Claude citește și răspunde, dar nu modifică nimic — poți lăsa să investigheze fără teama unei editări premature. Planifică: cere un plan concret și, cu Ctrl+G, deschide-l în editorul tău înainte să continue. Implementează: ieși din plan mode și lasă-l să codeze verificând față de plan. Comite: mesaj descriptiv, pull request. Costul e real — planificarea adaugă o tură întreagă — de aceea regula din citat: pentru un typo, un log sau o redenumire, direct la cod. Pentru funcționalități mari, ghidul propune «interviul până la specificație»: îi ceri să te intervieveze cu întrebări până acoperiți implementarea, interfața, cazurile-limită, apoi scrie o specificație și pornești o sesiune nouă, curată, doar pentru execuție. Specificațiile utile numesc fișierele și interfețele, spun explicit ce e în afara scopului și se termină cu o verificare cap-coadă. Promptul bun e specific: fișierul, scenariul care eșuează, ce înseamnă «reparat», un exemplu de pattern existent de urmat. Referințe cu @fișier în loc de descrieri, imagini lipite în loc de «arată cam așa», URL-uri la documentație în loc de presupuneri.
Pasajul 1. Semnalul care decide dacă merită un plan nu e mărimea sarcinii, ci numărul de necunoscute. O schimbare mică într-un cod necunoscut poate ascunde mai multă incertitudine decât una mare într-un cod pe care îl stăpânești. Gandeste-te la o corectură de o linie într-un modul veche, scris de altcineva: nu știi ce altceva apelează acea funcție, deci planul te apără. În schimb, o funcție nouă de două sute de linii într-un fișier pe care îl cunoști bine poate merge direct la cod. Întrebarea practică e simplă: pot numi acum, din cap, fișierele care vor fi atinse? Dacă lista e incompletă sau ai ezitat, planifică. Dacă răspunsul vine instant și fără rezerve, sari peste tură. Următorul pas arată cum arată un plan care chiar merită scris.
Un plan care merită scris nu e o listă de pași vagi, ci o specificație care elimină necunoscutele. Ghidul propune o metodă concretă: cere-i să te intervieveze până când acoperă implementarea, interfața și cazurile-limită, apoi să scrie totul într-un document. Documentul bun numește fișierele, spune explicit ce rămâne în afara scopului și se încheie cu o verificare cap-coadă. Diferența se vede în viața de zi cu zi: «repar autentificarea» lasă loc la interpretări; «schimbă verificarea tokenului în auth.py, ignoră sesiunile vechi, testează cu login eșuat apoi reușit» nu mai lasă nimic la noroc. Apoi pornești o sesiune nouă, curată, doar pentru execuție — contextul de investigație nu poluează cel de lucru. Următorul pas e ce faci când planul există, dar realitatea codului îl contrazice pe parcurs.
De ce contează O tură de planificare costă puțin; o implementare pornită pe o înțelegere greșită costă toată sesiunea.