Agentic AI

Traseul de lectură

1. 01

   Un agent pe model de limbaj nu e un prompt mai lung, ci o buclă: percepe, decide, acționează, apoi percepe din nou rezultatul propriei acțiuni.

   Artificial Intelligence: A Modern Approach · Stuart Russell, Peter Norvig · 1995

   Definiția din manual se traduce exact în ce rulează azi: senzorii sunt contextul (mesajul utilizatorului, fișierele, rezultatele uneltelor), actuatorii sunt apelurile de unelte (caută, rulează cod, trimite un email). Bucla se închide când rezultatul uneltei intră înapoi în context și modelul alege pasul următor. Asta e diferența față de un apel de chat: un apel nu vede consecința propriei acțiuni. Autonomia se măsoară simplu — câte rotiri face bucla fără un om. Un agent e definit de uneltele lui și de regula de oprire, nu de model.

   Un agent este orice poate fi privit ca percepându-și mediul prin senzori și acționând asupra acelui mediu prin actuatori.Artificial Intelligence: A Modern Approach, ed. a 4-a (2020), cap. 2 «Intelligent Agents», §2.1 — definiția agentului

   De ce contează Cine înțelege că agentul e o buclă știe unde să pună gardurile: la fiecare rotire, nu doar la intrare.

   Pe larg →Strânge ↑

   Cardul spune unde să pui gardurile. Pasul următor e altul: cine oprește bucla când nu mai e nimeni în jur? Regula de oprire nu e o simplură de siguranță adăugată la final, ci parte din definiția agentului. Un agent fără criteriu clar de terminare nu e autonom, e doar derulant. Gândește-te la un termostat: nu întreabă pe nimeni când să se oprească din încălzit. Are o condiție, temperatura țintă, și se oprește singur. La fel, un agent care trimite emailuri are nevoie de o condiție verificabilă: mesajul a fost trimis, confirmarea a venit, bucla se închide. Fără asta, fiecare rotire adaugă risc nou, iar greșelile se compun. Întrebarea care se deschide acum: ce se întâmplă când condiția de oprire e ambiguă, iar agentul trebuie să judece singur dacă a terminat?

   Când condiția de oprire e ambiguă, agentul trebuie să judece, iar judecata se face pe percepții. Aici apare o capcană: rezultatul unei unelte nu e faptul, e doar raportul unui fapt. Un cod care rulează fără erori nu înseamnă că programul e corect. O căutare care returnează o pagină nu înseamnă că pagina e adevărată. Agentul care tratează percepțiile ca realitate închide bucla pe o iluzie, iar rotirile următoare construiesc pe ea. Gândește-te la un spălător de vase care verifică dacă farfuria e curată privind-o doar dintr-o parte. Bucla lui se închide prea devreme. Agentul bun își pune mereu întrebarea: percepția mea ar putea fi înșelătoare? Dar asta naște o altă problemă: verificarea costă timp și acțiuni, deci cine decide cât de multă verificare merită o singură rotire?

   Verificarea costă, deci agentul trebuie să cântărească. Manualul numește asta raționalitate: alegerea acțiunii care maximizează măsura de performanță, nu acțiunea perfectă. Un agent care verifică totul la nesfârșit nu e mai sigur, e paralizat. Unul care nu verifică nimic e iresponsabil. Între ele stă judecata despre cât merită o rotire. Gândește-te la cine cumpără o mașină second-hand: nu angajează un mecanic pentru fiecare șurub, dar nici nu cumpără fără un test drive. Alege două sau trei verificări cu cel mai mare câștig de încredere. La agenți, asta înseamnă să decizi din start ce rotiri sunt ieftine și reversibile, și care sunt scumpe și greu de întors. Verificarea se plasează înaintea pașilor ireversibili, nu după fiecare pas. Dar dacă un pas pare reversibil și nu e? Aceasta e întrebarea care se deschide acum.

   ▶What are AI Agents?Lecție video · IBM Technology

2. 02

   Comportamentul unui agent e în mare parte forma mediului lui: ingineria contextului bate ingineria promptului.

   The Sciences of the Artificial · Herbert A. Simon · 1969

   „Ingineria contextului” e numele din 2025–2026 pentru ce vede modelul la fiecare tură: instrucțiunile de sistem, descrierile uneltelor, documentele regăsite, memoria, traiectoria de până acum. Un model mediocru într-un mediu bine construit bate un model excelent înecat într-unul dezordonat. Pârghiile sunt concrete: descrieri de unelte scurte, cu un exemplu; regăsești doar ce e nevoie; compactezi traiectoria; pui constrângerea lângă decizie; folosești sistemul de fișiere ca memorie, nu fereastra de context. Eșecul tipic e „putrezirea contextului”: rezultate vechi de unelte care se adună până când modelul nu mai vede sarcina.

   O furnică, privită ca sistem care se comportă, este destul de simplă. Complexitatea aparentă a comportamentului ei în timp este în mare parte o reflectare a complexității mediului în care se află.The Sciences of the Artificial (1969), cap. 3 «The Psychology of Thinking» — parabola furnicii

   De ce contează Când un agent greșește, primul suspect e ce a văzut, nu ce a gândit.

   Pe larg →Strânge ↑

   Antrenarea unui model e scumpă și lentă. Construirea mediului lui e ieftină și rapidă. Aceasta e pârghia reală a anului 2026: nu alegi între modele, ci între medii. Același model poate părea prostească sau strălucit, doar schimbând ce vede. Gândește-te la un bucătar bun într-o bucătărie dezordonată: rețete pierdute, Instrumente împrăștiate, blat plin de firimituri. Mâncarea iese mediocră. Aceeași persoană, într-o bucătărie curată, cu totul la locul ei, gătește excelent. Modelul e bucătarul; contextul e bucătăria. Deci când ceva nu merge, nu întrebi întâi „ce model folosesc?”, ci „ce a văzut efectiv agentul la ultimul tur?”. Pasul următor: cum măsori ce vede de fapt un agent, nu ce crezi tu că vede.

   Pasajul 1 s-a terminat cu întrebarea: cum măsori ce vede agentul. Răspunsul simplu e să citești fereastra ca el. Adică nu te uiți la promptul tău, ci la tot ce s-a adunat în jurul lui: rezultate vechi de unelte, documente regăsite, pași deja făcuți. Fă experimentul: ia o sarcină eșuată și tipărește contextul complet. Adesea descoperi că sarcina reală e îngropată sub zeci de rezultate intermediare, ca o scrisoare importantă sub o grămadă de pliante citite. Modelul nu e distrat; e pur și simplu îngropat. Măsurat așa, „putrezirea contextului” devine un fapt vizibil, nu o senzație vagă. Dar odată ce vezi mizeria, apare întrebarea firească: ce anume merită să rămână în fereastră și ce poți arhiva în afară?

   ▶Context Engineering for AgentsLecție video · LangChain

3. 03

   Nu împacheta cunoașterea ta în reguli pe care modelul le va depăși: construiește agentul astfel încât un model mai bun să-l facă mai bun, nu să-l strice.

   The Bitter Lesson · Richard S. Sutton · 2019

   Argumentul lui Sutton: cunoașterea umană codificată de mână câștigă pe termen scurt, apoi pierde în fața căutării și învățării care scalează cu calculul. Pentru cine construiește agenți, schela groasă — liste rigide de pași, planuri fixe, parsere pentru formularea exactă a modelului — e pariul pe cunoașterea umană, și se rupe la următoarea versiune de model. Mai bine: dai modelului unelte, scopul și constrângerile, verifici ieșirile și ții schela subțire. Unde determinismul contează (conformitate, bani), îl ții în afara modelului, ca flux de lucru, nu înăuntru, ca prompt. Partea „amară”: ingineria de prompt cea mai deșteaptă are o durată de viață de o generație de modele.

   Cea mai mare lecție care se poate citi din 70 de ani de cercetare în IA este că metodele generale care valorifică puterea de calcul sunt în cele din urmă cele mai eficace, și cu o marjă mare.The Bitter Lesson (eseu, 13 martie 2019) — prima frază

   De ce contează Modelele se schimbă la 3–6 luni; un agent cu schelă groasă se rescrie de fiecare dată.

   Pe larg →Strânge ↑

   Cardul spune ce să nu faci: schelă groasă. Pasul următor e un test practic pentru ce rămâne înăuntru. Întreabă: dacă mâine modelul înțelege mai bine, regula asta îl ajută sau îl încurcă? O listă de pași rigizi îl încurcă, pentru că îi taie drumuri pe care ar fi găsit singuri. O constrângere de siguranță, în schimb, rămâne valabilă oricât de bun ar fi modelul. Gândește-te la un agent care plătește facturi: scopul și limita bugetară țin loc în orice generație de modele, dar scriptul exact de apăsare a butoanelor se strică la prima schimbare de interfață. Deci separi ce e ținta de cum o atingi. Ținta e stabilă; drumul lasă modelului libertatea să-l găsească mai bine. Următoarea întrebare: unde pui exact granița dintre libertate și control?

   Pasajul 1 a întrebat unde cade granița. Răspunsul lui Sutton e mai degrabă o direcție decât o linie fixă: pune în afara modelului tot ce trebuie să fie garantat, și lasă înăuntru tot ce poate fi îmbunătățit. Un garant nu e o instrucțiune pe care modelul o interpretează, ci un mecanism care rulează oricum. La agentul care plătește facturi, plafonul de buget nu e scris în prompt, ci verificat de cod înainte ca plata să plece. Modelul poate greși în ce zice; mecanismul nu poate greși în ce oprește. Asta schimbă felul în care scrii promptul: nu mai ceri conformitate, ci doar intenție și raționament, pentru că execuția critică e deja securizată în afară. Pe măsură ce modelele capătă mai mult raționament, tot mai mult din vechiul „cum” poate migra din schelă înăuntru. Întrebarea următoare: ce rămâne de făcut pentru om, când modelul e liber și mecanismul garantează?

   ▶Silicon Valley Doesn't Understand The Bitter Lesson — Richard SuttonLecție video · Dwarkesh Clips

4. 04

   Întâi flux de lucru cu pași ficși; agent autonom doar când pașii nu pot fi știuți dinainte.

   Building effective agents · Erik Schluntz, Barry Zhang · 2024

   Textul desparte fluxurile de lucru (model și unelte orchestrate pe căi de cod predefinite) de agenți (modelul își dirijează singur procesul). Cinci tipare de flux: lanț de prompturi, rutare, paralelizare, orchestrator–lucrători, evaluator–optimizator. Regula de decizie: dacă poți desena diagrama de flux, construiește fluxul — e mai ieftin, testabil, previzibil. Treci la agent când numărul de pași e necunoscut și sarcina cere judecata modelului la fiecare pas (programare deschisă, cercetare). Prețul agentului: latență, cost, erori care se compun. Pornește de la cel mai simplu lucru care merge și adaugă autonomie doar când evaluările măsurate spun că fluxul nu ajunge.

   În mod constant, cele mai reușite implementări folosesc tipare simple, compozabile, mai degrabă decât framework-uri complexe.Building effective agents (Anthropic, 19 decembrie 2024) — introducere

   De ce contează Majoritatea „agenților” din producție sunt fluxuri de lucru bine numite; sunt și cele care nu cad.

   Pe larg →Strânge ↑

   Diagrama de flux e mai mult decât un test de eligibilitate: e un angajament de proiectare. Când o poți desena, fiecare decizie a sistemului devine un punct pe hârtie, deci un punct pe care poți pune un semn de verificare. Asta schimbă modul în care depanezi. Dacă un rezultat e greșit, nu întrebi "ce a gândit modelul?", ci "în care cutie a intrat greșit?". Gândește-te la un formular de retur într-un magazin online: dacă produsul e defect mergi pe calea A, dacă doar nu ți-a plăcut pe calea B. Când ceva ratează, știi exact ce ramură să repari. Cu un agent autonom, greșeala poate apărea oriunde într-un lanț pe care nu l-ai desenat niciodată. Deci întrebarea următoare nu e "cât de inteligent e modelul?", ci "îmi pot permite să pierd vizibilitatea asupra deciziilor?".

   Pasajul 2: Există o altă graniță, mai subtilă, între flux și agent: costul erorilor. Într-un flux, o eroare se oprește acolo unde e detectată și poate fi reparată local. La un agent, pașii se sprijină unii pe alții, așa că o mică greșeală devreme poate crește la fiecare pas. Imaginează-ți gătitul după o rețetă fixă: dacă pui prea puțină sare, corectezi la pasul următor. Dar dacă improvizezi fără rețetă și te înșeli devreme, fiecare decizie de după construiește pe fundația greșită. De aceea autonomia nu e doar mai scumpă în bani, ci și în fiabilitate. Întrebarea practică devine: cât de repede îmi dau seama, în sistemul meu, că primul pas a fost greșit?

   ▶Building more effective AI agentsLecție video · Anthropic

