---
title: "Cum lucrăm cu o flotă de agenți AI de programare fără să pierdem muncă"
description: "Rulăm mulți agenți AI de programare deodată, adesea pe aceleași fișiere și aceleași sisteme. Aproape nimic din ce am pierdut nu a venit din cod prost. A venit din coordonare: agenți care împart un spațiu de lucru, două fluxuri care scriu același fișier live, un deploy care a publicat munca neterminată a altcuiva și fluxuri care au murit împreună și au fost reluate orbește. Acestea sunt regulile după care lucrăm acum."
date: 2026-10-11
lang: ro
canonical: https://goingstellar.ro/ro/metode/lucrul-cu-o-flota-de-agenti-ai/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Proces / Agenți AI
license: CC BY 4.0
alternate_en: https://goingstellar.ro/methods/working-with-a-fleet-of-ai-coding-agents/
---

# Cum lucrăm cu o flotă de agenți AI de programare fără să pierdem muncă

*Rulăm mulți agenți AI de programare deodată, adesea pe aceleași fișiere și aceleași sisteme. Aproape nimic din ce am pierdut nu a venit din cod prost. A venit din coordonare: agenți care împart un spațiu de lucru, două fluxuri care scriu același fișier live, un deploy care a publicat munca neterminată a altcuiva și fluxuri care au murit împreună și au fost reluate orbește. Acestea sunt regulile după care lucrăm acum.*

> Proces · Agenți AI · 2026-10-11 · https://goingstellar.ro/ro/metode/lucrul-cu-o-flota-de-agenti-ai/

## Pe scurt

- Când mulți agenți AI de programare rulează în paralel, aproape toată munca pierdută vine din coordonare, nu din cod prost.
- Directorul de lucru al unei sesiuni arată privat, dar e comun tuturor agenților din sesiune, deci orice prompt de fan-out trebuie să ceară nume unice pentru copiile de siguranță.
- Fiecare fișier live trebuie să aibă un singur proprietar cât timp rulează fluxuri paralele, pentru că fluxurile paralele se ciocnesc la prima reparație, nu la prima citire.
- Un push reușit spune că transferul a mers, nu ce s-a transferat, așa că după fiecare deploy sursa servită se compară cu cea locală, fișier cu fișier.
- O reparație se testează pe cazuri care funcționează deja, unde ținta e zero modificări, fiindcă mulțimea cazurilor eșuate nu conține contraexemple.

## La ce folosește

Agenții în paralel înmulțesc producția și înmulțesc și felurile în care o poți pierde. Fiecare incident de mai jos ni s-a întâmplat nouă, cu agenții noștri, pe sistemele noastre. În niciunul nu a scris un model cod prost. De fiecare dată, două bucăți de muncă s-au întâlnit fără ca vreuna să știe de cealaltă.

Regulile sunt ordonate cam după locul în care începe paguba: spațiul comun, fișierele live, deploy-urile, fluxurile care se opresc și verificările care decid că o reparație e gata.

## Spațiul comun nu e spațiu privat

Am pornit 14 agenți în paralel, fiecare pe fișierul lui, cu instrucțiunea să facă o copie de siguranță a sursei înainte de modificare și s-o restaureze după. Toți au ales același nume evident pentru copie, în directorul de lucru al sesiunii. Directorul arată privat, dar e comun tuturor agenților din sesiune. Copiile s-au suprascris între ele, iar restaurările au scris codul unui proiect în altul. Au fost afectate 9 din 16 fișiere.

Un diff spunea că fișierele restaurate sunt identice cu originalele. Ambele părți ale comparației erau deja contaminate. Ce a prins problema a fost un hash luat înainte de rulare și comparat după. Producția a rămas neatinsă doar pentru că deploy-ul se făcuse înainte de fan-out.

**Reguli.** Orice prompt de fan-out cere nume unice pentru copii sau le pune lângă fișierul pe care îl protejează. Măsori starea de pornire, nu compari două stări care pot fi amândouă greșite. Pui arborele sub controlul versiunilor, ca următorul incident să fie un simplu checkout; proiectul acela a intrat sub git în aceeași zi.

