JetBrains Air: guida pratica al plugin Alpha

JetBrains Air permette di avviare un AI coding agent direttamente in un IDE JetBrains, fornirgli solo il contesto del progetto che serve e controllarne le modifiche nello stesso ambiente in cui il codice viene esplorato e testato. Il primo passo utile non è affidargli un refactoring esteso. Conviene installare Air Alpha, collegare un solo agente, assegnargli un file e un test non riuscito, quindi accettare la modifica soltanto quando sia il diff sia l'esito del test risultano chiari.

JetBrains Air in breve

Air va usato come cabina di regia per gli agenti, non come un pulsante di completamento automatico. L'agente esegue il lavoro; Air organizza la sessione, gli passa il contesto dell'IDE e riporta il risultato in un'interfaccia di revisione integrata nell'IDE.

Per la prima sessione:

1. Installare Air Alpha dal Marketplace dell'IDE.
2. Aprire un progetto o un branch sacrificabile, con un test che sia possibile eseguire.
3. Scegliere un preset New Session e mantenere Standard Access.
4. Inviare il primo messaggio e completare l'accesso, se Air lo richiede.
5. Allegare il file interessato con @file:.
6. Chiedere una correzione circoscritta e un test.
7. Esaminare ogni file modificato in Agent Sessions.
8. Eseguire personalmente il test, poi conservare, ritoccare, creare un commit oppure annullare la modifica.

Questo è l'intero ciclo che conta davvero. Sessioni parallele, altri agenti, controlli per le organizzazioni e passaggio al cloud possono aspettare finché il processo non si sarà dimostrato affidabile.

Che cos'è davvero JetBrains Air

Air è il livello di raccordo fra un progetto JetBrains e uno o più agenti di coding. Si può immaginare come il banco di collaudo di un'officina: l'agente porta un componente proposto, mentre l'IDE mette a disposizione misure, verifiche di compatibilità e decisione finale.

La versione del 22 settembre ha trasformato Air in un sistema più ampio, articolato in tre componenti: Air negli IDE JetBrains per il lavoro individuale, Air Teams per coordinamento e automazione e Air Governance per policy, visibilità e controllo dei costi. Questa guida si concentra sul percorso locale effettivamente utilizzabile, il plugin Air Alpha per l'IDE.

Il plugin per l'IDE non è un nuovo modello fondazionale. Può eseguire subito Codex, Gemini, GitHub Copilot, Claude e Junie; JetBrains afferma inoltre che altri agenti possono collegarsi tramite ACP. ACP, cioè Agent Client Protocol, offre un canale comune fra l'IDE e l'intera dotazione operativa dell'agente, inclusi strumenti e instradamento dei modelli.

La pagina attuale di Air per gli IDE indica ancora come di prossima disponibilità il passaggio dal lavoro locale al cloud. Per una prima prova affidabile, è meglio mantenere l'attività locale e circoscritta.

Cosa sapere prima dell'installazione

Air Alpha è un'alpha pubblica, non uno strumento stabile e ormai consolidato. JetBrains avverte che interfaccia e comportamento possono cambiare e prevede aggiornamenti con una cadenza approssimativamente settimanale. Prima di cercare altre cause di un problema, va controllata la compatibilità.

Il 23 settembre 2026, il pacchetto corrente sul Marketplace per la linea 2026.2 era Air 262.8665.463. Supporta IntelliJ IDEA dalla versione 2026.2 alla 2026.2.3, oltre alle corrispondenti versioni 2026.2 degli IDE JetBrains elencati. Sul Marketplace sono disponibili anche build per la linea 2026.3, quindi la build esatta del plugin può cambiare in base al ramo dell'IDE.

Verifica di compatibilità eseguita per questa guida

