JetBrains Air em IDEs abre EAP, mas a orquestração é a aposta real

A JetBrains abriu o acesso antecipado ao JetBrains Air em IDEs, reunindo cinco agentes de programação compatíveis em um espaço de trabalho criado para tarefas paralelas. A iniciativa tem menos a ver com adicionar outro chatbot e mais com definir onde os desenvolvedores irão supervisionar o código gerado por IA.

O Air oferece suporte nativo a Codex, Gemini, GitHub Copilot, Claude Agent e ao próprio Junie da JetBrains. Também pode conectar outras ferramentas compatíveis por meio do Agent Client Protocol, ou ACP, uma interface comum entre agentes de programação e ambientes de desenvolvimento.

Isso coloca a JetBrains diante de uma visão de desenvolvimento de software centrada no modelo. Nesse modelo, os desenvolvedores seguem o agente que estiver produzindo os melhores resultados no momento. A JetBrains aposta que o produto duradouro será o ambiente que fornece contexto, acompanha o trabalho simultâneo e ajuda humanos a revisar cada alteração.

A manchete inicial descrevia um EAP chegando a cinco IDEs. A documentação atual da JetBrains agora afirma que o plugin oferece suporte à sua linha de IDEs, exceto o Android Studio, tornando o escopo final mais amplo do que sugeria esse enquadramento inicial. O número mais importante continua sendo cinco agentes, porque o Air os trata como trabalhadores intercambiáveis dentro de uma única superfície de controle.

A JetBrains não está pedindo aos desenvolvedores que abandonem Codex, Claude, Gemini, Copilot ou Cursor. Ela quer que esses sistemas funcionem dentro dos produtos JetBrains. Essa distinção transforma o JetBrains Air EAP em um teste para saber se a IDE pode continuar sendo o centro do desenvolvimento de software quando os agentes executam uma parte maior da implementação.

JetBrains Air em IDEs separa o espaço de trabalho do modelo

O JetBrains Air em IDEs é uma camada de orquestração, não um novo modelo nem um novo nome para o AI Assistant.

A JetBrains lançou o EAP no início de outubro por meio do Marketplace e das builds 2026.3 EAP de suas IDEs. O anúncio da empresa sobre o Air EAP diz que o plugin chega sem um agente instalado e não atua como um provedor de IA.

Esse design importa porque separa três produtos que os usuários frequentemente encontram como uma única experiência integrada. O modelo gera ou interpreta texto. O agente de programação planeja tarefas, opera ferramentas, edita arquivos e executa comandos. O Air organiza esses agentes e seu trabalho dentro da IDE.

Os desenvolvedores podem conectar agentes que já utilizam, sujeitos às regras de autenticação de cada provedor. Eles não precisam de uma assinatura JetBrains AI apenas para executar um agente de terceiros compatível. O Air pode detectar instalações locais de agentes, oferecer agentes por meio de um registro e reutilizar métodos de autorização compatíveis.

Cinco agentes recebem suporte explícito de primeira classe: Codex, Gemini, GitHub Copilot, Claude Agent e Junie. Cursor e outras ferramentas podem ser conectados por compatibilidade com ACP, embora a interface exata e o caminho de autorização possam variar conforme o agente.

O produto organiza o trabalho em torno de sessões, em vez de um único chat contínuo. Cada sessão representa uma tarefa, seu agente, seu contexto, seu progresso e as alterações que produz. Os desenvolvedores podem ver o trabalho ativo entre projetos, identificar sessões aguardando entrada e abrir alterações concluídas para revisão.

O Air também oferece suporte a predefinições. Uma predefinição armazena um agente, a seleção de modelo, o esforço de raciocínio, o nível de acesso e outras configurações de inicialização. Isso permite que uma equipe crie diferentes configurações para correções de rotina, refatorações maiores, revisões ou experimentos.

Essa estrutura transforma a IDE em um despachante. Um desenvolvedor pode enviar um teste com falha para o Codex, atribuir alterações de documentação ao Gemini e pedir ao Junie que investigue um problema de desempenho. O Air não afirma que esses agentes irão cooperar como uma inteligência coletiva. Ele dá a cada tarefa um lugar visível e mantém seus resultados em um fluxo de revisão.

A distinção evita um mal-entendido importante sobre a expressão “executa cinco agentes de IA”. O Air oferece suporte nativo a cinco agentes nomeados, mas não exige que todos os cinco sejam executados juntos. Também não garante que agentes simultâneos produzirão código compatível.