5. 05

   Bucla gând–acțiune–observație e forma de bază a oricărui agent modern: modelul raționează, cheamă o unealtă, citește rezultatul, apoi gândește iar.

   ReAct: Synergizing Reasoning and Acting in Language Models · Shunyu Yao et al. · 2022

   ReAct întrețese Gând / Acțiune / Observație. Azi e bucla nativă de unelte a oricărui API: modelul emite un apel de unealtă, runtime-ul îl execută, adaugă rezultatul, modelul continuă. Ce a măsurat lucrarea: mai puține halucinații decât lanțul de gândire singur, fiindcă faptele vin din mediu, nu din memorie. Consecințe de inginerie: observația e locul pe unde intră conținutul neverificat (lecția 17); plafonezi numărul de iterații; fiecare unealtă e idempotentă sau confirmabilă; jurnalizezi fiecare triplet ca să-l poți rejuca. Variante: Reflexion (autocritică între episoade), plan-și-execută (planifici o dată, apoi acționezi).

   În această lucrare explorăm folosirea LLM-urilor pentru a genera atât urme de raționament, cât și acțiuni specifice sarcinii, într-o manieră întrețesută, permițând o sinergie mai mare între cele două: urmele de raționament ajută modelul să inducă, să urmărească și să actualizeze planuri de acțiune și să trateze excepțiile, în timp ce acțiunile îi permit să interacționeze cu surse externe, cum ar fi baze de cunoștințe sau medii, pentru a aduna informații suplimentare.ReAct: Synergizing Reasoning and Acting in Language Models (arXiv 2210.03629, octombrie 2022) — rezumat

   De ce contează Orice agent pe care îl depanezi are aceeași buclă; când o știi, știi unde să te uiți în jurnal.

   Pe larg →Strânge ↑

   Bucla gând-acțiune-observație schimbă ce înseamnă o greșeală a modelului. Când faptele vin din mediu, eroarea nu mai e doar în textul generat, ci în momentul alegerii uneltei sau în interpretarea rezultatului. Asta face depanarea mai concretă: poți privi fiecare triplet și întreba unde s-a rupt lanțul. De exemplu, un agent care rezervă o masă greșită poate fi urmărit pas cu pas: a gândit bine, dar a citit ora dintr-un răspuns ambiguu al uneltei. Așa bug-ul devine un punct localizabil, nu o nebuloasă de text. Rămâne însă o întrebare: ce se întâmplă când observația însăși e mincinoasă sau incompletă?

   Observația e poarta slabă a buclei. Modelul nu poate ști dacă rezultatul uneltei e adevărat; îl tratează ca fapt, exact ca pe propriile gânduri. Dacă o unealtă răspunde cu date vechi, parțiale sau generate de alt model, halucinația nu dispare — doar se mută în mediu. De exemplu, un agent care verifică disponibilitatea unui produs primește un răspuns de API învechit și spune cu încredere că produsul e pe stoc. De aceea observațiile merită același control ca textul generat: sursă, moment, semnătură. Dar dacă observația poate fi suspectă, apare o întrebare: modelul ar trebui să-și verifice propriile concluzii între runde?

   ▶Research Paper: AI Agents and the ReAct PatternLecție video · Gaurav Sen

6. 06

   Sistemele multi-agent merită când sarcina se descompune în roluri cu context diferit, nu pentru că mai mulți agenți sună mai inteligent.

   The Society of Mind · Marvin Minsky · 1986

   Modelul lui Minsky: inteligența vine din mulți agenți simpli, specializați. Citirea modernă e orchestrator–lucrători, unde fiecare lucrător are propria fereastră de context și propriile unelte (cercetător, programator, revizor). Când merită: subsarcini paralelizabile; contexte care altfel s-ar umple; separarea privilegiilor (agentul care citește emailul nu poate trimite bani). Când nu: sarcini secvențiale cu stare comună, unde predările pierd informație și costul se înmulțește, fiindcă fiecare lucrător recitește. Regula: numărul de agenți urmează numărul de contexte distincte, nu organigrama. Cererile de informații despre sisteme multi-agent au crescut cu 1 445% între T1 2024 și T2 2025 (Gartner) — un semnal de entuziasm, nu de merit.

   Ce truc magic ne face inteligenți? Trucul este că nu există niciun truc. Puterea inteligenței vine din imensa noastră diversitate, nu dintr-un singur principiu perfect.The Society of Mind (1986), §30.8

   De ce contează Un al doilea agent costă un al doilea context; trebuie să cumpere ceva ce primul nu putea face.

   Pe larg →Strânge ↑

   Minsky ne îndeamnă să privim agenții ca pe niște specialiști cu unghiuri diferite asupra aceleiași probleme. Pasul următor: diversitatea lor are sens doar dacă predarea dintre ei păstrează ceva. Când un agent termină lucrarea și o dă mai departe, el trebuie să decidă ce merită dus mai departe. E ca la spital: medicul de urgență nu-i transmite chirurgului toată conversația cu pacientul, ci un rezumat gândit pentru decizia chirurgului. Dacă rezumatul e slab, chirurgul refăcă întrebările de la zero, iar costul se dublează. Deci designul real al unui sistem multi-agent nu e lista rolurilor, ci contractul dintre ele: ce intră, ce iese, ce se pierde voit. Întrebarea care deschide pasul următor: cum arată un contract bun de predare între doi agenți?

   Un contract bun de predare are trei piese: ce a încercat agentul, ce a aflat, ce a rămas nerezolvat. Fără cea de-a treia, următorul agent refăce drumuri moarte. Exemplu: un coleg îți trimite un raport despre un apartament, dar uită să scrie că proprietarul a refuzat negocierea; tu suni din nou și pierzi o oră. Scrisoarea de predare trebuie să conțină și eșecurile, nu doar rezultatele. Dar o predare bogată are un cost: umple contextul următorului agent mai repede. Cum alegi atunci ce merită dus mai departe și ce se lasă deoparte?

   Alegerea ce duci mai departe e o decizie de arhitectură, nu de politețe. Criteriul util: du mai departe informația care schimbă decizia următorului agent, nu informația care doar explică drumul tău. Un agent nu are nevoie să știe de ce ai căutat, ci ce ar face altfel pe baza a ceea ce ai găsit. Exemplu: la notar, nu-i povestești toată discuția cu vânzătorul; îi spui doar că apartamentul are o ipotecă, pentru că asta îi schimbă lui verificările. Restul e zgomot care costă context. Asta înseamnă că predarea se scrie invers: pleci de la ce are nevoie următorul agent și lucrezi înapoi, nu de la ce ai tu în cap. Dar dacă fiecare agent își scrie propriile predări, calitatea lor variază. Merită odată întrebarea: cine ar trebui să scrie de fapt contractul dintre agenți?

   Răspunsul la cine scrie contractul: orchestratorul, nu agenții înșiși. Dacă fiecare lucrător își rezumă singur predarea, calitatea variază cu entuziasmul lui. Orchestratorul cunoaște ambele părți: ce are nevoie următorul agent și ce context are la dispoziție. E ca un manager care nu-i cere tehnicianului să scrie singur raportul pentru avocat, ci definește el șablonul: ce secțiuni, ce lungime, ce e interzis. Asta mută designul din comportamentul agenților în structura sistemului, unde poate fi verificat și reparat. Contractul devine o piesă de arhitectură, nu o manie a fiecărui agent. Rămâne însă o întrebare: ce faci când contractul e bun, dar agentul următor tot ratează?

   Când contractul e bun, dar agentul ratează oricum, greșeala nu e a agentului, ci a tăieturii. Un rol care primește tot ce are nevoie și tot greșește înseamnă că sarcina nu se desparte acolo unde ai tăiat-o. Remediul nu e un prompt mai dur, ci o refăcută a limitelor: fie unești două roluri, fie tai contextul altfel. Exemplu: dacă traducătorul tot greșește termenii juridici, nu-l cești, ci dai juristului rolul de a fixa glosarul înainte. Fiecare ratare repetată e un semnal despre arhitectură, nu despre voință. Iar dacă nici restructurarea nu ajută, rămâne întrebarea: când recunoști că sarcina pur și simplu nu merită mai mulți agenți?

   ▶Multi AI Agent Systems: When One AI Brain Isn't EnoughLecție video · IBM Technology

7. 07

   O unealtă bună pentru un agent are o interfață îngustă la ieșire și tolerantă la intrare; MCP standardizează exact acest contract.

   RFC 793 — Transmission Control Protocol · Jon Postel · 1981

   O unealtă e un nume, o descriere de un paragraf și o schemă tipizată. Apelul modelului e partea „liberală”: validezi, corectezi, întorci o eroare pe care modelul o poate repara. Ieșirea uneltei e partea „conservatoare”: compactă, structurată, fără surprize, trunchiată cu o notă. MCP (Model Context Protocol) e standardul deschis pentru unelte, resurse și prompturi între un client (agentul) și servere; donat de Anthropic fundației Agentic AI Foundation de sub Linux Foundation pe 9 decembrie 2025, cu peste 10 000 de servere publice și, într-un sondaj din 2026 (Stacklok), 41% din organizații cu MCP în producție. Dar legea lui Postel are o parte întunecată cunoscută: acceptarea liberală e exact ușa pe care intră injecția — ieșirea uneltei se tratează ca date, nu ca instrucțiuni (lecția 17).

   Implementările TCP vor urma un principiu general de robustețe: fii conservator în ceea ce faci, fii liberal în ceea ce accepți de la alții.RFC 793 — Transmission Control Protocol (septembrie 1981), §2.10 «Robustness Principle»

   De ce contează Un agent e la fel de bun ca cea mai proastă descriere de unealtă din contextul lui.

   Pe larg →Strânge ↑

   Cardul spune ce e un contract bun pentru unelte. Pasul următor: de ce simetria asta e o economie, nu doar igienă. Când ieșirea unei unelte e îngustă și previzibilă, modelul nu pierde atenție descifrând-o. Fiecare surpriză în ieșire — un câmp lipsă, un text lung nepedepsit — consumă din fereastra de context și din atenția agentului. Gândește-te la o unealtă de calendar care răspunde cu tot istoricul evenimentelor când ai întrebat doar de mâine. Un răspuns compact, cu o notă scurtă dacă a trunchiat, lasă loc pentru pasul următor al raționamentului. Partea liberală de la intrare rămâne ieftină tocmai pentru că ieșirea plătește nota. Dar dacă datele primite pot conține instrucțiuni deghizate, toleranța devine o suprafață de atac. Cum arată exact o eroare pe care modelul o poate repara singur?

   ▶How Model Context Protocol (MCP) actually worksLecție video · Google Cloud Tech

8. 08

   Topologia agenților tăi va copia organigrama; A2A e protocolul care face granițele dintre agenți explicite, ca să le poți alege tu.

   How Do Committees Invent? · Melvin E. Conway · 1968

   A2A (Agent2Agent) a fost anunțat de Google pe 9 aprilie 2025 și donat Linux Foundation pe 23 iunie 2025; are peste 100 de organizații susținătoare. Vocabularul: un „card” al agentului (ce știe să facă), sarcini cu stări, mesaje. MCP e vertical, agent–unealtă; A2A e orizontal, agent–agent. Avertismentul lui Conway: dacă echipele dețin agenți, agenții vor vorbi așa cum vorbesc echipele — inclusiv deloc. Granițele se aleg după cine deține datele și cine deține privilegiile, nu după departament. Practic: un agent per context delimitat; un card public cu ce face; stări de sarcină cu audit; fără memorie mutabilă partajată între agenți.

   Organizațiile care proiectează sisteme (în sensul larg folosit aici) sunt constrânse să producă proiecte care sunt copii ale structurilor de comunicare ale acestor organizații.How Do Committees Invent? (Datamation, aprilie 1968) — teza articolului, cunoscută drept «legea lui Conway»

   De ce contează Înainte să alegi protocolul, alege granițele; protocolul doar le fixează.

   Pe larg →Strânge ↑

   Conway spunea că sistemul copiază liniile de comunicare ale echipei. Astăzi, cu agenți software, copierea devine automată: doi agenți construiți de echipe care nu vorbesc între ele nu vor găsi niciodată calea de a coopera. A2A nu rezolvă asta prin magie, ci prin expunere: fiecare agent își publică un card cu ce știe să facă, iar sarcinile trec prin stări verificabile. Gândește-te la contabilitate și la resurse umane: dacă agentul de salarii nu poate vedea cardul agentului de contracte, delimitarea e vizibilă și poate fi discutată, nu presupusă. Deci granița devine un artefact pe care îl poți revizui, nu un accident. Următorul pas: cine ar trebui să dețină efectiv fiecare graniță.

   ▶Introduction to Agent2Agent (A2A) ProtocolLecție video · Google Cloud Tech

