Ce am înțeles când Anthropic a șters 80% din regulile lui Claude Code

Când lipseam de la clasă și venea un suplinitor, îi lăsam pe catedră o listă.

Ce să facă la prima oră. Ce să nu facă sub nicio formă. Unde e creta, care copil stă lângă geam, ce se întâmplă dacă Andrei termină primul. Cu cât aveam mai puțină încredere în cel care venea, cu atât lista era mai lungă.

Exact așa arată azi fișierele de instrucțiuni pe care le scriem agenților AI.

Săptămâna asta mi-am măsurat propriul sistem: 24 de skill-uri personale, 722.000 de caractere de instrucțiuni. Două dintre ele cântăresc mai mult decât toate celelalte la un loc. Am zâmbit strâmb când am văzut cifra. Scrisesem pentru Claude aceleași liste de suplinitor pe care le lăsam în cancelarie acum douăzeci de ani.

Și apoi a venit vestea.

Pe 24 iulie, Thariq Shihipar, inginer la Anthropic, a publicat pe blogul claude.com un articol cu un titlu tehnic și un conținut care schimbă felul în care lucrăm: The new rules of context engineering for Claude 5 generation models.

Faptul spectaculos din el: Anthropic a eliminat peste 80% din system promptul lui Claude Code pentru modelele din generația Claude 5 (Opus 5, Fable 5). Fără nicio pierdere măsurabilă pe evaluările de coding.

Să traduc pentru cei care nu stau toată ziua în terminal. Când trimiți un mesaj unui agent AI, mesajul tău e doar o parte mică din ce primește modelul. Restul e „contextul": instrucțiunile de sistem, fișierele de reguli (CLAUDE.md), skill-urile, memoria. Tot ce i-ai pus în ghiozdan înainte să plece la drum.

Disciplina de a construi acest ghiozdan se numește context engineering. Și tocmai i s-au rescris regulile.

Concluzia lui Shihipar e simplă și incomodă: vechile bune practici au devenit mituri. Modelele noi au judecată proprie suficient de bună încât regulile rigide mai mult le încurcă decât le ajută. Termenul folosit în articol e „unhobbling". Scoaterea piedicilor.

Orice dascăl cunoaște momentul ăsta. Regulile scrise pentru un copil de clasa întâi devin insultătoare pentru unul de-a opta. Și, mai subtil: îl fac să lucreze mai prost, pentru că își consumă atenția împăcând regulile tale contradictorii în loc să rezolve problema.

Articolul le așază față în față, atunci și acum:

Hai să le luăm pe rând, că fiecare are o poveste.

Reguli versus judecată

Exemplul din articol e chiar o regulă veche din Claude Code: „nu scrie comentarii în cod, niciodată docstring-uri pe mai multe paragrafe". Regula era corectă pentru majoritatea cazurilor și greșită pentru restul. A fost înlocuită cu o singură frază: scrie cod care se citește ca și codul din jur, potrivește-te la densitatea de comentarii, la numire, la stil. Regula absolută a devenit principiu contextual: uită-te în jur și potrivește-te.

Exemple versus interfețe

Asta m-a durut puțin, recunosc. Ani de zile, regula de aur era: dă-i modelului exemple. Acum se dovedește că exemplele îngustează spațiul de explorare. Modelul se agață de ele și nu mai caută soluții în afara lor. Alternativa: proiectează unealta în așa fel încât structura ei să comunice comportamentul. În loc de trei exemple despre cum se folosește o listă de sarcini, definești stările posibile (în așteptare, în lucru, terminat) și o singură regulă: un singur task în lucru la un moment dat. Structura spune mai mult decât exemplul.

Progressive disclosure

Aici se demontează mitul cel mai răspândit: ideea că CLAUDE.md trebuie să fie depozitul central al tuturor practicilor, ca nu cumva modelul să nu le găsească. Nu. Recomandarea nouă e un arbore de fișiere care se încarcă la momentul potrivit. Verificarea și code review-ul, de exemplu, au fost mutate din system promptul lui Claude Code în skills pe care modelul le deschide doar când are nevoie de ele. Ghiozdanul nu se cară întreg la fiecare oră. Se ia din el ce trebuie, când trebuie. În biblioteca mea de agenți fac asta instinctiv de câteva luni, montez un agent în sistem doar când lucrez efectiv cu el. Se pare că instinctul avea nume.

