Antigravity /swarm: echipe de agenți cu Gemini 4 Carbon

Antigravity /swarm a început să se lanseze în preview pe 10 noiembrie 2026, odată cu lansarea publică a lui Gemini 4 Carbon: scrii un singur prompt, iar conversația ta devine coordonatorul unei echipe de agenți care își împart sarcina, lucrează în paralel și raportează pe un board comun. Întrebarea utilă pentru un tech lead e când merită: fiecare worker e un agent separat, deci cota se consumă mult mai repede, iar o echipă prost briefată livrează diff-uri pe care nu le mai revizuiește nimeni. Mai jos: accesul, pornirea, rolurile, modelele, patru șabloane de prompt și review-ul.

Ce este Antigravity /swarm și ce problemă rezolvă

Definiția din documentația /swarm: comanda „rulează o echipă de agenți cu nume care îți împart sarcina, lucrează pe bucăți în același timp și se coordonează pe un singur message board comun” (traducerea noastră, ca la toate citatele de mai jos). O folosești când sarcina se împarte curat pe fișiere, pachete sau întrebări separate, ori când vrei ca un al doilea agent să revizuiască și să testeze modificările înainte să le vezi tu.

Articolul echipei Antigravity descrie problema pe care o atacă. Un singur agent merge bine pe sarcini delimitate, dar „cedează când o schimbare se întinde pe zeci de fișiere și suite de teste”. Subagenții dinamici ajută la sarcini punctuale, dar rămân „strangulați de contextul unui singur coordonator” care revizuiește și rutează fiecare pas. /swarm pune agenții să vorbească direct între ei, pe un board „append-only”: fiecare postare rămâne în ordine, iar coordonatorul nu mai e singurul canal. Restul platformei, adică Editor View, Agent Manager și Artifacts, e descris în ghidul Google Antigravity; aici rămânem la /swarm.

Ca idee, e tiparul orchestrator–workers plus o buclă evaluator. Diferența o face execuția: cum e descompusă sarcina, cine verifică și când se oprește echipa. Aceste decizii le lucrează cursul AI Agents: Arhitectura și Automatizarea Sistemelor Autonome: lecția „Agentic Design Patterns: Router, Evaluator și Parallelization” tratează orchestrator–workers, paralelizarea pe secțiuni și ciclul generare–critică–rafinare, iar „Planificare Ierarhică și Descompunerea Task-urilor Complexe” arată cum spargi o migrare în sub-sarcini cu buget propriu și re-planificare la eșec. Un swarm cu sarcini prost tăiate face aceleași greșeli, doar în paralel.

Cine are acces: planuri, preview și Gemini 4 Carbon

Din sursele oficiale, citite pe 10 noiembrie 2026:

Consecința practică: pe Pro poți rula /swarm, dar echipa lucrează pe modelele din selectorul tău, nu pe Carbon; pagina planurilor Google AI pune Carbon doar pe Ultra. Planul Individual de pe pagina de prețuri Antigravity, de 0 $ pe lună, nu apare printre planurile listate de documentația /swarm. Ce mai include Ultra e în Google AI Ultra cu Gemini 4 Carbon: ce primești și cât costă. Pentru companii, articolul Antigravity menționează Carbon în Gemini for business, dar nimic despre /swarm pe acel canal.

Avertismentul comun al surselor: „fiecare worker e propriul agent, deci un swarm consumă cota mult mai repede decât o singură conversație” (documentația), chiar cu așteptare la zero tokeni și schimbare dinamică de model (articolul). Iar în preview, comportamentul și tastele se pot schimba.

Cum pornești un swarm, pas cu pas

Documentația cere un singur lucru de la tine: să descrii ce vrei construit sau aflat și cum se verifică. Coordonatorul decide câți workeri adaugă, ce fișiere primește fiecare și când intră verifier-ul.

În Antigravity App

