Equipe integra agente de IA ao desenvolvimento e cria duas etapas de revisão

O agente escreveu o código rapidamente. Agora alguém precisa verificar se ele alterou o serviço certo, se consultou o banco de dados correto e se não travou a interface com uma operação demorada. Em um texto no Habr, a equipe descreveu como resolveu esses problemas em seu próprio agente para o IntelliJ IDEA. Um dos principais passos é aprovar a especificação em um pull request separado antes de começar a implementação. Essa ordem também pode ser testada com um agente que você já tenha instalado.

A história começou em 2024 com um plugin para gerar testes. Depois surgiu um chat dentro da IDE e, após conhecer o Windsurf em janeiro de 2025, a equipe passou a construir um agente completo: busca no projeto, alteração de arquivos e execução de verificações. Com o uso, ficou claro quais partes do trabalho precisavam ser explicadas de novo e onde a ferramenta exigia limites.

Contexto do projeto: encontrar o código e escolher o banco de dados certo

Para a busca, a equipe usou os índices do IntelliJ IDEA e o PSI, a representação estrutural do código dentro da IDE. Os índices ajudam a encontrar classes, métodos e arquivos, enquanto o PSI mostra os elementos do programa e as relações entre eles. O agente repassa essas informações ao modelo de linguagem.

Imagine uma tarefa: alterar o processamento de pedidos. Vale encontrar o próprio método, suas chamadas e as classes relacionadas antes de editar o primeiro arquivo que pareça adequado. Esta é uma ilustração da abordagem; os autores não apresentam medições concretas da qualidade dessa busca.

Para fontes externas, a equipe adicionou o MCP, uma forma de conectar servidores que fornecem ferramentas ao agente. Por meio deles é possível obter tarefas do GitHub, consultar um banco de dados ou verificar uma aplicação web no navegador. As ações disponíveis dependem do servidor específico e das permissões concedidas.

Mas conectar o banco de dados, por si só, não resolveu o problema de contexto. Segundo os autores, uma vez uma consulta foi para o ambiente errado e devolveu um resultado convincente, porém incorreto. O agente também confundia nomes de colunas. Os desenvolvedores tinham de repetir explicações, principalmente após abrir um novo chat.

A equipe organizou os procedimentos repetitivos em skills: instruções com a ordem das ações e as condições de verificação. Além disso, surgiu uma memória local do projeto para restrições e soluções encontradas. As regras proíbem salvar credenciais, mas o texto fornecido não revela mecanismos técnicos de proteção da memória.

Primeiro verificar a tarefa, depois a implementação

Agora o trabalho em uma funcionalidade começa pela especificação. O desenvolvedor a elabora junto com o agente e abre um pull request separado. Um colega revisa o documento e, após a aprovação, a implementação começa. As decisões e os esclarecimentos permanecem no repositório para que o próximo participante possa recuperar o contexto.

Pegue uma mudança de API. Antes de gerar o código, a equipe pode acordar os campos da resposta, o tratamento de erros e o comportamento esperado do cliente. O desenvolvedor de frontend recebe uma descrição que um colega já verificou. Surge aqui um ponto de verificação antecipado: um erro nos requisitos pode ser notado antes de se espalhar por vários arquivos.

Para a revisão de código, os autores usaram seus próprios comentários de pull requests anteriores. No desenvolvimento do plugin, eram frequentes operações demoradas na thread de interface EDT e chamadas à API do IntelliJ sem o read action necessário. Esses casos foram transformados em instruções para o agente revisor.

Mais tarde, a revisão foi dividida entre vários subagentes com papéis diferentes. Os resultados são reunidos em um relatório geral, após o qual o desenvolvedor escolhe as correções. Os autores afirmam que os erros conhecidos diminuíram, mas não mostram estatísticas, amostra de controle nem o custo das verificações. Não é possível avaliar o tamanho do efeito a partir do texto.

O que dá para levar para a sua equipe

O elemento mais prático da história é o controle das ações no nível do plugin. Uma ferramenta pode ser desativada ou exigir confirmação antes de ser chamada. A decisão de executar é tomada pela camada de software. Isso dá ao desenvolvedor um ponto de controle concreto ao trabalhar com comandos e serviços externos.

A equipe também separou a lógica do agente da interface e lançou uma CLI. Pela descrição, a versão de terminal mantém o trabalho com arquivos, skills, modelos e MCP. No entanto, o trecho fornecido é interrompido: aqui faltam o nome do produto, as condições de acesso e um quadro completo de operação.

Um experimento prático pode começar por um erro recorrente da sua própria equipe: descrever uma regra de verificação, adicionar a aprovação de requisitos e comparar os resultados nas tarefas seguintes. Vale medir o tempo até a mudança aceita, o número de devoluções da revisão e os defeitos após o merge. São justamente essas medições que ainda faltam a esta história para julgar se um agente próprio compensa.