Am văzut în ultimele luni o avalanșă de „ultimate prompts" pentru Claude Code, colecții de 30 de MCP-uri obligatorii și skill-uri pe care „trebuie" să le instalezi ca să fii productiv cu AI. Am vrut să verific o ipoteză contrară, pe propriile mele date: nu ai nevoie de niciunul dintre ele. Ai nevoie să tratezi AI-ul exact cum ai trata o echipă de ingineri.
Așa că am făcut ceva ușor meta: i-am cerut lui Claude Code să-și citească propria istorie. Fiecare sesiune Claude Code e salvată local, ca JSONL, în ~/.claude/projects/. Am pus AI-ul să parseze toată luna iulie — fiecare prompt pe care i l-am scris, fiecare tool call pe care l-a făcut, fiecare eroare — și să mă evalueze. Fără menajamente.
Rezultatul: 107 sesiuni în 22 de zile lucrătoare, 599 de prompturi reale, 14.608 apeluri de tool-uri, 312 MB de transcript. Munca unui singur om — eu — pentru clientul principal al firmei, un produs e-commerce din SUA, plus proiectele interne.
Și verdictul scurt: strategia funcționează. Iată cifrele, principiile din spatele lor și — pentru că un audit care găsește doar lucruri bune nu e audit — locurile unde greșesc exact ca un manager prost.
Cifrele care contează
Din 107 sesiuni, aproximativ 95% s-au închis cu rezultatul livrat și verificat — commit, deploy, verificare pe mediul real, ticket mutat mai departe. Doar 4-5 sesiuni au fost abandonate real, majoritatea din motive banale (una pentru că am pornit-o, glorios, în proiectul greșit).
Rata de corecție — de câte ori a trebuit să spun „nu merge", „greșit", „refă" — a fost de 8% din toate mesajele de follow-up. Maximul absolut într-o singură sesiune: 4 corecții. Zero bucle de frustrare, zero sesiuni în care AI-ul „mă plimbă în cerc". Narativul acela există, dar nu în datele mele.
Și poate cifra mea preferată, pentru că nu e despre AI, ci despre viață: toată luna asta s-a întâmplat între 9:00 și 19:00, zero sesiuni în weekend, două sesiuni după ora 21:00 în toată luna. Volumul unei echipe mici, livrat de un om, într-un program de om normal.
De unde vin rezultatele astea? Nu din prompturi speciale. Din trei principii pe care orice inginer cu experiență le cunoaște deja — pentru că sunt principiile cu care lucrezi cu oameni.
Principiul 1: Un prompt bun e un ticket bun
Cea mai clară descoperire din audit e legată de lungimea și structura primului mesaj dintr-o sesiune. Distribuția e bimodală, iar diferența de rezultat e brutală:
- Prompturile sub 120 de caractere — genul „hai să investigăm și asta" — au produs sistematic 2-4 tururi de clarificare și tool calls „oarbe" în care AI-ul ghicește ce vreau.
- Prompturile de peste 700 de caractere — 19 în toată luna — au avut median un singur prompt per task închis. Scrii spec-ul, pleci, task-ul e gata.
Ce au în comun cele 19? Nicio formulă magică. Au exact structura unui ticket bine scris: fișierul și linia, comportamentul actual, o dovadă concretă (un ID de comandă, un request ID, o linie de log), comportamentul dorit și criteriul de acceptanță. Cel mai eficient task din lună — un bug de emailuri pierdute într-un handler Lambda — s-a rezolvat dintr-un singur prompt de ~900 de caractere care conținea toate cele de mai sus: un prompt, 75 de tool calls, zero corecții, fix în producție.
Invers, cel mai scump incident al lunii a pornit de la un „aici" nedefinit: am cerut o modificare „aici", AI-ul a înțeles „peste tot", a făcut update pe toate înregistrările din producție, iar peste câteva tururi am recunoscut în chat: „am înțeles eu specurile greșit". Cu un inginer uman, același ticket vag ar fi produs aceeași pagubă — doar că aș fi aflat la demo, nu în zece minute.
Distilat, regula pe care o aplic de acum e de trei linii, nu de 700 de caractere:
UNDE: fișier / pagină / URL exact — nu „aici", nu „asta"
ACUM: ce se întâmplă + o dovadă — ID, log, screenshot
VREAU: criteriul de acceptanță — cum știm că e gata
Asta nu e prompt engineering. E ceea ce un lead cere de la orice ticket de 15 ani încoace. Skill-ul există deja în industrie; trebuie doar aplicat și mașinii.
Principiul 2: Proces minimal, nu colecție de tool-uri
Stack-ul meu de „AI tooling" e jenant de scurt: terminalul, un browser controlat prin MCP-ul de Chrome și task trackerul. Atât. Nu am 15 MCP-uri instalate, nu am bibliotecă de skill-uri descărcate de pe GitHub. Am scris despre fluxul meu de lucru cu Claude Code în terminal și, în esență, nu s-a schimbat mai nimic de atunci.
Datele confirmă că nu lipsesc: 50% din toate tool call-urile din iulie sunt Bash simplu — grep, git, curl, cat. AI-ul lucrează cu aceleași unelte primitive cu care lucrează orice inginer în terminal, și e suficient.
Singurul MCP care contează cu adevărat e browserul — și nu pentru că e sofisticat, ci pentru rolul lui în proces: verificarea pe mediul real. Instrucțiunea care apare obsesiv în sesiunile mele e „verifică cu Chrome pe mediul real, nu în preview". Auditul o identifică drept motivul direct al ratei de finalizare de 95%: nimic nu se declară gata până nu e văzut funcționând acolo unde rulează de fapt.
Cu alte cuvinte: nu tool-urile îți lipsesc. Îți lipsește un „definition of done" pe care să-l aplici fără excepție.
Principiul 3: Tratează AI-ul ca pe o echipă de ingineri
Aici e miezul. Uitându-mă la propriile sesiuni, tot ce funcționează e o practică veche de management de echipă, aplicată la o „echipă" care răspunde în secunde:
Design review înainte de cod. „Fă-mi un plan de implementare și zi-mi" apare în ~20 de sesiuni din iulie. Numărul de corecții în acele sesiuni: zero. Nu e o coincidență — e același motiv pentru care nu lași un coleg nou să scrie cod într-un sistem necunoscut fără să discutați întâi abordarea.
Acces limitat până înțelegi problema. „READ-ONLY, doar analizăm, nu modificăm nimic" — folosit sistematic la investigații. Accidente în producție cauzate de sesiuni de analiză: zero.
Review înainte de orice iese public. „Dă-mi comentariul înainte să-l postezi pe ticket." Exact ce ceri unui junior înainte să răspundă clientului.
Deploy discipline. Commit → push → build → verificare pe mediul real → ticketul mutat în Verify cu un comentariu scurt. Repetat consistent în ~60 de sesiuni de tichete.
Și cea mai interesantă descoperire a auditului, cea care m-a amuzat cel mai tare: cele mai bune prompturi din iulie nu le-am scris eu. Le-a scris mașina. Când o sesiune deleagă un task către o sesiune nouă (prin spawn de task-uri în worktree-uri separate), spec-ul generat automat are median ~900 de caractere și structura completă de ticket — iar acele 12 sesiuni delegate s-au închis, toate, cu median un prompt per task. AI-ul a învățat formatul din procesul meu și îl aplică mai disciplinat decât mine. Asta nu îmi subminează teza — o confirmă: procesul e cel transferabil, nu vreun talent de „prompter".
Unde greșesc — și de ce e liniștitor
Un audit care nu găsește nimic prost e propagandă. Al meu a găsit destule, și partea cu adevărat liniștitoare e că toate greșelile mele cu AI-ul sunt greșeli clasice de management cu oameni:
Micromanagement. 31% din tururile mele au sub 3 tool calls — adică o treime din interacțiuni sunt „fă exact pasul ăsta mic". Am repetat aceeași instrucțiune de proces („când termini, commit, push, build, verifică") de peste 25 de ori într-o lună, în loc s-o scriu o singură dată în CLAUDE.md — echivalentul onboarding-ului scris o dată, nu recitat la fiecare task. Între timp, delegarea reală (agenți, task-uri spawn-ate) a fost folosită de doar 34 de ori în 107 sesiuni.
Tichete vagi. „asdta il avem?" — 14 caractere, cu typo cu tot — a generat 156 de tool calls în care AI-ul a căutat singur ce voiam să zic. A găsit, dar am plătit în timp și tokeni. Cu un om, același mesaj pe Slack ar fi produs un „la ce te referi?" și zece minute pierdute.
Ședințe-maraton. O sesiune din 13 iulie: 15 tichete diferite, 41 de prompturi, 547 de tool calls, aproape 18 MB de context. La ticketul 12, contextul primelor 11 e balast pur — auditul arată că 17% din citirile de fișiere din iulie sunt re-citiri ale aceluiași fișier în aceeași sesiune, semn direct de context umflat. Regula corectă e aceeași ca la oameni: un subiect, o întâlnire. Un tichet, o sesiune.
Verificare scumpă. 1.405 screenshot-uri de browser într-o lună — 41% din tot volumul de date al sesiunilor — dintre care majoritatea „citeau" text care putea fi extras de zece ori mai ieftin din DOM. Într-o singură sesiune: 127 de screenshot-uri. Lecția, valabilă și pentru rapoartele cerute oamenilor: cere formatul cel mai ieftin care răspunde la întrebare.
Precizare: automat rămâne, doar canalul se schimbă
După publicare am primit o întrebare bună: „recomandarea cu screenshot-urile înseamnă mai multă verificare manuală?" Nu — și merită spus explicit, pentru că e o distincție ușor de ratat.
Verificarea automată pe mediul real nu se negociază: e motivul direct al ratei de 95% și exact ce îmi permite să delegi un task și să plec. Recomandarea e doar despre canal. Un screenshot și o citire de DOM (read_page, console, network) sunt la fel de automate — diferă doar costul. Când verificarea e de fapt textuală („apare mesajul X", „requestul returnează 200"), DOM-ul răspunde la aceeași întrebare la o fracțiune din context. Screenshot-ul rămâne pentru ce se verifică cu ochiul: layout, imagini, stil.
Și partea contraintuitivă: contextul umflat e dușmanul paralelismului, nu prietenul lui. O sesiune cu 127 de screenshot-uri își umple fereastra, începe să re-citească fișiere (de acolo cele 17% re-citiri) și moare mai repede. Aceeași sesiune, cu verificare prin DOM unde se poate, trăiește mai mult și lasă loc pentru mai multe sesiuni în paralel. Verifici la fel de mult, la fel de automat — doar plătești prețul de imagine numai acolo unde imaginea chiar vede ceva.
Niciuna dintre problemele astea nu e „AI-ul halucinează" sau „AI-ul nu e capabil". Toate sunt despre cum îl conduc eu. Diferența față de o echipă de oameni e doar viteza buclei de feedback: greșelile mele de management se văd în minute, nu peste un sprint. Ceea ce, dacă stai să te gândești, e cel mai rapid curs de management pe care l-am făcut vreodată.
Ce schimb în august
Auditul s-a încheiat cu cinci acțiuni concrete, pe care le las aici pentru că sunt aplicabile oricui:
- Procesul repetat intră în CLAUDE.md, nu în prompt. O dată scris, mereu aplicat, fără variații accidentale.
- Regula celor trei linii (UNDE / ACUM / VREAU) pentru orice prompt inițial. Fără „aici", fără „asta".
- Un tichet = o sesiune. Și corolarul invers: patru task-uri mărunte înrudite sunt un singur prompt cu o listă, nu patru sesiuni.
- Repo-ul explicit în prima linie a promptului — am avut 11 sesiuni pornite din directorul greșit, una pierdută complet din cauza asta.
- Screenshot doar pentru ce se verifică cu ochiul (layout, contrast, imagini). Pentru text și structură, extragerea din pagină e de zece ori mai ieftină. Bonus de securitate: niciodată screenshot pe panouri de admin cu secrete.
Peste o lună rulez același audit pe august și vedem dacă cifrele se mișcă. Ăsta e, până la urmă, avantajul faptului că totul e logat: managementul echipei tale de AI e primul management din istorie complet măsurabil.
Ca de obicei, disclaimerul meu: cred că AI-ul e viitorul meseriei noastre și că problemele de azi — contextul care se umflă, verificarea scumpă, nevoia de supervizare — se vor rezolva. Dar starea curentă merită discutată exact așa cum e, cu date, nu cu entuziasm sau panică. Cifrele din articol vin din auditul propriilor mele sesiuni de Claude Code pe iulie 2026; metoda e descrisă în articol și o poate replica oricine are un director ~/.claude/projects/ și o oră liberă.