„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.
De ce contează O tură de planificare costă puțin; o implementare pornită pe o înțelegere greșită costă toată sesiunea.