Google ha aggiunto al suo ambiente di sviluppo Antigravity un nuovo comando chiamato /boost. Invocarlo avvia una pipeline di ragionamento multi-agente invece di un singolo assistente di programmazione: un orchestratore legge il problema e lo suddivide in attività, le assegna ad agenti specializzati che lavorano in ambiti isolati, poi sottopone il risultato a round di verifica indipendenti che eseguono davvero i test prima che qualsiasi cosa arrivi a voi. La notizia non è che l'IA scrive codice più velocemente. È che gli strumenti di programmazione hanno iniziato a integrare la verifica nello strumento stesso.

Cosa ha annunciato davvero Google

Secondo la documentazione ufficiale di Antigravity, /boost è pensato specificamente per l'ingegneria del software più difficile: bug di concorrenza e race condition, ottimizzazione algoritmica, regressioni sottili che compaiono e scompaiono e refactoring complessi su più file. Sono esattamente i problemi in cui fallisce un assistente convenzionale a turno singolo, perché risolverli richiede sperimentazione e passi indietro anziché generazione diretta.

Il comando si svolge in tre fasi chiare:

  • Pianificazione: un orchestratore principale riceve il vostro prompt, esamina il contesto del workspace, formula una strategia di esecuzione e scompone la sfida in sotto-attività distinte e verificabili.
  • Esecuzione distribuita: l'orchestratore assegna queste sotto-attività ad agenti specializzati. I flussi di implementazione scrivono codice e test unitari. I flussi di indagine eseguono il debug della causa principale e tracciano i grafi delle chiamate senza modificare alcun file. Gli agenti di verifica locale eseguono i target di build e le suite di test per convalidare le ipotesi prima di riferire.
  • Verifica prima della consegna: l'orchestratore aggrega i risultati ed esegue controlli di regressione sulle suite di test complete e sui casi limite. Se un'asserzione fallisce, la diagnostica dell'errore alimenta l'iterazione successiva per la correzione automatica, e voi ricevete un riepilogo delle modifiche verificate solo quando tutto passa.

Tutto avviene all'interno di worktree effimeri e isolati, il che significa che gli agenti non sperimentano sulla vostra copia di lavoro del progetto.

Tre modalità, non una

Google documenta tre modalità di esecuzione distinte, e la differenza tra loro è la parte utile in pratica:

  • Agente predefinito: programmazione interattiva, navigazione nel codice e refactoring generale. Orizzonte dell'attività da secondi a minuti, un ciclo a singolo agente, verifica in un solo passaggio. Disponibile in tutti i piani.
  • /boost: ragionamento profondo e bug ostinati. Orizzonte dell'attività da secondi a ore, una gerarchia in tre fasi, verifica indipendente in più round. Disponibile nei piani a pagamento.
  • /teamwork-preview: team di agenti che lavorano per giorni su grandi migrazioni o sulla costruzione di interi sottosistemi, con ruoli definiti come Explorer, Worker, Critic e Auditor, più cancelli di verifica che cercano deliberatamente di rompere il codice prima che una milestone venga approvata.

Notate la gradazione: più grande è l'attività, più l'investimento va nella revisione anziché nella velocità. È un segnale a cui vale la pena prestare attenzione per chiunque gestisca un progetto software.

Perché conta per un imprenditore, non solo per uno sviluppatore

Negli ultimi due anni la conversazione sull'IA nella programmazione è stata una conversazione sulla velocità: quante righe vengono generate al minuto. Il problema è che la velocità non è il collo di bottiglia nei progetti reali. Lo è la fiducia. Questo codice funziona davvero nei casi che nessuno ha provato?

Ciò che l'architettura di /boost dice implicitamente è che il settore è arrivato alla stessa conclusione. Un codice che arriva più in fretta non vale nulla se costa due settimane di debug dopo la consegna. Per questo lo strumento è costruito attorno a tre regole che valgono per qualsiasi team tecnico, con o senza IA:

  • L'autore non valuta il proprio lavoro: chi verifica è separato da chi ha implementato. È il principio alla base della code review da decenni. Ora viene imposto all'interno dello strumento.
  • La prova è l'esecuzione, non l'affermazione: i test vengono eseguiti davvero e il loro output reale viene controllato, invece di accettare l'affermazione che siano passati.
  • L'isolamento protegge l'originale: la sperimentazione avviene in una copia separata, così i tentativi falliti non trapelano mai nel progetto.

Se acquistate sviluppo software, queste sono esattamente le tre domande da porre al vostro fornitore: chi lo revisiona, qual è la prova che i test sono passati e dove avviene la sperimentazione?

Cosa non cambia

È facile leggere una notizia del genere come l'annuncio che gli ingegneri non servono più. La documentazione dice chiaramente il contrario: gli agenti ereditano le regole di accesso ai file e le policy di autorizzazione dei comandi configurate per il vostro workspace, e qualsiasi comando protetto o modifica al di fuori degli ambiti attendibili genera una richiesta di autorizzazione all'utente. C'è un essere umano responsabile alla fine della catena.

E i permessi sono la metà minore della questione. Un agente risolve il problema che avete descritto. Non può sapere che la descrizione stessa era sbagliata. Non sa che il vostro ciclo di fatturazione si chiude il 25 e non il 30, che questo campo non deve mai essere visibile a un commerciale, o che quando il vostro cliente dice "ordine" intende qualcosa di diverso da ciò che intendete voi. Definire i requisiti, comprendere il dominio e assumersi la decisione restano un lavoro interamente umano.

Come la vediamo in Origami

Trattiamo gli strumenti multi-agente come qualsiasi strumento di produttività: accelerano l'esecuzione, non trasferiscono la responsabilità. Un progetto da noi passa ancora attraverso specifiche scritte, revisione umana, una suite di test e un ambiente di staging prima della produzione, sia che il codice l'abbia scritto una persona sia che l'abbia generato un agente. Uno strumento che esegue i propri test è un'aggiunta gradita a questa catena, ma ne è un anello, non un sostituto.

L'indicazione pratica per un imprenditore: aspettatevi che i tempi di consegna si riducano proprio sul lavoro complesso, ma non accettate una consegna senza test, senza documentazione e senza un responsabile umano. Gli strumenti che si revisionano da soli alzano il tetto della qualità raggiungibile. Non eliminano il vostro bisogno di qualcuno che garantisca che ciò che è stato costruito sia ciò che avete chiesto.

Fonti