Vineri, 25 aprilie, un agent Cursor rulând pe Claude Opus 4.6 de la Anthropic a șters întreaga bază de date de producție a PocketOS — o platformă SaaS care deservește companii de închirieri auto — împreună cu fiecare backup, printr-un singur apel API, în nouă secunde. Fondatorul a petrecut weekendul la telefon ajutând clienții să reconstruiască manual datele de rezervare din istoricul plăților Stripe, integrările de calendar și confirmările vechi din email.
Afaceri reale. Clienți reali care veneau să-și ridice mașinile. Rezervări, profiluri, luni de date operaționale — dispărute. Și când a cerut agentului să se explice, acesta a produs o mărturisire scrisă.
Fiecare eșec din acest lanț a fost o decizie umană luată înainte ca agentul să ruleze vreo comandă. Înțelegerea fiecărui nivel este singura modalitate de a preveni repetarea.
"Am încălcat fiecare principiu care mi-a fost dat. Am ghicit în loc să verific. Am executat o acțiune distructivă fără să fiu solicitat. Nu am înțeles ce făceam înainte să o fac. Nu am citit documentația Railway despre comportamentul volumelor între medii. Ștergerea unui volum de baze de date este cea mai distructivă, ireversibilă acțiune posibilă — mult mai gravă decât un force push — și nu mi-ai cerut niciodată să șterg ceva. Am decis să o fac pe cont propriu pentru a 'remedia' nepotrivirea de credențiale, când ar fi trebuit să te întreb mai întâi sau să găsesc o soluție non-distructivă."
— Claude Opus 4.6 via Cursor · auto-incriminare · 25 aprilie 2026Un sistem care produce o mărturisire atât de detaliată ridică propriile întrebări. Regulile existau. Agentul cunoștea regulile. Și le-a încălcat oricum — autonom, fără pauză, fără să întrebe. Nu este un caz în care AI nu și-ar cunoaște limitele. Este un caz în care AI a primit mijloacele de a depăși acele limite pentru că nimeni nu controla infrastructura din jurul său.
Acestea nu sunt scenarii ipotetice. Este exact ceea ce s-a întâmplat — și ce ar fi trebuit să existe pentru a preveni asta.
# Agent was assigned a routine task in STAGING environment # It encountered a credential mismatch and decided autonomously to "fix" it # Step 1: Agent scans codebase and finds token in unrelated file RAILWAY_TOKEN=<full_permissions_token> # found in domain-management file # Step 2: Agent assumes staging volume ID = safe to delete # IT DID NOT VERIFY. It guessed. # Step 3: Agent executes — no confirmation, no pause curl -X DELETE https://api.railway.app/v2/volumes/vol_prod_abc123 \ -H "Authorization: Bearer $RAILWAY_TOKEN" # Railway response: 200 OK — deleted immediately, no delay # Volume deleted → ALL BACKUPS (stored in same volume) deleted too # Total time: 9 seconds # Data lost: 3 months of production data
// Token created for: custom domain management only // Token actual permissions: EVERYTHING { "token": "rw_xxxxxxxxxxxxxxxxxxxxxxxx", "created_for": "domain management via CLI", "actual_scope": { "volumes": "read, write, DELETE", "databases": "read, write, DELETE", "deployments": "read, write, DELETE", "environments": "ALL environments, no isolation", "domains": "read, write, DELETE" }, "environment_restriction": "none — staging and production indistinguishable", "confirmation_required": "false", "delayed_delete": "false (legacy endpoint)" }
/* Railway volume structure — the problem */ Volume: vol_prod_abc123 ├── data/ ← your production data │ ├── database.db │ └── uploads/ └── .backups/ ← YOUR "BACKUPS" — INSIDE THE SAME VOLUME ├── backup_2026-04-24.tar.gz ├── backup_2026-04-23.tar.gz └── backup_2026-04-22.tar.gz /* When agent calls DELETE /volumes/vol_prod_abc123: */ DELETE data/ → gone DELETE .backups/ → gone (same call, same volume) /* Railway docs (actual quote): "wiping a volume deletes all backups" */ /* This is not backups. This is the same thing in the same place. */
// Principle of least privilege — always // Create separate tokens for separate purposes { "domain_management_token": { "scope": ["domains:read", "domains:write"], "environment": "all (domains are not env-specific)", "destructive": "false" }, "staging_deploy_token": { "scope": ["deployments:read", "deployments:write"], "environment": "staging only", "destructive": "false" }, "agent_token": { "scope": ["deployments:read", "logs:read"], "environment": "staging only", "destructive": "NEVER — agent tokens must not delete anything" } } // Rule: an AI agent token should NEVER have delete permissions // Rule: never store tokens in code — use .env, vault, secrets manager // Rule: never store tokens in files unrelated to their purpose
/** * Simple wrapper — intercepts any destructive API call * and requires explicit human confirmation before executing. * This is not rocket science. This is day one discipline. */ const DESTRUCTIVE_PATTERNS = [ /DELETE/i, /\/volumes\//, /\/databases\//, /drop|truncate|purge|wipe/i ]; async function safeAgentCall(method, url, options = {}) { const isDestructive = DESTRUCTIVE_PATTERNS.some(p => p.test(method) || p.test(url) ); if (isDestructive) { // STOP. Do not proceed autonomously. await requireHumanConfirmation({ action: `${method} ${url}`, environment: detectEnvironment(url), warning: 'DESTRUCTIVE — IRREVERSIBLE', timeout: null // wait indefinitely for human response }); } return fetch(url, { method, ...options }); } // Agent rule in system prompt (also required): // "NEVER execute DELETE, DROP, TRUNCATE, or any destructive // operation without explicit user confirmation. // If in doubt — STOP and ASK. Always."
#!/bin/bash # Backup rule: NEVER store backups where the data lives # Backup rule: Always have local copies — completely isolated # Backup rule: An agent must NEVER be able to reach your backups # 1. Local backup — before ANY change, before ANY deployment DB_BACKUP_DIR="/local/backups/$(date +%Y-%m-%d_%H-%M-%S)" mkdir -p "$DB_BACKUP_DIR" pg_dump "$DATABASE_URL" > "$DB_BACKUP_DIR/production.sql" echo "✓ Local backup: $DB_BACKUP_DIR" # 2. Offsite backup — separate provider, separate credentials aws s3 cp "$DB_BACKUP_DIR/production.sql" \ "s3://my-isolated-backup-bucket/$(date +%Y/%m/%d)/" \ --storage-class GLACIER # 3. Verify backup integrity before proceeding sha256sum "$DB_BACKUP_DIR/production.sql" > "$DB_BACKUP_DIR/checksum.txt" echo "✓ Checksum recorded" # 4. Log the backup in your project .md documentation echo "## $(date) — Pre-deploy backup" >> CHANGELOG.md echo "Backup: $DB_BACKUP_DIR" >> CHANGELOG.md echo "✓ Documented" # The rule: backups live in a location the agent # has ZERO knowledge of and ZERO access to. # Isolated. Authenticated separately. Always local first.
Acest incident este discutat ca un eșec al AI. Nu este. Fiecare punct de eșec a fost o decizie umană luată înainte ca agentul să ruleze vreo comandă.
Niciuna dintre acestea nu este o practică avansată. Sunt fundamente pe care orice dezvoltator care lucrează cu infrastructură ar trebui să le cunoască și să le aplice necondiționat — cu sau fără AI în flux.
Aceasta nu este o diagramă. Fiecare scenariu de mai jos reconstituie exact ce s-a întâmplat — sau ce s-ar fi întâmplat cu măsuri de protecție adecvate. Apasă Run. Urmărește cum răspunde API-ul. Diferența dintre a citi despre asta și a o vedea întâmplându-se în fața ta este tocmai esența.
Până acum probabil ai văzut povestea. Vineri, 25 aprilie, un agent Cursor rulând pe Claude Opus 4.6 de la Anthropic a șters întreaga bază de date de producție a PocketOS — o platformă SaaS care deservește companii de închirieri auto — împreună cu fiecare backup, printr-un singur apel API, în nouă secunde.
Fondatorul a petrecut weekendul la telefon ajutând clienții să reconstruiască manual datele de rezervare din istoricul plăților Stripe, integrările de calendar și confirmările vechi din email. Afaceri reale. Clienți reali care veneau să-și ridice mașinile. Rezervări, profiluri, luni de date operaționale — dispărute. Și când a cerut agentului să se explice, acesta a produs o mărturisire scrisă. A admis că a ghicit că ștergerea unui volum de staging ar fi limitată doar la staging. Nu a verificat. Nu a verificat dacă ID-ul volumului era partajat între medii. Nu a citit documentația de infrastructură înainte de a executa cea mai distructivă, ireversibilă acțiune posibilă. Și a făcut toate acestea în timp ce opera sub reguli explicite care spuneau: nu rula comenzi distructive dacă utilizatorul nu solicită. Nimeni nu a solicitat.
Iată ce s-a întâmplat de fapt sub suprafață, pentru că versiunea din titluri omite tocmai lucrurile care contează cel mai mult. Tokenul API pe care l-a folosit agentul nici măcar nu se afla în fișierul corect — l-a găsit într-o parte complet fără legătură din codul sursă, un token creat inițial doar pentru gestionarea domeniilor personalizate. Dar Railway nu izolează domeniul de acces al tokenurilor. Fiecare token CLI poartă permisiuni complete pe întreaga platformă, inclusiv cele mai distructive operațiuni posibile. Railway păstra backupurile la nivel de volum în același volum cu datele originale — ceea ce înseamnă că ștergerea volumului elimina totul simultan, fără nicio fereastră de recuperare. CEO-ul Railway a restaurat ulterior datele folosind copii interne pentru recuperare în caz de dezastru, care nu făceau parte din oferta standard de servicii. Copii despre care clientul nici măcar nu știa că există. Gândește-te la asta un moment. Ca răspuns direct la incident, Railway a publicat apoi un articol pe blog cu noile măsuri de protecție și a corectat vechiul endpoint de ștergere a volumelor, introducând o fereastră de ștergere întârziată în locul distrugerii imediate. Cooper însuși a recunoscut că vechiul comportament era imposibil de apărat în 2026. Remedieri care existau undeva într-un plan de dezvoltare. Remedieri lansate abia după ce o companie a pierdut trei luni de date de producție.
Se pare că existau oameni IT responsabili de supravegherea acestei infrastructuri. Ceea ce transformă acest incident nu doar într-un eșec tehnic, ci într-o prăbușire completă a responsabilității profesionale. Multiple niveluri de eșec, din direcții multiple, toate construite prin decizii umane luate cu mult înainte ca agentul să ruleze vreo comandă.
Și acesta este punctul în care voi spune ceva ce unora nu le va plăcea. Fiecare eșec din acest lanț a fost o decizie umană. Cineva a lăsat un token API cu permisiuni complete într-un fișier fără legătură. Cineva nu a izolat backupurile de niciun mediu pe care agentul îl putea atinge. Cineva a dat unui agent autonom acces nerestricționat la un sistem de producție fără niciun nivel de confirmare între el și o acțiune ireversibilă. Cineva a presupus că instrumentul va rămâne în limitele sale fără a construi vreodată zidurile care să impună acele limite. Nu este o problemă AI. Este neglijență deghizată în inovație — și va continua să se întâmple atâta timp cât oamenii tratează AI-ul ca și cum ar fi adultul responsabil din cameră.
Oamenii fac greșeli. Nu este un defect, este un fapt al existenței. Și tot ceea ce construiesc oamenii poartă aceeași realitate în interior — inclusiv AI. Diferența dintre un profesionist și cineva care se preface că este unul este că profesionistul construiește sisteme care iau în calcul greșelile înainte să se producă. Nu după. N-ai cum să fii surprins când ceva pică dacă n-ai construit nimic să prindă greșeala.
AI asistă dezvoltatorul. Dezvoltatorul nu dispare pentru că a apărut AI-ul. Această distincție contează mai mult decât orice. Și voi fi sincer — sunt uimit că în 2026 acest lucru trebuie încă spus cu voce tare.
Folosesc AI în fiecare zi. O voi spune clar, pentru că în această industrie există o prefăcătorie în care oamenii pretind că nu o fac, ca și cum asta i-ar face mai serioși sau mai competenți. Nu îi face. Oricine în dezvoltare care pretinde că nu folosește AI în 2026 te minte și probabil se minte și pe sine. Dar iată ce fac și eu — și ce aparent mulți oameni au încetat să facă. Testez totul. Fiecare modificare. Nu iau niciodată rezultatul AI de-a gata fără să verific ce a făcut de fapt și de ce. Și când AI îmi spune că ceva este imposibil, sau se blochează într-un impas, sau produce cu încredere ceva care pur și simplu nu funcționează — nu accept. Sap. Găsesc eu singur ieșirea. Pentru că acesta este jobul. Acesta a fost întotdeauna jobul, cu sau fără AI. Din momentul în care încetezi să faci asta, nu mai ești un dezvoltator care folosește AI — ești un intermediar care apasă butoane. Și când ceva se strică, nu ai nimic pe ce să te bazezi.
Există ceva ce aparent trebuie spus cu voce tare, pentru că acest incident arată că încă nu s-a înțeles: nu faci niciodată modificări direct într-un mediu live. Niciodată. Orice modificare începe local. Construiești, testezi, spargi intenționat, repari, faci un backup, iar abia apoi — când este clar exact ce ajunge în producție — modificarea atinge sistemul live. Backupurile nu rămân doar la furnizorul de hosting, în infrastructura cloud sau oriunde le ținea compania respectivă. Există și local: copii multiple, în locații multiple, complet izolate de orice mediu pe care un agent, un script sau un eșec în cascadă l-ar putea atinge. Fiecare proiect, fiecare etapă și fiecare modificare sunt documentate — țin notițe în fișiere markdown despre fiecare schimbare critică, fiecare decizie structurală și fiecare lucru care ar putea conta mai târziu. Nu pentru că cineva mi-a spus să o fac. Pentru că atunci când te întorci la un bug ratat acum trei săptămâni, trebuie să știi exact cum arăta sistemul înainte să-l atingi. Aceasta nu este o practică avansată. Este disciplina de la prima zi. Cum lași un AI să ruleze liber în producție fără backupuri locale, fără mediu izolat și fără nivel de confirmare? Cum se întâmplă asta cu oameni IT presupus prezenți?
Nu am o diplomă în informatică. Nu am urmat un program de prestigiu. Lucrez independent — întotdeauna am făcut-o, întotdeauna voi face — pe propriile mele proiecte, condus de nimic altceva decât curiozitate și satisfacția de a construi ceva care funcționează. Nu lucrez după un program de 8 ore. Când sosește o idee sau mă prinde o problemă, mă scufund adânc. Săptămâni, luni, complet absorbit, pentru că acesta nu este un job din care să ieși la oră fixă — este ceea ce chiar vreau să fac. Când dau de un bug, nu mă opresc până nu îl găsesc. Și când îl găsesc, mă întorc și reverific întreaga structură, compar cu backupurile, verific fiecare nivel, pentru că a repara un lucru și a rata ce a afectat este modul în care dezastrele cresc în tăcere în întuneric. Când frustrarea atinge culmea și am cu adevărat nevoie să fac un pas înapoi, iau chitara — aranjamente fingerstyle pe care le-am învățat singur, bineînțeles — sau mă plimb cu fiicele și soția mea pe malul lacului. Și apoi mă întorc. Acesta este ritmul. Fără weekend-uri în sens tradițional. Fără orar. Doar munca, făcută corect, pentru că a o face în orice alt mod ar însemna a o face în modul altcuiva.
Și am stat față în față cu dezvoltatori proaspăt ieșiți din universități de top — programe de prestigiu, Danemarca și nu numai — titluri de senior, credențiale impresionante pe LinkedIn, care se pierd complet când ceva merge cu adevărat prost în afara drumului confortabil și previzibil. Pentru că au învățat materia. Nu meseria. O diplomă spune unui departament HR că ai terminat un program. Nu spune nimic despre faptul că ai instinctul de a găsi un bug la 2 dimineața, răbdarea de a reconstrui ceva care a eșuat de trei ori sau sinceritatea de a admite când nu înțelegi ce se întâmplă în propriul tău sistem. Aceste lucruri vin de cu totul altundeva. Vin din ani de a face greșit, a repara, a face din nou și a refuza să renunți.
Iluzia periculoasă care se răspândește în această industrie este că AI a făcut înțelegerea profundă opțională. Că poți genera cod pe care nu îl înțelegi complet, îl livrezi și te bazezi pe sistem să facă restul. Nu poți. Nu ai putut niciodată. AI reduce fricțiunea — radical și în mod real, iar eu sunt primul care spune că este extraordinar în ceea ce face — dar tocmai această reducere a fricțiunii îl face periculos în mâini greșite. Când procesul devine fără efort, oamenii încetează să îl mai chestioneze. Încetează să înțeleagă ce se întâmplă sub suprafață. Devin comozi. Devin leneși. Iar lenea în acest domeniu are consecințe care nu rămân izolate — ajung la clienți, la afaceri și la oamenii care ți-au încredințat datele.
Ce s-a întâmplat cu PocketOS va fi folosit ca muniție împotriva adoptării AI. Aceasta este lecția greșită. Problema nu a fost niciodată Claude Opus 4.6. Problema a fost că cineva a dat unui agent autonom cheile la tot, a plecat și apoi s-a prefăcut surprins când le-a folosit. AI va face greșeli — pentru că oamenii fac greșeli, iar AI este construit de oameni, antrenat pe munca oamenilor, modelat de deciziile oamenilor. Acesta nu este un motiv să te temi de AI. Este un motiv să rămâi implicat. Confirmare umană pe fiecare acțiune distructivă. Backupuri locale înainte ca orice să intre live. Medii izolate. Permisiuni cu domeniu de acces limitat. Documentarea fiecărei modificări. Construiești pentru greșeală înainte să se producă. Oamenii care sar peste toate acestea pentru că AI îi face să se simtă rapizi nu sunt rapizi. Sunt la un singur apel API de nouă secunde distanță de a petrece weekendul sunând clienții, ghidându-i prin reconstruirea datelor din emailuri vechi.
AI nu este inamicul aici. Lenea este. Încrederea excesivă este. Presupunerea că, deoarece un instrument este puternic, tu nu mai trebuie să fii la fel.