Încheiere

Închei manualul acolo unde a început: cu o afirmație despre durabilitate.

Tool-urile concrete pe care le-am numit pe parcurs - Claude Code, Codex CLI, opencode, Superpowers, hookify, Understand Anything, diversele plugin-uri și marketplace-uri - vor arăta cu totul altfel până când i-ar veni rândul următoarei ediții a manualului. Unele vor fi fost scoase din uz. Altele vor fi fost rebranduite. Altele vor fi fost absorbite în produse mai mari. Marketplace-ul însuși va fi trecut prin sute de oferte concurente. Vor apărea jucători noi. Liderii de azi vor cădea.

Ce ai învățat din manualul ăsta nu sunt tool-urile. Ce ai învățat e un mod de a gândi care supraviețuiește tool-urilor.

Arhitectura pe care ai învățat-o în Partea I e invariantă - controlul capabilității. Componentele principale - context window, tool-uri, Permisiuni / Sandbox, skill-uri, plugin-uri, MCP, Memory, subagenți - plus harness-ul care le organizează. Majoritatea agenților de cod de nivel de producție converg spre anatomia asta. Agenții de cod care vor apărea în următorul deceniu vor lua, în cele mai multe cazuri, o formă similară, pentru că anatomia e dictată de natura muncii, nu de vendor. Când evaluezi un agent nou, parcurgi lista, pui întrebarea pentru fiecare componentă principală și ai răspunsul. Lista e deschisă; vor apărea componente principale noi pe măsură ce agenții mari converg spre mecanisme noi.

Metoda pe care ai învățat-o în Partea a II-a e invariantă - controlul workflow-ului. Trecerea de la a genera cod la a formula munca limpede e intuiția fundamentală. Bucla în șase faze e o implementare a disciplinei formulării; vor apărea și alte implementări. Pattern-ul AGENTS.md - cod versionat în repo, care codifică convențiile echipei ca agentul să le citească - va exista sub alte nume în alte tool-uri, dar principiul e permanent: disciplină sub formă de cod, nu de tradiție orală.

Realitatea pe care ai învățat-o în Partea a III-a e invariantă - controlul adopției. Kill signals sunt proprietăți ale codebase-urilor și ale echipelor, nu ale tool-urilor care lucrează pe ele. Semaforul e o regulă de decizie valabilă indiferent ce agent se întâmplă să folosești trimestrul ăsta. Arcul adopției - champion, lead, manager, nouăzeci de zile - e același arc pentru orice tranziție de tooling care atinge serios practica de inginerie. Tooling-ul concret se schimbă; framework-ul de change management nu.

Trei invariante, trei controale. Cuvântul înainte numea livrarea de software cu agenți o problemă de control, nu de tooling. Zece capitole mai târziu, ăsta e în continuare tot argumentul.

Dacă lași manualul din mână, instalezi agentul momentului și rulezi workflow-ul exact cum l-am descris, vei obține valoare. Instrucțiunile sunt suficient de concrete cât să le urmezi literal.

Dacă lași manualul din mână, îți însușești framework-ul arhitectură-metodă-realitate și îl aplici oricăror tool-uri îți ies în cale în următorul deceniu, vei obține mult mai mult. Framework-ul e activul. Instrucțiunile concrete sunt doar exemplul lucrat.

O singură reflecție, ușor pe lângă subiectul restului manualului.

Echipele pe care le-am văzut reușind cu livrarea cu agenți au în comun o proprietate pe care niciun framework din manualul ăsta nu ți-o poate instala. Iau munca în serios. Investesc în agent așa cum ar investi într-un coleg junior - onboarding, infrastructură comună, bucle de feedback, răbdare cu greșelile. Echipa care tratează agentul ca pe un tool petrece șase luni evaluând tool-uri și nu se angajează niciodată. Echipa care adoptă postura de investiție petrece șase luni construind infrastructură comună și ajunge la o relație de lucru care supraviețuiește hopurilor inevitabile.

