Veja como a Skyscanner ampliou os recursos do Codex CLI da OpenAI ao integrá-lo aos IDEs da JetBrains. Com essa integração, o assistente de IA passou a usar as mesmas ferramentas de depuração e teste que os desenvolvedores usam.
Na Skyscanner, estamos sempre buscando formas de acelerar o desenvolvimento sem comprometer a qualidade. Nos últimos meses, venho experimentando o Codex da OpenAI como parceiro de programação no meu dia a dia.
O que fiz de diferente? Conectei o Codex CLI aos IDEs da JetBrains usando o servidor Model Context Protocol (MCP) da empresa. Assim, a IA consegue ver e usar os recursos do IDE. Essa integração mudou bastante a forma como trabalhamos. Neste post, vou contar como o acesso às ferramentas da JetBrains ajudou o Codex a resolver problemas e acelerou nosso trabalho de desenvolvimento.
Como dar ao Codex acesso ao contexto do IDE
Com o servidor MCP da JetBrains, o Codex agora tem acesso a informações detalhadas do meu ambiente de desenvolvimento que normalmente não conseguiria “ver”.
Com o MCP da JetBrains, o Codex pode pedir mais informações ao IDE. Por exemplo, ele pode:
- Identificar problemas em um arquivo: usar as inspeções do IntelliJ para analisar um arquivo em busca de erros e avisos e obter a mensagem e a localização de cada problema.
- Executar configurações predefinidas: usar as configurações de execução para rodar testes unitários, linters ou formatadores, por exemplo, e obter o código de saída e a saída de cada execução.
Na prática, isso fez uma grande diferença. Ao escrever, compilar e testar código, o Codex recebe o mesmo feedback que orienta os desenvolvedores. Com esse contexto do IDE, ele consegue verificar com mais precisão se o código que gerou funciona e leva menos tempo a cada iteração.
Como detectar erros mais cedo na prática
Enquanto escrevia testes unitários para o tratamento de erros no nosso código que usa o SDK da Databricks para Java, pedi ajuda ao Codex para simular uma exceção. Ele sugeriu com toda a confiança uma linha de código Java parecida com esta:
var stubError = new NotFound("dummy error");À primeira vista, a sugestão faz sentido. Queremos simular um erro NotFound. Mas, instantes depois, o IntelliJ sublinhou a linha em vermelho.
O problema é que a classe de exceção NotFound do SDK da Databricks não tem um construtor que receba uma única string como argumento (como mostra o arquivo NotFound.java no código-fonte do SDK). Ou seja, o código sugerido pelo Codex nem sequer compilaria.
Por padrão, o Codex não saberia desse erro. Talvez só percebesse que havia algo errado mais tarde, ao tentar executar os testes. Com a integração via MCP da JetBrains, porém, ele detectou o erro imediatamente. Nos bastidores, o Codex chamou a ferramenta get_file_problems do IDE para inspecionar o arquivo. Ela informou na hora o motivo do erro de compilação: nenhum construtor aceitava aquele argumento.
Sem o MCP, o Codex provavelmente teria seguido estas etapas:
- Gerar o código
- Descobrir como executar os testes unitários
- Executar os testes unitários (talvez precisasse pedir autorização ao usuário para executar os comandos)
- Ler e interpretar a mensagem de falha
- Tentar corrigir o erro
Com o MCP da JetBrains, o ciclo é bem mais curto:
- Gerar o código
- Consultar o IDE da JetBrains para identificar problemas no arquivo
- Corrigir o erro específico que o IntelliJ apontou
Isso economizou tempo e consumiu menos contexto. Foi como programar em dupla com um engenheiro que diz na hora: “Ah, essa classe não tem um construtor assim. Ela espera outros argumentos. Deixa eu corrigir isso rapidinho.”
Configurações predefinidas para testes e formatação
Outra vantagem para mim é que o Codex consegue usar nossas ferramentas de build e teste diretamente pelo IDE. Para a maioria dos nossos projetos, já tenho configurações de execução locais no IDE para tarefas como executar testes, formatar o código e rodar o linter. Com o MCP da JetBrains, o Codex consegue encontrar e executar essas configurações quando precisa.
Na prática, o Codex gasta menos tempo e consome menos contexto para descobrir como executar essas tarefas. Assim, consegue manter o foco no problema original. Desde essa mudança, percebi que o Codex já não tem dificuldade para executar os testes, formatar o código ou rodar o linter.
Por isso, nas minhas instruções personalizadas para o agente, peço ao Codex que execute os testes, rode o linter e formate o código após cada alteração.
## Instruções para editar o código
Depois de concluir as alterações:
- Se o servidor MCP da JetBrains estiver disponível, use-o para verificar se há problemas.
- Se o comando de formatação estiver disponível, execute-o.
- Se o comando de lint estiver disponível, execute-o.Tenho percebido que agora o Codex muitas vezes resolve os problemas sozinho, sem que eu precise intervir. Para mim, como desenvolvedor, isso faz muita diferença:
- Não preciso executar os testes, rodar o linter e formatar o código manualmente sempre que o Codex altera alguma coisa.
- Não preciso copiar as mensagens de erro e colá-las no chat.
- O Codex recebe feedback rápido e preciso sobre o funcionamento das alterações, o que reduz o número de ciclos de feedback.
Com isso, sobra mais tempo para eu me concentrar na tarefa que tenho em mãos: entregar software de qualidade que funcione como esperado.
O que mudou na nossa forma de desenvolver software
Com a integração do Codex ao MCP da JetBrains, nosso assistente de IA consegue fazer mais e se tornou mais confiável no dia a dia do desenvolvimento. Estes são alguns dos benefícios que observamos na prática:
- Ciclos de feedback mais rápidos: o IDE informa o Codex imediatamente sobre erros de compilação e testes que falharam.
- Menos trocas de mensagens: o Codex pode consultar o IDE diretamente, sem precisar esperar toda vez que eu execute algo e cole a mensagem de erro.
- Sugestões de melhor qualidade: como o Codex vê o que o IDE vê, é mais provável que o código corrigido compile e passe nos testes logo na primeira tentativa.
- Maior compatibilidade com nossos fluxos de trabalho: o Codex usa as ferramentas que já adotamos em vez de inventar as próprias.
Com isso, o Codex passou de uma ferramenta isolada a uma parte mais integrada do nosso ambiente de desenvolvimento.
Resumo
Para nós, na Skyscanner, a principal lição foi simples: o contexto faz toda a diferença. O Codex já é uma ferramenta poderosa por si só, mas é muito mais eficaz quando tem acesso às informações do IDE. Com esse contexto, o Codex entende melhor o problema e consegue propor correções precisas mais rapidamente. Isso aumenta ainda mais minha confiança nos resultados.
Esperamos que nossa experiência inspire outras pessoas a experimentar essas integrações. Tenho cada vez menos a sensação de estar usando uma ferramenta e cada vez mais a de estar programando em dupla com uma IA que vê o que a gente vê.