Autor
Anthropic (documentația Claude Code)
4 fișe de lectură din 2 cărți · 2026.
4 fișe
Best practices for Claude Code · 2026
După două corecții ratate: /clear și un prompt mai bun, nu a treia corecție.
Cele cinci tipare. Sesiunea «chiuvetă»: sarcini fără legătură în același context, fiecare lăsând reziduuri — /clear între ele. Corecția la nesfârșit: după două corecții ratate, contextul e plin de abordări eșuate și fiecare răspuns e mai prost — /clear și un prompt nou care încorporează ce ai învățat, nu o a treia corecție. CLAUDE.md supra-specificat: reguli pe care Claude le ignoră fiindcă se pierd în zgomot — taie, sau transformă regula în hook. Încredere fără verificare: cod care «pare bine» și e greșit — teste, scripturi, capturi. Explorare infinită: «investighează» fără scop umple fereastra cu sute de fișiere — scop îngust sau un subagent care întoarce doar concluzia. Tweak-urile de productivitate din același ghid, în ordinea în care le folosești: Esc oprește fără să piardă contextul; Esc Esc sau /rewind întoarce conversația, codul sau ambele la un punct de control (fiecare prompt creează unul) și poate rezuma doar o porțiune; /compact cu instrucțiuni alege ce supraviețuiește; /btw pentru întrebări laterale care nu intră în istoric; /rename ca sesiunile să fie ramuri de lucru; /usage arată ce consumă limitele; /permissions și sandbox pentru mai puține întreruperi; o linie de stare cu consumul de context. Ghidul se încheie cu antidotul la rețete: când o sesiune a mers bine, observă ce a mers — promptul, contextul, modul — și de ce.
“O sesiune curată cu un prompt mai bun bate aproape întotdeauna o sesiune lungă cu corecții acumulate.”
What's new in Claude Code — weekly dev digest · 2026
Worktrees pentru izolare, mesaje între sesiuni pentru coordonare, rulări fără interfață pentru fan-out.
Ghidul pune scalarea după verificare, nu înaintea ei. Uneltele: worktrees git (checkout-uri izolate, editările nu se ciocnesc, EnterWorktree pornește unul din sesiune), claude -p pentru scripturi și CI (cu ieșire JSON și lista de unelte permise pentru rulări nesupravegheate), /batch care împarte o schimbare mare pe 5–30 de subagenți, fiecare cu worktree-ul și pull request-ul lui, și tiparul Writer / Reviewer în două sesiuni: un context proaspăt nu e părtinitor față de codul tocmai scris. Ce s-a schimbat între iunie și august 2026, după digestul săptămânal: Sonnet 5 (fereastră nativă de un milion de tokeni, gândire adaptivă) și Opus 5 (același milion, plus modul rapid) au devenit modelele implicite; subagenții rulează implicit în fundal, iar din august modul fork e pornit — un subagent poate moșteni toată conversația în loc să pornească gol; sesiunile își trimit mesaje și pot fi menționate cu @ după nume; auto mode a devenit modul implicit de permisiuni pe planurile plătite, cu un clasificator care blochează doar ce pare riscant; /code-review rulează ca subagent în fundal; /design (preview) desenează artboard-uri editabile; workflow-urile dinamice orchestrează zeci de agenți dintr-un script. Costul fiecărei trepte e că mută coordonarea de la tine la unelte; ce nu se mută e verificarea. Paralelismul înmulțește debitul, nu calitatea.
“Mesagerie între sesiuni: pe macOS și Linux, sesiunile tale Claude Code își pot trimite acum mesaje una alteia, așa că Claude transmite o constatare sau o decizie dintr-o sesiune în alta în loc să o explici tu din nou.”
Best practices for Claude Code · 2026
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.
“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.”
Best practices for Claude Code · 2026
Dovezi, nu afirmații: ieșirea testului, comanda rulată, captura comparată.
Ghidul numește asta cel mai important lucru pe care îl poți face pentru calitate. O verificare e orice întoarce un «trecut / picat» citibil în conversație: o suită de teste, codul de ieșire al unui build, un linter, un script care compară ieșirea cu un fixture, o captură de ecran față de un design. Există patru trepte de rigoare. Prima: în prompt («rulează testele și iterează până trec»). A doua: /goal — un evaluator separat re-verifică rezultatul după fiecare tură și împinge înapoi dacă nu e atins. A treia: un hook Stop, un script determinist care blochează încheierea turei până trece; după opt blocări consecutive Claude Code renunță, ca o verificare imposibilă să nu țină sesiunea ostatică. A patra: un subagent de verificare sau un workflow dinamic în care un alt model încearcă să infirme rezultatul. Cere dovezi, nu afirmații: ieșirea testului, comanda rulată și ce a întors, captura comparată. Ghidul o spune direct: dacă nu poți verifica, nu livra. Iar pentru revizuire, cere semnalarea doar a ceea ce afectează corectitudinea — un recenzor căruia îi ceri lacune va găsi întotdeauna lacune.
“Dă-i lui Claude o verificare pe care o poate rula: teste, un build, o captură de ecran de comparat. E diferența dintre o sesiune pe care o supraveghezi și una de la care poți pleca.”