Codex JetBrains com Air: do primeiro prompt à revisão

Para quem procura uma integração Codex JetBrains, o Air permite iniciar um agente de programação dentro da IDE, fornecer apenas o contexto selecionado do projeto e revisar as alterações no mesmo ambiente em que você navega e testa o código. O melhor primeiro passo não é pedir uma refatoração ampla. Instale o Air Alpha, conecte um agente, entregue um arquivo e um teste com falha e só aceite a mudança quando o diff e o resultado do teste fizerem sentido.

Em poucas palavras

Use o Air como uma central de controle de agentes, não como um botão de autocomplete. O agente executa o trabalho; o Air organiza a sessão, encaminha o contexto da IDE e devolve o resultado em uma área de revisão integrada ao ambiente de desenvolvimento.

Para a primeira sessão:

1. Instale o Air Alpha pelo Marketplace da IDE.
2. Abra um projeto ou branch descartável que tenha um teste executável.
3. Escolha uma predefinição em New Session e mantenha Standard Access.
4. Envie a primeira mensagem e conclua o login se o Air solicitar.
5. Anexe o arquivo relevante com @file:.
6. Peça uma correção pequena e um teste.
7. Confira cada arquivo alterado em Agent Sessions.
8. Rode o teste por conta própria e, depois, mantenha, edite, faça commit ou reverta a alteração.

Esse é o ciclo que realmente importa. Sessões paralelas, mais agentes, controles organizacionais e transferência para a nuvem podem esperar até que esse fluxo seja confiável.

O que é o JetBrains Air, na prática

O Air funciona como a camada entre seu projeto JetBrains e um ou mais agentes de programação. Pense em uma bancada de inspeção: o agente coloca uma peça proposta sobre a mesa, mas é a IDE que oferece as medidas, as verificações de encaixe e a decisão final.

O lançamento de 22 de setembro transformou o Air em um sistema mais amplo, dividido em três partes: Air in JetBrains IDEs para o trabalho individual, Air Teams para coordenação e automação e Air Governance para políticas, visibilidade e controle de custos. Este guia se concentra no caminho local que já pode ser executado, o plugin Air Alpha para a IDE.

O plugin da IDE não é um novo modelo fundacional. Ele executa Codex, Gemini, GitHub Copilot, Claude e Junie sem configuração adicional, e a JetBrains afirma que outros agentes podem se conectar por ACP. ACP, ou Agent Client Protocol, é uma interface comum entre a IDE e toda a estrutura operacional do agente, incluindo suas ferramentas e o roteamento de modelos.

A página atual do Air para IDEs ainda apresenta a transferência do ambiente local para a nuvem como um recurso futuro. Para uma primeira execução previsível, mantenha a tarefa pequena e local.

Antes de instalar

O Air Alpha é um alpha público, não um utilitário estável e discreto. A JetBrains avisa que a interface e o comportamento podem mudar e prevê atualizações aproximadamente toda semana. Antes de investigar qualquer problema, confira a compatibilidade.

Em 23 de setembro de 2026, o pacote atual do Marketplace para a linha 2026.2 era o Air 262.8665.463. Ele oferece suporte ao IntelliJ IDEA 2026.2 até o 2026.2.3 e às versões 2026.2 correspondentes das IDEs JetBrains listadas. O Marketplace também oferece builds para a linha 2026.3, portanto a versão exata do plugin pode variar conforme a linha da sua IDE.

Verificação de compatibilidade desta análise

O IntelliJ IDEA 2026.2.3, build IU-262.10968.63, carregou o Air 262.8665.463 em um perfil isolado e indexou um projeto Node descartável sem erro de plugin. O agente detectado foi o codex-cli 0.153.4, mas estava desconectado, e a máquina não tinha sessão gráfica. Portanto, esta análise não afirma que houve uma tarefa interativa no Air, um diff gerado ou um teste escrito pelo agente que tenha passado. As etapas de interface abaixo seguem o guia rápido atual da JetBrains e os rótulos incluídos nessa versão do plugin.

Como usar Codex JetBrains com o Air, passo a passo

1. Instale o Air Alpha

Abra as configurações da IDE, selecione Plugins, acesse Marketplace, procure Air Alpha e clique em Install. Reinicie a IDE se ela solicitar.

O Air em si é gratuito. O agente conectado a ele ainda pode exigir conta, assinatura ou cobrança por API. Se o custo for o ponto que impede sua decisão, Is JetBrains Air Free explica separadamente o preço do plugin e o custo do agente.

2. Abra um projeto com uma falha simples de reproduzir

