Claude Code autonom: cum îi predai o treabă și pleci de lângă el

Claude Code autonom înseamnă să-i predai o treabă întreagă, să pleci de lângă calculator și să te întorci la un rezultat pe care îl verifici după dovezile pe care ți le arată. Altfel pierzi mult timp stând lângă el: citești planul, aprobi, scrii „continuă”.

Articolul ăsta continuă „Sfaturi Claude care au expirat”. Acolo am arătat ce sfaturi nu mai merg pe modelele de acum. Aici e partea practică: ce faci în loc, pas cu pas, pe un exemplu pe care îl poate urma oricine, raportul săptămânal pentru un client.

Primul articol nu e obligatoriu, pașii de mai jos se înțeleg și singuri. Dacă vrei totuși să-l citești, îl găsești aici: sfaturile Claude care au expirat.

De ce nu mai începi cu un plan?

Boris Cherny, creatorul Claude Code, folosea modul de plan ca să nu mai ceară de fiecare dată un plan înainte de cod. La sfârșitul lui septembrie 2026, a scris pe Hacker News că, în felul lui de lucru, „plan mode was useful, and is no longer useful.” A fost util și nu mai e.

Modul nu dispare. Într-un comentariu următor, Cherny spune că îl poți porni oricând cu /plan, iar ghidul oficial îl recomandă în continuare când drumul e nesigur sau schimbarea atinge multe fișiere. Pentru o treabă cu sarcina și limitele clare, poți sări peste aprobarea separată a planului.

Ce face Cherny în loc a explicat la Startup School, conferința Y Combinator: îi dai modelului o sarcină puțin mai grea decât crezi că poate duce și îi descrii trei lucruri.

În original: „You wanna describe the task, you wanna describe the guardrails, you wanna describe like the exit criteria” (prezentarea de la Y Combinator, capitolul de la minutul 14).

Nici cât de mult se gândește Claude nu mai trebuie reglat la fiecare mesaj. În Claude Code, dacă nu l-ai schimbat din setări, nivelul implicit de efort pe Opus 5.5, Sonnet 5.5 și Haiku 5.5 e „medium”. Documentația Claude Code spune: „In Anthropic’s testing, Opus 5.5 at `medium` matches or exceeds Opus 5 at `high` on coding and knowledge-work evaluations.”

Ce îi scrii înainte să pleci?

Trei rânduri, nu un plan. Sarcina: ce trebuie făcut și din ce. Limitele: ce nu are voie să atingă. Ce înseamnă „gata”: cum recunoști, la întoarcere, că treaba e bună. Al treilea rând e cel mai important.

Pentru raportul săptămânal, fișa sună așa. Sarcina: fă raportul pentru clientul X din exportul CRM de azi. Limitele: nu schimba șablonul și nu trimite nimic nimănui. Gata înseamnă: fiecare cifră din raport se potrivește cu exportul și nicio secțiune nu e goală.

Merge la fel pentru o ofertă. Sarcina: oferta pentru firma Y din notițele întâlnirii de ieri. Limitele: prețuri doar din lista de prețuri, fără termene promise. Gata înseamnă: fiecare preț din ofertă există în listă, iar oferta încape pe două pagini.

Observă ce lipsește: pașii. Nu-i spui în ce ordine să lucreze. Cherny descrie chiar greșeala asta în aceeași prezentare: instrucțiuni prea detaliate, de tipul „fă unu, apoi doi, apoi trei”, care la modelele de acum încurcă mai mult decât ajută.

Cum știe Claude că a terminat?

Din al treilea rând al fișei faci o verificare pe care Claude o poate rula singur. Ghidul de bune practici Claude Code pune sfatul ăsta primul și îi spune și miza: „It’s the difference between a session you watch and one you walk away from.”

Cherny a dat și o cifră, pe X, în ianuarie 2026: cu o astfel de buclă de verificare, „it will 2-3x the quality of the final result” (postarea lui Boris Cherny). E estimarea lui din experiență. Documentația Anthropic nu dă un procent.

Pentru raport, verificarea e un mic program care ia fiecare cifră din raport și o caută în export, apoi verifică dacă vreo secțiune a rămas goală. Nu trebuie să-l scrii tu. Îi ceri lui Claude să-l scrie, să-l ruleze o dată în fața ta și să-ți arate ce găsește.