A documentação do Air da JetBrains afirma que os agentes locais são executados na máquina do desenvolvedor. O Air se comunica com agentes compatíveis com ACP por meio do protocolo, enquanto agentes de linha de comando podem manter suas interfaces de terminal dentro da IDE.

O plugin pode ser instalado nas versões 2026.2 e vem integrado às builds 2026.3 EAP. A JetBrains agora documenta suporte em suas IDEs, exceto o Android Studio. A disponibilidade, a autorização de agentes e a execução em nuvem ainda podem depender da versão do produto do usuário e das configurações da organização.

Esses detalhes tornam isso mais do que uma atualização de distribuição. A JetBrains está reorganizando sua interface de IA em torno do trabalho delegado, mantendo seu editor, depurador, inspeções, navegação e ferramentas de controle de versão próximos do resultado.

Por que a JetBrains está indo além do painel de chat com IA

A pressão sobre a JetBrains vem de uma mudança no comportamento dos desenvolvedores, e não apenas de modelos de linguagem mais fortes.

A primeira geração de recursos de IA baseados em IDE se concentrou em preenchimento automático e chat. Um desenvolvedor selecionava código, fazia uma pergunta, recebia uma resposta e decidia o que copiar ou aplicar. Essa interação se encaixava confortavelmente em um painel lateral.

Os agentes de programação criam um problema de gerenciamento diferente. Eles podem ler vários arquivos, formular um plano, executar comandos, modificar um repositório e rodar testes antes de devolver o controle. Um desenvolvedor também pode iniciar outra tarefa enquanto o primeiro agente permanece ativo.

A JetBrains afirma que tentou inserir mais agentes no chat já existente do AI Assistant. A empresa concluiu que supervisionar tarefas simultâneas exigia um produto organizado em torno do estado do trabalho, e não do histórico da conversa.

Essa conclusão explica por que Air e AI Assistant permanecem separados durante o EAP. O AI Assistant continua fornecendo chat, conclusão, insights de código, sugestões para a próxima edição e acesso a agentes dentro da experiência estabelecida da IDE. O Air trata agentes e sessões como as principais unidades de trabalho.

A JetBrains espera que o Air se torne sua principal interface agêntica ao longo do tempo, mas não anunciou a remoção do AI Assistant. Os usuários podem manter o AI Assistant instalado, embora instalar o Air por meio de uma notificação do AI Assistant desative o plugin mais antigo para impedir que ambas as interfaces sejam executadas simultaneamente. Ele pode ser ativado novamente nas configurações de plugins.

A questão competitiva mais profunda é a posse da atenção do desenvolvedor. Editores e ferramentas de linha de comando voltados a agentes podem afastar o trabalho da IDE tradicional. Se os desenvolvedores passarem a maior parte do tempo emitindo prompts e revisando patches em outro lugar, a IDE corre o risco de se tornar um local secundário, usado apenas para depuração difícil.

O Air tenta inverter esse fluxo. Em vez de forçar desenvolvedores a escolher entre a JetBrains e um agente externo, ele convida o agente externo para o ambiente JetBrains. O agente fornece planejamento e geração, enquanto a IDE fornece contexto do repositório e ferramentas de verificação.

Essa abordagem também responde à rotatividade dos modelos. O principal modelo de programação pode mudar mais rapidamente do que uma organização muda seu ambiente de desenvolvimento. Uma empresa pode preferir um agente para migrações Java, outro para trabalho de interface e um agente interno para repositórios que contêm código restrito.

A JetBrains não precisa que o Junie vença todas as comparações se o Air continuar sendo o local onde esses sistemas são gerenciados. A empresa pode se beneficiar de agentes de terceiros mais fortes porque eles tornam o espaço de trabalho compartilhado mais útil.

É por isso que o ACP desempenha um papel central. O contrato ACP define uma conexão comum entre um cliente, como uma IDE, e um agente. O agente mantém sua própria seleção de modelo, ferramentas, autenticação e comportamento de planejamento.

A JetBrains compara esse limite ao papel do Language Server Protocol. Um editor não precisa de uma integração privada separada para cada servidor de linguagem compatível. O ACP busca reduzir a necessidade de um plugin sob medida entre cada agente e cada ambiente de desenvolvimento.

A analogia tem limites. Agentes de programação podem executar comandos e alterar grandes partes de um repositório, portanto suas permissões e efeitos colaterais apresentam maior risco. Ainda assim, uma camada de conexão comum reduz o trabalho de integração e torna a troca de agentes menos disruptiva.