Comece com um projeto existente que possa ser descartado ou restaurado. Uma boa primeira tarefa tem um único arquivo relevante, uma falha observável e um comando capaz de provar se a mudança funcionou.

Alguns exemplos: uma função de slug que trata incorretamente espaços repetidos, um formatador sem cobertura para um caso-limite ou uma pequena função de validação com um teste unitário quebrado. Na primeira execução, evite migrações, autenticação, código de implantação e atualizações amplas de dependências.

Registre o ponto de partida antes de abrir a sessão:

• o branch atual ou o worktree descartável;
• o comando de teste exato;
• se esse teste passa ou falha antes da mudança;
• quais arquivos você espera que a tarefa altere.

Assim, a revisão vira uma comparação objetiva, não uma impressão.

3. Escolha uma predefinição em New Session

O botão New Session da barra de ferramentas principal inicia a predefinição selecionada no momento. Use a seta ao lado para escolher outra.

Uma predefinição é uma configuração de inicialização salva. Ela define o agente e pode selecionar previamente o modelo, o nível de raciocínio, o nível de acesso e a superfície da sessão. O Air mostra os agentes detectados na máquina ao lado das predefinições incluídas. Se o agente escolhido não estiver instalado, o plugin pode oferecer a instalação.

Na primeira tarefa, escolha Standard Access. Na versão atual do plugin, Standard Access permite que o agente leia, edite e execute comandos dentro do projeto; o acesso a arquivos externos ou à rede exige aprovação. Full Access remove essas confirmações para o uso da rede e para edições em qualquer parte da máquina. Não é uma boa configuração inicial.

4. Envie a primeira mensagem e autorize o agente

A autorização acontece quando o agente realmente precisa dela. Digite uma mensagem curta e pressione Enter. Se o Air encontrar credenciais que o agente já utiliza na máquina, a sessão continuará. Caso contrário, ele exibirá Choose a sign-in method to continue.

O caminho disponível depende do agente:

• o login do agente pode prosseguir pelo navegador ou terminal;
• uma licença elegível do JetBrains AI ou um workspace da organização pode fornecer créditos;
• Add an AI provider abre Tools | Air | Accounts para configurar uma assinatura de terceiros ou uma chave de API.

Em Accounts, selecione More Providers, adicione as credenciais necessárias, use Test Connection, salve com OK e volte à sessão para escolher esse provedor.

Não cole segredos no prompt da tarefa. As credenciais devem ficar no fluxo de conexão do provedor.

5. Forneça apenas o contexto necessário

O Air permite anexar arquivos, commits e skills pelo controle de inclusão de contexto. Você também pode digitar @file: para um arquivo ou @folder: para uma pasta. A diferença é importante: anexar um único arquivo relevante é como entregar a peça defeituosa ao mecânico; anexar o repositório inteiro é como despejar toda a garagem sobre a bancada.

Na primeira execução, anexe o arquivo de implementação e informe o comando de teste. Acrescente o arquivo de teste apenas quando o agente precisar entender um padrão já existente.

6. Peça uma mudança bem delimitada e exija uma prova

Um bom prompt identifica o defeito, delimita o escopo permitido e informa o comando de verificação. Por exemplo:

Corrija o tratamento de espaços repetidos em @file:src/slug.js. Adicione ou atualize o menor teste relevante. Execute node --test. Não altere dependências nem arquivos que não tenham relação com a tarefa. Se não for possível executar o comando de teste, pare e explique o motivo.

Esse prompt dá ao agente uma linha de chegada. “Melhore esta função” não dá.

7. Acompanhe a sessão, mas não avalie o trabalho pela narração

O agente informa o andamento e pode fazer perguntas. Esclareça requisitos ausentes, aprove somente ações que você entende e observe com atenção pedidos inesperados de acesso à rede ou a arquivos fora do projeto.

O texto de progresso oferece contexto, mas não serve como prova. A prova é o diff produzido junto de um teste que você consegue repetir.

8. Revise a alteração em Agent Sessions

Abra Agent Sessions e expanda a sessão concluída. Veja o diff de cada arquivo alterado. O pacote atual inclui as ações Show Diff, Generate summary... e Revert. Segundo o guia rápido da JetBrains, você pode manter, editar, fazer commit ou reverter os arquivos modificados.

Siga esta ordem na revisão:

1. Escopo: apenas os arquivos esperados foram alterados?
2. Comportamento: a implementação resolve exatamente a falha descrita?
3. Qualidade do teste: o novo teste falharia sem a correção?
4. Efeitos colaterais: houve mudanças na configuração, nas dependências ou nas interfaces públicas?
5. Verificação: o teste passa quando você o executa fora da narração do agente?

