JetBrains ha annunciato, all’inizio di settembre 2026, JetBrains Air, un sistema di prodotti aperto e coerente destinato a sviluppatori, team e organizzazioni, nei propri ambienti di sviluppo integrati (IDE) e oltre. Il sistema si estende su più interfacce e più servizi. Ogni prodotto risponde a un problema distinto, ma l’editore indica che funzionano meglio insieme.
JetBrains Air integra Air Teams, uno spazio di collaborazione dedicato allo sviluppo agentico, cioè al lavoro affidato ad agenti, programmi di intelligenza artificiale capaci di eseguire compiti in modo autonomo. Air Teams fornisce ai team e agli agenti il contesto, gli ambienti, gli strumenti e le istruzioni condivise di cui hanno bisogno durante l’intero ciclo di sviluppo.
L’azienda spiega di aver osservato due evoluzioni dal lancio di Air, presentato « diversi mesi fa » come un primo passo. Gli sviluppatori non hanno bisogno di un’applicazione autonoma aggiuntiva, perché gli strumenti e gli agenti devono essere integrati nell’ambiente in cui lavorano già. Inoltre, man mano che i singoli sviluppatori aumentavano la produttività grazie agli agenti, « il vero collo di bottiglia si è spostato a livello del team ». JetBrains precisa: « Abbiamo quindi deciso di far evolvere Air per andare oltre una semplice applicazione desktop autonoma e proporre un sistema più vasto e integrato ».
Automatizzazioni condivise da tutto il team
Air Teams si basa su quattro elementi: le automatizzazioni, gli ambienti cloud condivisi, i compiti cloud e i progetti. Le automatizzazioni sono workflow, cioè sequenze di passaggi, che si eseguono da soli nel cloud a partire da un evento o una pianificazione. Air Teams ne fornisce 10 modelli, in particolare per la revisione del codice, la correzione di bug, l’aggiornamento delle dipendenze (le librerie esterne utilizzate da un progetto) e la manutenzione della documentazione.
Ogni automatizzazione si basa su quattro parametri: istruzioni, un ambiente, strumenti e un trigger. Gli strumenti possono includere Jira, Figma e Linear tramite connettori. Il trigger può essere un evento GitHub o Jira, un webhook o una pianificazione. Nell’esempio fornito da JetBrains, l’aggiunta dell’etichetta Bug a un ticket avvia un agente, che legge il ticket, identifica la causa nel codice e apre una richiesta di merge, chiamata pull request, contenente una proposta di correzione che « un ingegnere potrà verificare ».
JetBrains presenta tre esempi. Per la revisione del codice, l’agente pubblica commenti e un riepilogo, poi può approvare la pull request o richiedere modifiche. Per le correzioni di ticket in YouTrack, un membro del team può assegnare a un agente un compito semplice e ben definito. Infine, due volte alla settimana, un agente aggiorna le dipendenze del progetto, compila il codice, esegue i test e apre una pull request riepilogativa.
Ambienti e progetti che non dipendono da una persona
Ogni automatizzazione e ogni compito cloud si esegue in un ambiente. In Air Teams, questa configurazione è memorizzata nel repository, al percorso .air/cloud/startup.sh, per essere versionata e revisionata con il resto del codice. Una volta pronto, l’ambiente può essere salvato come snapshot e condiviso. JetBrains precisa che condividere la configurazione non significa condividere le credenziali: i segreti condivisi possono essere utilizzati senza essere visibili, mentre i segreti personali rimangono propri di ciascuno.
I compiti cloud, invece, non sono legati al dispositivo che li ha avviati. Un utente può avviare un compito dal proprio IDE e poi riprenderlo sul web, e l’agente continua a lavorare dopo la chiusura del portatile. Un progetto di team riunisce i membri, gli ambienti condivisi, i connettori MCP e le automatizzazioni. Ogni progetto dispone del proprio account di servizio e dei propri crediti IA, e un amministratore decide se le automatizzazioni consumano questi crediti o quelli dei loro creatori. Nel primo caso, continuano a funzionare dopo la partenza del loro creatore.