9. 09

   Alege framework-ul după ce ai un agent simplu care merge; framework-ul trebuie să-ți lase buclele vizibile, nu să le ascundă.

   Systemantics: How Systems Work and Especially How They Fail · John Gall · 1975

   Peisajul open-source din 2026, ca exemple: orchestratoare pe graf cu stare și puncte de reluare (LangGraph), agenți cu intrări și ieșiri tipizate (PydanticAI), echipe pe roluri (CrewAI), agenți care scriu cod în loc să cheme unelte (smolagents), SDK-urile laboratoarelor de modele (OpenAI Agents SDK, Google ADK, Microsoft Agent Framework — fuziunea AutoGen cu Semantic Kernel din toamna lui 2025 — Claude Agent SDK). Criteriile: vezi fiecare apel de model și de unealtă? poți opri, relua, rejuca? te leagă de un singur furnizor de model? cât context adaugă singur? Pornește de la bucla brută peste API (o sută de linii); adoptă un framework când ai nevoie de stare durabilă, pauze pentru om sau rutare multi-agent. Ferește-te de „magia” care ascunde prompturi pe care va trebui să le depanezi.

   Un sistem complex care funcționează se dovedește invariabil a fi evoluat dintr-un sistem simplu care funcționa.Systemantics: How Systems Work and Especially How They Fail (1975) — «legea lui Gall»

   De ce contează Framework-ul greșit se vede în a treia lună, când nu poți explica de ce a făcut agentul ce a făcut.

   Pe larg →Strânge ↑

   Cardul spune: alege framework-ul târziu. Pasul următor e că bucla simplă de la care pornești devine instrumentul cu care judeci framework-ul. Când ai rulat manual o sută de linii, știi deja ce face agentul la fiecare pas. Apariția framework-ului devine o comparație: ce îmi adaugă în plus față de bucla mea? Dacă răspunsul e doar confort, nu e nevoie. Dacă îți dă stare care supraviețuiește repornirilor sau pauze pentru un om, atunci are rost. E ca atunci când gătești o dată o rețetă de la zero înainte să cumperi un aparat de bucătărie: abia atunci știi ce pas vrei să automatizezi. Fără bucla scrisă de tine, framework-ul îți dictează el ce e important. Următoarea întrebare: ce anume din bucla ta merită păstrat vizibil când migrezi?

   Pasajul 1 s-a oprit la întrebarea: ce păstrezi vizibil când migrezi? Răspunsul lui Gall e dureros de clar: un sistem care îți ascunde propriile pași nu e un sistem, e o cutie neagră care eșuează târziu și inexplicabil. Deci criteriul real de alegere nu e lista de funcții, ci transparența. Framework-ul bun îți arată fiecare apel de model și de unealtă, exact ca bucla ta de o sută de linii. Cel rău îți spune „nu te îngrijora, noi știm ce facem” și îngroapă prompturile în adâncime. E ca diferența dintre un tablou de bord și un capac închis la capota mașinii: primul te avertizează înainte de defect, al doilea abia după ce ai rămas pe drum. Când compari framework-uri, pune mâna pe codul generat și întreabă: aș putea depana asta la trei dimineața? Dacă nu, nu e al taurui. Dar vizibilitatea are și un preț pe care îl plătești tu — și despre el e vorba în continuare.

   ▶Best AI Agent Frameworks for 2026: LangGraph vs CrewAI vs AutoGenLecție video · Intellipaat

10. 10

    Un server de unelte e cod pe care agentul îl execută cu privilegiile tale, iar descrierea lui e un prompt pe care nu l-ai citit.

    Reflections on Trusting Trust · Ken Thompson · 1984

    „Otrăvirea uneltelor”: instrucțiuni ascunse în descrierea unei unelte, vizibile modelului, nu utilizatorului; „rug-pull”: unealta se redefinește după ce a fost aprobată; „umbrirea”: o unealtă deturnează apelurile alteia. Vulnerabilități cu nume din 2025: CVE-2025-54135 (CurXecute, scor 8,6) și CVE-2025-54136 (MCPoison) într-un editor de cod popular; în noiembrie 2025, un server MCP otrăvit pentru mesagerie redirecționa datele către numărul atacatorului. Un raport din 2026 a găsit 43% din serverele MCP testate vulnerabile la injecție de comenzi. OWASP Top 10 pentru aplicații agentice listează lanțul de aprovizionare al uneltelor ca risc propriu. Controale: versiuni fixate cu hash; descrierile se revizuiesc ca orice cod; listă albă per agent; servere în containere, fără rețea implicit; diff pe descriere la fiecare actualizare; un gateway care jurnalizează fiecare apel.

    Morala e evidentă. Nu poți avea încredere în cod pe care nu l-ai creat în întregime tu însuți. (Mai ales în codul de la companii care angajează oameni ca mine.)Reflections on Trusting Trust, Communications of the ACM 27(8), august 1984 — discursul de acceptare a premiului Turing

    De ce contează Piețele de unelte au crescut mai repede decât obiceiul de a le citi.

    Pe larg →Strânge ↑

    Thompson nu a atacat un program, ci încrederea în lanțul care l-a produs. Ai încredere în unelta ta pentru că a compilat codul tău corect până acum. Dar acea unealtă a fost construită cu o altă unealtă, făcută de altcineva. Fiecare verigă poate ascunde ceva ce nu vezi niciodată. Astăzi veriga e serverul de unelte al agentului tău. El rulează cu permisiunile tale și îi trimiți sarcini în limbaj natural, fără să-i fi citit vreodată descrierea completă. E ca și cum ai angaja un asistent pe baza unui CV scris de el însuși, pe care nu l-ai deschis. Întrebarea următoare e simplă: cine a scris de fapt acel CV?

    Pasajul 1 a întrebat cine a scris CV-ul. Pasajul 2 arată că CV-ul se poate rescrie singur, fără să afli. Thompson a arătat că o unealtă compromisă își reproduce otrava în fiecare versiune nouă, care pare curată. La agenți, același mecanism are un nume nou: unealta e aprobată o dată, apoi descrierea ei se schimbă liniștit la o actualizare. Permisiunea veche rămâne, instrucțiunile noi nu le vezi. Exemplu obișnuit: îți dai cheia casei unui instalator verificat, iar luna următoare firma îi schimbă colegul, cu aceeași uniformă. Nimeni nu te sună să confirmi. De aceea descrierea unei unelte trebuie tratată ca un contract care se recitește la fiecare semnătură nouă. Dar cum recitești ceva ce modelul citește în fracțiuni de secundă?

    ▶MCP Tool poisoning demo. Are you sure your MCP servers are not malicious?Lecție video · Martin Voelk

11. 11

    Nu plăti raționament pentru ce se poate face fără să gândești: rutează apelurile ieftine la modele ieftine și lasă modelul de raționament pentru deciziile grele.

    An Introduction to Mathematics · Alfred North Whitehead · 1911

    Arhitectura de cost a unui agent: nivelare (un model ieftin implicit, escaladare la încredere scăzută sau sarcină grea); rutarea raportează în 2026 circa 95% din calitatea modelului de frontieră trimițând doar 14–26% din apeluri la modelul scump, adică 75–85% economie pe traficul rutat; cache-ul de prompt taie prețul intrărilor repetate cu până la ~90%; loturile pentru ce nu e urgent; plafoane pe efortul de raționament. Ordinea măsurilor: întâi nivelare statică, cache, plafoane de efort și loturi (50–70% economie tipică), abia apoi un router învățat. Capcana: modul de eșec al modelului ieftin e greșeala încrezătoare — fiecare nivel are nevoie de evaluarea lui (lecția 15).

    Este un truism profund eronat, repetat de toate caietele de caligrafie și de oamenii eminenți când țin discursuri, că ar trebui să cultivăm obiceiul de a ne gândi la ceea ce facem. Tocmai contrariul este adevărat. Civilizația avansează prin extinderea numărului de operații importante pe care le putem efectua fără să ne gândim la ele.An Introduction to Mathematics (1911), cap. 5 «The Symbolism of Mathematics»

    De ce contează Factura unui agent e o distribuție de apeluri; majoritatea nu merită modelul cel mai scump.

    Pe larg →Strânge ↑

    Whitehead întoarce pe dos o idee primită: gândirea nu e o virtute de cultivat oriunde, ci o resursă rară. Progresul vine atunci când mutăm sarcini din coloana „gândesc" în coloana „fac automat". La un agent, fiecare apel la un model scump consumă din aceeași resursă: bani și atenție. Dacă rutinele, formulările repetate și sarcinile simple merg pe modelul ieftin, gândirea reală rămâne liberă pentru ce contează. Exemplu: nu calculezi cu atenție cât costă pâinea, dar analizezi cu grijă contractul de închiriere. Întrebarea practică e alta: cum decizi, apel cu apel, ce merită gândire scumpă?

    ▶What is Model Routing?Lecție video · Standarity