## Un singur proprietar pentru fiecare fișier live

Două dintre fluxurile noastre, pornite în paralel pe sarcini înrudite, aveau amândouă voie să scrie același script live. Primul l-a înlocuit în etapa de reparație. Al doilea construise deja pe versiunea veche și era în verificare când verificatorul lui a găsit fișierul schimbat sub el. A raportat, ca problemă critică, un actor necoordonat. Actorul era celălalt flux al nostru. Nu s-a întâmplat nimic grav doar pentru că niciunul nu aplicase încă nimic.

Fiecare prompt descria sistemul așa cum era la pornire și niciunul nu știa că celălalt are voie să scrie. Fluxurile paralele se ciocnesc la prima reparație, nu la prima citire.

**Reguli.** Înainte să pornim fluxuri paralele, listăm fișierele live pe care le poate scrie fiecare. Fiecare fișier are un singur proprietar, iar celelalte fluxuri află că pentru ele e doar de citit. Unde un pas depinde de o stare live, suma de control se verifică chiar înainte de pas, nu cea notată la pornire. Când un flux raportează un actor necunoscut, ne uităm întâi la celelalte fluxuri ale noastre.

Într-un folder comun, aceeași idee merge la scară mai mică. Facem modificări țintite, nu rescrieri de fișier întreg, și recitim chiar înainte de modificare, ca o potrivire veche să eșueze sigur în loc să suprascrie. Completăm intenția altei sesiuni în loc s-o înlocuim. Pe o zonă care e a altcuiva, o reparație mică și clară de corectitudine se poate aplica și nota; o decizie de judecată se raportează cu reparația exactă, nu se ia.

## Deploy-ul publică discul, nu intenția ta

Un script de deploy sincroniza tot arborele în producție. Am făcut deploy de șase ori fără să atingem fișierele altui agent și tot i-am publicat munca în curs, pentru că un deploy nu întreabă cine a scris un fișier. Build-ul a trecut, verificarea de sănătate a răspuns. Nimic nu a semnalat ceva.

Altă dată am publicat două dintre aplicațiile noastre cu alt cod decât intenționam: una avea un fișier al altei aplicații, cealaltă arăta în panou o sondă de depanare. Făcusem deploy dintr-un arbore pe care îl modifica un flux paralel. Push-ul a raportat succes, corect, pentru că transferul a mers. Un push reușit spune că transferul a mers, nu ce s-a transferat.

Apoi am înrăutățit lucrurile. Am spus că sonda nu ajunsese la utilizatori, pe baza unei căutări în istoricul git. Nu fusese comisă niciodată, deci căutarea nu avea cum s-o găsească. Absența din git nu dovedește absența din producție.

**Reguli.** Înainte de un deploy dintr-un arbore comun, căutăm fișierele modificate recent pe care nu le-am scris noi și îi anunțăm pe proprietari înainte, nu după. Nu facem deploy cât timp un flux atinge sursa. După deploy, comparăm sursa servită cu cea locală, fișier cu fișier. Scriptul nostru de deploy face asta acum, se oprește înainte să schimbe versiunile dacă diferă și refuză să pornească dacă există modificări necomise. La prima rulare a găsit o a doua contaminare pe care nu o căutam, și așa am știut că merita.

## Fluxurile mor împreună; reluarea pornește de la dovezi

Limita de sesiune a contului oprește toți agenții în același moment. O dată au murit nouă fluxuri deodată. A rămas muncă necomisă în worktree-uri, iar un pas care scria în producție era făcut pe jumătate. Un agent reluat pornește de la zero, cu același prompt, fără să știe că jumătate din pașii lui s-au întâmplat deja.