Se o diff estiver quase certo, edite-o por conta própria ou dê um feedback preciso para outra iteração. Se o escopo causar surpresa, reverta a mudança e recomece com um prompt mais restrito. Uma explicação convincente não merece um commit por si só.

A conta que interessa para o negócio

O Air muda o custo de orquestração, não o preço da inteligência por trás dele. O plugin acrescenta $0 ao gasto com software, enquanto o agente conectado pode consumir uma assinatura existente, um saldo de API ou créditos do JetBrains AI.

Isso importa quando a equipe já paga por agentes. Adotar uma segunda superfície de controle costuma significar mais uma licença antes mesmo de saber se ela melhora a revisão. Como referência pública, o GitHub lista atualmente o Copilot Business por $19 por usuário ao mês e o Enterprise por $39. Dez licenças Business custam $190 por mês antes do uso adicional. O Air conecta agentes compatíveis sem cobrar uma taxa pelo plugin, mas não elimina a licença da IDE, a assinatura do provedor, o consumo da API nem o tempo humano de revisão.

A pergunta orçamentária, portanto, é bem específica: uma superfície local e gratuita de revisão consegue facilitar o direcionamento e a verificação do investimento atual em agentes? Teste com uma equipe e uma categoria de tarefa antes de comprar ou padronizar qualquer outra coisa.

Seis casos de uso, do maior para o menor ganho

1. Equipes JetBrains que já pagam por vários agentes

Uma equipe de engenharia que usa Codex para uma carga de trabalho e Claude para outra pode iniciar ambos no mesmo ambiente da IDE, anexar o mesmo contexto do projeto e revisar os arquivos alterados em um só lugar. O ganho não está, por padrão, em tokens mais baratos. Está na redução da troca entre ferramentas e em um hábito consistente de revisão para assinaturas que a equipe já mantém.

2. Mantenedores resolvendo defeitos pequenos e testáveis

Um mantenedor pode anexar a função com falha, descrever uma única regressão, exigir um teste focado e revisar o diff antes que ele chegue a um branch. Isso compensa quando o diagnóstico já está claro, mas implementar a correção mecânica disputa tempo com trabalhos mais profundos.

3. Consultores entrando em uma base de código desconhecida

Um consultor pode usar a navegação de código da IDE para examinar símbolos, anexar apenas os arquivos relevantes e pedir ao agente uma mudança delimitada. Manter o trabalho em um branch descartável com Standard Access reduz a chance de as convenções ainda desconhecidas do repositório virarem uma edição espalhada. O ganho é uma adaptação mais rápida, sem fingir que o agente conhece regras não documentadas do cliente.

4. Profissionais de QA transformando um bug reproduzível em teste de regressão

Quem trabalha com QA e consegue reproduzir um bug pode anexar o arquivo envolvido e a área de testes, pedir o menor teste de regressão possível e conferir se ele realmente captura a falha. O valor está em encurtar o caminho entre a reprodução e um artefato de engenharia pronto para revisão.

5. Desenvolvedores seniores ensinando revisão com diffs concretos

Um desenvolvedor sênior pode deixar o agente propor uma pequena implementação e, em seguida, orientar alguém menos experiente pela análise de escopo, premissas, desenho do teste e decisões de reversão dentro da IDE que a equipe já conhece. O resultado não é apenas código: é um exercício de revisão visível, baseado em uma alteração real.

6. Equipes de plataforma comparando agentes na mesma tarefa

Uma equipe de plataforma pode executar a mesma tarefa delimitada com predefinições diferentes e comparar arquivos afetados, comportamento dos testes, aprovações e esforço de revisão. Isso gera uma avaliação mais útil do que comparar respostas de chat, pois a unidade de análise é uma mudança verificada no mesmo repositório.

Dois produtos que vale construir em torno disso

1. Um registro de evidências para revisar alterações de agentes

Esta é a oportunidade mais forte. Crie um pequeno complemento que transforme uma sessão do agente em um pacote de revisão: tarefa, contexto anexado, arquivos alterados, comando e resultado do teste, decisão humana e referência do commit final. Gestores de engenharia e equipes reguladas pagariam por um registro claro que funciona acima do agente responsável por gerar o código.

A demanda é específica o bastante para ser relevante: ai powered code review platform recebe cerca de 1,900 buscas mensais nos EUA, com intenção comercial. Os preços de $19 para o GitHub Business e $39 para o Enterprise também mostram que as equipes já reservam orçamento para assistência e governança na programação.