Para a JetBrains, isso cria uma abertura estratégica. Cursor, Codex, Claude, Copilot e Gemini não precisam ser derrotados na camada de modelo. Eles podem se tornar escolhas dentro de uma IDE multiagente da JetBrains.

A IDE se torna o plano de controle para o trabalho dos agentes

A aposta central do Air é que a verificação se torna mais valiosa à medida que gerar código fica mais fácil.

Gerar um patch é apenas uma parte do desenvolvimento de software. Alguém precisa determinar se o patch atende ao requisito, preserva a arquitetura, passa nos testes, respeita limites de segurança e se comporta corretamente em condições reais.

A JetBrains já detém muitas ferramentas usadas nesse trabalho. Suas IDEs entendem símbolos, tipos, referências, estrutura de projetos, executores de teste, controle de versão, bancos de dados, depuradores e perfis de desempenho. O Air conecta a atividade dos agentes a essas superfícies existentes.

Um agente pode receber arquivos, commits, capturas de tela e instruções reutilizáveis como contexto. O desenvolvedor pode inspecionar arquivos alterados, comparar diffs, navegar por código relacionado e executar o projeto sem transferir o resultado para outro aplicativo.

Essa conexão pode reduzir a exploração duplicada. Um agente de programação frequentemente gasta tokens listando diretórios, abrindo arquivos de configuração e localizando símbolos relevantes. O contexto fornecido pela IDE pode direcioná-lo ao código correto mais cedo, embora a economia varie conforme o agente e a tarefa.

O Air também oferece aos agentes compatíveis acesso a habilidades da IDE para atividades como depuração, criação de perfis, exploração de bancos de dados e busca semântica de código. A JetBrains afirma que essas ferramentas podem melhorar os resultados em algumas tarefas, mas essa alegação ainda precisa de testes amplos em repositórios e linguagens.

A sessão do agente se torna o contêiner desse fluxo de trabalho. Ela registra o agente selecionado, a conversa, a atividade, os arquivos alterados, os commits e o custo informado. As sessões podem permanecer visíveis em vários projetos, o que ajuda um desenvolvedor a identificar trabalhos concluídos ou que exigem intervenção.

Esse modelo é diferente de abrir cinco abas de chat. Uma aba de chat preserva principalmente uma conversa. Uma sessão do Air vincula a conversa ao estado do repositório e às ações de revisão.

Considere um desenvolvedor responsável por um serviço com um teste de integração falhando. Uma sessão pode investigar a falha. Uma segunda pode atualizar uma dependência relacionada em uma ramificação isolada. Uma terceira pode analisar a documentação afetada pela mudança.

O desenvolvedor pode continuar trabalhando no checkout principal enquanto essas sessões avançam. Quando uma termina, a IDE se torna o local para revisar o diff, executar inspeções, verificar testes e decidir se o resultado pertence à ramificação de destino.

Esse processo se encaixa em uma mudança mais ampla no trabalho de engenharia. Os desenvolvedores coordenam cada vez mais alterações geradas, em vez de digitar diretamente cada implementação. Sua responsabilidade não desaparece. Ela se desloca para especificar tarefas, fornecer contexto, examinar evidências e resolver conflitos.

A JetBrains está posicionando a IDE como o plano de controle para essas responsabilidades. O termo significa uma superfície que coordena trabalhadores e estado sem ser o próprio trabalhador. O Air não precisa gerar o melhor patch para se tornar valioso se tornar vários agentes mais fáceis de supervisionar.

O modelo também preserva a escolha do usuário. Um desenvolvedor pode conectar uma assinatura existente quando o provedor permitir, selecionar o JetBrains AI ou usar um agente ACP configurado localmente. O próprio Air não fornece um modelo proprietário.

Essa flexibilidade é estrategicamente importante. Um espaço de trabalho fechado e vinculado a um único modelo herda as fraquezas desse modelo e as mudanças comerciais associadas a ele. Um espaço de trabalho multiagente pode permitir que desenvolvedores substituam o agente preservando os hábitos do projeto e as ferramentas de revisão.

Equipes que já estão construindo contexto de engenharia pesquisável talvez reconheçam o mesmo padrão. O ativo duradouro não é uma única resposta, mas a estrutura que conecta código, decisões, documentos e revisão. Uma base de conhecimento técnico pode complementar as sessões de agentes ao preservar informações que devem sobreviver além de uma única tarefa de programação.