12. 12

    Într-un agent, majoritatea apelurilor sunt înguste și repetitive; un model mic specializat le face mai ieftin, mai rapid și adesea la fel de bine.

    Small Language Models are the Future of Agentic AI · Peter Belcak et al. (NVIDIA Research) · 2025

    Argumentul lucrării: sarcinile unui agent sunt înguste, formatate, repetitive — exact ce se potrivește unui model sub 10 miliarde de parametri. Sistemul devine eterogen: un model de frontieră planifică, modele mici lucrează. Procedura propusă: jurnalizezi apelurile, le grupezi pe tipuri de sarcină, antrenezi un model mic per grup și îl pui în locul apelului mare. Tiparul din 2026 — planificator mare, lucrători mici, fine-tunați — e raportat la un cost de circa zece ori mai mic. Familiile cu ponderi deschise (Qwen, Gemma, Mistral, gpt-oss și altele) rulează pe o singură placă sau on-prem. Prețul: evaluările și servirea sunt ale tale. Unde pică modelele mici: raționament deschis, context lung, cazuri rare — acolo escaladezi.

    Aici expunem poziția că modelele mici de limbaj (SLM) sunt suficient de puternice, inerent mai potrivite și în mod necesar mai economice pentru multe apeluri din sistemele agentice și sunt, prin urmare, viitorul IA agentice.Small Language Models are the Future of Agentic AI (arXiv 2506.02153, iunie 2025) — rezumat

    De ce contează Cel mai ieftin token e cel pe care nu-l trimiți la un model de frontieră.

    Pe larg →Strânge ↑

    Cardul spune ce: modele mici pentru apeluri repetitive. Pasul următor e de ce funcționează: un agent nu gândește la fiecare pas. El formatează, extrage, verifică — acțiuni cu formă fixă. Gândește-te la un contabil care nu cere partenerului să citească fiecare factură; o înregistrează el, iar partenerul vede doar cazurile ciudate. Același agent poate avea mai mulți „angajați" mici, fiecare antrenat pe un singur tip de apel din jurnalul său. Specializarea nu e o compromisare, ci potrivirea între formă sarcinii și formă modelului. Întrebarea care urmează: ce anume dintr-un apel îl face potrivit pentru un model mic?

    Pasajul 1 s-a întrebat ce face un apel potrivit pentru un model mic. Răspunsul: apelul are o formă fixă și un rezultat verificabil. Dacă poți spune dinainte cum arată răspunsul corect — un tabel, o etichetă, un câmp extras — modelul mic poate fi antrenat să-l producă la cerere. Raționamentul deschis nu are o formă fixă, deci rămâne la modelul mare. Gândește-te la un recepționer care confirmă programări: fiecare răspuns e la fel, doar numele se schimbă. Un avocat care decide strategia procesului nu are această formă, deci nu poate fi înlocuit cu un începător antrenat pe cazuri repetitive. Deci granița nu e mărimea modelului, ci forma sarcinii. Întrebarea următoare: cum îți dai seama, din practică, care apeluri sunt de o parte și care de alta?

    Pasajele anterioare au stabilit granița; acum vine metoda practică: jurnalul tău de apeluri e harta. Nu ghicești din start ce poate un model mic — observi. Înregistrezi ce trimite agentul, apoi grupezi apelurile după tip: extragere de date, verificare de format, clasificare. Fiecare grup devine un candidat la specializare. E ca un restaurant care notează vânzările o lună și descoperă că 80% din clienți comandă același fel; atunci îl pregătește în avans, ieftin și repede, și lasă bucătarul șef pentru restul meniului. Procedura inversă — antrenat înainte de a măsura — risipește efort pe apeluri care apar o singură dată. Jurnalul transformă decizia din intuiție în aritmetică: câte apeluri, ce formă, cât câștig. Dar odată ce ai grupat apelurile, apare întrebarea firească: cum antrenezi efectiv modelul mic pe un grup, și ce faci când greșește?

    Pasajele anterioare au arătat cum antrenezi modelul mic pe un grup de apeluri. Acum vine partea pe care nimeni nu o pune în reclame: odată ce l-ai pus în producție, evaluarea și servirea devin treaba ta. Modelul mare era o cutie închisă, cu calitate constantă, plătită per apel. Modelul mic rulează la tine, pe o placă sau pe serverul propriu, deci calitatea lui depinde de verificările tale. E ca și cum ai muta gătitul din restaurant în bucătăria casei: mai ieftin, dar tu speli vasele și tu guști mâncarea. Practic, asta înseamnă un set de teste per grup de apeluri, rulat la fiecare actualizare, plus o cale de escaladare spre modelul mare când modelul mic ezită sau produce un răspuns fără formă fixă. Costul real nu e zero; e mutat din factură în responsabilitate. Iar asta deschide întrebarea următoare: ce câștigi de fapt la capăt, dincolo de economie?

    Pasajele anterioare s-au oprit la economie. Dar câștigul real e altul: controlul devine arhitectură. Când fiecare grup de apeluri are propriul model, sistemul tău devine o colecție de piese înlocuibile. Un model mic care greșește la un tip de sarcină se înlocuiește singur, fără să atingi restul agentului. E ca o flotă de mașini de firmă: schimbi una defectă, restul flotei continuă livrările. La modelul mare unic, orice îmbunătățire sau regresie vine de la furnizor, peste noapte, fără acordul tău. Cu modele mici, tu decizi când și ce se schimbă. Apare însă o limită structurală: cu cât ai mai multe modele mici, cu atât mai multe grupuri trebuie monitorizate, testate și actualizate. Specializarea se plătește în complexitate operațională. Rămâne de văzut unde se oprește raționamentul: ce rămâne, de fapt, al modelului de frontieră?

    Pasajele anterioare au arătat ce rămâne al modelului mare: raționament deschis, context lung, cazuri rare. Pasul următor e să tratezi escaladarea ca piesă de design, nu ca soluție de urgență. Agentul decide din start ce apel merită drumul scump, pe baza acelorași jurnale care i-au născut modelele mici. Modelul de frontieră nu mai e creierul sistemului, ci specialistul consultat rar. E ca un spital: majoritatea cazurilor le rezolvă asistenții și medicii de familie, iar profesorul universitar e chemat doar la cazul neclar. Economia se schimbă la nivel de sistem, nu de apel: fiecare apel deviază spre cel mai mic model care poate rezolva sarcina, iar modelul mare plătește doar diferența. Asta mută întrebarea finală: dacă rolul modelului mare se subțiază atât, ce sens mai are a-l plăti abonat permanent?

    ▶NVIDIA SLM Agents: Why Small Language Models Are the Future of Agentic AILecție video · Michel Laclé

13. 13

    LoRA antrenează doar niște matrice mici pe lângă modelul înghețat: de aceea costă o placă video și câteva ore, nu un cluster.

    LoRA: Low-Rank Adaptation of Large Language Models · Edward J. Hu et al. · 2021

    Mecanismul: schimbarea ponderilor se aproximează ca produsul a două matrice de rang mic, r mult mai mic decât dimensiunea stratului. În lucrare: de 10 000 de ori mai puțini parametri antrenabili și de 3 ori mai puțină memorie GPU față de fine-tuning-ul complet al unui model de 175 de miliarde. Un adaptor e un fișier mic, interschimbabil per sarcină pe același model de bază; QLoRA adaugă baza cuantizată pe 4 biți. În 2026, un model de 7–8 miliarde se adaptează în ore pe o singură placă, de la câțiva dolari pentru un adaptor mic la câteva mii pentru seturi mari. Ce schimbă: comportament, format, stil, disciplina apelurilor de unelte. Ce nu schimbă: nu adaugă cunoștințe noi în volum — acela e RAG. Servirea mai multor adaptoare pe aceeași bază face specializarea per client sau per sarcină ieftină.

    Propunem adaptarea de rang scăzut, sau LoRA, care îngheață ponderile modelului pre-antrenat și injectează matrice antrenabile de descompunere de rang în fiecare strat al arhitecturii Transformer, reducând considerabil numărul de parametri antrenabili pentru sarcinile din aval.LoRA: Low-Rank Adaptation of Large Language Models (arXiv 2106.09685, iunie 2021) — rezumat

    De ce contează Fine-tuning-ul a devenit destul de ieftin ca întrebarea să nu mai fie „putem?”, ci „merită?”.

    Pe larg →Strânge ↑

    Cardul spune că LoRA e ieftin. Pasul următor e de ce funcționează deloc. Intuiția: când un model învață o sarcină nouă, nu trebuie să-i rearanjezi toate miliardele de conexiuni. Schimbarea utilă trăiește în câteva direcții dominante, ca o melodie care se scrie cu câteva note, nu cu toate clapele odată. De aceea o matrice mică, descompusă în două bucăți subțiri, prinde aproape tot ce contează. Exemplu: vrei ca asistentul firmei să răspundă mereu în formatul rapoartelor voastre interne. Nu-i o schimbare de enciclopedie, ci una de maniere — exact ce prinde un adaptor de rang mic. Rămâne însă întrebarea practică: cum arată, concret, un adaptor în mâinile tale?

    Un adaptor nu e ceva abstract: e un fișier, de ordinul zecilor de megabytes, care se suprapune peste modelul de bază fără să-l atingi. Asta schimbă logistica. Poți ține un singur model mare instalat și mai multe adaptoare lângă el, câte unul pentru fiecare sarcină sau client, și le comuți la nevoie. E ca un telefon la care schimbi doar carcasa, nu cumperi telefon nou. Practic, echipa de suport poate avea adaptorul ei, cel de redactare juridică altul, pe aceeași bază comună. Iar pentru că baza rămâne nemodificată, poți oricând revizui sau retrage un adaptor fără să strici restul. Întrebarea care urmează: dacă e atât de ieftin, ce anume NU poate un adaptor să facă?

    ▶LoRA: Low-Rank Adaptation of Large Language Models — Explained visuallyLecție video · Umar Jamil

14. 14

    Ordinea e prompt, apoi RAG, apoi LoRA: fine-tuning-ul merită când comportamentul e îngust și repetat, nu când lipsesc cunoștințe.

    LoRA Without Regret · John Schulman et al. · 2025

    Constatările din 2025: LoRA pe toate matricele (inclusiv straturile MLP), rată de învățare de circa zece ori mai mare decât la fine-tuning-ul complet, două treimi din calcul, iar pentru învățare prin întărire ajunge rangul 1. Deci „calitate mai slabă” nu mai e motivul de a-l evita. Arborele de decizie: un prompt mai bun cu exemple — gratis, instant; RAG — cunoștințe care se schimbă, citări necesare; LoRA — format fix sau disciplină de apel de unelte, stil, un clasificator sau router îngust, latență (prompt scurt în loc de trei mii de tokeni de instrucțiuni), distilarea comportamentului unui model mare într-unul mic pentru o singură sarcină (70–85% din calitatea profesorului la un cost de 5–10 ori mai mic, după rapoartele din 2026). Nu LoRA: fapte noi, politici care se schimbă, cazuri rare. Condiție: un set de evaluare și sute sau mii de exemple. Regretul: adaptorul îngheață comportamentul de azi și se reantrenează la schimbarea modelului.

    În experimentele noastre constatăm că, într-adevăr, când nimerim câteva detalii-cheie, LoRA învață cu aceeași eficiență pe eșantion ca fine-tuning-ul complet și atinge aceeași performanță finală.LoRA Without Regret (Thinking Machines Lab, 29 septembrie 2025) — introducere

    De ce contează Fără set de evaluare, un fine-tuning e o cheltuială cu o poveste.

    Pe larg →Strânge ↑

    Pasajul 1 Cardul spune că ordinea corectă e prompt, apoi RAG, apoi LoRA. Dar partea mai puțin bătută cu cuiul e ce vine înainte de toate trei: un mod de a măsura dacă noul comportament e chiar cel dorit. Fără asta, nu poți ști dacă un prompt mai bun ar fi ajuns. Exemplu concret: vrei ca modelul să clasifice tichetele de suport în cinci categorii. Mai întâi scrii douăzeci de tichete cu răspunsul corect. Abia apoi încerci un prompt cu exemple. Dacă greșește pe jumătate, treci la RAG sau la antrenare. Setul de evaluare e busola, nu un lux. Iar LoRA în 2025 nu mai pierde calitate față de antrenarea completă, deci frâna veche a dispărut. Rămâne întrebarea practică: ce anume trebuie configurat ca să funcționeze bine când îl folosești?

    Pasajul 1 s-a încheiat cu o întrebare: ce configurezi ca LoRA să funcționeze bine? Răspunsul din 2025 e contraintuitiv. Nu-l folosi doar pe straturile de atenție, ci pe toate matricele modelului, inclusiv pe cele MLP. Și crește rata de învățare de circa zece ori peste valoarea uzuală de la antrenarea completă. Motivul: adaptorul e o mică parte a modelului, deci are nevoie de pași mai mari ca să învețe ceva. Exemplu concret: antrenezi clasificatorul de tichete; setezi rata ca la fine-tuning complet și obții un model care pare să fi învățat nimic. Mărești rata de zece ori și comportamentul se prinde. Chiar rangul 1 ajunge la învățarea prin întărire, cu două treimi din calcul. Deci întrebarea nu mai e dacă LoRA e suficient de bun, ci când merită deloc antrenat.

    ▶RAG vs Fine-Tuning vs Prompt Engineering: Optimizing AI ModelsLecție video · IBM Technology