IntelliJ IDEA 2026.2.3, build IU-262.10968.63, ha caricato Air 262.8665.463 in un profilo isolato e indicizzato un progetto Node sacrificabile senza errori del plugin. L'agente rilevato era codex-cli 0.153.4, ma non aveva effettuato l'accesso e il sistema host era privo di sessione grafica. Non si sostiene quindi di aver eseguito un'attività interattiva in Air, prodotto un diff o ottenuto il superamento di un test scritto dall'agente. I passaggi relativi all'interfaccia seguono la guida rapida corrente di JetBrains e le etichette incluse in quella build del plugin.

Come usare JetBrains Air, passo dopo passo

1. Installare Air Alpha

Aprire le impostazioni dell'IDE, scegliere Plugins, passare a Marketplace, cercare Air Alpha e fare clic su Install. Se richiesto, riavviare l'IDE.

Air è gratuito. L'agente collegato può comunque richiedere un account, un abbonamento o la fatturazione tramite API. Se il dubbio riguarda i costi, JetBrains Air è gratuito? distingue il prezzo del plugin da quello dell'agente.

2. Partire da un errore poco costoso

È preferibile iniziare con un progetto esistente che si possa eliminare o ripristinare. Un buon primo incarico riguarda un solo file, presenta un errore osservabile e dispone di un comando capace di dimostrare se la modifica ha funzionato.

Può trattarsi, per esempio, di una funzione per gli slug che gestisce male gli spazi ripetuti, di un formatter privo di un caso limite o di una piccola funzione di validazione con uno unit test non riuscito. Alla prima prova è meglio evitare migrazioni, autenticazione, codice di deployment e aggiornamenti estesi delle dipendenze.

Prima di aprire una sessione, annotare il punto di partenza:

• il branch corrente o il worktree sacrificabile;
• il comando di test esatto;
• se quel test al momento riesce o fallisce;
• quali file si prevede che l'attività modifichi.

Così la revisione diventa un confronto, non una sensazione.

3. Scegliere un preset New Session

Il pulsante New Session nella barra degli strumenti principale avvia il preset selezionato. Per sceglierne un altro si usa la freccia accanto al pulsante.

Un preset è una configurazione di avvio salvata. Stabilisce l'agente e può preselezionare modello, livello di ragionamento, livello di accesso e interfaccia della sessione. Air mostra gli agenti rilevati sul computer insieme ai preset integrati. Se l'agente scelto non è presente, il plugin può proporne l'installazione.

Per il primo incarico, scegliere Standard Access. Nel plugin corrente, Standard Access consente all'agente di leggere e modificare file ed eseguire comandi all'interno del progetto; per accedere a file esterni al progetto o alla rete serve invece un'approvazione. Full Access elimina queste richieste di approvazione per l'uso della rete e le modifiche in qualsiasi punto del computer. Non è una buona impostazione predefinita per una prima sessione.

4. Inviare il primo messaggio e autorizzare l'agente

L'autorizzazione viene richiesta quando serve davvero all'agente. Scrivere un primo messaggio breve e premere Invio. Se Air trova credenziali già utilizzate dall'agente sul computer, la sessione prosegue. In caso contrario, compare Choose a sign-in method to continue.

Il percorso disponibile varia in base all'agente:

• l'accesso dell'agente può proseguire nel browser o nel terminale;
• una licenza JetBrains AI idonea o un workspace dell'organizzazione può fornire i crediti;
• Add an AI provider apre Tools | Air | Accounts per configurare un abbonamento di terze parti o una chiave API.

In Accounts, scegliere More Providers, aggiungere le credenziali necessarie, usare Test Connection, salvare con OK, quindi tornare alla sessione e selezionare il provider.

Le credenziali non vanno incollate nel prompt dell'attività: il loro posto è il flusso di connessione del provider.

5. Aggiungere soltanto il contesto necessario

Dal controllo per l'aggiunta del contesto, Air può allegare file, commit e skill. È anche possibile digitare @file: per un file o @folder: per una cartella. La differenza è sostanziale: allegare il singolo file interessato equivale a consegnare al meccanico il componente difettoso; allegare l'intero repository significa rovesciare tutta l'officina sul banco di lavoro.