1. Într-o conversație din proiect scrii /swarm și apeși Tab (sau Enter) ca să inserezi comanda.
2. Descrii sarcina. Exemplul din documentație: teste unitare pentru src/utils/date.ts și src/utils/currency.ts, verificate cu npm test.
3. Coordonatorul adaugă workerii și își încheie răspunsul cu linkul Open the Swarm UI, care deschide panoul Swarm în panoul lateral.
4. Lucrezi în continuare cu coordonatorul în conversația principală: îi ceri stadiul sau îi dai instrucțiuni noi.

Panoul se redeschide și din Overview, la Extensions > Swarm.

În Antigravity CLI

1. În directorul proiectului scrii /swarm (Tab completează comanda) și descrii sarcina.
2. Coordonatorul adaugă workerii, le dă brief-urile, rezumă cine ce deține și îți spune să rulezi /swarm board.
3. Sub prompt apare un rând de status: titlul swarm-ului, ultima postare și autorul ei, numărul de postări.
4. Board-ul se deschide pe tot ecranul cu /swarm board sau Alt+S.

Pe macOS, Alt+S merge doar dacă terminalul trimite Option ca Alt (Meta); /swarm board merge în orice terminal.

Rolurile: coordonator, workeri, @verifier și @monitor

Când rulezi /swarm <sarcină>, conversația ta curentă devine coordonatorul. Restul membrilor îi adaugă el.

Pe board trec alocările, întrebările, rezumatele de diff și rezultatele testelor, cu mențiuni @nume, @grup sau @all. Un membru fără treabă adoarme fără să consume tokeni și se trezește când e menționat. Mesajele tale directe către un worker nu ajung pe board.

Brief-ul public decide calitatea: un worker care nu știe ce nu are voie să atingă va „repara” și fișierul colegului. De ce contează contextul curat al fiecărui agent și cum predai munca între ei e subiectul lecției „Sisteme Multi-Agent: Izolare de Context, Sub-Agenți și Handoff” din cursul Context Engineering și Memorie pentru Agenți AI.

Ce model pe ce rol: documentația și articolul nu spun același lucru

În practică: dacă pornești /swarm dintr-o conversație pe Carbon și nu spui nimic, toată echipa rulează pe Carbon, inclusiv workerii care doar redenumesc variabile. Asta arde cota cel mai repede. Pe Ultra, configurația sugerată de Google se cere explicit: coordonatorul și verifier-ul pe Carbon, workerii pe Argon. Anunțul Google spune că Argon „rămâne alegerea ideală” pentru majoritatea sarcinilor de software engineering, iar Carbon folosește mai mulți tokeni ca să exploreze și să verifice. Cum se traduce diferența în cost pe sarcină e în Gemini 4 Carbon vs Gemini 4 Argon: cost pe sarcină; ce aduce Carbon ca model, în Gemini 4 Carbon: ce este și ce aduce nou.

Spații de lucru: workspace comun sau copie de lucru proprie

Și aici sursele diferă. Documentația: implicit, workerii împart workspace-ul tău; când mai mulți editează sau compilează în același timp, coordonatorul poate da fiecăruia propria copie de lucru a repo-ului. Articolul Antigravity: workerii pornesc „în git worktree-uri izolate, ca editările să nu se ciocnească niciodată”. Citite împreună: izolarea există, dar documentația o descrie ca decizie a coordonatorului, nu ca regulă.

• Workspace comun înseamnă risc de coliziune. Dacă sarcina implică build-uri paralele, cere explicit în prompt câte o copie de lucru pentru fiecare worker.
• Scoaterea unui worker îi șterge copia. De aceea, spune documentația, coordonatorul îl pune să-și integreze întâi modificările. Nu scoate tu un worker din mijlocul muncii.
• Pornește dintr-un arbore curat. Un commit sau o ramură înainte de swarm îți dă punctul de comparație. E bun-simț, nu o cerință a documentației.