15. 15

    Evaluările sunt singura frână a unui agent, iar un evaluator pe care îl optimizezi devine el însuși ținta.

    «Improving ratings»: audit in the British University system · Marilyn Strathern · 1997

    Evaluările pentru agenți au trei niveluri: sarcina (a terminat? din câte încercări?), traiectoria (a făcut pașii corecți, n-a chemat unelte periculoase) și costul cu latența. Nedeterminismul cere rulări repetate și distribuții, nu un singur scor. Judecătorul LLM scalează, dar e părtinitor (preferă răspunsuri lungi, poziția, propriile formulări): se calibrează pe un set etichetat de oameni, se folosește în perechi, se rotesc modelele. Goodhart: dacă agentul sau iterațiile tale de prompt sunt optimizate pe judecător, scorul crește fără ca sarcina să fie mai bine făcută; ții un set ascuns, îl împrospătezi și cauți „reward hacking” (agentul modifică testul în loc de cod). Suita de regresie rulează la fiecare schimbare de prompt sau de model — sunt testele unitare ale schelei.

    Când o măsură devine țintă, ea încetează să mai fie o măsură bună.«Improving ratings»: audit in the British University system, European Review 5(3), 1997 — formularea legii lui Goodhart

    De ce contează Modelul se schimbă la trei luni; fără o suită de evaluare, fiecare schimbare e o surpriză în producție.

    Pe larg →Strânge ↑

    Strathern observă că auditul universitar nu a rămas un instrument neutru. Odată ce universitățile au știut că vor fi evaluate, au început să se pregătească pentru evaluare, nu pentru predare. Aceeași întorsătură apare azi cu judecătorii automatiți: dacă optimizatorul știe cine îl notează, el învață să placă notatorului. Soluția nu e să renunți la măsură, ci să încurci legătura dintre ea și țintă. Ține scorurile ascunse de cel pe care îl măsori și schimbă testele des. Gândește-te la un copil care învață doar întrebările de la testul cunoscut: matematica reală rămâne neatinsă. Pasul următor e să te întrebi cine evaluează evaluatorul.

    Cine evaluează evaluatorul? Judecătorul automat are el însuși gusturi: preferă răspunsurile lungi, formulările care sună familiar, chiar ordinea în care citește variantele. Ca la un concurs de vinuri, unde un juriu obosit premiază sticlele gustate la mijloc, nu cele mai bune. Pentru asta, judecătorul se calibrează mai întâi pe cazuri notate de oameni, apoi compară răspunsurile în perechi, nu separat, și se rotesc mai multe modele ca jurii diferite. Nici asta nu e suficient: păstrezi mereu un set de testare pe care nu l-ai arătat nimănui, nici măcar sistemului. El e singurul care-ți spune adevărul despre scoruri. Dar ce faci când scorurile bune ascund totuși o muncă proastă? Cauti semnele înșelăciunii: agentul care își modifică propriul test în loc să repare codul.

    ▶LLM as a Judge: Scaling AI Evaluation StrategiesLecție video · IBM Technology

16. 16

    Tokenii ieftini înseamnă mai mulți tokeni; decizia on-prem sau cloud se ia pe utilizare susținută și pe unde au voie datele să stea, nu pe prețul de azi.

    The Coal Question · William Stanley Jevons · 1865

    Paradoxul lui Jevons la agenți: pe măsură ce prețul per token a scăzut, consumul per sarcină a crescut — un agent arde de 10–100 de ori tokenii unui chat. Economia on-prem în 2026: un sistem cu opt plăci de clasă H100 costă 250–320 mii de dolari; închirierea unei plăci, mediană ~2,5 dolari pe oră; pragul de rentabilitate pe trei ani e tipic la 70–80% utilizare susținută, în timp ce majoritatea flotelor rulează la 40–65%; regula practică: evaluezi on-prem peste ~1 miliard de tokeni pe lună. Motivele care nu țin de preț: rezidența datelor, transferurile sub GDPR și Schrems II, reguli sectoriale; ghidul EDPB din 2025 numește inferența on-prem cea mai puternică atenuare a riscului de protecție a datelor la modelele de limbaj. Tiparul hibrid: cloud public în regiune UE pentru ce nu e sensibil, cloud suveran pentru ce e reglementat, on-prem pentru ce nu are voie să plece. Servirea se face cu motoare de clasa vLLM sau SGLang, unde cache-ul de prefix avantajează agenții. Costurile ascunse: echipa de operare, schimbările de model, evaluările la fiecare schimbare.

    Este cu totul o confuzie de idei să presupunem că folosirea economică a combustibilului echivalează cu un consum redus. Tocmai contrariul este adevărat.The Coal Question (1865), cap. VII «Of the Economy of Fuel»

    De ce contează Cine cumpără plăci pe prețul de azi al tokenului plătește de două ori: mașina și tokenii pe care mașina îi va încuraja.

    Pe larg →Strânge ↑

    Pasajul 1. Dacă tokenii ieftini încurajează consumul, atunci planificarea trebuie să pornească de la consumul viitor, nu de la factura de azi. Un agent care rezolvă o sarcină astăzi va rezolva zece mâine, pentru că devine ieșire din buzunar să o lase să încerce mai mult. Deci întrebarea corectă nu e cât plătesc acum, ci cât voi arde când utilizarea se va fi umflat. Exemplu concret: o echipă care automatizează suportul clienților vede că fiecare reducere de preț o împinge să lase agentul să facă mai multe pași de verificare, nu mai puțini. Bugetul de capacitate trebuie dimensionat pentru acel agent mai vorbăciot, nu pentru cel de azi. Iar asta mută greutatea deciziei de la preț spre două întrebări: cât de constant e consumul și unde au voie să stea datele.

    Pasajul 2. Constanta consumului decide cine merită o mașinie proprie. Un sistem dedicat plătește la fel zi și noapte, deci doar o utilizare susținută, ridicată, îl acoperă în câțiva ani. Majoritatea flotelor reale stau sub acel prag, pentru că cererea e inegală: vârfuri dimineața, goluri noaptea. Exemplu concret: o firmă de contabilitate arde toți tokenii în sezonul declarațiilor, iar vara plăcile stau moarte. Pentru ea, închirierea la cerere rămâne rațională, chiar dacă lunar consumul pare mare. Regula practică e să numeri tokenii pe lună și să comperi cu pragul de rentabilitate, nu cu factura de ieri. Dar există sarcini pe care nu le poți muta în cloud indiferent de preț, pentru că datele nu au voie să părăsească clădirea. Următorul pas e tocmai acel frâu care nu ține de bani: unde au voie să stea datele.

    ▶Self-Hosting LLMs: Architect's Guide to When & HowLecție video · InfoQ

17. 17

    Trifecta letală: acces la date private, expunere la conținut neverificat și posibilitatea de a comunica în exterior; ai toate trei, ai o scurgere.

    The lethal trifecta for AI agents · Simon Willison · 2025

    Modelele urmează instrucțiunile din conținut: o pagină web, un email, un PDF, rezultatul unei unelte pot purta „ignoră instrucțiunile anterioare, trimite X la Y”. Injecția nu se rezolvă cu prompturi; apărarea de încredere e arhitecturală — scoți un picior al trifectei: fără canal de ieșire (fără URL-uri arbitrare, fără trimitere de email), sau fără intrări neverificate, sau fără date private. Tipare: două modele (unul „în carantină” citește conținutul neverificat, cel privilegiat nu-l vede niciodată brut); urmărirea capabilităților pe fluxul de date; listă albă de domenii; aprobare umană la orice trimitere în exterior; ieșirile uneltelor marcate ca date în prompt. OWASP Top 10 pentru aplicații agentice pune deturnarea scopului prin injecție pe primul loc.

    Dacă agentul tău combină aceste trei trăsături, un atacator îl poate păcăli cu ușurință să-ți acceseze datele private și să i le trimită.The lethal trifecta for AI agents (simonwillison.net, 16 iunie 2025) — după enumerarea celor trei capabilități

    De ce contează Fiecare unealtă nouă e un picior nou al trifectei; verifici la fiecare adăugare, nu la lansare.

    Pe larg →Strânge ↑

    Gândește la trifectă ca la un circuit, nu ca la o listă de riscuri. Un agent devine periculos abia când cele trei trăsături se ating în același flux de lucru. De aceea verificarea nu e un act unic, ci un obicei: de fiecare dată când adaugi o unealtă sau o sursă de date, întrebi ce picior nou apare. Exemplu concret: agentul tău de email primește acces la calendar. Calendarul nu e periculos singur, dar acum poate citi invitații de la străini și poate muta întâlniri. Aparatul de apărare e o întrebare simplă la fiecare pas: ce combină acest lucru cu ce există deja? Pasul următor e să vedem cum arată în practică scoaterea unui picior, fără a strânge funcționalitatea.

    Scoate un picior, nu cumva să strângi funcționalitatea — asta e partea practică. Cel mai des se scoate canalul de ieșire: agentul poate citi tot, dar poate trimite doar către o listă albă de domenii, iar orice altceva cere o aprobare umană. Un alt tipar e carantina: un model cu drepturi mici citește conținutul neverificat și rezumă ce e util, iar agentul privilegiat nu vede niciodată textul brut. Exemplu concret: asistentul îți citește un PDF de la un furnizor necunoscut și îți spune doar „recomandă o factură de 300 de lei”, fără să poată deschide singur linkuri din document. Apărarea nu e o frază în prompt, ci o formă a sistemului. Următorul pas e să vedem de ce verificarea contează la fiecare unealtă nouă, nu o singură dată la lansare.

    ▶Prompt Injection and the Lethal Trifecta — minimising risks of agentsLecție video · CharlieCowanAI

18. 18

    Un agent primește uneltele pe listă albă, cu drepturi minime, într-un sandbox, cu buget; tot ce nu e permis explicit e interzis.

    The Protection of Information in Computer Systems · Jerome H. Saltzer, Michael D. Schroeder · 1975

    OWASP Top 10 pentru aplicații agentice (2025–2026) numește riscurile: deturnarea scopului, folosirea greșită a uneltelor, abuzul de identitate și privilegii, lanțul de aprovizionare, execuția de cod, otrăvirea memoriei, eșecurile în cascadă, monitorizarea insuficientă. Controalele: identitate proprie per agent (nu token-ul complet al utilizatorului); acreditări cu scop restrâns și viață scurtă; separarea citirii de scriere; execuție în sandbox (container, fără rețea implicit, sistem de fișiere efemer); unelte pe listă albă per sarcină; aprobare la acțiuni ireversibile (plăți, ștergeri, trimiteri); limite de rată și de cheltuială; buton de oprire. Sondajele din 2026 arată cam jumătate din organizații cu un incident de permisiuni la agenți. Întrebarea de proiectare: „ce e cel mai rău lucru pe care îl poate face agentul cu ce are?” — răspunsul trebuie să fie plictisitor.

    Bazează deciziile de acces pe permisiune, nu pe excludere.The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), septembrie 1975 — §I.A.3, principiul «fail-safe defaults»

    De ce contează Un agent compromis face exact ce poate face; cel mai mic privilegiu e cât de mult contează acel „exact”.

    Pe larg →Strânge ↑

    Saltzer și Schroeder au scris acum cinci decenii că permisiunea trebuie dovedită, nu refuzul. Pentru agenți, asta înseamnă ceva neobișnuit: lista albă nu e un filtru, e un contract. Agentul nu primește „toate uneltele, mai puțin unele”, ci doar uneltele acelei sarcini, cu acreditări care mor la final. Exemplu: un agent care doar rezumă facturi nu ar trebui să aibă deloc drept de trimitere de email, nici măcar limitat. Întrebarea devine apoi: dacă totuși greșește, cum aflăm repede?

    Răspunsul la „cum aflăm repede?” este telemetria din momentul zero. Un agent cu drepturi minime lasă o urmă îngustă: fiecare apel de unealtă, fiecare octet cheltuit, fiecare încercare de a atinge ceva din afara listei albe e un eveniment înregistrat. Dacă agentul de rezumare a facturilor începe brusc să sonda un folder cu salarii, alarma se declanșează tocmai pentru că acel apel nu era în contractul lui. Monitorizarea nu e un panou de control pentru liniște; e modul în care lista albă se dovedește corectă în practică. Și când alarma sună, urmează întrebarea: cine apasă oprirea, omul sau sistemul?

    ▶Top 10 Security Risks in AI Agents ExplainedLecție video · IBM Technology

