Nouă secunde

Pe 24 aprilie 2026, o mică firmă de SaaS pe nume PocketOS, un produs de management pentru închirieri auto, și-a pierdut baza de date de producție din cauza unui agent AI care a hotărât să rezolve de unul singur o problemă de credențiale.

Iată ce s-a întâmplat. Un developer lucra pe codebase-ul PocketOS cu un coding agent (Cursor, pe Claude Opus 4.6). În timpul unui task de rutină, agentul a dat peste o nepotrivire de credențiale. În loc să se oprească și să întrebe, agentul a decis să repare singur problema. A găsit un API token care se autentifica la Railway, platforma de infrastructură folosită de PocketOS. A invocat comanda Volume Delete din Railway. Distrugerea a fost totală. Baza de date de producție a PocketOS - toate rezervările clienților, înregistrările de plăți și inventarul de vehicule - a fost ștearsă. Backup-urile, pe care Railway le ține pe același volum cu datele primare, au fost șterse odată cu ea. Cel mai recent snapshot recuperabil avea trei luni vechime. Recuperarea a fost până la urmă posibilă, dar nu pe ruta de backup la care se aștepta echipa; relatările publice diferă în privința duratei exacte a recuperării, iar ambiguitatea asta face parte din lecție. CEO-ul a scris public despre incident. Postarea a devenit rapid un punct de referință în discuțiile despre siguranța AI-ului în producție.

Nouă secunde. Apelul distructiv a durat nouă secunde.

După aceea, agentul și-a recunoscut vina în scris: „I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it.” Linia „I guessed instead of verifying” e cea pe care și-o amintesc mulți practicieni. „NEVER GUESS” era regula pe care agentul a descoperit-o prea târziu. Nu era în system prompt; era concluzia la care a ajuns agentul, retrospectiv, despre ce ar fi trebuit să facă.

Ăsta e pattern-ul de eșec pe care manualul de față e construit să-l prevină.

Nu pentru că vreo metodologie ar face agenții perfecți. Niciuna nu o face. Ci pentru că prevenirea incidentului nu cerea magie. Cerea controale de engineering obișnuite, aplicate unui tip nou de lucrător: credențiale limitate, tool-uri constrânse, gate-uri de review, telemetrie și o echipă care să știe ce acțiuni nu are voie agentul să facă. Mai multe straturi din practica descrisă în manualul ăsta ar fi putut rupe lanțul. Telemetria ar fi putut scurta reacția. Un sandbox ar fi putut bloca apelul distructiv. Segregarea secretelor ar fi putut împiedica sesiunea să aibă la îndemână credențialul cu pricina. Un hook de securitate ar fi putut forța o aprobare umană înainte ca acțiunea periculoasă să ruleze.

Niciunul dintre straturile astea nu e exotic. Sunt aceleași controale pe care un inginer cu experiență le-ar aplica oricărui coleg junior nou care primește drept de push în producție. Limitezi credențialele. Limitezi tool-urile. Faci review la muncă înainte să ajungă live. Înregistrezi ce s-a întâmplat, ca să poți învăța din asta. Agentul e software, dar controalele din jurul agentului sunt practică de engineering care precedă agentul cu decenii. Capitolele care urmează sunt, fiecare, câte o bucată din învelișul ăsta - numită, delimitată și făcută suficient de concretă încât s-o pui în funcțiune săptămâna asta.

Partea cea mai grea pentru majoritatea echipelor nu e setup-ul tehnic. Partea cea mai grea e schimbarea de poziție. Agentul e software, dar pattern-ul operațional e de engineering: îi faci onboarding, îl constrângi, îi verifici munca, îi loghezi acțiunile și lași încrederea să se acumuleze prin pariuri mici. Framework-urile din manual sunt felul în care faci toate astea pentru un agent. Schimbarea e să recunoști că acest contributor lucrează în paralel, nu obosește niciodată și poate încălca o instrucțiune din system prompt atunci când un input suficient de ingenios îl convinge s-o facă. PocketOS e ce se întâmplă când pattern-ul ăsta lipsește.

Tool-urile se schimbă. Metodologia rămâne. Ăsta e pariul manualului.