AIREITERCinquanta milioni di righe di Lean 4 per una sola dimostrazione, 800.000 righe di Rust sicuro scritte in due settimane e kernel TPU 4,09 volte più veloci: l'aggiornamento di ricerca pubblicato da Google il 13 novembre dà un'idea delle possibilità di Antigravity Teamwork. Ma nella pratica conviene soprattutto per progetti organizzati per milestone, destinati a durare ore o giorni, perché una singola esecuzione può consumare una parte consistente della quota settimanale.
Che cos'è davvero Antigravity Teamwork
Antigravity Teamwork è il workflow di orchestrazione multi-agente di Google per affrontare attività complesse e soggette a verifiche all'interno di Antigravity. Il comando /teamwork avvia un team coordinato — Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor e Success Auditor — che organizza il lavoro in milestone, opera in una directory di progetto dedicata e sottopone ogni traguardo a una verifica indipendente.
Il lavoro si articola in due fasi. La prima è un'intervista di definizione: l'agente principale raccoglie obiettivi, requisiti, metodi di verifica, criteri di accettazione e directory del progetto (per impostazione predefinita ~/teamwork_projects/{PROJECT_NAME}). La seconda consiste nell'esecuzione autonoma attraverso artefatti strutturati — richiesta, piano di progetto e report di avanzamento — con assegnazione esclusiva dei file a ciascun Worker e con i controlli di Critic, Challenger, Auditor e Success Auditor prima del passaggio di consegne (documentazione di Teamwork).
Durante l'intervista si sceglie anche la modalità di integrità, che determina il livello di rigore:
development(predefinita): iterazione rapida; sono ammessi il riuso del codice e i framework, mentre vengono rifiutati risultati inventati e implementazioni di facciata.demo: presentazione riproducibile; non sono consentiti il riutilizzo della logica principale da progetti open source, la delega all'esterno del lavoro centrale né la lettura dei sorgenti dei test per ricavare le risposte.benchmark: massimo rigore; implementazione da zero usando la libreria standard del linguaggio e valutazione indipendente basata su risultati di riferimento.
I percorsi di esecuzione adattano automaticamente la composizione del team:
- General distributed coding (predefinito): sviluppo e refactoring su più file.
- Iterative coding: una correzione circoscritta quando il prompt dice "keep it small".
- Document Review: revisione di paper e documenti di progettazione da più angolazioni.
- Math / Proof e Math / Proof Large Team: ragionamento formale e campagne estese su congetture matematiche.
L'orizzonte tipico va da alcune ore a diversi giorni sui piani a pagamento, nell'app e nella CLI di Antigravity (documentazione di Teamwork).
Teamwork, Swarm, Boost e subagent: quale scegliere
Antigravity Teamwork ha senso solo quando servono milestone, controlli di audit e una directory dedicata. Per la maggior parte delle attività quotidiane bastano opzioni più leggere: scegliere lo strumento sbagliato significa consumare quota senza motivo.
| Strumento | Ideale per | Come si avvia | Workspace | Verifica | Orizzonte tipico | Piano |
|---|---|---|---|---|---|---|
| Subagents | Attività collaterali mirate: analisi del repository, controlli nel browser, esecuzione dei test | Automaticamente o con @subagent | Workspace corrente | L'agente principale controlla la risposta | Da secondi a minuti | Tutti i piani |
Boost (/boost) | Problemi difficili ma circoscritti: race condition, bug complessi, algoritmi | /boost <task>, avvio immediato | Workspace corrente, contesti isolati | I Worker mettono in discussione e riverificano il risultato; l'orchestratore esegue controlli a campione | Da secondi a ore | Piani a pagamento |
Swarm (/swarm) | Lavori ampi che si dividono bene: file, pacchetti, suite di test | /swarm <task>, avvio immediato | Workspace corrente o copie per worker | Un @verifier dedicato revisiona le differenze ed esegue i test | Da minuti a ore | Google AI Pro e Ultra |
Teamwork (/teamwork) | Progetti con più milestone: migrazioni, simulazioni, dimostrazioni formali | /teamwork <goal> + intervista di definizione | ~/teamwork_projects/{PROJECT_NAME} dedicata | Controlli di Critic, Challenger, Auditor e Success Auditor | Da ore a giorni | Piani a pagamento |
Scegli Teamwork per una migrazione da REST a Fastify su decine di file con copertura completa dei test, per un simulatore cycle-accurate validato sui timer hardware o per una dimostrazione formale verificata da Lean 4. Swarm è più adatto ad aggiungere la validazione a tre handler API indipendenti, con un worker per file e un verifier che esegue npm test. Boost funziona meglio per una singola race condition o per un refactoring interdipendente, quando la sequenza sfida-correzione-verifica è più efficace del lavoro in parallelo. I subagent sono invece perfetti per la ricerca di background mentre la conversazione principale prosegue.
La confusione è comprensibile. Come ha scritto un utente di Antigravity:
"agy has way too many modes now and honestly it's getting confusing. right now we have ... /teamwork (long milestone projects with audit gates) ... and now dynamic workflows... to be fair, we really don't need all of them. fewer modes = less confusion..."
— @Heamanth_alturi (X)
La regola pratica è semplice: se il lavoro ha un unico criterio di completamento e si chiude in una sessione, Teamwork è eccessivo. Se invece servono un artefatto di pianificazione, uno di avanzamento e la firma di qualcuno che non sia l'autore su ogni milestone, allora Teamwork è lo strumento giusto.
Cosa dimostra davvero l'aggiornamento di ricerca di novembre
L'aggiornamento di Google Research del 13 novembre è un resoconto dei risultati, non un annuncio di lancio. Teamwork esisteva già per i piani a pagamento con il nome /teamwork-preview; il post documenta ciò che team organizzati per milestone hanno ottenuto con Gemini 4 Argon, Carbon e Hydrogen. Gli esseri umani hanno continuato a definire problemi, vincoli e modalità di valutazione, mentre nuovi critic hanno riesaminato il lavoro partendo da contesti puliti.
| Ambito | Progetto di esempio | Scala degli agenti | Risultato riportato |
|---|---|---|---|
| Matematica | Dimostrazione della congettura Courtade–Kumar (Google, CUHK, USC, CMU) | Schema da dimostrazione lunga, formalizzazione in Lean 4 | Dimostrazione completa in circa 50 milioni di righe di codice Lean |
| Chimica | Struttura molecolare dai dati NMR | 30 agenti specializzati + simulatore fisico | 95% di corrispondenza esatta al primo risultato, 100% tra i primi tre |
| Sistemi | Riscrittura da C++ a Rust di Zircon | Campagna Argon di due settimane | Circa 800.000 righe di Rust sicuro, avviate su arm64 |
| Hardware ML | Ottimizzazione di kernel TPU (DuoDiscover) | Valutatori proxy (23 secondi contro 7–32 minuti) | Accelerazione media di 4,09 volte su 17 kernel JAXBench |
Google ha inoltre aperto le candidature per 10.000 ricercatori accademici, che potranno ricevere sei mesi di accesso top-tier. Alcuni workflow descritti nel post sono ancora in distribuzione agli utenti esterni: la tabella va quindi letta come prova delle capacità, non come garanzia che ogni progetto ottenga gli stessi miglioramenti.
Il costo in quota che le pagine ufficiali non mostrano
La pagina dei prezzi di Antigravity indica Individual a 0 $/mese, con completamenti Tab illimitati e limiti settimanali di base, oltre a Pro e Ultra con limiti più alti e un pool flessibile di crediti AI; il numero esatto di richieste non viene pubblicato. Le quote di Pro e Ultra si rinnovano ogni cinque ore finché non viene raggiunto il tetto settimanale, mentre l'eventuale consumo oltre quota può usare crediti acquistati, con un'impostazione Never o Always (documentazione dei piani). Teamwork e Boost richiedono un piano a pagamento; Swarm richiede Pro o Ultra (documentazione di Swarm). Lo stesso post di Google dedicato al sistema operativo avvertiva che un paio di attività complesse in anteprima potevano consumare un'intera quota settimanale (post sul sistema operativo di Antigravity).
Le testimonianze degli utenti, aneddotiche e non rappresentative di un campione statistico, vanno da consumi gestibili a situazioni molto pesanti:
"holy crap that sucked all my quota in about only 5 minutes (3.5 Flash (high))"
— u/Several_Bag_3665 (Reddit)
"very usable on ultra sub actually, had a teamwork preview with gemini flash medium going for 50 minutes straight and it took about 20% of my 5-hour quota and did huge refactorings properly"
— u/ningkaiyang (Reddit)
Due meccanismi spiegano questa differenza. Per /swarm, Antigravity documenta che ogni worker è un agente separato, che i worker in attesa non consumano token e che quelli rimasti senza quota si mettono in pausa invece di riprovare automaticamente, fino a un nuovo messaggio sulla board, al cambio di modello o a un messaggio diretto (documentazione di Swarm); la documentazione di Teamwork non pubblica la stessa indicazione sulla ripresa, quindi è meglio considerarla una caratteristica comune dei sistemi multi-agente da verificare sul proprio piano. Teamwork produce inoltre molti artefatti intermedi — richiesta, piano e report di avanzamento, oltre a note di lavoro e log di verifica per ciascun agente (documentazione di Teamwork) — che rappresentano lo stato del progetto, non necessariamente avanzamento reale.
Come provare Teamwork senza bruciare una settimana di quota
Avviare Teamwork richiede un solo comando, ma è l'intervista iniziale a determinare gran parte del costo. Nell'app, apri una conversazione di progetto e inserisci /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation. Nella CLI, dalla directory del progetto, esegui /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests. Puoi seguire il lavoro dal pannello dei subagent o dalla barra di stato della CLI, saltare alle approvazioni con Alt+J e consultare in tempo reale gli artefatti di piano e avanzamento (documentazione di Teamwork).
Considera la prima fase come il principale strumento di controllo dei costi. Descrivi cosa vuoi ottenere, non come farlo: obiettivo, pubblico di riferimento (demo, produzione o benchmark), vincoli inderogabili e un controllo oggettivo per ogni requisito, ad esempio una suite di test o uno script per le metriche. Usa development per iterare e riserva demo o benchmark ai casi in cui servano una dimostrazione presentabile o una prova realizzata da zero, perché verifiche più rigide implicano più lavoro per gli agenti. Prima di approvare, controlla la directory dedicata al progetto.
Durante l'esecuzione, mantieni il coordinamento centralizzato. Fai passare le modifiche di ambito dal coordinatore, integra le modifiche dei worker prima di rimuoverli e valuta l'avanzamento in base ai gate delle milestone e alle prove fornite dai test, non al numero di file. Per il primo utilizzo, nelle impostazioni imposta su Never il consumo extra di crediti AI, così l'esaurimento della quota di base interromperà il lavoro invece di spendere crediti senza avvisare (documentazione dei piani). Quando la documentazione del piano lo consente, puoi affiancare un planner più potente a un'implementazione più economica: Ultra supporta Orchestrator (Carbon) e Orchestrator (Argon), che pianificano con Gemini 4 Carbon o Argon mentre Gemini 4 Hydrogen implementa (pagina dei prezzi), un compromesso visibile anche nei confronti tra Carbon e Argon.
Domande frequenti
Qual è la differenza tra /teamwork e /teamwork-preview?
/teamwork-preview era il nome usato nella precedente fase di anteprima per la ricerca. L'attuale documentazione di Teamwork usa /teamwork sui piani a pagamento; Google non ha pubblicato un annuncio separato sulla disponibilità generale.
Teamwork può essere messo in pausa o recuperato dopo l'esaurimento della quota?
Il comportamento documentato per /swarm prevede che i worker rimasti senza quota si mettano in pausa fino a un nuovo messaggio sulla board, al cambio di modello o a un messaggio diretto (documentazione di Swarm); la documentazione di Teamwork non conferma lo stesso percorso di ripresa. Prima di riavviare, controlla il piano e gli artefatti di avanzamento in ~/teamwork_projects/{PROJECT_NAME}, perché le milestone parziali restano salvate come file.
Quali artefatti genera Teamwork?
Artefatti di richiesta, piano di progetto e avanzamento, oltre a note di lavoro per ciascun agente, script di supporto e log di verifica (documentazione di Teamwork). Una grande quantità di output Markdown è normale: valuta l'avanzamento in base ai gate delle milestone e alle prove dei test, non al numero di file.
Teamwork è sicuro per i repository di produzione?
Teamwork isola il lavoro in una directory dedicata, assegna i file in modo esclusivo e applica gate di audit, riducendo così il rischio di conflitti (documentazione di Teamwork). Anche in produzione serve comunque una revisione umana dei criteri di accettazione, delle prove fornite dai test e del controllo finale del Success Auditor prima del merge.
La checklist di 30 secondi prima di digitare /teamwork
Digita /teamwork solo se sono vere tutte e cinque queste condizioni: il lavoro comprende più milestone, ogni milestone ha un controllo oggettivo, una directory dedicata è utile, i gate di audit indipendenti fanno la differenza e una singola esecuzione ad alto consumo di quota costa meno di settimane di lavoro manuale. Altrimenti usa Swarm per il lavoro parallelizzabile, Boost per i bug difficili ma circoscritti o i subagent per le attività collaterali di ricerca. Teamwork va tenuto per il progetto che ha davvero bisogno di un team.