O Air não resolve sozinho esse problema mais amplo de conhecimento. Uma sessão contém contexto de trabalho útil, mas as equipes ainda precisam de registros duradouros para decisões de arquitetura, incidentes e requisitos. O IDE pode coordenar a implementação, enquanto sistemas compartilhados de conhecimento preservam o motivo de sua existência.

Agentes Paralelos Criam um Problema de Integração e Atenção

Executar mais agentes aumenta a produtividade apenas quando os desenvolvedores conseguem revisar, conciliar e confiar em seus resultados.

O Air permite que desenvolvedores iniciem sessões a partir de uma branch e coloquem o trabalho em um worktree temporário do Git. Um worktree é uma cópia de trabalho separada, vinculada ao mesmo histórico do repositório. Ele mantém as edições de um agente afastadas do checkout atual do desenvolvedor.

Esse isolamento é essencial para o trabalho paralelo. Dois agentes editando os mesmos arquivos em um único espaço de trabalho podem sobrescrever premissas ou criar alterações que passam de forma independente, mas falham juntas. Worktrees separados reduzem a interferência direta.

O Air pode exibir o resultado e permitir que o desenvolvedor transfira commits selecionados de volta para o projeto ativo. Seu fluxo de trabalho de sessão documentado permite revisar as alterações antes de fazer cherry-pick delas na branch de destino.

O isolamento não elimina o trabalho de integração. Se cinco agentes alterarem áreas conectadas, o desenvolvedor poderá enfrentar cinco branches, edições duplicadas, abstrações inconsistentes e conflitos de merge. Cada agente pode produzir um resultado local plausível, enquanto o sistema combinado se torna menos coerente.

O gargalo então passa da produção de código para a atenção humana. Um desenvolvedor precisa entender o que cada agente alterou e por quê. Também precisa decidir quais testes fornecem evidências significativas, em vez de aceitar um resumo positivo gerado pelo mesmo sistema que escreveu o código.

A lista de sessões do Air ajuda a expor essa carga de trabalho. Ela pode mostrar sessões ativas, atualizações não lidas, arquivos alterados, commits pendentes e tarefas aguardando entrada. Essa visibilidade é útil, mas não pode determinar se as decisões subjacentes estão corretas.

Esse é o principal trade-off por trás do JetBrains Air EAP. O paralelismo pode reduzir o tempo de espera, mas também pode multiplicar as obrigações de revisão. Uma equipe que inicia agentes mais rápido do que consegue verificar seu trabalho simplesmente cria uma fila maior de patches incertos.

Os presets introduzem outra preocupação de governança. Eles tornam a configuração repetível, mas as equipes precisam decidir quais modelos, permissões e níveis de esforço se aplicam a cada classe de tarefa. Um agente com alto nível de acesso adequado para um repositório de testes descartável pode ser inaceitável para infraestrutura de produção.

A autenticação também continua desigual. A JetBrains oferece várias rotas, incluindo logins gerenciados pelo provedor, credenciais de terceiros e JetBrains AI. No entanto, uma assinatura utilizável em uma interface pode não autorizar o mesmo agente em outra superfície.

Claude ilustra essa complexidade. A JetBrains afirma que uma assinatura do Claude pode ser usada pela interface de terminal, enquanto o Claude Agent no chat estruturado exige JetBrains AI ou uma chave de API da Anthropic com cobrança de API. Os desenvolvedores devem verificar as regras atuais de autorização antes de tratar o Air como um hub universal de assinaturas.

A execução na nuvem adiciona mais limites. As sessões locais são executadas na máquina do desenvolvedor, mas organizações elegíveis podem enviar certas tarefas para a infraestrutura da JetBrains. As execuções na nuvem podem continuar após o fechamento do IDE, embora a disponibilidade dependa das configurações da organização, da hospedagem do repositório e de uma assinatura JetBrains AI.

O tratamento de dados, portanto, depende do caminho selecionado. A JetBrains afirma que os dados de agentes de terceiros vão diretamente para esse provedor sob o acordo já existente do usuário quando uma assinatura de terceiros é usada. O JetBrains AI e os recursos de nuvem operam sob seus termos aplicáveis.

O acordo do EAP também deixa explícito o nível de maturidade. Softwares de acesso antecipado podem conter erros, comportar-se de maneira inesperada e mudar durante o desenvolvimento. As equipes não devem tratar o rótulo EAP como algo rotineiro quando agentes podem editar arquivos e executar comandos.