Pentru un text, verificarea poate fi o listă: tonul din ghidul tău, lungimea, cuvintele interzise, fiecare cifră cu sursa ei. O verificare mecanică prinde sigur greșelile pe care le acoperă criteriile ei. Un „sună bine?” nu e verificare.

Cum îl lași să meargă până trece verificarea?

Aici intră comanda /goal din Claude Code. Îi scrii o condiție, iar Claude lucrează tură după tură, fără să-i ceri tu fiecare pas. Se oprește când condiția e îndeplinită, când arbitrul o judecă imposibilă sau la o eroare pe care trebuie s-o rezolvi tu. După fiecare tură încheiată, un alt model verifică dacă a terminat.

Documentația comenzii /goal explică de ce contează: „completion is decided by a fresh model rather than the one doing the work”. Cine a făcut munca nu-și dă singur nota. Implicit, arbitrul e un model mic și rapid, iar costul lui e de obicei neglijabil față de restul.

Un detaliu care contează când pleci: comanda nu schimbă permisiunile. În modul manual, Claude tot îți cere aprobare la unele acțiuni. Ca să meargă nesupravegheat, pornește-o în modul automat.

Arbitrul are însă o limită: „It doesn’t run commands or read files independently, so write the condition as something Claude’s own output can demonstrate.” Nu deschide fișierele tale. Vede doar conversația. Dacă scrii doar „raportul e gata”, arbitrul n-are nicio dovadă de cântărit, iar treaba se poate opri prea devreme.

Documentația recomandă patru lucruri într-o condiție: o singură stare finală măsurabilă, felul în care Claude o dovedește, ce nu are voie să se schimbe pe drum și o limită de ture, de tipul „sau te oprești după 20 de ture„.

Limita e o propoziție pe care arbitrul o judecă din conversație, nu un întrerupător mecanic, iar la reluarea sesiunii numărătoarea pornește de la zero.

Pentru raport, condiția bună sună așa: verificarea raportului trece și îmi arăți rezultatul ei; șablonul rămâne neschimbat; te oprești după 15 ture, chiar dacă nu ai terminat. Rezultatul verificării apare în conversație, deci arbitrul are ce citi.

O nuanță cinstită. În prezentarea de la Y Combinator, Cherny spune că, pe Opus 5 cu modul automat, modelul duce sarcinile lungi și fără /goal. Comanda rămâne utilă exact când pleci de lângă calculator: îi dă lui Claude o condiție clară de oprire și o limită.

Ce verifici tu la întoarcere?

Nu citești tot ce a făcut. Îi ceri, ca ultim rând în fișă, un rezumat de o pagină: ce a făcut, ce a presupus pe drum, ce n-a putut verifica. Presupunerile sunt partea cea mai utilă, fiindcă acolo apar greșelile pe care verificarea nu le prinde.

Pentru schimbări mari, cere un desen. Cherny scrie, în același comentariu, despre schimbările complexe: „I will often ask it to make diagrams or even interactive demos so I can better understand the change”. În sesiunile în care sunt disponibile, paginile vii din Claude Code pot arăta schimbările ca tablou sau cronologie.

Pe 8 octombrie, Anthropic a lansat și în aplicația Claude tablouri de bord și explicații animate, ambele în probă: tablourile pe planurile plătite, explicațiile animate doar pe Team și Enterprise. În Enterprise, amândouă sunt oprite până le pornește administratorul.

Ce lucruri nu au voie să se întâmple niciodată?

Pentru ele nu ajunge o regulă scrisă. Documentația Claude Code spune despre fișierele de instrucțiuni: „Claude treats them as context, not enforced configuration.” O regulă e o rugăminte, chiar scrisă cu majuscule.

Ce trebuie oprit sigur se face cu un hook, o verificare care rulează automat înainte de acțiune. Ghidul de bune practici: „Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens.”

În exemplul nostru, limita „nu trimite nimic nimănui” devine o pază pe uneltele prin care s-ar putea trimite un email.