Întreruperea sesiunii principale oprește și toate fluxurile din fundal, fără nicio notificare de eșec. Așa au murit unsprezece deodată. Și nu orice întrerupere e ce pare: agenții unui flux arătau întreruperi pe care le-am pus pe seama mesajelor noi, dar jurnalul fluxului arăta un watchdog de blocaj care îi repornea după aproximativ douăzeci și opt de minute fără progres.

Un mesaj trimis unui agent dintr-un flux nu a ajuns la agentul care rula. A pornit o a doua copie din transcrierea lui, iar cele două au lucrat în același worktree, fiecare convinsă că alt agent îi scrie peste fișiere. S-a întâmplat de două ori în aceeași zi.

**Reguli.** Fiecare pas care scrie în producție ține un jurnal rând cu rând. Înainte de reluare citim starea reală: starea worktree-ului, jurnalul de acțiuni, fișierele de lucru ale agentului mort. O punem într-o notă de reluare care spune ce e făcut, ce a fost început și ce nu a ajuns în jurnal, și îi cerem agentului să revadă, nu să refacă. Relansăm în valuri de cel mult trei, în ordinea priorității. Nu trimitem mesaje agenților dintr-un flux; deciziile noi se aplică după ce se termină.

## O reparație nu e gata până nu o verifică altcineva

De două ori în aceeași zi, un flux de cod s-a încheiat cu runda de reparații raportând totul verde și fără niciun verificator după ea. Într-unul dintre ele, un verificator independent a descoperit apoi că reparația era parțială: comanda „anulează tot” deschidea dialogul pentru acțiunea opusă, pe toată lista. Cel care repară își testează propria înțelegere a problemei. Decizia de publicare o ia un verificator independent pe commit-ul final, care își rulează propriile atacuri și pe cele ale verificatorului anterior.

Un verificator unic poate și să anuleze un unghi prin construcție. Am rulat cinci unghiuri independente, fiecare urmat de un verificator adversarial, dar verificatorul era scris pentru întrebarea principală. Al cincilea unghi întreba altceva, deci constatările lui aveau altă formă, iar verificatorul le-a respins pe toate: 3 constatări brute, 0 confirmate. Una era reală și mai urgentă decât întrebarea de la care pornisem. Acum verificatorii se scriu pe unghi, iar rapoartele arată constatările brute lângă cele confirmate, ca un zero produs de harness să nu treacă drept un zero produs de realitate.

## Unde am greșit

De trei ori în aceeași zi am reparat o regulă care nu rula. Pe una n-o chema nimic. Una era oprită din configurare peste tot unde s-ar fi putut aplica. Una avea o gardă care compara ranguri cu „mai mare sau egal” și astfel excludea exact cazul pentru care exista regula: rezolva 0 din 2.258 de cazuri și 47 după ce am corectat comparația. A patra oară, un test oprise o gardă ca să poată verifica drumul principal, iar garda însăși era greșită în producție.

Codul care nu rulează arată la fel ca acela care rulează și nu găsește nimic. Înainte să modificăm o regulă îi cerem acum două numere: de câte ori a rulat și pe câte cazuri a produs un rezultat, măsurat acolo unde e chemată efectiv.

Am testat și o reparație doar acolo unde era nevoie de ea. O regulă nouă arăta impecabil pe 160 de cazuri eșuate. Rulată pe 400 de cazuri despre care știam că funcționează, ar fi rescris 91 dintre ele. Mulțimea eșuată nu conține contraexemple, pentru că orice pare o îmbunătățire pe ceva care nu merge. O reparație se testează pe ce funcționează deja, iar ținta acolo este zero modificări.

## Limite

Regulile acestea reduc ciocnirile, nu le detectează pe toate. Depind de faptul că știm ce fișiere poate scrie un flux, iar agenții nu spun mereu. Hash-urile și comparațiile cu sursa servită dovedesc o stare la un moment dat, nu că nimic nu s-a schimbat după. Valurile și verificatorii independenți costă timp, și îl plătim știind asta.

## Lista de verificare

