Per creare e provare una piccola app web con Google Antigravity, scegli Antigravity IDE, collega una cartella locale al progetto e controlla le modifiche prima di testarle. Un esempio pratico di app per l’inventario di chitarre, realizzato e descritto da un autore di InfoWorld, passa da Astro a HTMX e SQLite; il flusso mostra anche perché i suggerimenti di codice non sostituiscono il lavoro di integrazione e debug. InfoWorld racconta il proprio progetto Vintage Guitar Vault.

Scegli Antigravity IDE e collega il progetto

Tutorial in inglese di Mikey No Code: progetto locale, revisione del piano e test nel browser

Google distingue l’applicazione Antigravity standalone, pensata come centro di gestione degli agenti, da Antigravity IDE, l’ambiente di sviluppo con editor e strumenti per lavorare sul codice, e da Antigravity CLI, l’interfaccia da terminale. La Codelab di Google consiglia l’IDE per chi cerca un ambiente di sviluppo agentico e descrive separatamente anche l’SDK. La guida ufficiale di Google indica macOS, Windows e alcune distribuzioni Linux per l’installazione; per il suo esercizio introduttivo richiede anche Chrome e un account Gmail personale.

Prima di chiedere all’agente di modificare file locali, crea un progetto e collegalo alla cartella di lavoro. Google spiega che il progetto può comprendere una o più cartelle e ne definisce l’ambito per file, strumenti, autorizzazioni e impostazioni. Se l’agente non interviene sui file che ti aspetti, controlla anzitutto quale cartella è collegata.

Il tutorial in inglese di Mikey No Code mostra la configurazione di un progetto e il controllo delle modifiche, ma usa una to-do app in Node.js, non l’app per chitarre sviluppata nel racconto di InfoWorld. Il video mostra anche prompt mirati ai singoli file e prove di adattabilità nel browser.

Dalla pagina Astro ai dati di manutenzione

Il progetto descritto da InfoWorld parte da un catalogo statico di chitarre e lo trasforma, passo dopo passo, in un’app locale con una cronologia degli interventi. Ecco la sequenza riportata dall’autore:

  1. Crea il progetto Astro. Nel terminale integrato, l’autore avvia npm create astro@latest vintage-guitar-vault.
  2. Prepara la pagina e i dati iniziali. Il lavoro prosegue in src/pages/index.astro, con un elenco di chitarre inserito direttamente nella pagina. Nel caso descritto, il blocco frontmatter di Astro delimitato da --- serve a far scattare il completamento inline usato dall’autore; un commento con i campi desiderati produce dati d’esempio più mirati di una richiesta generica.
  3. Aggiungi la richiesta HTMX. L’interfaccia invia una richiesta a /api/maintenance/${guitar.id} per recuperare la cronologia di manutenzione della chitarra selezionata. Il completamento inline ha aiutato con la sintassi, ma non ha risolto da solo l’integrazione della libreria HTMX e le modifiche necessarie agli altri file.
  4. Sposta i dati in SQLite. Per il lavoro trasversale, l’autore passa ad Agent Manager e usa SQLite locale tramite better-sqlite3. Il progetto aggiunge anche uno script di seed, che inserisce i dati iniziali nel database.
  5. Collega l’endpoint di manutenzione. L’esempio implementa /api/maintenance/[id], l’endpoint che fornisce i dati richiesti dall’interfaccia.

Questi passaggi descrivono il progetto di InfoWorld, non requisiti universali di Antigravity o una struttura obbligatoria per ogni app. La distinzione pratica è utile: un completamento inline può aiutare a scrivere una porzione di codice, mentre le modifiche a librerie, database e endpoint coinvolgono più file e richiedono indicazioni più ampie.

Rivedi le modifiche e prova l’app

Chiedere un piano prima di una modifica estesa può aiutarti a individuare passaggi mancanti. Google documenta /plan per richiedere un piano d’implementazione e cita tra i possibili artefatti piani, liste di attività, walkthrough, diff e schermate. Non compaiono però in ogni attività, e l’agente può procedere anche senza un pulsante visibile «Proceed»: esamina quindi le modifiche e i permessi effettivi, senza dare per scontato che un passaggio di approvazione sia sempre presente.

Nella prova descritta da InfoWorld su Windows, l’autore ha incontrato un errore node-gyp, che l’agente ha corretto dopo l’approvazione. In seguito, il test della funzione di manutenzione ha restituito un TypeError; l’autore riferisce di aver risolto il problema con prove nel browser e ulteriore lavoro dell’agente. Sono intoppi e risultati di quel progetto specifico.

Per avviare l’app dell’esempio, l’autore esegue npm run dev e la apre in localhost:4321. Verifica che la pagina si carichi e che la richiesta di manutenzione restituisca la cronologia prevista: vedere il codice generato non basta a dimostrare che il flusso funzioni nell’app in esecuzione.

Controllo rapido

  • Il progetto punta alla cartella locale corretta.
  • Hai esaminato le modifiche e le autorizzazioni prima di proseguire.
  • Il server parte con npm run dev e l’app si apre in localhost:4321.
  • La funzione di manutenzione risponde durante la prova nel browser.