Claude Code. Nu un chat, un sistem de lucru.

Capabilitățile se așază pe trei niveluri, iar fiecare nivel îl presupune pe cel de dedesubt. Primul nivel e accesul brut la proiect: citește fișierele și le urmărește legăturile fără să i le lipești tu, scrie și modifică direct pe disc în mai multe fișiere din aceeași trecere, execută build, teste, git sau orice comandă din terminal și citește rezultatul.

Al doilea nivel e comportamentul de agent, adică ce face cu accesul ăla. Împarte o cerință în pași, ți-i arată înainte de execuție, apoi îi duce la capăt. Închide bucla de verificare: rulează testele, citește eroarea, repară, rulează din nou, până trece. Deleagă explorarea către un subagent cu context propriu și primește înapoi doar concluzia, nu tot ce a citit pe drum.

Al treilea nivel e sistemul din jur, cel pe care îl construiești tu. Prin MCP ajunge în baze de date, browser sau API-uri, nu doar în fișiere. Hooks rulează la momente fixe, indiferent ce decide modelul: formatare, blocaje, porți de calitate. CLAUDE.md, skill-uri și plugin-uri versionate dau întregii echipe același agent, cu aceleași reguli, nu configurația personală a fiecăruia.

Diferența dintre cineva care obține rezultate cu unealta asta și cineva care se plânge de ea stă aproape în întregime în nivelul al treilea. Nivelurile unu și doi vin din cutie.

Model Context Protocol este standardul deschis prin care Claude Code se conectează la unelte, baze de date și API-uri externe. Rezolvă o problemă foarte concretă: fără el, tot ce e în afara fișierelor ajunge în conversație prin copy-paste. Exporți un rezultat SQL, îl lipești, agentul lucrează pe o poză veche a datelor. Cu un server MCP, interoghează direct schema și datele, deschide un browser și verifică pagina reală, citește issue-uri și deschide pull request-uri, aduce documentația actuală a unei librării în loc să se bazeze pe memorie, păstrează decizii între sesiuni într-un depozit structurat.

Transporturile acceptate sunt stdio, HTTP, care e recomandat pentru servere la distanță, SSE, depreciat, și WebSocket. Scopurile sunt trei: local și user, în ~/.claude.json, și project, în .mcp.json din rădăcina proiectului. Ultimul se poate comite, iar asta e partea care contează în echipă: un server de proiect versionat dă tuturor același set de unelte, nu configurația de pe laptopul unuia.

Adăugarea se face cu claude mcp add --transport http nume url, iar claude mcp list arată starea fiecărei conexiuni. Resursele se citează cu @server:protocol://cale, iar prompturile expuse de server apar ca /mcp__server__prompt.

Eu am 12 servere configurate manual, în cele trei locuri de configurare. Unul dintre ele e nefuncțional și e marcat ca atare în documentația mea de proiect, ca să nu-l mai chem. Nu am scris niciun server MCP, sunt pachete terțe. Le-am configurat, ceea ce e o treabă diferită și merită numită corect. Aceeași conectare stă la baza lucrului meu pe agenți AI pentru automatizări de business.

Cel mai mare proiect dus cu fluxul ăsta e o aplicație web construită cu ajutorul agenților AI pentru o firmă de montaj: peste 70.000 de linii de cod în src, 506 fișiere, 74 de migrații de bază de date cu 47 de tabele, 79 de fișiere de test. Toate cele 28 de commituri sunt ale mele. Înainte de prima linie de cod au existat 26.943 de linii de documentație de proiect: plan, specificație, model de date, design, stack, anexe. Nu scriu documentația ca formalitate. O scriu fiindcă un agent care citește specificația scrisă propune altceva decât unul care ghicește.

Din specificația aia au ieșit 116 reguli de construcție numerotate, C1 la C116, iar o parte dintre ele sunt marcate ca porți și verificate automat. Sunt 24 de comenzi de verificare care pică livrarea dacă o regulă e încălcată, din cele 60 de scripturi npm ale proiectului. Regula scrisă în CLAUDE.md e context, nu constrângere. Regula transformată în poartă e constrângere. Diferența asta e tot ce contează când lucrezi cu un agent care uneori scrie cod plauzibil și greșit.

Site-ul pe care îl citești are 191 de commituri, toate ale mele, 35 de pagini, 29 de rute API și 18 tabele în spate. Tot cu fluxul ăsta am scris patru agenți Python autonomi, pentru licitații publice, prospectare și promovare. Doi dintre ei au istoric git, peste 23.000 de linii de Python. Ceilalți doi rulează local, fără versionare, deci nu îi trec la cifre verificabile. Poți vedea și proiecte livrate cu acest flux de lucru. Țin și un fișier de decizii acceptate, ca să nu reapară aceleași constatări la fiecare audit, inclusiv compromisuri asumate explicit, de tipul rate limit fail-open ca să nu pierd lead-uri dacă pică baza de date.

Pe partea de configurare a uneltei: am 137 de skill-uri instalate în ~/.claude/skills, dar hai să fim exacți, fiindcă cifra aia circulă umflată. 57 sunt symlink-uri către biblioteci ale altora, 25 vin dintr-o clonă, 38 declară explicit alt autor în fișier. Scrise de mine sunt 3, pentru fluxurile mele repetitive: carusele Instagram, execuția planului SEO pe loturi și generarea de idei de video doar din date proprii. Am scris în schimb hook-uri proprii, un strat de instrucțiuni pe patru niveluri și o unealtă care citește transcripturile de sesiune și împerechează fiecare apel de unealtă cu rezultatul lui, ca să măsoare timpul real. 847 de minute pe 30 de sesiuni. De acolo au ieșit regulile de viteză pe care le respect acum.

Lucrez cu Claude Code zi de zi, 7 din 7. Am 3.925 de transcripturi de sesiune pe disc, în 18 proiecte. Nu e o unealtă pe care am testat-o. E felul în care construiesc.

Prefer cifra verificabilă în locul celei impresionante. De asta fiecare număr de mai sus vine dintr-o comandă rulată pe disc, nu dintr-o estimare.