Nume unice în orice spațiu comun. Un singur proprietar pentru fiecare fișier live și o sumă de control chiar înainte de orice pas care depinde de el. Niciun deploy cât timp un flux modifică sursa; după deploy, compari sursa servită cu cea locală. Pașii din producție țin jurnal rând cu rând. Reluarea pornește de la starea citită, cu notă de reluare, în valuri mici. Niciun mesaj către un flux care rulează. Ultimul pas e un verificator independent, scris pe unghi, care raportează și cifrele brute. Întrebi o regulă de câte ori a rulat înainte s-o repari și testezi reparația pe ce funcționează deja.

## Întrebări și răspunsuri

### Cum împiedici agenții AI care rulează în paralel să-și suprascrie munca?

Agenții AI care rulează în paralel sunt împiedicați să-și suprascrie munca dacă fiecare fișier live are un singur proprietar, iar celelalte fluxuri știu că pentru ele fișierul e doar de citit. Prompturile de fan-out trebuie să ceară nume unice pentru copii, pentru că directorul de lucru comun doar pare privat. Agenții fac modificări țintite, recitesc chiar înainte de modificare și verifică suma de control înaintea pasului care depinde de fișier.

### Cum reiei fluxurile de agenți AI oprite de limita de sesiune?

Fluxurile de agenți AI oprite de limita de sesiune se reiau pornind de la dovezi, nu orbește. Citești întâi starea reală: starea worktree-ului, jurnalul de acțiuni și fișierele de lucru ale agentului mort. Scrii o notă de reluare cu ce e făcut, ce a fost început și ce n-a ajuns în jurnal, iar agentului îi ceri să revadă, nu să refacă. Relansezi în valuri mici, în ordinea priorității.

### De ce poate un deploy să publice munca neterminată a altui agent?

Un deploy poate publica munca neterminată a altui agent pentru că sincronizează ce e pe disc și nu întreabă cine a scris fiecare fișier. Build-ul poate trece, iar verificarea de sănătate poate răspunde, în timp ce pleacă în producție alt cod. Înainte de deploy dintr-un arbore comun cauți fișierele modificate recent de alții, nu publici cât timp un flux atinge sursa și compari apoi sursa servită cu cea locală.

### E sigur să trimiți un mesaj unui agent AI în timp ce rulează un flux?

Nu e sigur să trimiți un mesaj unui agent AI dintr-un flux care rulează, pentru că mesajul poate porni o a doua copie a agentului din transcrierea lui, în loc să ajungă la agentul activ. Cele două copii pot lucra apoi în același worktree, fiecare convinsă că alt agent îi scrie peste fișiere. Deciziile noi se aplică după ce fluxul se termină.

### Cum afli dacă o regulă automată chiar rulează înainte s-o repari?

Afli dacă o regulă automată chiar rulează cerându-i două numere înainte s-o modifici: de câte ori a rulat și pe câte cazuri a produs un rezultat, măsurat acolo unde e chemată efectiv. Codul care nu rulează arată la fel ca acela care rulează și nu găsește nimic. O regulă poate să nu fie chemată de nimic, să fie oprită din configurare sau exclusă de o gardă greșită.

## Cum se citează

**Citare:** Going Stellar (2026). *Cum lucrăm cu o flotă de agenți AI de programare fără să pierdem muncă*. GOING STELLAR S.R.L.. https://goingstellar.ro/ro/metode/lucrul-cu-o-flota-de-agenti-ai/

```bibtex
@misc{goingstellar2026working,
  title  = {Cum lucrăm cu o flotă de agenți AI de programare fără să pierdem muncă},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/ro/metode/lucrul-cu-o-flota-de-agenti-ai/},
  note   = {2026-10-11}
}
```

Licență. Se poate cita liber, cu atribuire.

## Mai există și

- Pagina în HTML: https://goingstellar.ro/ro/metode/lucrul-cu-o-flota-de-agenti-ai/
- Același articol în engleză: https://goingstellar.ro/methods/working-with-a-fleet-of-ai-coding-agents/