Alla prima prova, allegare il file di implementazione e indicare il comando di test. Il file di test va aggiunto solo se serve all'agente per comprendere uno schema già esistente.

6. Chiedere una modifica circoscritta e una prova

Un buon prompt specifica il difetto, i confini dell'intervento e il comando di verifica. Per esempio:

Correggi la gestione degli spazi ripetuti in @file:src/slug.js. Aggiungi o aggiorna il test pertinente più piccolo possibile. Esegui node --test. Non modificare le dipendenze e non intervenire su file estranei. Se non è possibile eseguire il comando di test, fermati e spiegane il motivo.

Un prompt simile offre all'agente un traguardo verificabile. «Migliora questa funzione» non lo fa.

7. Seguire la sessione senza valutare soltanto il resoconto

L'agente comunica l'avanzamento e può porre domande. È opportuno fornire i requisiti mancanti, approvare solo le azioni comprese e prestare attenzione a richieste inattese di accesso alla rete o a file esterni al progetto.

Il testo sullo stato di avanzamento offre contesto, ma non costituisce una prova. La prova è il diff prodotto, insieme a un test che sia possibile ripetere.

8. Controllare la modifica in Agent Sessions

Aprire Agent Sessions ed espandere la sessione conclusa. Visualizzare il diff di ogni file modificato. Il pacchetto corrente comprende le azioni Show Diff, Generate summary... e Revert. Secondo la guida rapida di JetBrains, i file modificati possono essere conservati, ritoccati, inclusi in un commit oppure ripristinati.

Seguire quest'ordine durante la revisione:

1. Ambito: sono cambiati soltanto i file previsti?
2. Comportamento: l'implementazione risolve esattamente l'errore?
3. Qualità del test: senza la correzione, il nuovo test fallirebbe?
4. Effetti collaterali: sono cambiate configurazione, dipendenze o interfacce pubbliche?
5. Verifica: il test riesce anche quando viene eseguito al di fuori del resoconto dell'agente?

Se il diff è quasi corretto, lo si può sistemare direttamente oppure lasciare un feedback preciso per un'altra iterazione. Se l'ambito sorprende, è meglio annullare tutto e ricominciare con un prompt più restrittivo. Una spiegazione plausibile non merita automaticamente un commit.

I costi, in pratica

Air cambia la voce di costo dell'orchestrazione, non quella dell'intelligenza che utilizza. Il plugin aggiunge $0 alla spesa software, mentre l'agente collegato può attingere da un abbonamento esistente, da un saldo API o dai crediti JetBrains AI.

È un aspetto importante quando il team paga già più agenti. Aggiungere una seconda interfaccia di controllo spesso significa acquistare un'altra licenza prima ancora di sapere se migliorerà la revisione. Come riferimento pubblico, GitHub indica attualmente Copilot Business a $19 per utente al mese ed Enterprise a $39. Dieci licenze Business costano $190 al mese prima degli utilizzi aggiuntivi. Air può collegare gli agenti supportati senza aggiungere un costo per il plugin Air, ma non elimina la licenza dell'IDE, l'abbonamento al provider, l'uso delle API o il tempo dedicato dalle persone alla revisione.

La domanda di budget utile è quindi molto più precisa: un'interfaccia locale gratuita per la revisione può rendere più semplice dirigere e verificare la spesa già destinata agli agenti? Prima di acquistare o standardizzare altro, conviene provarla con un solo team e una sola categoria di attività.

Sei casi d'uso, in ordine di vantaggio

1. Team JetBrains che pagano già più agenti

Un team di sviluppo che usa Codex per un carico di lavoro e Claude per un altro può avviarli entrambi dallo stesso ambiente IDE, allegare lo stesso contesto di progetto e controllare i file modificati in un unico posto. Il vantaggio non consiste necessariamente in token più economici, ma in meno passaggi fra strumenti e in un'abitudine di revisione coerente intorno agli abbonamenti già attivi.