Repetiția

Modelele vechi ascultau mai bine instrucțiunile de la sfârșitul contextului decât pe cele de la început, așa că scriam totul de două ori. Modelele noi nu mai au nevoie. Instrucțiunile despre o unealtă stau la unealtă, o singură dată.

Memoria

Până acum, userul își nota manual preferințele în fișiere. Acum modelul își notează singur ce contează din lucrul cu tine. Auto-memory. Fișierul de reguli rămâne pentru ce e stabil: cine ești, ce capcane are proiectul tău.

Referințele bogate

În loc de planuri simple în markdown, modelul poate lucra cu artefacte HTML, cu cod pe post de specificație (o suită de teste spune mai precis ce vrei decât o pagină de cerințe) și cu rubrici, adică criterii de gust pe care le dai unor agenți verificatori. Un mockup HTML produce rezultate mai bune decât o descriere a designului sau un screenshot. Codul e limba maternă a modelului. Vorbește-i pe limba lui.

Partea care îmi place cel mai mult: practica a luat-o înaintea teoriei. Confirmarea din teren fusese publicată cu o lună înainte de articolul Anthropic.

Jesse Vincent e autorul Superpowers, unul dintre cele mai populare framework-uri open source pentru agenți de coding, cu peste 160.000 de stele pe GitHub. În iunie, când a primit acces timpuriu la Fable, a făcut un lucru pe care îl consider cea mai frumoasă lecție de agentic engineering de până acum: a întors modelul către propriul framework.

I-a cerut lui Fable să-i optimizeze sistemul. Peste noapte, cu jurnal de ipoteze și predicții scrise înainte de fiecare test. 25 de experimente, rulate pe o suită de evaluare, nu pe impresii.

Rezultatul, publicat pe blogul lui cu tot cu date: build-uri cu până la 50% mai rapide, costuri cu până la 60% mai mici. Aceeași calitate.

Și detaliul care mă interesează cel mai tare: Jesse nu a șters disciplina. A șters balastul. Regulile ferme au rămas exact în zona în care greșeala costă scump, acolo unde framework-ul decide dacă un skill se activează sau nu. Restul a fost comprimat fără milă.

Asta e, de fapt, toată filozofia nouă într-o singură frază din articolul lui Shihipar: evită supraconstrângerea, cu excepția zonelor cu adevărat importante.

Pentru cei care își construiesc agenți personali, câteva lucruri concrete de luat acasă.

1. Deschide-ți fișierul CLAUDE.md al agentului tău și citește-l cu ochii de acum. Câte dintre reguli sunt capcane reale ale proiectului tău și câte sunt frică veche, scrisă pe vremea când modelul chiar greșea acolo? Primele rămân. Restul pleacă.
2. Skill-urile tale sunt valoroase în măsura în care conțin opiniile tale, cunoștințele tale, felul tău de a lucra. Ce poate modelul să deducă singur din context nu mai are ce căuta în ele. Skill-ul bun e un ghid subțire, nu un manual gros.
3. Păstrează regulile dure doar unde greșeala doare: bani, date personale, chei de acces, tot ce e ireversibil. Acolo nu negociem. În rest, dă-i modelului aer.
4. Claude Code are acum o comandă nouă, /doctor, care îți analizează skill-urile și fișierele CLAUDE.md și îți spune ce e de subțiat (ai nevoie de Claude Code actualizat la zi ca să o vezi). Rulează-o. E ca o vizită la medic pentru ghiozdanul agentului tău.

Și o nuanță de care țin să nu uităm, că altfel aruncăm copilul odată cu apa: totul de mai sus e valabil pentru generația Claude 5. Modelele mici și ieftine, pe care le folosim pentru sarcini mecanice, au în continuare nevoie de reguli explicite. „Mai puține reguli" nu e un adevăr universal. Depinde de capacitatea celui din fața ta. Ca la clasă.

Eu unul mi-am pus în calendar o oră de curățenie. Nu ca să am fișiere mai scurte. Ca să am un agent care gândește la problema mea, nu la contradicțiile dintre regulile mele.

Tu când i-ai șters ultima oară o regulă agentului tău?