Zece mii de dolari pe săptămână

În iulie 2026, o echipă de trei senior engineers pe nume Slopfix a ajuns pe prima pagină a Hacker News cu o ofertă neobișnuită: „O săptămână. Trei senior engineers. 10.000 de dolari.” Treaba lor nu e să scrie cod, ci să-l șteargă. Preiau codebase-uri construite cu coding agents și le aduc înapoi la ceva ce o echipă poate întreține, iar plata e proporțională cu cât din reducerea de linii de cod agreată reușesc să livreze.

Diagnosticul lor încape într-o frază: „Asta se întâmplă oricărui proiect vibecoded peste o anumită dimensiune: agentul nu mai vede imaginea de ansamblu și începe să duplice cod în loc să-l găsească.” Nimeni n-a șters vreo bază de date și niciun agent n-a scăpat de sub control. Agentul a făcut ce i s-a cerut, task după task, până când „adăugarea unui feature durează acum zile și strică alte două lucruri”. Exemplul lor de curățenie: „cele paisprezece formatoare de dată devin unul singur”.

Surpriza e în propriul lor FAQ: „Da, folosim și noi Claude Code. În lesă foarte scurtă.” Același tip de agent care a produs dezastrul e cel care face curat. Diferența e structura din jurul lui: o listă scrisă cu ce face aplicația, ecran cu ecran, înainte să se taie ceva; senior engineers care decid ce rămâne; și, printre livrabile, un CLAUDE.md, reguli de lint și verificări în CI. Cum spun ei, „agentul nu are drept de vot”.

Folosesc Slopfix ca ilustrare publică a unui pattern de eșec, nu ca studiu de caz auditat. Sursa și limitele ei sunt în Anexa C.

De ce se tot întâmplă asta. Un senior engineer îmi spune că a încercat Claude Code, sau Codex, sau alt coding agent, și că „n-a mers”: codul arăta corect, dar nu era, sau s-a stricat ceva și nimeni n-a observat timp de două săptămâni. Cele mai multe adopții ratate nu se explică doar prin slăbiciunea modelului. Sunt eșecuri ale structurii din jurul agentului: lipsește contextul, lipsesc constrângerile, lipsește procesul, lipsește disciplina de review.

Un ciocan îl iei din raft și îl folosești. Un inginer junior nu-l iei din raft să-l folosești: trebuie să-i faci onboarding, să-i dai context, să pui la punct review-ul, să construiești încredere în timp. Agenții sunt mai aproape de inginerul junior decât de ciocan - o poziție de lucru, nu o afirmație despre natura agentului: agentul e software.

Teza. Livrarea de software cu agenți nu e în primul rând o problemă de tooling. E o problemă de control. Controlează contextul, acțiunile, verificarea și suprafața de adopție, și agentul devine util; dacă nu le controlezi, devine zgomot scump sau risc operațional. Cele trei părți ale manualului sunt trei controale: Arhitectura e controlul capabilității (ce poate ști și ce poate face agentul), Metoda e controlul workflow-ului (cum se formulează, se execută și se verifică munca), Realitatea e controlul adopției (unde aplici metoda și unde n-ar trebui s-o aplici).

Prin „agentic” înțeleg un sistem care primește un obiectiv, decide ce acțiuni trebuie executate și le execută, cu o anumită doză de autonomie. Nu mai scrii tu fiecare apăsare de tastă; superviezi munca. Agenții nu oferă tastat mai rapid, ci posibilitatea de a delega muncă bine formulată. Să înțelegi problema, ideea de pe copertă, e partea care rămâne a ta.

Nu o să-ți spun ce agent să alegi. Agentul pe care îl alegi azi va fi deprecated, rebranduit sau înghițit de un produs mai mare într-un ciclu de procurement. Felul în care gândești munca supraviețuiește înlocuirii.

De unde vorbesc. Scriu software profesionist din 2000 și construiesc sisteme AI de mai bine de un deceniu. Am folosit fiecare generație de asistent de coding, de la inteligența timpurie din IDE-uri la Copilot și până la coding agents de azi, iar în ultimele optsprezece luni am urmărit echipe de producție care adoptă workflow-uri cu agenți - unele bine, altele prost. Manualul ăsta e ce a supraviețuit utilizării repetate în echipe reale. Contextul complet: Despre autor.

Unde poate greși.

• Tool-urile se vor schimba. Produsele pe care le numesc, formatele de hook-uri, sintaxa regulilor de permisiuni și prețurile vor îmbătrâni. Componentele principale și modelul în cinci straturi sunt ce mă aștept să reziste.
• Mediile reglementate sunt altfel. Presupun că poți instala hook-uri, configura AGENTS.md, pune la punct sandbox-uri și rula subagenți. Acolo unde asta cere un review board sau luni de procurement, manualul descrie destinația, nu drumul.
• Procesul are un cost. Pornește cu agentul nativ și controalele existente ale echipei. Adaugă planificare, skill-uri și revieweri unde task-ul le cere; cele șase faze din Capitolul 4 numesc funcții, nu șase documente sau opriri obligatorii pentru aprobare.

Recomandările despre workflow, skill-uri, delegare, review și fișierele de instrucțiuni au fost revizuite pe 23 octombrie 2026. Celelalte afirmații despre produse și cercetare își păstrează datele și limitele din Anexa C; această revizie nu reprezintă un nou fact-check al întregului manual. Actualizările care contează sunt în changelog.

Cum se citește. Manualul e scris pentru senior engineer - staff, principal sau tech lead - care va pune practica asta pe picioare într-o echipă reală și o va apăra în sus; oricine livrează software cu AI îl poate urmări. Citește-l în ordine pentru argumentul complet sau alege un traseu care se încheie cu un rezultat inspectabil. Anexa D cuprinde dovezile extinse și limitele lor.