2. Maintainer alle prese con difetti piccoli e verificabili

Un maintainer può allegare la funzione che fallisce, descrivere una singola regressione, richiedere un test mirato e controllare il diff prima che raggiunga un branch. È una soluzione utile quando la diagnosi è chiara, ma la correzione meccanica sottrae tempo a lavori più complessi.

3. Consulenti che entrano in una codebase sconosciuta

Un consulente può usare la navigazione del codice nell'IDE per esaminare i simboli, allegare soltanto i file pertinenti e chiedere all'agente una modifica circoscritta. Svolgere il lavoro in un branch sacrificabile con Standard Access riduce il rischio che convenzioni del repository ancora sconosciute producano un intervento troppo esteso. Il vantaggio è un orientamento più rapido, senza fingere che l'agente conosca le regole implicite del cliente.

4. QA engineer che trasformano un bug riproducibile in un test di regressione

Chi si occupa di QA e sa riprodurre un bug può allegare il file coinvolto e l'area dei test, chiedere il test di regressione più piccolo possibile e verificare se il test rappresenta davvero l'errore. Il risultato è un passaggio più breve dalla riproduzione a un artefatto tecnico pronto per la revisione.

5. Sviluppatori senior che insegnano la revisione attraverso diff concreti

Uno sviluppatore senior può lasciare che un agente proponga una piccola implementazione, poi guidare una persona meno esperta nella valutazione di ambito, ipotesi, progettazione del test e scelte di ripristino all'interno dell'IDE abituale. Il risultato non è soltanto codice: è un esercizio di revisione visibile, basato su un insieme reale di modifiche.

6. Platform team che confrontano gli agenti sulla stessa attività

Un platform team può eseguire la stessa attività circoscritta con preset diversi e confrontare file toccati, comportamento dei test, approvazioni necessarie e impegno richiesto dalla revisione. È una valutazione più utile rispetto al confronto fra risposte in chat, perché l'unità di giudizio è una modifica verificata nello stesso repository.

Due prodotti che vale la pena costruire intorno ad Air

1. Un sistema accessorio che documenta le prove di revisione

È l'opportunità più solida. Si può creare un piccolo prodotto complementare che trasformi una sessione dell'agente in un pacchetto di revisione: attività, contesto allegato, file modificati, comando di test, risultato del test, decisione umana e riferimento al commit finale. Engineering manager e team regolamentati pagherebbero per una documentazione ordinata, indipendente dall'agente che ha prodotto il codice.

La domanda è abbastanza specifica da essere rilevante: ai powered code review platform registra circa 1,900 ricerche mensili negli Stati Uniti, con intento commerciale. Anche i prezzi GitHub di $19 per Business e $39 per Enterprise mostrano che i team hanno già un budget per assistenza alla programmazione e governance.

La versione minima vendibile non deve controllare l'agente. Può importare un diff e l'output dei test, imporre una checklist al revisore ed esportare un record firmato in Markdown o JSON. Il limite è il rischio legato alla piattaforma: Air è in alpha, le sue interfacce possono cambiare ogni settimana e JetBrains potrebbe introdurre direttamente funzioni più ricche per le prove o gli audit. Il vantaggio difendibile deve essere una policy trasversale agli agenti e una reportistica durevole, non un semplice pulsante dentro un solo IDE.

2. Un consulente per configurare gli agenti in base al repository

Si può realizzare uno strumento di onboarding che analizzi linguaggi, comandi di test, percorsi sensibili e regole di contribuzione di un repository, quindi consigli un modello sicuro per la prima attività e le impostazioni del preset. Sarebbe destinato ai team che adottano agenti in repository eterogenei, dove oggi ogni sviluppatore ripete lo stesso lavoro di configurazione.

