JetBrains coloca um orquestrador de agentes dentro de cada IDE que lança

A JetBrains abriu o acesso antecipado ao Air em suas IDEs em 1º de outubro. Ele está disponível como plugin no JetBrains Marketplace ou incluído nas builds EAP 2026.3 do IntelliJ, PyCharm, WebStorm, Rider e do restante da família, e funciona a partir da versão 2026.2. O plugin é gratuito.

O enquadramento é a parte interessante. O Air não é um modelo nem um agente. Ele vem sem nenhum agente instalado. A JetBrains o descreve como um canal para agentes e assinaturas que o desenvolvedor já paga, e ele detecta o que já está na máquina da mesma forma que a IDE detecta terminais.

Sessões em vez de chat

A JetBrains argumenta que orquestrar várias tarefas simultaneamente é uma atividade diferente de conversar com um modelo, e que usar uma única interface para as duas coisas foi um erro. A IA clássica das IDEs era centrada no chat. O Air é centrado em sessões.

Cada sessão é um agente trabalhando em uma tarefa, e a interface as acompanha em conjunto: atividade, atualizações não lidas, arquivos alterados, commits de saída e o custo de cada sessão em uma única visão. As sessões podem ser executadas em vários projetos, aparecer como abas do editor ou permanecer em um terminal ou chat gráfico, dependendo da tarefa. Pressionar Ctrl duas vezes em qualquer lugar da IDE abre uma janela de prompt com o contexto atual anexado.

O isolamento é feito com worktrees temporárias do Git. Uma sessão pode começar a partir de qualquer branch, em um novo branch ou de forma desanexada (detached), e os resultados são trazidos de volta ao projeto principal via cherry-pick. A JetBrains afirma que a saída do agente aparece como um diff revisável dentro da IDE, usando as mesmas ferramentas que um desenvolvedor usaria para revisar um pull request, e que as alterações não são aplicadas automaticamente.

A aposta no protocolo é a parte estratégica

O Air conecta agentes que suportam o Agent Client Protocol, um padrão aberto que a JetBrains cocriou com a Zed e lançou sob a licença Apache. O ACP usa JSON-RPC 2.0 sobre stdin e stdout, e JetBrains, Zed, Google, GitHub e mais de 25 agentes o adotaram. As duas empresas também lançaram um ACP Registry, um diretório pesquisável de agentes compatíveis integrado à IDE.

A comparação mais fácil é com o Language Server Protocol. O LSP permitiu que qualquer editor suportasse qualquer linguagem por meio de um padrão compartilhado, em vez de uma integração sob medida para cada combinação. O ACP pretende fazer o mesmo para agentes.

A JetBrains está competindo pela camada onde os agentes são iniciados, supervisionados e revisados, e não pela qualidade do modelo, e cocriar o protocolo que rege como os agentes conversam com os editores é uma forma de ser infraestrutura em vez de um recurso. A própria explicação da empresa é mais direta: uma IDE que mantém os agentes a distância terá dificuldades à medida que o desenvolvimento agêntico se tornar normal.

Entre os agentes suportados estão Codex, Claude Agent, GitHub Copilot, Gemini, OpenCode e o Junie da própria JetBrains, além de outras ferramentas compatíveis com ACP. Um usuário com uma chave existente da Anthropic, OpenAI ou Google não paga nada à JetBrains. Para quem não tem uma assinatura de agente, a JetBrains oferece execuções gratuitas do Junie Lite após fazer login com uma conta JetBrains. Os créditos de IA da JetBrains começam em dez dólares por mês para o acesso aos modelos hospedados pela própria empresa.

O recurso que o Cursor não tem

O diferencial em que a JetBrains se apoia é que agentes conectados ao Air podem invocar ferramentas da IDE como skills. Um agente pode disparar uma execução de depuração para investigar um teste que falha, ou executar o profiler, ou usar o motor de refatoração com contexto completo de vários arquivos. Os agentes também podem acessar as ferramentas da IDE via MCP e trabalhar com contexto estruturado em vez de texto colado.

A JetBrains afirma que isso produz melhores resultados em algumas tarefas e, em alguns casos, consome menos tokens. A afirmação sobre os tokens é da empresa, e nenhum teste independente foi publicado.

O argumento de fundo é sobre o que um agente consegue enxergar. Um agente que só sabe ler e escrever arquivos trabalha a partir de texto. Um agente que consegue analisar o desempenho de uma função lenta e inspecionar a pilha de chamadas tem o contexto que um desenvolvedor sênior teria ao diagnosticar o mesmo problema. A JetBrains passou 26 anos construindo esse conjunto de ferramentas, e o Air é a primeira vez que os agentes têm acesso a ele.

Por que o momento faz sentido

A JetBrains está lançando isso em um momento no qual a etapa de revisão se tornou o gargalo reconhecido. Escrever código já não é a restrição para muitas equipes. Verificar o que foi escrito é.

Esse diagnóstico está aparecendo em todo o mercado de ferramentas ao mesmo tempo. A Qodo lançou a versão 3.0 na mesma semana com a revisão como peça central, e o Cursor adicionou um bot de revisão ao seu fluxo de trabalho de agentes. Três fornecedores convergindo para a mesma conclusão sugere que a restrição mudou de vez: quando os agentes conseguem produzir código mais rápido do que os humanos conseguem lê-lo, o valor se desloca para tudo o que reduz o custo de leitura.

O design do Air reflete isso. O produto trata sessões paralelas de agentes como uma fila de trabalho a ser revisado, e não como uma conversa a ser conduzida, e coloca o custo por sessão na mesma visão que os arquivos alterados. Para um gerente de engenharia decidindo quantos agentes executar, essa linha de custo é o limite prático.

A exibição do custo por sessão é um recurso pequeno com um efeito desproporcional sobre o comportamento. Uma equipe que não consegue ver quanto um agente de longa duração está gastando tende a executar um único agente com cautela. Uma equipe que consegue ver o número por sessão está mais disposta a executar vários, porque a decisão se torna uma alocação em vez de uma aposta. É a mesma mudança que aconteceu com os painéis de gastos em nuvem, e ela altera a forma como as pessoas organizam o trabalho.

Há também um problema de coordenação que o Air tenta resolver. Uma equipe que executa o Claude em uma tarefa, o Codex em outra e o Copilot em uma terceira acaba com três interfaces separadas e nenhum registro compartilhado do que cada um tocou. Consolidá-los em uma IDE que já domina diffs, inspeções e controle de versão é uma mudança menor do que adotar uma nova ferramenta e, para equipes padronizadas na JetBrains para Java, Kotlin ou Python, evita empurrar todo mundo para um editor diferente só para ter agentes.

O que ainda não está definido

O Air é um lançamento de acesso antecipado. A JetBrains diz para esperar arestas, mudanças na interface e no comportamento, e atualizações aproximadamente toda semana. A empresa não informou uma data de disponibilidade geral. A execução em nuvem para tarefas de longa duração está limitada a organizações com assentos de IA, e a JetBrains não divulgou o preço para isso.

Sobre privacidade, a empresa afirma que, sem nenhum agente conectado, nada sai da máquina, e que, com uma assinatura de terceiros, os dados vão para esse fornecedor sob o acordo existente, e não por meio da JetBrains. Desativar o plugin não altera mais nada, e o AI Assistant separado continua com suporte.

A afirmação que vale a pena testar no repositório da própria equipe é a sobre revisão. O Air facilita executar vários agentes ao mesmo tempo. Se isso produz mais trabalho integrado ou mais diffs que ninguém lê é uma questão empírica, e ela será respondida no primeiro mês de uso, e não em um post de lançamento.