Mecanica izolării prin worktree-uri și compararea mai multor agenți pe aceeași sarcină sunt tratate, pe alt IDE, în lecția „Git Worktrees și /best-of-n: Izolarea Agenților și Comparație Multi-Model” din cursul Cursor ca Pro; principiile se transferă direct.

Board-ul, Members, Graph și tastele

În App: panoul Swarm

• Board: fluxul live de postări, cu expeditor, destinatari, număr și oră; necititele apar sub separatorul New; ai Search, Filters și Follow.
• Members: coordonatorul, apoi workerii grupați în Active și Standing by, cu cei scoși în grupul Retired. Fiecare rând arată starea, ID-ul modelului și la ce lucrează; un clic deschide conversația membrului.
• Graph: cine pe cine a menționat, cu săgeți îngroșate după numărul de postări și redare de la prima postare la ultima.

În CLI: board-ul pe tot ecranul

Trei panouri: Roster (starea și modelul fiecărui membru), Posts și Message (postarea selectată, completă).

/agents listează workerii și deschide conversația oricăruia. Ca să vorbești cu un singur worker: în App îi deschizi conversația din Members, în CLI începi promptul cu @nume, de exemplu @verifier also run the integration tests. Schimbările de plan le spui coordonatorului, care le postează workerilor potriviți.

Stările membrilor și ce se întâmplă când se termină cota

Comportamentul la cotă e cel mai ușor de ratat. Un membru rămas fără cotă se oprește în loc să reîncerce: vezi eroarea o singură dată, iar el rămâne în pauză până apare o postare nouă pe board, până i se schimbă modelul sau până îi scrii tu. Nu repornește singur când ți se reîmprospătează cota: un swarm oprit noaptea stă oprit și dimineața. Workerii în Waiting nu trebuie opriți; îi poți scoate prin coordonator, dar definitiv.

/swarm, /boost, /teamwork sau subagenți

Documentația compară cele patru moduri de a pune mai mulți agenți pe o sarcină:

Regula documentației: /boost când problema e grea, nu mare; /swarm când sarcina e mare, dar se împarte curat și vrei să conduci echipa; /teamwork când proiectul are multe milestone-uri și cere specificație și verificare strictă înainte de predare.

Patru șabloane de prompt pentru /swarm

Sunt exemple adaptate după cele patru prompturi din documentație, cu ce nu se atinge, ce înseamnă „gata” și cum se verifică scrise explicit, adică exact ce intră în brief-urile workerilor. Documentația recomandă să spui ce vrei și cum se verifică și să lași coordonatorul să împartă; fixează tu împărțirea doar când știi granițele mai bine.

1. Implementare paralelă pe fișiere separate

/swarm Adaugă validarea inputului în cele trei handlere din src/routes/users.ts,
src/routes/orders.ts și src/routes/products.ts.
Câte un worker pe handler; fiecare modifică doar handlerul lui și testul de lângă el.
Nu atinge routerul comun, configurația sau dependențele.
Gata înseamnă: fiecare handler respinge inputul invalid în formatul de eroare folosit
deja de API, are teste pentru cazurile valide și invalide, iar npm test trece.
Un verifier rulează npm test după ce termină toți și postează lista fișierelor
modificate de fiecare worker.

2. Cod și verificare pe modele diferite

/swarm Adaugă retry cu exponential backoff în clientul HTTP din pkg/httpclient
și în expeditorul de webhookuri din pkg/webhooks.
Workerii pe Gemini 4 Argon, verifier-ul pe Gemini 4 Carbon.
Verifier-ul caută race conditions, rulează go test -race ./... și confirmă
că testele existente nu au fost slăbite.
Gata înseamnă: go test -race ./... trece, numărul de reîncercări și pauza maximă
sunt configurabile, iar fiecare worker postează un rezumat al diff-ului.

Pe Pro, unde Carbon nu e disponibil, înlocuiești a doua linie cu „rulează verifier-ul pe alt model decât workerii”, formularea din documentație.

