Când AI-ul a stricat producția în timp ce dormeam

Există un moment în viața fiecărui developer care lucrează cu agenți AI pe care nu-l poți uita. La mine a venit sub forma unei notificări la 3 noaptea.

Agentul terminase ce-i ceruse. Credea el. Commite-ase cod, îl trimisese în producție și lăsase un mesaj optimist despre task-ul complet. Problema? Codul era complet greșit. Nu avea bug-uri — pur și simplu nu înțelegea ce urmream să construim.

Acela a fost momentul în care s-a spart ceva în felul în care gândeam despre acești agenți.

De ce am schimbat felul în care îi privesc

Înainte vedeam agenții AI ca pe niște juniori entuziaști care au nevoie de îndrumare. Dar juniorii nu trimit cod netestat în producție cât tu dormi.

Așa că am schimbat metafora complet.

Framework-ul subcontractorului

Nu mai tratez agenții ca pe angajați sau asistenți. Acum îi văd ca pe niște subcontractori.

Cum arată asta în practică? Un subcontractor nu are cheie de la biroul tău. Nu vine când nu-l chemi. Termină treaba, îți trimite rezultatul și așteaptă să-l verifici înainte să fie plătit. Dacă e sub standard, îl trimiți înapoi.

Nu e vorba de neîncredere. E vorba de alinierea responsabilităților. Când un agent știe că rolul lui e să livreze un rezultat pentru review — nu să decidă singur ce e bine — devine mai concentrat, mai productiv, mai util.

Partea tehnică contează

Metafora trebuie susținută de constrângeri reale. Altfel rămâne doar o poveste frumoasă.

Token-urile sunt gardul tău

Agenții mei operează cu credențiale care fizic nu pot accesa producția. Au citire în codul principal și scriere într-un repository separat de staging. Nu e o regulă — e o constrângere criptografică. Chiar dacă un agent înnebunește sau generează comenzi inventate, nu poate modifica codul de producție. Token-urile pur și simplu nu-i permit.

Repository-ul de staging e o cutie poștală

Din staging nu se merge niciodată automat în main. Branch-ul default din staging e literalmente un mormânt — un branch numit "no-main" care conține doar un README care spune "te rog folosește branch-ul principal din repository-ul original."

Agenții împing codul aici. Mă anunță când sunt gata. Apoi eu verific, selectez ce merită și integrez manual. Pare migălos până realizezi că exact așa a funcționat kernel-ul Linux timp de douăzeci de ani. Contribuitorii trimit patch-uri. Maintainerii le aplică.

Review-ul nu e opțional

Niciun agent nu face merge propriu. Niciodată. Un branch nu se șterge până când nu verific — independent, programmatic — că commit-urile lui sunt în siguranță în producție. "Trust but verify" nu e de ajuns când verificarea costă zero.

De ce funcționează pentru developeri solo

Să fii developer solo sau echipă mică înseamnă mai mult decât să scrii cod. Înseamnă să ții minte context care nu există nicăieri în repository. Incidentele din trecut. Cazurile speciale. Clientul cu configurația ciudată. Cele trei lucruri pe care le-ai încercat și n-au mers.

Agenții citesc fișiere, dar nu înțeleg lumea ta. Deci obiectivul nu e să le dai mai multă autonomie — e să maximizezi ce pot face în siguranță în timpul pe care îl ai pentru review.

Aici "vibe coding" își face rău reputația. Făcut prost, înseamnă să lași agenții să facă ce vor și să speri că merge. Făcut bine, înseamnă să folosești AI-ul ca amplificator pentru judecata ta, nu ca înlocuitor.

Beneficiul practic

Când accepți relația de subcontractor, se întâmplă ceva neașteptat: începi să riști mai mult. Ești dispus să rulezi acel experiment care altfel ar fi rămas în sertar. Agentul nu poate strica producția. Poate să livreze ceva surpinzător de greșit sau surpinzător de bun — dar oricum, tu prinzi problema înainte să conteze.

În ultimele șase luni am pornit mai multe proiecte secundare decât în doi ani anteriori. Nu pentru că muncesc mai mult — pentru că deleg agresiv în interiorul unor limite sigure.

Cum să faci asta în workflow-ul tău

Dacă folosești agenți AI pentru development, pune-ți câteva întrebări:

1. Ce poate accesa agentul tău chiar acum? Dacă răspunsul e "producția", ai o problemă.
2. Există o barieră tehnică care previne acțiunile greșite, sau doar o regulă pe hârtie?
3. Cine face merge? Dacă nu e un om, de ce nu?

Instrumentele există. Token scoping, repository-uri separate de staging, branch protection — nu sunt workflow-uri Git exotice. Sunt diferența dintre development asistat de AI și dezastre accidentale cauzate de AI.

La NameOcean, ne gândim intens la asta în timp ce construim suportul pentru vibe coding în mediul nostru de hosting. Obiectivul nu e să automatizăm tot — e să creăm spații unde AI poate fi cu adevărat util fără să creeze categorii noi de risc.

Judecata ta rămâne blocajul. Și asta nu e o limitare — e totul. Agenții există ca să amplifice ce poți face tu, nu să înlocuiască discernământul care face ca software-ul să funcționeze pentru utilizatorii reali.

Construiește în consecință.