Uma implementação cautelosa começaria com repositórios não críticos e permissões restritas. As equipes devem exigir revisão humana, preservar branches recuperáveis e executar testes independentes antes do merge. Código sensível exige uma decisão clara sobre provedor e roteamento de dados antes que qualquer agente receba contexto.

Esses controles não são argumentos contra o JetBrains Air nos IDEs. São as condições sob as quais seu modelo paralelo se torna útil. A orquestração só cria vantagem quando torna a responsabilidade mais visível, em vez de escondê-la atrás de painéis de atividade.

A JetBrains Está Transformando Rivais em Componentes Substituíveis

O Air desafia editores voltados a agentes ao incorporar seus agentes e preservar o ambiente de desenvolvimento da JetBrains.

O oponente mais importante não é uma única empresa. É a ideia de que o agente de programação deve controlar todo o espaço de trabalho do desenvolvedor.

Um editor voltado a agentes pode otimizar cada interação em torno de um sistema integrado. Isso cria uma experiência focada, mas também pode tornar o fluxo de trabalho do desenvolvedor dependente do roteamento de modelos, das decisões de interface e do calendário de lançamentos desse produto.

A JetBrains adota a posição oposta. O IDE permanece estável enquanto os agentes competem por tarefas dentro dele. Os desenvolvedores podem manter ferramentas familiares de navegação, refatoração, depuração e inspeção enquanto mudam o sistema que gera código.

O ACP torna essa proposta crível. Sem um protocolo compartilhado, oferecer suporte a muitos agentes exigiria uma coleção crescente de integrações privadas. Cada atualização de provedor poderia quebrar um conector ou deixar recursos inconsistentes entre produtos.

Com o ACP, a unidade substituível inclui mais do que um modelo. Um agente carrega sua lógica de planejamento, ferramentas, permissões, roteamento de modelos e comportamento de interface. O Air se conecta a esse pacote completo por meio de um limite comum de cliente.

Isso dá à JetBrains uma maneira de se beneficiar da inovação externa. Se o Codex melhorar em alterações na escala de repositórios, os usuários do Air poderão escolhê-lo. Se o Gemini se tornar melhor para outra carga de trabalho, o espaço de trabalho não precisará mudar. Um agente ACP interno pode atender tarefas restritas.

Os cinco agentes nomeados são, portanto, uma formação inicial, não um teto fixo. Codex, Gemini, GitHub Copilot, Claude Agent e Junie oferecem escolhas reconhecíveis para o EAP. O registro e a configuração personalizada expandem o conjunto possível.

Cursor é um exemplo revelador. Ele compete pela atenção dos desenvolvedores como um ambiente de programação orientado por IA, mas seu agente também pode se conectar a produtos JetBrains por meio do ACP. A JetBrains pode transformar um produto associado à troca de editores em um trabalhador disponível dentro de seu próprio IDE.

Isso não garante que os usuários permanecerão. Um produto nativo voltado a agentes ainda pode oferecer uma interface mais coerente, entrega mais rápida de recursos ou integração mais estreita com seu modelo preferido. A compatibilidade de protocolo raramente torna toda experiência de cliente idêntica.

O Air também precisa justificar a complexidade da escolha. Cinco agentes com permissões, assinaturas, modos e capacidades diferentes podem se tornar mais difíceis de administrar do que uma ferramenta familiar. O espaço de trabalho precisa de status claro, configuração previsível e informações confiáveis de revisão.

A própria linha de produtos da JetBrains acrescenta outro risco. Os usuários já encontram AI Assistant, Junie, Air, agentes ACP, contas de provedores e JetBrains AI. O Air cria uma divisão conceitual mais clara, mas o período de transição ainda pode parecer fragmentado.

A empresa está tentando resolver esse problema ao tornar o Air o ambiente dedicado para fluxos de trabalho agênticos, mantendo o AI Assistant para chat e assistência em linha. Se os usuários compreenderão e preferirão essa divisão será um resultado-chave do EAP.

A JetBrains apresentou inicialmente o ambiente Air independente como um lugar construído em torno de agentes, e não como um editor com IA adicionada. Sua prévia pública de março estabeleceu a delegação simultânea como ideia central do produto.

Levar essa experiência para IDEs estabelecidos muda a proposta. Os desenvolvedores não precisam mais adotar um aplicativo separado para testar o fluxo de trabalho. A JetBrains pode distribuir o Air por meio de produtos já incorporados às equipes de engenharia.