3. Investigație read-only

/swarm Află de ce pornirea CLI-ului nostru e lentă.
Trei workeri read-only, fără nicio modificare de fișiere: unul pe importurile de module,
unul pe încărcarea configurației, unul pe descoperirea pluginurilor.
Fiecare postează dovezi: comanda rulată, măsurătoarea, fișierul și linia.
Gata înseamnă: o listă de remedieri ordonată după impact, fiecare cu dovada ei,
verificată încrucișat de ceilalți doi workeri.

Varianta read-only e cel mai sigur prim swarm: nu produce diff-uri, iar dovezile îți arată cât de bine lucrează echipa pe codul tău.

4. Repararea testelor pe mai multe pachete

/swarm Rulează pytest pe tot repo-ul, grupează testele care pică pe pachete
și dă câte un worker fiecărui pachet stricat.
Reparațiile nu au voie să șteargă aserțiuni, să marcheze teste ca sărite
sau să modifice fixture-uri comune fără să întrebe pe board.
Un verifier re-rulează toată suita după ce fiecare worker raportează teste verzi.
Gata înseamnă: suita completă trece, iar pentru fiecare pachet există pe board
cauza eșecului și fișierele atinse.

Interdicția de a șterge aserțiuni vine din exemplul original și e cea mai importantă linie: pentru un agent presat să facă testele verzi, cea mai scurtă cale e să slăbească testul.

Când NU merită /swarm

• Sarcina e mică. Un fișier sau două nu au ce împărți; coordonatorul, brief-urile și verifier-ul costă tokeni înainte de prima linie utilă. O conversație obișnuită e mai rapidă și mai ieftină.
• Bucățile sunt cuplate. Dacă toți workerii trebuie să modifice aceeași interfață sau aceeași schemă, „bucăți care nu se ciocnesc” nu există. Fă întâi schimbarea comună, apoi paralelizează restul.
• Nu ai teste. Fără teste, verifier-ul nu are ce rula și ajunge să-și dea cu părerea despre diff-uri. Scrie întâi testele sau criteriile verificabile.
• Problema e grea, nu mare. Un bug de concurență într-o funcție nu se rezolvă cu cinci workeri; documentația trimite asemenea cazuri spre /boost.
• Ești aproape de limita cotei. Un swarm oprit la jumătate lasă munca împrăștiată în mai multe conversații și copii de lucru.

Disciplina de review: ce verifici înainte să accepți

Un swarm care raportează „gata” îți dă o ipoteză, nu un rezultat.

1. Rulezi tu testele pe rezultatul integrat, nu te bazezi doar pe raportul verifier-ului. Un verifier pe același model ca workerii are aceleași puncte oarbe; de aceea documentația dă exemplul cu verifier-ul pe alt model.
2. Citești diff-urile pe worker. Orice fișier atins în afara brief-ului e un semnal; board-ul îți arată cine a cerut ce și de ce.
3. Cauți teste slăbite: aserțiuni șterse, praguri relaxate, teste sărite, mock-uri care înlocuiesc exact codul testat.
4. Aprobi cu Ctrl+K doar ce ai citit. Scurtătura aprobă fără să vezi contextul. Folosește întâi Alt+J ca să ajungi la worker și să citești cererea; o comandă aprobată în grabă rulează cu permisiunile tale.
5. Secretele nu intră în prompt. Cheile și parolele din descrierea sarcinii ajung în brief-uri și pe board. Documentația Antigravity are pagini separate despre permisiuni și sandbox: stabilește regulile acolo înainte de primul swarm pe un repo real.
6. Integrezi pe ramură, nu pe main, prin același review ca orice pull request.

Latura de proces, adică cine aprobă ce și cu ce urmă de audit, o tratează lecția „Human-in-the-Loop și Approval Workflows Enterprise” din același curs de AI Agents.