A menor versão comercializável não precisa controlar o agente. Ela pode receber um diff e a saída do teste, exigir um checklist do revisor e exportar um registro assinado em Markdown ou JSON. O risco é a plataforma: o Air está em alpha, suas interfaces podem mudar toda semana, e a JetBrains pode implementar recursos mais completos de evidência ou auditoria. A vantagem competitiva precisa vir de políticas independentes de agente e relatórios duráveis, não de um botão superficial dentro de uma única IDE.

2. Um consultor de configuração de agentes específico para cada repositório

Crie uma ferramenta de onboarding que analise as linguagens, os comandos de teste, os caminhos sensíveis e as regras de contribuição de um repositório e, então, recomende um modelo seguro de primeira tarefa e as configurações da predefinição. O produto atenderia equipes que estão adotando agentes em repositórios variados, nas quais cada pessoa hoje repete o mesmo trabalho de configuração.

A demanda ampla é grande: ai coding assistant recebe cerca de 18,100 buscas mensais nos EUA, enquanto ai powered coding agent recebe aproximadamente 8,100. O MVP pode ser um questionário sobre o repositório acompanhado de notas de configuração geradas, prompts iniciais delimitados e um checklist de teste rápido. Não é necessário começar com uma integração profunda à IDE.

O desafio é criar diferenciação. A JetBrains, os fornecedores de agentes ou os próprios templates de repositório podem incorporar orientações genéricas de configuração. Para ser viável, o produto precisa verificar políticas específicas de cada organização e demonstrar que suas recomendações reduzem alterações malsucedidas ou amplas demais.

Limites e uma avaliação franca

O Air faz mais sentido para quem já prefere uma IDE JetBrains e quer escolher entre agentes sem abrir mão da revisão integrada ao ambiente. Ele não é um bom motivo para delegar uma mudança arriscada que você não sabe verificar.

Três restrições importam hoje:

• É um alpha. Rótulos e comportamento podem mudar em um ritmo de atualizações aproximadamente semanal.
• O plugin é gratuito; o trabalho, não. Autorização do agente, assinaturas, uso de API, licença da IDE e revisão humana continuam sendo custos separados.
• O ambiente local é o ponto de partida confiável. A página da IDE ainda descreve a transferência para a nuvem como um recurso futuro; portanto, não monte o primeiro fluxo contando com a continuidade da tarefa depois de fechar o notebook.

Standard Access também não significa somente leitura. Esse nível permite edições e comandos dentro do projeto. Use um branch ou worktree descartável, examine o diff e execute novamente o teste por conta própria.

A conclusão é simples: vale experimentar o Air em uma mudança pequena se a JetBrains já faz parte do seu trabalho diário. Ainda é cedo para transformá-lo no caminho obrigatório de repositórios sensíveis sem um plano de reversão, uma política de provedores e evidências de revisão.

A ação para segunda-feira

Escolha um bug que tenha um teste executado por um único comando. Coloque-o em um branch descartável, instale a versão correspondente do Air Alpha na máquina de uma pessoa da equipe, escolha Standard Access, anexe um arquivo relevante e peça a menor correção possível acompanhada de um teste de regressão. Só mantenha a alteração se o diff for restrito e o teste passar quando você mesmo executá-lo. Esse único ciclo ensina mais do que uma semana de demonstrações de agentes.

O que o JetBrains Air faz?

O JetBrains Air coordena agentes de programação, o contexto, as sessões e a revisão deles dentro e fora das IDEs JetBrains. No plugin local da IDE, você seleciona um agente, envia uma tarefa com o contexto do projeto e examina as mudanças resultantes em Agent Sessions.

Quais são as principais diferenças entre JetBrains Air e Claude Code?

Claude Code é um agente de programação. O Air é uma superfície de controle e revisão para vários agentes, capaz de executar Claude ao lado de Codex, Junie, GitHub Copilot, Gemini, OpenCode e agentes compatíveis com ACP, conforme as integrações e autorizações disponíveis.

Qual é a melhor IDE para programação com agentes?

Não existe uma vencedora universal. O Air é atraente quando a equipe já depende dos recursos de navegação, inspeção e diff da JetBrains. A melhor opção é o ambiente em que você consegue limitar, examinar, testar e reverter o trabalho de um agente com segurança.

O JetBrains é gratuito?

O plugin Air Alpha é gratuito. Sua IDE JetBrains e o agente conectado ao Air podem ter custos separados de licença, assinatura ou API.

Se você quer um fluxo seguro de agentes adaptado aos seus repositórios e regras de revisão, conheça desenvolvimento de agentes de IA.