Essa vantagem de distribuição é relevante, mas a adoção depende da utilidade diária. Os desenvolvedores não manterão outra janela de ferramenta apenas porque ela reconhece vários agentes. O Air precisa tornar o trabalho simultâneo mais fácil de entender, revisar e integrar do que terminais ou aplicativos de provedores separados.

O Que Observar Após o JetBrains Air EAP

O próximo teste não é quantos agentes o Air lista, mas se as equipes concluem trabalho real com menos mudanças de contexto e custos de revisão administráveis.

O primeiro sinal é a adoção em repositórios comuns. A JetBrains precisa de evidências de que os desenvolvedores continuam usando o Air depois que passa a novidade de iniciar sessões paralelas. O uso recorrente em depuração, manutenção, testes e refatoração apoiaria a tese da orquestração.

A métrica útil não é o número de prompts. As equipes devem examinar tarefas concluídas, alterações aceitas, tempo de revisão, defeitos reabertos e a quantidade de reparo manual necessária após um agente terminar. Um alto volume de sessões pode ocultar resultados de baixa qualidade.

O segundo sinal é a confiabilidade da integração baseada em worktrees. O Air deve tornar evidentes o estado da branch, as alterações não commitadas, os conflitos e os destinos de transferência. Um sistema projetado para agentes paralelos precisa evitar que desenvolvedores percam trabalho ou apliquem um patch correto na branch errada.

A JetBrains documenta salvaguardas e controles de revisão, mas o EAP revelará como eles se comportam sob pressão diária. Repositórios grandes, arquivos gerados, monorepos e refatorações sobrepostas oferecerão testes mais difíceis do que demonstrações isoladas.

O terceiro sinal é a resposta competitiva de provedores de agentes e editores rivais. Uma adoção mais ampla do ACP fortaleceria a estratégia de espaço de trabalho aberto da JetBrains, pois os desenvolvedores poderiam mover agentes entre clientes compatíveis. Em vez disso, os provedores podem favorecer recursos proprietários que funcionam melhor dentro de seus próprios aplicativos.

O suporte a capacidades comuns será tão importante quanto o número de agentes. Permissões, chamadas de ferramentas, anexos de contexto, relatórios de custo, retomada de sessões e atribuição de diffs precisam ter comportamento consistente. Um protocolo que conecta muitos agentes, mas expõe apenas seus recursos comuns mínimos, limitaria a vantagem do Air.

As organizações também devem observar os controles administrativos. A JetBrains afirma que empresas podem desativar o Air por meio do acesso gerenciado à IA, mas sua documentação observa que o gerenciamento de serviços do IDE ainda não está completo. A adoção empresarial exige políticas claras para provedores, credenciais, execuções na nuvem, roteamento de dados e auditabilidade.

A relação entre o Air e o AI Assistant é outro sinal concreto. A JetBrains afirma que o AI Assistant continuará sendo oferecido, enquanto o Air se tornará a experiência agêntica preferencial. As próximas versões devem mostrar se essa divisão se simplifica ou gera interfaces sobrepostas.

Uma transição bem-sucedida deixaria os desenvolvedores com um local claro para tarefas delegadas e outro para ajuda contextual leve. Uma transição confusa forçaria os usuários a entender qual plugin controla cada agente, assinatura ou modo de chat.

Os cinco agentes compatíveis também mostrarão se a especialização oferece valor prático. Os desenvolvedores precisam de motivos observáveis para escolher o Codex para uma tarefa e o Junie ou o Gemini para outra. Caso contrário, o seletor se torna uma escolha administrativa, e não um recurso de produtividade.

No fim, o JetBrains Air nos IDEs se baseia em uma premissa defensável: o código gerado aumenta o valor do contexto e da revisão. A questão em aberto é se um único IDE consegue organizar agentes suficientes sem transformar os desenvolvedores em gestores de filas em tempo integral.

Experimente o EAP em uma branch recuperável e atribua a ele uma tarefa que envolva vários arquivos, testes e etapas de revisão. Em seguida, compare o fluxo de trabalho completo com sua configuração atual de agentes. O Air reduziu a troca de contexto, tornou as alterações mais fáceis de inspecionar e preservou o controle sobre o repositório? Ou apenas reuniu cinco interfaces em uma única janela? Essa resposta, repetida entre equipes reais, determinará se o JetBrains Air se tornará a camada operacional do desenvolvimento agêntico ou permanecerá um experimento interessante.