Nu trebuie s-o scrii tu: îi ceri lui Claude s-o construiască, apoi încearcă un email de probă pe fiecare cale pe care o are și te uiți că paza îl oprește de fiecare dată. Pentru interdicțiile ferme, documentația recomandă și regulile de permisiuni.

Când îl lași să-și ia ajutoare?

Claude Code poate porni ajutoare, adică alți agenți care fac o parte din treabă în paralel. Ghidul Anthropic pentru Opus 5 spune: „Claude Opus 5 delegates to subagents more readily than prior models.”

Pe sarcini mici, ajutoarele înmulțesc costul și timpul. De aceea ghidul recomandă fie să spui când merită delegat, fie să pui o limită fixă: „give explicit guidance on which scenarios warrant delegation, or set deterministic caps on how many agents can be launched”.

Pentru raportul săptămânal, scrie în fișă „fără ajutoare”. Pentru o cercetare mare, de pildă zece concurenți analizați separat, ajutoarele sunt exact ce trebuie: fiecare lucrează în contextul lui și aduce înapoi un rezumat. Cere-le rezumate scurte, fiindcă rezultatele lor intră în conversația ta principală.

Cum pui treaba pe program?

După ce o treabă a mers bine de câteva ori, o poți programa. Claude Code are trei feluri de programare, și diferă exact acolo unde contează: unde rulează și ce vede.

Rutinele rulează, implicit, în cloudul Anthropic. Documentația: „A remote routine runs in the cloud even when your computer is off, and can also fire on API calls or GitHub events.”

Rutinele nu văd însă fișierele de pe calculatorul tău. Sunt în probă, pe planurile plătite, iar o programare care se repetă nu poate rula mai des de o dată pe oră.

Sarcinile programate din aplicația desktop rulează pe calculatorul tău și văd fișierele tale, dar pornesc doar dacă aplicația e deschisă și calculatorul e treaz. Există și o variantă care se repetă doar cât ai o conversație deschisă.

Pentru raportul de luni dimineață, dacă exportul CRM e pe calculatorul tău, alegi sarcina din aplicația desktop și o rulezi o dată de probă, ca să vezi ce aprobări îți cere. Dacă datele vin dintr-un serviciu online, o rutină îl poate face și cu laptopul închis.

Cu ce începi luni dimineață?

1. Alege o treabă care îți ia 30-60 de minute și se repetă săptămânal.
2. Scrie fișa în trei rânduri: sarcina, limitele, ce înseamnă gata.
3. Cere-i lui Claude să facă din „gata” o verificare și s-o ruleze o dată în fața ta.
4. Pornește treaba cu /goal în modul automat, cu verificarea ca dovadă și cu o limită de ture.
5. La întoarcere, citește rezumatul de o pagină și presupunerile. Programeaz-o abia după trei rulări bune.

Ce face robOS din toate astea?

Am construit robOS, sistemul nostru peste Claude Code, tocmai ca să nu stăm lângă el. Mare parte din pașii de mai sus vin gata făcuți. Nu toți, așa că mai jos e lista cinstită, verificată în codul pe care îl primesc cursanții.

Proiectele mai mari au o fișă cu obiectiv și criterii de acceptare, adică al treilea rând de mai sus, iar robOS îți amintește la pornire proiectele active. Verificările sunt scrise în cod: citatele exacte, structura articolelor, registrul de afirmații cu dovada fiecăreia. Citatele și structura articolului ăstuia au trecut prin ele.

robOS are și o aptitudine pentru bucla de lucru, în care un alt agent notează fiecare criteriu, cu cel mult cinci încercări din oficiu. Comenzile de ștergere pe care paza le poate citi sunt oprite în zonele importante. Majoritatea ajutoarelor au modelul și efortul fixate dinainte, iar sarcinile programate rulează singure cât timp calculatorul e pornit și robOS rulează.

Ce nu face: nu rulează cu calculatorul oprit și nu testează încă automat fiecare aptitudine cu ea și fără ea. Detalii despre robOS găsești pe robos.vip.

Modelele se schimbă repede, iar odată cu ele și felul în care merită să lucrezi cu ele. Dacă vrei să afli când un sfat de aici expiră, înainte să te coste, abonează-te la newsletter. Îți scriu doar când se schimbă ceva care te privește: