JetBrains Air negli IDE apre l’EAP, ma la vera scommessa è l’orchestrazione

JetBrains ha aperto JetBrains Air negli IDE all’accesso anticipato, portando cinque agenti di coding supportati in uno spazio di lavoro progettato per attività parallele. La mossa riguarda meno l’aggiunta di un altro chatbot e più la definizione di dove gli sviluppatori supervisioneranno il codice generato dall’AI.

Air supporta nativamente Codex, Gemini, GitHub Copilot, Claude Agent e Junie, lo strumento proprietario di JetBrains. Può inoltre connettere altri strumenti compatibili tramite l’Agent Client Protocol, o ACP, un’interfaccia comune tra agenti di coding e ambienti di sviluppo.

Questo pone JetBrains in contrasto con una visione dello sviluppo software incentrata sul modello. In quel modello, gli sviluppatori seguono l’agente che in quel momento produce i risultati migliori. JetBrains scommette invece che il prodotto durevole sia l’ambiente che fornisce contesto, tiene traccia del lavoro simultaneo e aiuta le persone a rivedere ogni modifica.

Il primo annuncio parlava di un EAP in arrivo su cinque IDE. La documentazione attuale di JetBrains afferma ora che il plugin supporta la sua gamma di IDE, a eccezione di Android Studio, rendendo la portata finale più ampia di quanto suggerisse quella formulazione iniziale. Il numero più importante resta cinque agenti, perché Air li tratta come lavoratori intercambiabili all’interno di un’unica superficie di controllo.

JetBrains non chiede agli sviluppatori di abbandonare Codex, Claude, Gemini, Copilot o Cursor. Vuole che questi sistemi funzionino all’interno dei prodotti JetBrains. Questa distinzione trasforma JetBrains Air EAP in un test per capire se l’IDE possa restare il centro dello sviluppo software quando gli agenti svolgono una quota maggiore dell’implementazione.

JetBrains Air negli IDE separa lo spazio di lavoro dal modello

JetBrains Air negli IDE è un livello di orchestrazione, non un nuovo modello né un nuovo nome per AI Assistant.

JetBrains ha lanciato l’EAP all’inizio di ottobre tramite il Marketplace e le build EAP 2026.3 dei suoi IDE. L’annuncio Air EAP dell’azienda afferma che il plugin arriva senza un agente installato e non opera come fornitore di AI.

Questo design è importante perché separa tre prodotti che gli utenti spesso incontrano come un’unica esperienza integrata. Il modello genera o interpreta testo. L’agente di coding pianifica attività, utilizza strumenti, modifica file ed esegue comandi. Air organizza questi agenti e il loro lavoro all’interno dell’IDE.

Gli sviluppatori possono connettere gli agenti che già utilizzano, nel rispetto delle regole di autenticazione di ciascun fornitore. Non hanno bisogno di un abbonamento JetBrains AI solo per eseguire un agente di terze parti compatibile. Air può rilevare le installazioni locali degli agenti, proporre agenti tramite un registro e riutilizzare i metodi di autorizzazione supportati.

Cinque agenti ricevono supporto esplicito di prima classe: Codex, Gemini, GitHub Copilot, Claude Agent e Junie. Cursor e altri strumenti possono accedere tramite la compatibilità ACP, anche se l’interfaccia esatta e il percorso di autorizzazione possono variare a seconda dell’agente.

Il prodotto organizza il lavoro attorno alle sessioni anziché a una singola chat continua. Ogni sessione rappresenta un’attività, il relativo agente, il suo contesto, i progressi e le modifiche prodotte. Gli sviluppatori possono visualizzare il lavoro attivo tra più progetti, identificare le sessioni in attesa di input e aprire le modifiche completate per la revisione.

Air supporta anche i preset. Un preset memorizza un agente, la selezione del modello, lo sforzo di ragionamento, il livello di accesso e altre impostazioni di avvio. Ciò consente a un team di creare configurazioni diverse per correzioni di routine, refactoring più ampi, revisioni o esperimenti.

Questa struttura trasforma l’IDE in un dispatcher. Uno sviluppatore potrebbe affidare un test fallito a Codex, assegnare modifiche alla documentazione a Gemini e chiedere a Junie di analizzare un problema di prestazioni. Air non sostiene che questi agenti coopereranno come un’unica intelligenza collettiva. Offre a ogni attività un posto visibile e mantiene i relativi output all’interno di un flusso di revisione.

Questa distinzione evita un importante malinteso sull’espressione “esegue cinque agenti AI”. Air supporta nativamente cinque agenti nominati, ma non richiede che tutti e cinque operino insieme. Inoltre, non garantisce che agenti simultanei produrranno codice compatibile.

La documentazione Air attuale di JetBrains afferma che gli agenti locali vengono eseguiti sulla macchina dello sviluppatore. Air comunica con gli agenti compatibili con ACP tramite il protocollo, mentre gli agenti da riga di comando possono mantenere le proprie interfacce terminale all’interno dell’IDE.

Il plugin è installabile per le versioni 2026.2 ed è incluso nelle build EAP 2026.3. JetBrains documenta ora il supporto per tutti i suoi IDE tranne Android Studio. Disponibilità, autorizzazione degli agenti ed esecuzione cloud possono comunque dipendere dalla versione del prodotto dell’utente e dalle impostazioni dell’organizzazione.

Questi dettagli rendono l’iniziativa più di un semplice aggiornamento della distribuzione. JetBrains sta riorganizzando la propria interfaccia AI attorno al lavoro delegato, mantenendo vicini al risultato l’editor esistente, il debugger, le ispezioni, la navigazione e gli strumenti di controllo versione.

Perché JetBrains si sta spingendo oltre il pannello di chat AI

La pressione su JetBrains deriva da un cambiamento nel comportamento degli sviluppatori, non semplicemente da modelli linguistici più potenti.

La prima generazione di funzionalità AI basate su IDE era incentrata sul completamento automatico e sulla chat. Uno sviluppatore selezionava il codice, poneva una domanda, riceveva una risposta e decideva cosa incollare o applicare. Questa interazione si adattava comodamente a un pannello laterale.

Gli agenti di coding creano un diverso problema di gestione. Possono leggere più file, elaborare un piano, eseguire comandi, modificare un repository e lanciare test prima di restituire il controllo. Uno sviluppatore può anche avviare un’altra attività mentre il primo agente rimane attivo.

JetBrains afferma di aver provato a collocare più agenti nella chat esistente di AI Assistant. L’azienda ha concluso che supervisionare attività simultanee richiedeva un prodotto organizzato attorno allo stato del lavoro piuttosto che alla cronologia della conversazione.

Questa conclusione spiega perché Air e AI Assistant restano separati durante l’EAP. AI Assistant continua a fornire chat, completamento, approfondimenti sul codice, suggerimenti per la modifica successiva e accesso agli agenti nell’esperienza IDE consolidata. Air tratta agenti e sessioni come le principali unità di lavoro.

JetBrains prevede che Air diventi nel tempo la sua interfaccia agentica principale, ma non ha annunciato la rimozione di AI Assistant. Gli utenti possono mantenere AI Assistant installato, anche se l’installazione di Air tramite una notifica di AI Assistant disabilita il plugin più vecchio per impedire l’esecuzione simultanea delle due interfacce. Può essere riattivato dalle impostazioni del plugin.

La questione competitiva più profonda riguarda il controllo dell’attenzione dello sviluppatore. Editor incentrati sugli agenti e strumenti da riga di comando possono sottrarre lavoro all’IDE tradizionale. Se gli sviluppatori trascorrono la maggior parte del tempo a inviare prompt e rivedere patch altrove, l’IDE rischia di diventare un luogo secondario, usato solo per il debugging più complesso.

Air tenta di invertire questo flusso. Invece di costringere gli sviluppatori a scegliere tra JetBrains e un agente esterno, invita l’agente esterno nell’ambiente JetBrains. L’agente fornisce pianificazione e generazione, mentre l’IDE mette a disposizione il contesto del repository e gli strumenti di verifica.

Questo approccio affronta anche il ricambio dei modelli. Il principale modello di coding può cambiare più rapidamente di quanto un’organizzazione cambi il proprio ambiente di sviluppo. Un’azienda può preferire un agente per le migrazioni Java, un altro per il lavoro sulle interfacce e un agente interno per repository che contengono codice soggetto a restrizioni.

JetBrains non ha bisogno che Junie vinca ogni confronto se Air rimane il luogo in cui questi sistemi vengono gestiti. L’azienda può beneficiare di agenti di terze parti più capaci, perché tali agenti rendono più utile lo spazio di lavoro condiviso.

Per questo ACP svolge un ruolo centrale. Il contratto ACP definisce una connessione comune tra un client, come un IDE, e un agente. L’agente conserva la propria selezione del modello, gli strumenti, l’autenticazione e il comportamento di pianificazione.

JetBrains paragona questo confine al ruolo del Language Server Protocol. Un editor non necessita di un’integrazione privata separata per ogni language server compatibile. ACP mira a ridurre la necessità di un plugin su misura tra ogni agente e ogni ambiente di sviluppo.

L’analogia ha dei limiti. Gli agenti di coding possono eseguire comandi e modificare ampie porzioni di un repository, quindi le loro autorizzazioni e i loro effetti collaterali comportano rischi maggiori. Tuttavia, un livello di connessione comune riduce il lavoro di integrazione e rende meno dirompente il cambio di agente.

Per JetBrains, questo crea un’apertura strategica. Cursor, Codex, Claude, Copilot e Gemini non devono essere sconfitti a livello di modello. Possono diventare opzioni all’interno di un IDE JetBrains multi-agente.

L’IDE diventa il piano di controllo per il lavoro degli agenti

La scommessa centrale di Air è che la verifica diventi più preziosa man mano che la generazione di codice diventa più semplice.

Generare una patch è solo una parte dello sviluppo software. Qualcuno deve stabilire se la patch corrisponde al requisito, preserva l’architettura, supera i test, rispetta i confini di sicurezza e si comporta correttamente in condizioni reali.

JetBrains possiede già molti degli strumenti utilizzati per questo lavoro. I suoi IDE comprendono simboli, tipi, riferimenti, struttura del progetto, esecutori di test, controllo versione, database, debugger e profili delle prestazioni. Air collega l’attività degli agenti a queste superfici esistenti.

Un agente può ricevere file, commit, screenshot e istruzioni riutilizzabili come contesto. Lo sviluppatore può ispezionare i file modificati, confrontare le differenze, navigare nel codice correlato ed eseguire il progetto senza trasferire il risultato in un’altra applicazione.

Questa connessione può ridurre l’esplorazione duplicata. Un agente di coding spesso consuma token per elencare directory, aprire file di configurazione e individuare simboli rilevanti. Il contesto fornito dall’IDE può indirizzarlo prima verso il codice corretto, anche se il risparmio varierà in base all’agente e all’attività.

Air offre inoltre agli agenti supportati accesso alle skill dell’IDE per attività quali debugging, profiling, esplorazione di database e ricerca semantica del codice. JetBrains afferma che questi strumenti possono migliorare i risultati per alcuni compiti, ma la dichiarazione necessita ancora di test estesi su repository e linguaggi diversi.

La sessione dell’agente diventa il contenitore di questo flusso di lavoro. Registra l’agente selezionato, la conversazione, l’attività, i file modificati, i commit e il costo segnalato. Le sessioni possono restare visibili tra più progetti, aiutando uno sviluppatore a individuare il lavoro completato o quello che richiede un intervento.

Questo modello è diverso dall’aprire cinque schede di chat. Una scheda di chat conserva principalmente una conversazione. Una sessione Air collega la conversazione allo stato del repository e alle azioni di revisione.

Si consideri uno sviluppatore responsabile di un servizio con un test di integrazione fallito. Una sessione può indagare sul problema. Una seconda può aggiornare una dipendenza correlata in un branch isolato. Una terza può esaminare la documentazione interessata dalla modifica.

Lo sviluppatore può continuare a lavorare nel checkout principale mentre queste sessioni procedono. Quando una termina, l’IDE diventa il luogo per rivedere il diff, eseguire le ispezioni, controllare i test e decidere se il risultato appartiene al branch di destinazione.

Questo processo si inserisce in un cambiamento più ampio del lavoro ingegneristico. Gli sviluppatori coordinano sempre più modifiche generate invece di digitare direttamente ogni implementazione. La loro responsabilità non scompare. Si sposta verso la definizione delle attività, la fornitura di contesto, l’esame delle prove e la risoluzione dei conflitti.

JetBrains sta posizionando l’IDE come piano di controllo per queste responsabilità. Il termine indica una superficie che coordina lavoratori e stato senza essere il lavoratore stesso. Air non deve generare la patch migliore per diventare prezioso, se rende più semplice supervisionare più agenti.

Il modello preserva inoltre la scelta dell’utente. Uno sviluppatore può collegare un abbonamento esistente quando il provider lo consente, selezionare JetBrains AI o usare un agente ACP configurato localmente. Air non fornisce di per sé un modello proprietario.

Questa flessibilità è strategicamente importante. Uno spazio di lavoro chiuso e vincolato a un unico modello eredita le debolezze e i cambiamenti commerciali di quel modello. Uno spazio di lavoro multi-agente può consentire agli sviluppatori di sostituire l’agente preservando al contempo le abitudini di progetto e gli strumenti di revisione.

I team che già costruiscono un contesto ingegneristico ricercabile potrebbero riconoscere lo stesso schema. La risorsa durevole non è una singola risposta, ma la struttura che collega codice, decisioni, documenti e revisione. Una base di conoscenza tecnica può integrare le sessioni con gli agenti preservando le informazioni che dovrebbero sopravvivere oltre una singola attività di programmazione.

Air non risolve da sola questo problema più ampio di gestione della conoscenza. Una sessione contiene un utile contesto di lavoro, ma i team necessitano comunque di registrazioni durevoli per decisioni architetturali, incidenti e requisiti. L’IDE può coordinare l’implementazione, mentre i sistemi di conoscenza condivisa preservano il perché dell’implementazione.

Gli agenti paralleli creano un problema di merge e attenzione

L’esecuzione di più agenti aumenta la produttività solo quando gli sviluppatori riescono a rivedere, riconciliare e fidarsi dei loro risultati.

Air consente agli sviluppatori di avviare sessioni da un branch e collocare il lavoro in un Git worktree temporaneo. Un worktree è una copia di lavoro separata collegata alla stessa cronologia del repository. Mantiene le modifiche dell’agente lontane dal checkout corrente dello sviluppatore.

Questo isolamento è essenziale per il lavoro parallelo. Due agenti che modificano gli stessi file nello stesso spazio di lavoro possono sovrascrivere presupposti o creare modifiche che funzionano singolarmente ma falliscono insieme. Worktree separati riducono le interferenze dirette.

Air può mostrare il risultato e consentire allo sviluppatore di trasferire commit selezionati nuovamente nel progetto attivo. Il suo flusso di lavoro delle sessioni documentato supporta la revisione delle modifiche prima di applicarle con cherry-pick al branch di destinazione.

L’isolamento non elimina il lavoro di integrazione. Se cinque agenti modificano aree collegate, lo sviluppatore può trovarsi davanti a cinque branch, modifiche duplicate, astrazioni incoerenti e conflitti di merge. Ogni agente può produrre un risultato locale plausibile mentre il sistema combinato diventa meno coerente.

Il collo di bottiglia si sposta quindi dalla produzione di codice all’attenzione umana. Uno sviluppatore deve comprendere cosa ha modificato ciascun agente e perché. Deve inoltre decidere quali test forniscano prove significative, anziché accettare un riepilogo positivo generato dallo stesso sistema che ha scritto il codice.

L’elenco delle sessioni di Air aiuta a rendere visibile questo carico di lavoro. Può mostrare sessioni attive, aggiornamenti non letti, file modificati, commit in uscita e attività in attesa di input. Questa visibilità è utile, ma non può stabilire se le decisioni sottostanti siano corrette.

Questo è il compromesso centrale alla base dell’EAP di JetBrains Air. Il parallelismo può ridurre i tempi di attesa, ma può anche moltiplicare gli obblighi di revisione. Un team che avvia agenti più rapidamente di quanto riesca a verificarne il lavoro crea semplicemente una coda più grande di patch incerte.

I preset introducono un’altra preoccupazione di governance. Rendono la configurazione ripetibile, ma i team devono decidere quali modelli, autorizzazioni e livelli di impegno appartengano a ciascuna classe di attività. Un agente con accesso elevato adatto a un repository di test usa e getta potrebbe essere inaccettabile per l’infrastruttura di produzione.

Anche l’autenticazione resta disomogenea. JetBrains supporta varie modalità, inclusi accessi gestiti dal provider, credenziali di terze parti e JetBrains AI. Tuttavia, un abbonamento utilizzabile in un’interfaccia potrebbe non autorizzare lo stesso agente in un’altra superficie.

Claude illustra questa complessità. JetBrains afferma che un abbonamento Claude può essere usato tramite l’interfaccia terminale, mentre Claude Agent nella chat strutturata richiede JetBrains AI oppure una chiave API Anthropic con fatturazione API. Gli sviluppatori dovrebbero verificare le attuali regole di autorizzazione prima di considerare Air un hub universale per gli abbonamenti.

L’esecuzione cloud aggiunge ulteriori confini. Le sessioni locali vengono eseguite sulla macchina dello sviluppatore, ma le organizzazioni idonee possono inviare determinate attività all’infrastruttura JetBrains. Le esecuzioni cloud possono continuare dopo la chiusura dell’IDE, sebbene la disponibilità dipenda dalle impostazioni dell’organizzazione, dall’hosting del repository e da un abbonamento JetBrains AI.

La gestione dei dati dipende quindi dal percorso selezionato. JetBrains afferma che i dati degli agenti di terze parti vanno direttamente a quel provider in base all’accordo esistente dell’utente quando viene usato un abbonamento di terze parti. JetBrains AI e le funzionalità cloud operano secondo i termini applicabili.

Anche l’accordo EAP esplicita il livello di maturità. Il software in accesso anticipato può contenere errori, comportarsi in modo inatteso e cambiare durante lo sviluppo. I team non dovrebbero considerare l’etichetta EAP un semplice distintivo di routine quando gli agenti possono modificare file ed eseguire comandi.

Un’implementazione prudente inizierebbe con repository non critici e autorizzazioni ristrette. I team dovrebbero richiedere una revisione umana, preservare branch recuperabili ed eseguire test indipendenti prima del merge. Il codice sensibile richiede una decisione chiara sul provider e sul percorso dei dati prima che qualsiasi agente riceva contesto.

Questi controlli non sono argomenti contro JetBrains Air negli IDE. Sono le condizioni alle quali il suo modello parallelo diventa utile. L’orchestrazione crea leva solo quando rende la responsabilità più visibile anziché nasconderla dietro dashboard delle attività.

JetBrains trasforma i rivali in componenti sostituibili

Air sfida gli editor agent-first incorporandone gli agenti e preservando al contempo l’ambiente di sviluppo JetBrains.

L’avversario più importante non è una sola azienda. È l’idea che l’agente di programmazione debba possedere l’intero spazio di lavoro dello sviluppatore.

Un editor agent-first può ottimizzare ogni interazione attorno a un unico sistema integrato. Questo crea un’esperienza mirata, ma può anche rendere il flusso di lavoro dello sviluppatore dipendente dall’instradamento dei modelli, dalle decisioni di interfaccia e dal calendario di rilascio di quel prodotto.

JetBrains adotta la posizione opposta. L’IDE rimane stabile mentre gli agenti competono per le attività al suo interno. Gli sviluppatori possono mantenere strumenti familiari di navigazione, refactoring, debug e ispezione cambiando al contempo il sistema che genera il codice.

ACP rende credibile questa proposta. Senza un protocollo condiviso, il supporto di molti agenti richiederebbe una collezione crescente di integrazioni private. Ogni aggiornamento del provider potrebbe interrompere un connettore o rendere le funzionalità incoerenti tra i prodotti.

Con ACP, l’unità sostituibile include più di un modello. Un agente porta con sé la propria logica di pianificazione, gli strumenti, le autorizzazioni, l’instradamento dei modelli e il comportamento dell’interfaccia. Air si collega a questo pacchetto completo attraverso un confine client comune.

Questo offre a JetBrains un modo per beneficiare dell’innovazione esterna. Se Codex migliora nelle modifiche su scala di repository, gli utenti di Air possono sceglierlo. Se Gemini diventa migliore per un altro carico di lavoro, lo spazio di lavoro non deve cambiare. Un agente ACP interno può gestire attività con restrizioni.

I cinque agenti nominati sono quindi una formazione iniziale, non un limite fisso. Codex, Gemini, GitHub Copilot, Claude Agent e Junie offrono all’EAP scelte riconoscibili. Il registro e la configurazione personalizzata ampliano l’insieme possibile.

Cursor è un esempio rivelatore. Compete per l’attenzione degli sviluppatori come ambiente di programmazione orientato all’IA, eppure il suo agente può anche collegarsi ai prodotti JetBrains tramite ACP. JetBrains può trasformare un prodotto associato al cambio di editor in un collaboratore disponibile all’interno del proprio IDE.

Ciò non garantisce che gli utenti rimarranno. Un prodotto agent-first nativo può comunque offrire un’interfaccia più coerente, una distribuzione più rapida delle funzionalità o un’integrazione più stretta con il modello preferito. La compatibilità di protocollo raramente rende identica ogni esperienza client.

Air deve anche giustificare la complessità della scelta. Cinque agenti con autorizzazioni, abbonamenti, modalità e punti di forza diversi possono diventare più difficili da gestire di uno strumento familiare. Lo spazio di lavoro necessita di stato chiaro, configurazione prevedibile e informazioni di revisione affidabili.

Anche la gamma di prodotti JetBrains aggiunge un altro rischio. Gli utenti incontrano già AI Assistant, Junie, Air, agenti ACP, account dei provider e JetBrains AI. Air crea una divisione concettuale più chiara, ma il periodo di transizione può comunque sembrare frammentato.

L’azienda sta cercando di risolvere questo problema rendendo Air l’ambiente dedicato ai flussi di lavoro agentici, mantenendo al contempo AI Assistant per chat e assistenza inline. Se gli utenti comprenderanno e preferiranno questa divisione sarà un risultato chiave dell’EAP.

JetBrains ha inizialmente presentato l’ambiente Air standalone come uno spazio costruito attorno agli agenti anziché un editor con l’IA aggiunta. La sua anteprima pubblica di marzo ha stabilito la delega concorrente come idea centrale del prodotto.

Portare questa esperienza negli IDE consolidati cambia la proposta. Gli sviluppatori non devono più adottare un’applicazione separata per testare il flusso di lavoro. JetBrains può distribuire Air attraverso prodotti già radicati nei team di ingegneria.

Questo vantaggio distributivo è significativo, ma l’adozione dipende dall’utilità quotidiana. Gli sviluppatori non manterranno un’altra finestra di strumenti solo perché riconosce vari agenti. Air deve rendere il lavoro concorrente più facile da comprendere, rivedere e integrare rispetto a terminali separati o applicazioni dei provider.

Cosa osservare dopo l’EAP di JetBrains Air

Il prossimo test non è quanti agenti elenchi Air, ma se i team completino lavoro reale con meno cambi di contesto e costi di revisione gestibili.

Il primo segnale è l’adozione nei repository ordinari. JetBrains ha bisogno di prove che gli sviluppatori continuino a usare Air dopo che la novità dell’avvio di sessioni parallele svanisce. Un uso ripetuto tra debug, manutenzione, test e refactoring sosterrebbe la tesi dell’orchestrazione.

La metrica utile non è il numero di prompt. I team dovrebbero esaminare attività completate, modifiche accettate, tempo di revisione, difetti riaperti e quantità di riparazione manuale richiesta dopo la conclusione del lavoro di un agente. Un alto volume di sessioni può nascondere output di bassa qualità.

Il secondo segnale è l’affidabilità dell’integrazione basata sui worktree. Air dovrebbe rendere evidenti lo stato dei branch, le modifiche non salvate nel commit, i conflitti e le destinazioni di trasferimento. Un sistema progettato per agenti paralleli deve evitare che gli sviluppatori perdano lavoro o applichino una patch corretta al branch sbagliato.

JetBrains documenta misure di protezione e controlli di revisione, ma l’EAP rivelerà come si comportano sotto la pressione quotidiana. Repository di grandi dimensioni, file generati, monorepo e refactoring sovrapposti offriranno test più impegnativi rispetto a dimostrazioni isolate.

Il terzo segnale è la risposta competitiva dei provider di agenti e degli editor rivali. Una più ampia adozione di ACP rafforzerebbe la strategia di spazio di lavoro aperto di JetBrains, perché gli sviluppatori potrebbero spostare gli agenti tra client supportati. I provider potrebbero invece favorire funzionalità proprietarie che funzionano meglio all’interno delle proprie applicazioni.

Il supporto per capacità comuni conterà tanto quanto il numero di agenti. Autorizzazioni, chiamate agli strumenti, allegati di contesto, rendicontazione dei costi, ripresa delle sessioni e attribuzione delle differenze devono avere un comportamento coerente. Un protocollo che collega molti agenti ma espone soltanto le loro funzionalità comuni minime limiterebbe il vantaggio di Air.

Le organizzazioni dovrebbero inoltre osservare i controlli amministrativi. JetBrains afferma che le aziende possono disabilitare Air tramite l’accesso IA gestito, ma la sua documentazione rileva che la gestione di IDE Services non è ancora completa. L’adozione aziendale richiede politiche chiare per provider, credenziali, esecuzioni cloud, instradamento dei dati e verificabilità.

Il rapporto tra Air e AI Assistant è un altro segnale concreto. JetBrains afferma che AI Assistant continuerà a essere supportato, mentre Air diventerà l’esperienza agentica preferita. Le prossime release chiariranno se questa distinzione si semplificherà o produrrà interfacce sovrapposte.

Una transizione riuscita lascerebbe agli sviluppatori un punto chiaro per le attività delegate e un altro per l’assistenza inline più leggera. Una transizione confusa costringerebbe gli utenti a capire quale plugin gestisce ciascun agente, abbonamento o modalità di chat.

I cinque agenti supportati riveleranno inoltre se la specializzazione offre un valore pratico. Gli sviluppatori hanno bisogno di ragioni osservabili per scegliere Codex per un’attività e Junie o Gemini per un’altra. In caso contrario, il selettore diventa una scelta amministrativa anziché una funzionalità per la produttività.

JetBrains Air negli IDE si fonda, in ultima analisi, su una premessa difendibile: il codice generato aumenta il valore del contesto e della revisione. La domanda ancora aperta è se un singolo IDE possa organizzare un numero sufficiente di agenti senza trasformare gli sviluppatori in gestori di code a tempo pieno.

Provate l’EAP su un branch facilmente ripristinabile e assegnategli un’attività che coinvolga più file, test e fasi di revisione. Poi confrontate l’intero flusso di lavoro con la vostra attuale configurazione di agenti. Air ha ridotto il passaggio di contesto, reso più semplici da ispezionare le modifiche e mantenuto il controllo sul repository? Oppure ha semplicemente raccolto cinque interfacce in un’unica finestra? La risposta, ripetuta nei team reali, determinerà se JetBrains Air diventerà il livello operativo per lo sviluppo agentico o resterà un esperimento interessante.