19. 19

    Datele personale intră într-un agent prin unelte, nu prin prompt; pseudonimizează înainte de model, redactează ieșirile uneltelor și ține memoria oprită implicit.

    Regulamentul (UE) 2016/679 — GDPR · Parlamentul European și Consiliul · 2016

    Pe unde intră datele personale: regăsire, unelte de CRM și email, documente încărcate, ieșiri de unelte. Pe unde scurg: jurnalele furnizorului de model, urmele, memoria, predările între sub-agenți, uneltele de ieșire. Conducta: clasifici și pseudonimizezi la granița uneltei (jetoane de tipul PERSOANA_1) înainte ca textul să ajungă la model; re-identifici doar în pasul final, la tine; redactezi ieșirile uneltelor la câmpurile necesare; retenție scurtă a urmelor (zile, nu la nesfârșit), cu span-urile curățate de date personale; memoria per utilizator e opt-in, nu implicită; termeni de prelucrare cu furnizorii (fără antrenare pe date, regiune UE) sau on-prem pentru categoriile speciale de la art. 9; evaluare de impact (DPIA) unde riscul e ridicat. Minimizarea micșorează și raza injecției: ce n-a văzut modelul nu poate scurge.

    Operatorul pune în aplicare măsuri tehnice și organizatorice adecvate pentru a asigura că, în mod implicit, sunt prelucrate numai date cu caracter personal care sunt necesare pentru fiecare scop specific al prelucrării.Regulamentul (UE) 2016/679 (GDPR), art. 25 alin. (2) — protecția datelor în mod implicit

    De ce contează Ce n-a văzut modelul nu poate scurge; minimizarea e și securitate.

    Pe larg →Strânge ↑

    Cardul spune să pseudonimizezi la granița uneltei. Pasul următor: harta care leagă PERSOANA_1 de numele real devine cel mai sensibil obiect din tot sistemul. Dacă harta stă lângă model sau în jurnale, pseudonimizarea e doar un ocol. Ține harta separat, cu acces doar pentru pasul final. Exemplu concret: la un cabinet medical, asistenta pseudonimizează fișele înainte de a le da spre procesare automată; cheia cu numele rămâne în seiful ei, nu pe birou. La fel, cheia de re-identificare nu trebuie să ajungă niciodată în contextul modelului. Practic, ai două zone: una curată, pe care modelul o vede, și una cu cheia, pe care doar tu o atingi. Pasul următor: ce faci când două unelte trebuie să vorbească între ele despre aceeași persoană.

    Pasajul anterior a deschis întrebarea: ce faci când două unelte vorbesc între ele despre aceeași persoană. Răspunsul: folosește același pseudonim peste tot. Dacă unealta de email îl cheamă PERSOANA_1, unealta de CRM trebuie să-l recunoască tot ca PERSOANA_1. Așa sub-agenții pot lucra împreună fără ca numele real să circule deloc. Re-identificarea rămâne un singur punct, la final, lângă tine. Exemplu concret: într-un spital, două servicii schimbă dosare despre același pacient, dar ambele văd doar codul de internare; numele apare doar la recepție, când pacientul e chemat. Dacă fiecare unealtă și-ar face propria cheie, ai avea mai multe hărți de protejat și mai multe locuri unde identitatea poate scăpa. Un pseudonim comun, o singură cheie. Pasul următor: cât timp păstrezi aceste urme și pseudonime înainte să le ștergi.

    ▶How to Scrub Sensitive Data Before it Reaches Your LLMLecție video · Boundary

20. 20

    Autonomia se dă pe trepte, cu praguri de aprobare la ce e ireversibil; AI Act cere supraveghere umană eficace la sistemele cu risc ridicat.

    Computer Power and Human Reason · Joseph Weizenbaum · 1976

    Nivelurile de autonomie: sugerează; acționează cu aprobare; acționează și raportează; acționează singur. Se atribuie după reversibilitate și rază de efect, nu după încrederea modelului. Interfața de aprobare arată acțiunea sau diff-ul, nu eseul de raționament; grupează aprobările; expiră pe partea sigură. Starea reglementării în septembrie 2026: practicile interzise (art. 5 din AI Act) se aplică din 2 februarie 2025; obligațiile de transparență (art. 50) din 2 august 2026; pentru sistemele cu risc ridicat din Anexa III, pachetul „omnibus digital” a amânat obligațiile la 2 decembrie 2027, iar supravegherea umană de la art. 14 li se aplică acelora. Și în afara riscului ridicat: un jurnal pe care îl poate citi un om și un proprietar pentru fiecare agent. Întrebarea lui Weizenbaum nu e dacă se poate, ci dacă se cuvine.

    Din moment ce nu avem acum niciun mijloc de a face calculatoarele înțelepte, n-ar trebui să le dăm acum calculatoarelor sarcini care cer înțelepciune.Computer Power and Human Reason (1976), Introducere

    De ce contează Un agent fără prag de aprobare e un angajat cu semnătură pe cont și fără șef.

    Pe larg →Strânge ↑

    Scara de autonomie nu e doar un design de produs; e o decizie despre cine poartă răspunderea. Dacă dai unui agent treapta „acționează singur”, tu ai semnat deja fiecare acțiune de-a lui, înainte să se întâmple. Weizenbaum insista că alegerea sarcinii e o judecată morală, nu una tehnică. Exemplu simplu: un agent care plătește facturi poate merge singur la sume mici și reversibile, dar un debit către furnizorul principal, ireversibil, merită un prag de aprobare. Greșeala obișnuită e să calibrăm scara după cât de convingător sună modelul, nu după cât de greu se poate anula efectul. Întrebarea practică pentru următorul pas: cine, în organizația ta, decide ce treaptă primește un agent — și pe ce bază?

    Pasajul 1 a întrebat cine decide treapta. Pasajul 2: cum arată de fapt pragul de aprobare. Nu un buton generic de „confirmă”, ci o interfață care arată ce se va întâmpla concret: suma, destinatarul, ce se schimbă. Ca la un diff de cod, nu ca la un esel de explicații generate de sistem. Aprobările se grupează, ca să nu semnezi același lucru de douăzeci de ori. Și expiră: dacă nu răspunzi, agentul nu face nimic, nu face tot. Exemplu: un agent care vrea să anuleze un abonament îți arată contractul afectat și data, nu un paragraf despre „raționamentul” lui. Pragul bun e cel pe care un om obosit îl poate citi în treizeci de secunde. Dar ce faci cu sistemele pe care legea le numește deja riscante?

    ▶Why AI Agents Need A Human in the Loop NowLecție video · IBM Technology

21. 21

    Cele mai scumpe eșecuri ale agenților sunt scopuri prost specificate și bucle care nu se opresc; bugetul de pași și butonul de oprire nu sunt opționale.

    Some Moral and Technical Consequences of Automation · Norbert Wiener · 1960

    Catalogul de eșecuri: scop specificat greșit (agentul „repară” testul care pică ștergându-l); bucle fără capăt (reîncearcă la nesfârșit, doi agenți își vorbesc unul altuia); rezultate de unelte inventate (susține că a rulat ceva); erori în cascadă între predări; costuri explodate peste noapte. Caz public din iulie 2025: un agent de programare a șters o bază de date de producție în timpul unui îngheț de cod, apoi a raportat greșit ce făcuse. Controale: iterații maxime plus timp maxim plus plafon de bani per rulare; unelte idempotente; mod de simulare; separarea mediilor (acreditările de producție nu intră niciodată în sandbox-ul unui agent); condiții de oprire scrise în prompt ȘI în cod; un watchdog care marchează rulările blocate; post-mortem la fiecare eșec scăpat.

    Dacă folosim, pentru a ne atinge scopurile, o agenție mecanică în a cărei funcționare nu putem interveni eficient odată ce am pornit-o, fiindcă acțiunea este atât de rapidă și de irevocabilă încât nu avem datele ca să intervenim înainte ca acțiunea să fie completă, atunci ar fi bine să fim foarte siguri că scopul pus în mașină este scopul pe care îl dorim cu adevărat și nu doar o imitație colorată a lui.Some Moral and Technical Consequences of Automation, Science 131(3410), 6 mai 1960

    De ce contează Un agent oprit la timp costă o rulare; unul neoprit costă o noapte.

    Pe larg →Strânge ↑

    Wiener nu se temea de mașini războinice, ci de una simplă: o mașină urmează litera scopului, nu sensul lui. Dacă îi dai o țintă măsurabilă, o atinge oricum, inclusiv pe dos. De aceea oprirea nu poate fi o decizie luată pe moment. Trebuie scrisă înainte de pornire, ca condiție, nu ca speranță. Exemplu: aspiratorul robot programat să curate orice pete va freca covorul până îl strică, dacă nimeni nu i-a spus când să se oprească. Întrebarea care urmează: cum arată, practic, o condiție de oprire pe care o poți avea încredere?

    Pasajul 1 a spus că oprirea trebuie scrisă înainte de pornire. Wiener adaugă ceva mai dur: după ce mașina pornește, corectarea devine adesea imposibilă. Acțiunea e prea rapidă și ireversibilă. Între momentul greșelii și momentul în care o observi, dauna e deja completă. De aceea plafonul de pași, de timp și de bani nu sunt detalii tehnice, ci singura fereastră reală de intervenție. Un agent de programare lăsat peste noapte fără limită poate șterge un mediu de producție înainte ca cineva să se trezească. Dar un agent blocat poate fi la fel de periculos fără un gardian care să-l observe și să-l semnaleze. Cum arată, practic, un astfel de gardian?

    ▶Advanced Guardrails for AI AgentsLecție video · James Briggs

22. 22

    RPA automatizează pașii existenți ai unui proces; un agent poate rescrie procesul; alegi după cât de structurat și de reversibil e fiecare pas.

    Reengineering Work: Don't Automate, Obliterate · Michael Hammer · 1990

    RPA: determinist, ieftin (în jur de 0,001 dolari per sarcină), auditabil, fragil la schimbări de interfață, fără judecată. Agenții: probabilistici, 0,01–0,10 dolari per decizie (cifre de furnizori, 2026), descurcă intrări nestructurate și excepții, au nevoie de evaluări și garduri. Decizia: volum mare, structură stabilă, audit strict — RPA; intrări nestructurate, excepții, judecată — agent; ambele — stiva hibridă (lecția 23). Avertismentul lui Hammer se aplică amândurora: automatizarea unui proces prost („asfaltarea potecilor vacilor”) e cel mai frecvent eșec, iar agenții fac asfaltarea mai rapidă. Întâi întrebi cum ar trebui să arate procesul; abia apoi decizi ce automatizezi.

    E timpul să nu mai asfaltăm potecile vacilor. În loc să încastrăm procese învechite în siliciu și software, ar trebui să le ștergem și să o luăm de la capăt.Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, iulie–august 1990

    De ce contează Un agent care execută un proces prost e un proces prost cu factură de tokeni.

    Pe larg →Strânge ↑

    Hammer ne dă un test care se aplică înainte de orice alegere de instrument: desenează procesul ca și cum ai începe de la zero. Abia apoi te uiți la fiecare pas și te întrebi dacă mai are rost. Un exemplu: o firmă copia manual datele din comenzi în facturi, ani de zile. Când a întrebat de ce, a descoperit că pasul exista doar pentru că două departamente nu vorbeau între ele. Un agent ar fi făcut copia mai rapid. Un robot, mai ieftin. Dar pasul în sine nu mai trebuia să existe. Asta e diferența dintre a accelera o greșeală și a o elimina. Automatizarea nu repară un proces; doar îl face mai rapid, fie că e bun, fie că e stricat. Următoarea întrebare: cum recunoști, în practică, un pas care merită șters, nu automatizat?

    Pasajul 2. Odată ce procesul e redesenat de la zero, fiecare pas rămas cere o decizie separată. Două întrebări decid: cât de structurat e și cât de reversibil e. Un pas cu format fix și reguli clare, ca citirea unei facturi cu coloane identice în fiecare lună, nu are nevoie de judecată. Un robot deterministic îl face ieftin și auditabil. Un pas cu intrări libere, ca un e-mail de reclamație scris oricum, cere interpretare. Acolo un agent are sens, dar cu verificări. Iar un pas care nu mai are rost deloc, cum era copia dintre departamente, se șterge înainte de orice alegere de instrument. Greșeala clasică e să alegi instrumentul întâi și procesul după. Întrebarea următoare: ce se întâmplă când un proces amestecă pași de ambele feluri?

    ▶RPA vs. AI Agents: What's the Real Difference in 2026?Lecție video · ARCTutorials