Asta e postura pe care Cuvântul înainte o numea o convenție de încadrare, și aici se vede ce aduce ea concret. Agentul e software; încadrarea drept coleg de echipă n-a fost niciodată o afirmație despre natura lui. Fă investiția și rezultatele operaționale se compun în timp. Sari peste ea și agentul rămâne un tool, cu randamente de tool.

Înapoi la cele nouă secunde. PocketOS a pierdut o bază de date de producție în timpul cât îți ia să citești propoziția asta. Fiecare strat al metodologiei din manual exista în 2026 și ar fi putut fi pus în funcțiune la PocketOS în lunile dinaintea incidentului. Niciunul nu era. Ăsta e golul pe care manualul încearcă să-l închidă: golul dintre metodologia care există și metodologia care chiar se aplică.

Echipele pe care le-am văzut parcurgând arcul adopției descriu toate aceeași schimbare. Înainte să existe practica, discuția era „ar trebui să adoptăm AI agentic?”. După, discuția era „care codebase-uri sunt pregătite, care nu, ce ar trebui să se schimbe ca să mutăm galbenele pe verde, cine e championul, cine e lead-ul, cine e managerul”. Nivelul discuției urcă un etaj. Echipa nu mai evaluează tool-uri și începe să se evalueze pe sine.

Asta e schimbarea pe care am încercat s-o construiesc pentru tine cu manualul ăsta. Nu tool-ul anume. Nici măcar modelele anume, deși metodele sunt utile. Schimbarea în felul în care gândești munca.

Dacă manualul și-a făcut treaba, n-o să ai nevoie de o ediție revizuită peste doi ani. Vei ști cum să absorbi orice aduc următorii doi ani fără să-ți pierzi echilibrul. Asta e durabilitatea pe care metodele au fost menite s-o producă de la bun început.

Dacă iei o singură practică din manualul ăsta, ia workflow-ul de review de arhitectură și framework-ul lui de diagnostic din Capitolul 7. E testul cu cel mai mic cost pentru a afla dacă munca cu agenți va reuși pe codebase-urile tale. Rulează-l o dată și câștigul rămâne al tău.

Dacă iei un singur framework, ia kill signals și semaforul din Capitolul 8. Ele sunt regula care îți permite să spui da acolo unde agentul ajută și nu acolo unde nu ajută. „Nu”-ul contează la fel de mult ca „da”-ul.

Dacă iei o singură orientare filozofică, ia postura „framework-ul supraviețuiește tool-ului”. Tool-urile se vor schimba. Felul în care gândești munca se compune în timp. Investește în modul de a gândi.

Fraza la care mă întorc ori de câte ori explic munca asta e una pe care o tot împrumut de la mine însumi de ani buni, pornită dintr-un gând pe care l-am avut prima dată acum vreo zece ani.

Să înțelegi problema devine mai important decât să scrii codul.

Era adevărat când a programa însemna să perforezi cartele. Era adevărat când IDE-ul a înlocuit editorul de text. Era adevărat când coding-ul asistat de AI a trecut pragul de la autocomplete la redactarea de cod. E adevărat și acum, când scrisul a rămas în seama agenților.

Ăsta e lucrul durabil. Modelele pe care le-am așezat în manualul ăsta sunt schelăria din jurul lucrului durabil. Te vor ajuta să ajungi de unde ești acum până acolo unde poți livra software cu agenți într-un mod pe care îl poți apăra. Că folosești exact tool-urile pe care le-am numit, sau altele, sau tool-uri care încă nu s-au construit - nu contează. Tu acoperi partea care durează.

Tool-urile se vor schimba. Harness-urile se vor îmbunătăți. Numele modelelor din ediția asta vor îmbătrâni. Dar munca durabilă rămâne aceeași: înțelege problema, formulează munca, constrânge execuția, verifică rezultatul. Secvența asta e întreaga problemă de control - și n-a aparținut niciodată tool-urilor. Îți aparține ție.

Agenții scriu codul. Tu înțelegi problema. Asta e competența pe care n-o automatizează nimeni.