La domanda generale è ampia: ai coding assistant registra circa 18,100 ricerche mensili negli Stati Uniti, mentre ai powered coding agent ne registra circa 8,100. L'MVP può consistere in un questionario sul repository, corredato da note di configurazione generate, prompt iniziali ben delimitati e una checklist per lo smoke test. All'inizio non serve una profonda integrazione con l'IDE.

Il limite è la difendibilità. JetBrains, i fornitori di agenti o i template dei repository possono incorporare consigli di configurazione generici. Per essere sostenibile, il prodotto deve includere verifiche delle policy specifiche dell'organizzazione e prove che la configurazione consigliata riduca le modifiche fallite o troppo estese.

Limiti e valutazione realistica

Air esprime il massimo valore per chi preferisce già un IDE JetBrains e desidera scegliere fra più agenti senza rinunciare alla revisione integrata nell'IDE. Non è un motivo per delegare una modifica rischiosa che non si è in grado di verificare.

Al momento contano soprattutto tre vincoli:

• È un'alpha. Etichette e comportamento possono cambiare con un ritmo di rilascio approssimativamente settimanale.
• Il plugin è gratuito, il lavoro no. Autorizzazione dell'agente, abbonamenti, uso delle API, licenza dell'IDE e revisione umana restano costi separati.
• Il lavoro locale è il punto di partenza affidabile. La pagina dedicata all'IDE continua a indicare il passaggio al cloud come di prossima disponibilità; il primo workflow non dovrebbe quindi dipendere dalla possibilità di chiudere il portatile mentre l'attività prosegue.

Inoltre, Standard Access non equivale alla sola lettura: permette modifiche e comandi all'interno del progetto. È bene usare un branch o un worktree sacrificabile, esaminare il diff ed eseguire di nuovo il test in prima persona.

La conclusione è semplice: vale la pena provare Air su una piccola modifica se JetBrains è già l'ambiente di lavoro quotidiano. È invece troppo presto per imporlo come percorso obbligatorio nei repository sensibili senza un piano di ripristino, una policy per i provider e prove documentate della revisione.

La prova da fare lunedì

Scegliere un bug verificabile con un solo comando. Spostarlo su un branch sacrificabile, installare la build Air Alpha compatibile su un solo computer di sviluppo, scegliere Standard Access, allegare un file pertinente e chiedere la correzione più piccola possibile insieme a un test di regressione. La modifica va conservata soltanto se il diff è circoscritto e il test riesce quando viene eseguito personalmente. Questo singolo ciclo insegnerà più di una settimana di demo sugli agenti.

A cosa serve JetBrains Air?

JetBrains Air coordina gli agenti di coding e ne gestisce contesto, sessioni e revisione all'interno e all'esterno degli IDE JetBrains. Nel plugin locale per l'IDE si seleziona un agente, si invia un'attività con il contesto del progetto e si controllano poi le modifiche in Agent Sessions.

Quali sono le differenze principali tra JetBrains Air e Claude Code?

Claude Code è un singolo agente di coding. Air è un'interfaccia multi-agente per controllo e revisione, capace di eseguire Claude insieme a Codex, Junie, GitHub Copilot, Gemini, OpenCode e agenti compatibili con ACP, in base alle integrazioni e alle autorizzazioni disponibili.

Qual è il miglior IDE per l'agentic coding?

Non esiste un vincitore universale. Air è interessante quando il team dipende già dagli strumenti JetBrains per navigazione, ispezioni e diff. La scelta migliore è l'ambiente in cui il lavoro di un agente può essere delimitato, esaminato, testato e annullato in modo affidabile.

JetBrains si può usare gratuitamente?

Il plugin Air Alpha è gratuito. L'IDE JetBrains e l'agente collegato ad Air possono prevedere costi separati per licenze, abbonamenti o API.

Per costruire un workflow sicuro con agenti, calibrato sui repository e sulle regole di revisione dell'organizzazione, è disponibile il servizio di sviluppo di agenti AI.