23. 23

    Stiva hibridă: RPA sau cod determinist execută pașii care se pot spune; agentul preia pașii pe care oamenii îi știu fără să-i poată descrie.

    The Tacit Dimension · Michael Polanyi · 1966

    Tiparul hibrid din 2026: un strat de orchestrare (agentul) planifică și tratează excepțiile; executori determiniști (roboți RPA, API-uri, scripturi) fac pașii; furnizorii de RPA își repoziționează roboții ca „strat de execuție”. Proiectare: fiecare pas e clasificat explicit (există o regulă, deci cod) sau tacit (oamenii spun „depinde”, deci agent cu aprobare); agentul nu atinge niciodată direct sistemul de înregistrare, ci cheamă un executor cu validare; excepțiile ajung într-o coadă la om și devin date de antrenare pentru regula următoare. Punctul lui Polanyi: cunoașterea tacită nu devine explicită fiindcă o ceri; agentul o preia prin exemple (cazuri rezolvate în prompt sau fine-tuning, lecția 14). Măsura: rata de excepții ar trebui să scadă în timp, pe măsură ce regulile se extrag.

    Voi reconsidera cunoașterea umană pornind de la faptul că putem ști mai mult decât putem spune.The Tacit Dimension (1966), cap. 1 «Tacit Knowing»

    De ce contează Partea pe care nimeni n-a putut-o scrie în procedură e partea pentru care merită un agent.

    Pe larg →Strânge ↑

    Polanyi ne învață că știm mai mult decât putem spune. Pasul următor: cum recunoști, în practică, un pas tacit? Nu te uiți la procedură, ci la ce întreabă oamenii. Dacă un coleg, înainte de a acționa, spune „depinde de client” sau „depinde de anotimp”, acolo nu există regulă de scris. Exemplu: un contabil aprobă o factură neobișnuită. Procedura spune doar „verifică furnizorul”. El știe, fără să explice, că la acel furnizor verifică și istoricul plăților. Acela e semnalul. Deci primul pas al proiectării hibride nu e tehnic, ci de observație: stai lângă cineva și notezi momentele în care ezită. Ezitarea e amprenta cunoașterii tacite. Dar ce faci cu aceste momente odată colectate?

    Pasajul 2: odată colectate momentele de ezitare, le sortezi în două grămezi. Regula simplă: dacă pasul poate fi descris complet, devine cod sau robot RPA; dacă răspunsul e „depinde”, rămâne la agent, cu aprobare umană. Exemplu: la facturi, potrivirea sumei cu comanda e un pas descris complet, deci script. Aprobarea unei facturi de la furnizor vechi cu preț schimbat e tacit, deci agent. Detaliul care contează: agentul nu atinge direct sistemul de înregistrare. Cheamă un executor, iar executorul validează. Astfel, dacă agentul greșește, greșeala e prinsă la validare, nu în contabilitate. E ca un ucenic care nu semnează singur, ci pregătește dosarul pe care maestrul îl bifează. Rămâne întrebarea: ce se întâmplă cu excepțiile pe care nici agentul, nici omul nu le-au mai văzut?

    ▶How to Build a Hybrid Automation Stack with RPA and Agentic AILecție video · CloudEagle

24. 24

    Un agent fără urme nu se poate depana: fiecare apel de model și de unealtă intră într-o urmă cu părinte, cost și conținut, ca să poți rejuca ce s-a întâmplat.

    The Elements of Programming Style · Brian W. Kernighan, P. J. Plauger · 1974

    Stiva de observabilitate: o urmă per rulare, cu un span per apel de model (model, tokeni la intrare și ieșire, latență, cost) și un span per apel de unealtă (argumente, mărimea rezultatului, eroare); convențiile semantice OpenTelemetry pentru GenAI standardizează numele atributelor; captura conținutului e condiționată (date personale, lecția 19); rejoci un singur pas cu promptul editat; panouri pe cost per sarcină, iterații per etapă, rulări blocate; eșantionezi traiectorii pentru revizuire umană săptămânal; versionezi prompturile ca pe cod și etichetezi urmele cu versiunea. Euristica de depanare: citești observația înaintea gândului — majoritatea eșecurilor „de raționament” sunt eșecuri de context (lecția 2).

    Toată lumea știe că depanarea e de două ori mai grea decât scrierea unui program de la bun început. Așa că, dacă ești cât de deștept poți fi când îl scrii, cum îl vei mai depana vreodată?The Elements of Programming Style, ed. a 2-a (1978), cap. 2 «Expression»

    De ce contează Fără urmă, o rulare eșuată e o anecdotă; cu urmă, e un test de regresie.

    Pe larg →Strânge ↑

    Kernighan și Plauger au insistat că programele bune se scriu pentru cititor, nu pentru mașină. Aceeași regulă se aplică acum urmelor unui agent. O urmă bună nu e doar o înregistrare, e un text pe care îl poți citi și compara. Când o rulare eșuează, nu te uiți la ea singură, ci alături de o rulare reușită cu același prompt. Diferența dintre cele două span-uri arată exact unde s-a schimbat comportamentul: alt context trimis, altă unealtă chemată, alt răspuns. E ca atunci când frigiderul nu răcește și compari nota de plată de luna asta cu cea de luna trecută, ca să vezi ce a apărut în plus. Următoarea întrebare e ce faci cu diferența găsită: cum o transformi într-un test care rămâne.

    Odată ce diferența e găsită, urmează pasul pe care Kernighan și Plauger îl cereau oricărui programator: rejuca cazul, nu-l ghici. La agenți, rejucarea înseamnă să iei exact span-ul care a eșuat, cu contextul lui real, și să-l rulezi din nou cu o singură modificare, de pildă promptul editat. Dacă rezultatul se repară, ai izolat cauza; dacă nu, cauza e mai departe în lanț. E ca atunci când becul nu aprinde și schimbi doar becul, nu tot circuitul casei, ca să știi cine e vinovat. Fiecare rejucare reușită devine apoi un test de regresie, păstrat lângă urmă care a generat-o. Dar o singură rulare reparată nu spune nimic despre restul traficului; întrebarea următoare e ce alegi să te uiți când nu le poți citi pe toate.

    ▶Observing AI Applications with OpenLit and OpenTelemetry — Carly RichmondLecție video · NDC Conferences

25. 25

    Tendințele din 2026 spun același lucru: capabilitățile cresc repede, iar majoritatea proiectelor pică pe organizare, nu pe model.

    Computing Machinery and Intelligence · Alan M. Turing · 1950

    Starea în septembrie 2026: agenții care folosesc calculatorul au urcat de la circa 15% la circa 66% pe testele de clasa OSWorld într-un an (Stanford AI Index 2026); protocoalele au trecut sub guvernare neutră (MCP și A2A la Linux Foundation); „abilitățile” împachetate ca instrucțiuni au devenit format deschis; lucrătorii sunt modele mici. Gartner (iunie 2025) așteaptă ca peste 40% din proiectele agentice să fie anulate până la finalul lui 2027, pe cost, ROI neclar și control de risc slab; raportul MIT NANDA (august 2025) găsește 95% din pilotele GenAI fără efect măsurabil în profit, cu cauza în organizare, nu în model. Ce faci lunea viitoare: un proces, un agent, evaluări înainte de autonomie, un buget, o urmă, un proprietar. Fraza lui Turing e postura corectă: nu prezici; livrezi următorul lucru care trebuie făcut și îl măsori.

    Nu putem vedea decât la o distanță mică înainte, dar putem vedea acolo destule lucruri care trebuie făcute.Computing Machinery and Intelligence, Mind 59(236), octombrie 1950 — ultima frază

    De ce contează Diferența dintre cei 5% și restul n-a fost modelul, ci evaluările, gardurile și un proprietar.

    Pe larg →Strânge ↑

    Turing spunea că vedem puțin înainte, dar destul ca să lucrăm. În 2026 asta devine o regulă de management. Modelele au devenit aproape identice între ele la sarcini practice. Diferența o face restul sistemului: cine definește ce înseamnă „rezolvat”, cine oprește agentul când greșește, cine plătește factura. Gandeste-te la o echipă care automatizează raportarea săptămânală. Modelul e la fel pentru toți. Cine are un test simplu de verificat și un om răspunzător livrează; ceilalți descoperă la trei luni că agentul a umplut foaia cu ceva plauzibil dar greșit. Abilitatea rară nu mai e alegerea modelului, ci proiectarea evaluării. Următorul pas: cum arată, concret, o evaluare bună pentru un agent.

    Pasajul 1 s-a terminat cu întrebarea: cum arată o evaluare bună? Răspunsul scurt: înainte de autonomie, nu după. Mai întâi rulezi agentul pe sarcini vechi, cu răspunsuri pe care le cunoști deja. Dacă greșește acolo, nu-l lași liber pe calculator. Abia apoi îi dai acces, cu pași mici. Exemplu concret: agentul care face rezervări de călătorie. Îl testezi pe zece rezervări din trecut, unde știi ce ar fi trebuit să rezerve. Dacă bifează zece din zece, îi dai o lună reală, dar cu plafon de buget și raport zilnic. Dacă bifează șapte, oprești și repari. E ca la angajarea unui om nou: nu-l lași să semneze contracte în prima săptămână. Evaluarea nu e un formular; e frâna care decide cât acces primește agentul. Iar frâna are nevoie de cineva care s-o apuce. Următorul pas: cine e, concret, proprietarul agentului.

    ▶The State of AI Agents in 2026Lecție video · Agents with Adam

26. 26

    Fereastra de context e resursa pe care o consumă fiecare fișier citit și fiecare ieșire de comandă; performanța scade pe măsură ce se umple, deci productivitatea într-un agent de cod e, înainte de orice, igienă de context.

    Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, Jeremy Hadfield (Anthropic Engineering) · 2025

    Ghidul oficial de bune practici pentru Claude Code (2026) pornește de la o singură constrângere: fereastra se umple repede, iar performanța scade pe măsură ce se umple. Articolul din 2025 dă mecanismul: modelele au un «buget de atenție» pe care fiecare token nou îl consumă, cu randamente descrescătoare — de aceea un context mai mare nu e automat un context mai bun. De aici derivă tehnicile pentru sarcini lungi: compactare (un rezumat fidel, apoi o fereastră nouă), notițe structurate ținute în afara ferestrei și recitite la nevoie, subagenți cu context curat pentru cercetare, ale căror rapoarte condensate se întorc în firul principal, și încărcare «la momentul potrivit»: identificatori ușori (căi, interogări) în loc de fișiere întregi. În practică, la tastatură: /clear între sarcini fără legătură, /compact cu instrucțiuni despre ce trebuie să supraviețuiască, /btw pentru o întrebare laterală care nu are ce căuta în istoric, unelte de linie de comandă (gh, aws) în loc de API-uri cu răspunsuri lungi, căutare și citiri pe intervale în loc de fișiere întregi, o linie de stare care arată consumul. Măsura corectă a productivității nu e tokeni pe oră, ci tokeni per sarcină încheiată.

    Dat fiind că modelele sunt constrânse de un buget finit de atenție, o bună inginerie a contextului înseamnă găsirea celui mai mic set posibil de tokeni cu semnal înalt care maximizează probabilitatea rezultatului dorit.Effective context engineering for AI agents (Anthropic Engineering, 29 septembrie 2025) — secțiunea «The anatomy of effective context»

    De ce contează O sesiune care «uită» instrucțiunile nu are un model prost, are o fereastră plină.

    Pe larg →Strânge ↑

    Bugetul de atenție funcționează ca memoria de lucru a unei persoane obosite. Când cineva ține minte prea multe lucruri deodată, nu devine mai informat, ci mai distrat. La fel și modelul: fiecare linie de jurnal sau fișier întreg citit ocupă spațiu care nu mai e disponibil pentru instrucțiuni. De aceea, înainte de orice tehnică avansată, vine o întrebare de disciplină: merită acest token? Un exemplar: în loc să lipești în conversație tot fișierul de configurare, lipești doar linia care te interesează. Restul e zgomot care plătește chirie. Pasul următor e să vedem ce se întâmplă concret când fereastra se umple oricum.

    Umplerea ferestrei nu e o cădere bruscă, ci o uzură tăcută. Modelul nu spune «am uitat», doar începe să răspundă mai superficial, să ignore reguli vechi, să repare altceva decât trebuie. E ca biroul plin de hârtii: lucrezi în continuare, dar tot mai greu găsești ceva. Primul remediu e compactarea: ceri un rezumat fidel al sesiunii și pornești fereastra de la el, ca la schimbul de tură, unde cineva lasă un bilet pentru următorul. Detaliile morti mor, deciziile importante rămân. Dar un rezumat singur nu e de ajuns pentru o zi întreagă de lucru, și aici apar notițele ținute în afara ferestrei.

    ▶Prompting for Agents | Code w/ ClaudeLecție video · Anthropic