Demonstrațiile Google: ce spun și ce nu dovedesc

Anunțul Google prezintă câteva rezultate obținute cu /swarm și Carbon. Sunt afirmații ale Google, nereproduse independent:

• Turnul Eiffel: o expoziție 3D în Three.js despre construcția turnului (1887–1889), dintr-un singur prompt cu /swarm.
• Platform 37: o reconstrucție Three.js de 906K triunghiuri a biroului, din 7 PDF-uri publice cu 206 vederi de desen tehnic, „în 10 bucle peste noapte”.
• Dogfooding intern: potrivit articolului Antigravity, în cinci săptămâni inginerii Google au folosit swarm-uri pentru migrări pe mai multe pachete, investigații de cauză între subsisteme și redesign arhitectural.

Nu aflăm costul rulărilor, câte intervenții umane au fost sau cum s-a verificat rezultatul. Testul relevant e un swarm read-only pe repo-ul tău, apoi unul mic de implementare, verificat de tine.

Întrebări frecvente

Ce este Antigravity /swarm? O comandă Google Antigravity, în preview din 10 noiembrie 2026, care face din conversația ta coordonatorul unei echipe de agenți: workerii lucrează în paralel, un @verifier rulează testele, iar toți comunică pe un board comun.

Pe ce planuri merge /swarm și am nevoie de Gemini 4 Carbon? Pe Google AI Pro și Google AI Ultra, în Antigravity App și CLI. Carbon nu e obligatoriu și e disponibil doar pe Ultra; pe Pro echipa rulează pe Gemini 4 Argon.

Pe ce model rulează workerii? Implicit, pe modelul conversației tale; alt model se cere în prompt. Articolul Antigravity recomandă Carbon pentru coordonare, arhitectură, audit și verificare, iar modele mai ușoare pentru editările paralele.

Ce se întâmplă dacă un worker rămâne fără cotă? Se oprește în loc să reîncerce și nu repornește singur la reîmprospătarea cotei. Revine la o postare nouă pe board, la schimbarea modelului sau când îi scrii tu.

Când folosesc /boost sau /teamwork în loc de /swarm? /boost pentru probleme grele, dar mici. /teamwork pentru proiecte cu multe milestone-uri, de ore până la zile. /swarm pentru sarcini mari care se împart curat, de minute până la ore.

Concluzie

Antigravity /swarm aduce în produs tiparul orchestrator–workers–verifier: un coordonator care nu scrie cod, workeri cu brief-uri publice, un verifier la doi–patru workeri și un board pe care se vede tot. Funcționează pe Pro și Ultra, cu Carbon doar pe Ultra, și e în preview.

Pe partea cealaltă: consumă cota mult mai repede decât o conversație, rulează implicit toată echipa pe modelul tău, inclusiv pe Carbon, și nu repornește singur după ce cota s-a terminat. Merită pe sarcini mari, care se împart curat și au teste; nu pe modificări mici, cuplate sau fără criterii verificabile. Rezultatul rămâne o propunere până îl verifici tu.

Surse

• Google Antigravity, documentația „Swarm (/swarm)”: https://antigravity.google/docs/swarm
• Google Antigravity Blog, „Gemini 4 Carbon and /swarm”: https://antigravity.google/blog/gemini-4-carbon-in-google-antigravity
• Google, „Gemini 4 Carbon is now available”: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available/
• Google One, planurile Google AI: https://one.google.com/about/google-ai-plans
• Google Antigravity, prețuri: https://antigravity.google/pricing

Verificat la 10 noiembrie 2026 pe documentația /swarm, articolul echipei Antigravity, anunțul Google și pagina planurilor Google AI. /swarm e în preview, deci comenzile, tastele și disponibilitatea se pot schimba. Demonstrațiile sunt afirmații Google, nereproduse independent; prompturile din articol sunt exemple adaptate după documentație. Conținutul are caracter informativ.