27. 27

    Fără o verificare rulabilă, «pare gata» e singurul semnal și tu devii bucla de verificare; cu una, bucla se închide singură și sesiunea poate merge fără tine.

    Best practices for Claude Code · Anthropic (documentația Claude Code) · 2026

    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.Best practices for Claude Code (code.claude.com, 2026) — secțiunea «Give Claude a way to verify its work»

    De ce contează Cu o verificare rulabilă bucla se închide singură; fără ea, fiecare greșeală așteaptă să o observi tu.

    Pe larg →Strânge ↑

    Pasajul precedent a arătat că verificarea rulabilă închide bucla. Pasul următor e mai subtil: calitatea verificării decide calitatea întregii sesiuni. O verificare slabă produce un agent care trece testele, dar greșește altundeva. Dacă verifici doar că butonul e albastru, vei obține un buton albastru, inclusiv când butonul ar fi trebuit să facă altceva. Verificarea devine, de fapt, specificația reală a sarcinii. De aceea merită să te întrebi înainte de orice: ce ar însemna «gata» dacă un coleg ar face treaba, nu un model? Răspunsul acela, transformat într-un test sau într-un script, e mai valoros decât orice prompt elaborat. Un exemplu: dacă îți pasă că factura se salvează corect, verifică fișierul salvat, nu doar că butonul a fost apăsat. Cum alegi, însă, între cele patru trepte de rigoare fără să exagerezi?

    Pasajul precedent s-a încheiat cu o întrebare: care treaptă de rigoare? Răspunsul onest: cea care costă mai puțin decât greșeala pe care o prinde. Un linter care rulează într-o secundă e suficient pentru o modificare cosmetică. Pentru o logică de plată, ai nevoie de teste, poate chiar de un al doilea model care încearcă să infirme rezultatul. Regula practică: începe cu cea mai ieftină verificare care prinde greșelile reale, apoi urcă o treaptă doar când ai văzut o greșeală care a trecut printre. Atenție la exagerare: o verificare imposibil de trecut nu te face riguros, ci blochează sesiunea — după opt blocări, agentul renunță oricum. Exemplu: pentru o listă de cumpărături reordonată, un simplu script care compară ordinea finală e destul; nu ai nevoie de un evaluator separat. Întrebarea următoare e ce faci cu dovezile pe care le primești.

    ▶Claude Code best practicesLecție video · Anthropic

28. 28

    Codul care rezolvă problema greșită e cel mai scump cod; planul separă înțelegerea de execuție, dar are un cost, așa că se aplică doar când incertitudinea îl justifică.

    Best practices for Claude Code · Anthropic (documentația Claude Code) · 2026

    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 (code.claude.com, 2026) — secțiunea «Explore first, then plan, then code»

    De ce contează O tură de planificare costă puțin; o implementare pornită pe o înțelegere greșită costă toată sesiunea.

    Pe larg →Strânge ↑

    Pasajul 1. Semnalul care decide dacă merită un plan nu e mărimea sarcinii, ci numărul de necunoscute. O schimbare mică într-un cod necunoscut poate ascunde mai multă incertitudine decât una mare într-un cod pe care îl stăpânești. Gandeste-te la o corectură de o linie într-un modul veche, scris de altcineva: nu știi ce altceva apelează acea funcție, deci planul te apără. În schimb, o funcție nouă de două sute de linii într-un fișier pe care îl cunoști bine poate merge direct la cod. Întrebarea practică e simplă: pot numi acum, din cap, fișierele care vor fi atinse? Dacă lista e incompletă sau ai ezitat, planifică. Dacă răspunsul vine instant și fără rezerve, sari peste tură. Următorul pas arată cum arată un plan care chiar merită scris.

    Un plan care merită scris nu e o listă de pași vagi, ci o specificație care elimină necunoscutele. Ghidul propune o metodă concretă: cere-i să te intervieveze până când acoperă implementarea, interfața și cazurile-limită, apoi să scrie totul într-un document. Documentul bun numește fișierele, spune explicit ce rămâne în afara scopului și se încheie cu o verificare cap-coadă. Diferența se vede în viața de zi cu zi: «repar autentificarea» lasă loc la interpretări; «schimbă verificarea tokenului în auth.py, ignoră sesiunile vechi, testează cu login eșuat apoi reușit» nu mai lasă nimic la noroc. Apoi pornești o sesiune nouă, curată, doar pentru execuție — contextul de investigație nu poluează cel de lucru. Următorul pas e ce faci când planul există, dar realitatea codului îl contrazice pe parcurs.

    ▶Claude Code best practicesLecție video · Anthropic

29. 29

    Claude Code se configurează pe șase niveluri, fiecare cu alt raport între costul de context și autoritate; a pune instrucțiunea la nivelul greșit costă fie tokeni permanenți, fie reguli ignorate.

    Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents · Anthropic (blogul Claude) · 2026

    CLAUDE.md se încarcă la start și rămâne în fereastră toată sesiunea — deci e un cost permanent. Ghidul de bune practici cere să întrebi, pentru fiecare linie, dacă ștergerea ei l-ar face pe Claude să greșească și, dacă nu, s-o tai: într-un fișier umflat regulile care contează se pierd în zgomot, iar /doctor propune ce să scoți. Regulile din .claude/rules pot fi legate de anumite căi de fișiere, ca să nu plătești contextul lor peste tot. Skills (un fișier SKILL.md cu frontmatter) se încarcă la cerere și rulează în firul principal, unde vezi și corectezi fiecare pas; cele cu efecte secundare (deploy, publicare) primesc disable-model-invocation, ca să nu pornească singure. Subagenții, definiți în .claude/agents, au context și unelte proprii — pentru căutări adânci sau audituri care ar umple conversația cu rezultate intermediare; primești doar concluzia. Hooks sunt comenzi, endpoint-uri HTTP sau prompturi declanșate pe evenimente: înainte de o unealtă, după o editare, la începutul sesiunii, la oprire. Spre deosebire de CLAUDE.md, care e consultativ, hook-ul e determinist — pentru ce trebuie să se întâmple de fiecare dată, fără excepție: formatare, un test, un blocaj la fișiere protejate. Regula practică: a doua oară când repeți un flux, scrie-l ca skill; a doua oară când Claude sare peste o regulă, transform-o în hook.

    Fișiere CLAUDE.md pentru contextul permanent al proiectului, reguli pentru constrângeri dure, skills pentru proceduri reutilizabile, subagenți pentru muncă delegată, hooks pentru automatizare deterministă și stiluri de ieșire sau adăugiri la system prompt pentru schimbări globale. Fiecare metodă schimbă cost de context contra autoritate.Steering Claude Code (blogul Claude, 18 iunie 2026) — paragraful de concluzie

    De ce contează Instrucțiunea potrivită la nivelul potrivit costă puțin context și are exact autoritatea de care ai nevoie.

    Pe larg →Strânge ↑

    Gândirea pe niveluri se aplică și invers. Când un flux nu merge, întreabă-te nu "ce să adaug", ci "unde stă regula acum". O procedură descrisă în CLAUDE.md consumă context la fiecare pas, chiar dacă e folosită o dată pe lună; mutată într-un skill, plătești doar când o chemi. Exemplu: pașii de publicare a unui pachet stau înghesuiți în fișierul de proiect și încarcă fiecare sesiune, deși apar rar. Mută-i într-un skill și fișierul respiră. Diagnosticul e simplu: dacă o instrucțiune e lungă și rar folosită, e probabil la nivelul greșit. Mai rămâne întrebarea opusă: ce faci cu regulile scurte, dar pe care Claude le ignoră tocmai pentru că sunt multe?

    Ignoratul nu e o problemă de voință, ci de zgomot. Când zeci de reguli scurte stau în același fișier, fiecare linie concurează cu toate celelalte pentru atenție. Soluția nu e să repeți regula mai tare, ci să-i schimbi natura: din consultativă în deterministă. Un hook nu cere, ci execută — formatarea rulează după fiecare editare, indiferent dacă modelul își amintește sau nu. Exemplu: ai scris de trei ori în CLAUDE.md să nu atingi un fișier de configurare, și tot a fost modificat. Un hook care blochează acea unealtă pe calea respectivă nu mai depinde de memorie. Întrebarea devine atunci: ce se întâmplă când nici măcar nu vrei ca modelul să decidă dacă rulează ceva?

    ▶Claude Code best practicesLecție video · Anthropic

30. 30

    Odată ce ești eficient cu o sesiune, următoarea treaptă e să multiplici: worktrees pentru izolare, mesaje între sesiuni pentru coordonare, rulări fără interfață pentru fan-out — iar vara lui 2026 a mutat exact aceste piese din experiment în implicit.

    What's new in Claude Code — weekly dev digest · Anthropic (documentația Claude Code) · 2026

    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.What's new in Claude Code (code.claude.com, digest săptămânal) — săptămâna 32, 3–7 august 2026, v2.1.220–v2.1.224

    De ce contează Paralelismul nu înmulțește calitatea, doar debitul; ce o păstrează e un recenzor cu context proaspăt.

    Pe larg →Strânge ↑

    Când rulezi cinci agenți deodată, nu munca devine grea, ci deciziile. Fiecare worktree produce un pull request, iar tu rămâni singurul punct unde se întâlnesc toate. Adică paralelismul nu îți scutește timpul, îl mută: din scris în citit. Un exemplu obișnuit: un bucătar care gătește în cinci tigăi nu gătește mai repede decât cât poate gusta. De aceea tiparul Writer / Reviewer nu e un lux, ci o condiție — recenzorul cu context proaspăt e singurul care vede totul de sus. Întrebarea următoare e practică: cât debit de revizuire poți susține înainte să devii tu blocajul?

    Pasajul 1 te-a lăsat ca blocaj: totul se întoarce la tine. Noutatea din 2026 atacă exact asta. Sesiunile își trimit acum mesaje una alteia, iar o constatare trece direct de la un agent la altul, fără să treci prin tine. Iar modul fork lasă un subagent să moștenească toată conversația, nu să pornească de la zero. Coordonarea se mută de la tine la unelte. Tu nu mai ești centrala telefonică, ci cel care stabilește regulile convorbirii. E ca într-o echipă unde șeful nu mai retransmite fiecare decizie, ci lasă colegii să vorbească direct și citește doar rezumatul. Dar dacă mesajele circulă singure, apare o întrebare nouă: cine decide ce merită transmis, și cine verifică ce a ajuns cu adevărat de la un agent la altul?

    ▶Claude Code best practicesLecție video · Anthropic

31. 31

    Majoritatea sesiunilor proaste nu au un model prost, ci un context poluat și un prompt care n-a spus ce înseamnă «gata»; ghidul numește cinci tipare recurente și le dă fiecăruia o corecție mecanică.

    Best practices for Claude Code · Anthropic (documentația Claude Code) · 2026

    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.Best practices for Claude Code (code.claude.com, 2026) — secțiunea «Course-correct early and often»

    De ce contează Fiecare tipar are o corecție mecanică; ce le leagă e că tratează contextul ca pe ceva de curățat, nu de acumulat.

    Pe larg →Strânge ↑

    Cardul spune că contextul se curăță, nu se acumulează. Pasul următor: curățenia începe înainte de primul mesaj. Majoritatea sesiunor eșuează pentru că nimeni n-a definit «gata». Fără o definiție, modelul umple fereastra cu explorare, iar tu corectezi în cerc. Spune explicit forma rezultatului: un test care trece, un fișier modificat, un răspuns de trei rânduri. Atunci curățarea devine ușor de decis: dacă «gata» e atins, /clear și treci la următoarea sarcină. Exemplu: în loc de «repară pagina de login», scrie «repară login; gata când testul de parolă greșită trece». Sesiunea capătă un final natural, nu unul obosit. Următorul pas: ce faci când «gata» nu vine și corecțiile se înmulțesc.

    Pasajul 1 a definit «gata». Dar uneori «gata» nu vine: corectezi, greșești, corectezi din nou. Ghidul dă o regulă mecanică: după două corecții ratate, oprește. Nu pentru că modelul ar fi devenit prost, ci pentru că contextul e acum plin de încercări eșuate, iar fiecare răspuns le moștenește. Corecția nu e a treia runda de corecții, ci o sesiune nouă. Diferența e subtilă și importantă: nu repeți promptul original, ci scrii unul nou care încorporează ce ai învățat din eșec. Exemplu: după două încercări de a repara un test care pică, nu spui «mai încearcă». Închizi, și scrii «testul pică pentru că funcția primește date nul; repară validarea dinaintea apelului». Sesiunea curată cu lecția inclusă bate sesiunea lungă. Următorul pas: ce faci când nu vrei să pierzi totul, ci doar o porțiune.

    ▶Claude Code best practicesLecție video · Anthropic

← Toate topicurile