IA escritora e revisora: como dividir o trabalho por papel

Separar quem implementa de quem revisa cria duas responsabilidades claras: produzir uma mudança e procurar problemas nela. Com agentes de IA, essa divisão pode ser útil para organizar o desenvolvimento, desde que a revisão examine o código e os testes, em vez de apenas concordar com o resumo da implementação.

O benefício esperado é um processo mais verificável. Usar duas IAs, ou dois modelos diferentes, não garante que os erros serão encontrados. As duas podem compartilhar limitações ou interpretar o mesmo requisito de forma errada.

Defina o resultado antes de escolher as IAs

Comece pela tarefa e pelos critérios de aceite. Em um exemplo hipotético de agenda online, a mudança será impedir duas reservas para o mesmo horário. O comportamento esperado precisa ser o mesmo para a IA que escreve e para a que revisa.

Registre também o que está fora do escopo. Se a tarefa é corrigir reservas duplicadas, redesenhar o painel ou trocar o banco de dados não deve entrar no pacote sem uma decisão explícita. Quanto mais fácil identificar a mudança, mais objetiva pode ser a revisão.

Para quem está começando, o guia sobre criar um SaaS com IA explica como transformar uma ideia em critérios que você consegue verificar.

Dê à IA escritora uma entrega concreta

A escritora, ou agente de implementação, recebe a responsabilidade de produzir a mudança dentro do escopo. A entrega deve incluir o que foi alterado, quais testes foram executados, o resultado e qualquer limitação conhecida.

Um pedido possível para a agenda é:

Implemente a proteção contra reservas duplicadas. Preserve o fluxo atual e acrescente um teste para duas tentativas de reservar o mesmo horário. Explique os arquivos alterados. Não publique em produção. Se não conseguir executar um teste, informe isso claramente.

Esse pedido não determina sozinho a solução técnica. Ele estabelece o resultado e as evidências esperadas, deixando espaço para que o agente investigue a estrutura existente.

Faça a revisora examinar a mudança real

A revisora precisa receber o objetivo, os critérios, a versão exata da mudança e acesso ao contexto relevante. Peça que examine o diff, que é a comparação entre versões, e os arquivos relacionados. Um relatório escrito pela própria implementadora não substitui essa inspeção.

Na agenda, a revisão deve perguntar se a proteção funciona quando duas requisições chegam quase ao mesmo tempo, se a permissão é conferida no servidor e se o teste realmente reproduz a falha que se queria corrigir.

Peça achados específicos: localização, cenário em que ocorre o problema, impacto e forma de verificar. “Pode estar inseguro” é pouco acionável. “O cliente A consegue cancelar a reserva do cliente B neste fluxo” descreve algo que pode ser confirmado ou refutado.

Separe papel de modelo

Escritora e revisora são responsabilidades. Claude, Codex e outras opções compatíveis são ferramentas ou famílias de modelos que podem assumir essas responsabilidades conforme a configuração disponível.

O NexusIDE organiza agentes em missões e permite trabalhar com diferentes CLIs no mesmo ambiente, com papéis, terminais e passagens de contexto. Também oferece worktrees, pastas separadas do mesmo repositório para organizar mudanças em paralelo. Veja os recursos do produto.

Para uma tarefa rotineira e bem delimitada, experimente uma opção de menor custo na escrita e reserve um modelo mais capaz para a revisão complexa. Isso é uma estratégia de trabalho a validar no seu projeto. Preço mais alto não comprova qualidade, e um modelo barato que exige várias correções pode custar mais por entrega aceita.

Escolher modelos diferentes pode ser uma estratégia a experimentar para obter outra análise. Não trate diversidade como prova de independência ou qualidade. Compare resultados em tarefas reais e mantenha os mesmos critérios de avaliação. Custo, disponibilidade e contexto necessário também entram na escolha.

Devolva problemas como correções delimitadas

Quando houver um achado, confirme que ele se aplica à versão atual. Encaminhe à escritora o cenário e a evidência, peça uma correção localizada e revise a nova versão. Uma mudança feita depois da revisão pode invalidar parte das conclusões anteriores.

Evite deixar escritora e revisora alterarem os mesmos arquivos sem coordenação. No processo recomendado aqui, a primeira revisão identifica problemas; a correção entra em uma etapa explícita. Isso é uma organização de trabalho, não uma promessa de bloqueio técnico de escrita no Nexus.

Se a revisão não encontrar problemas, registre o que foi examinado e as limitações. Não é necessário fabricar alterações para demonstrar atividade.

Exija testes e mantenha a decisão humana

Uma entrega pode trazer código, testes, comandos executados e pendências. Ela não deve transformar “não consegui verificar” em “está pronto”. Revise também a interface quando o comportamento depender de layout, acessibilidade ou interação.

A documentação do GitHub ressalta que a revisão por IA pode errar e deve complementar a revisão humana. A concordância de agentes não substitui sua responsabilidade sobre a mudança. Consulte a orientação sobre uso responsável.

Em áreas sensíveis, como autenticação, dados de clientes e pagamentos, envolva alguém com experiência para avaliar a entrega antes de liberar o uso real. Decida a publicação com base em evidências e riscos conhecidos, não apenas no tom confiante da resposta.

Comece com uma dupla e observe

Para experimentar, escolha uma tarefa pequena, uma escritora e uma revisora. Registre quantos problemas reais foram encontrados, o trabalho de correção e o consumo informado. Acrescente outros papéis apenas quando houver uma necessidade clara. Veja também como acompanhar o consumo de tokens.

Veja os downloads do NexusIDE para organizar esse fluxo no seu computador. Confira os instaladores e as condições atuais do Nexus; o acesso aos modelos continua nas suas próprias contas de provedores compatíveis.

Fontes e referências

• GitHub: uso responsável de agentes de IA ↗

As recomendações práticas são orientação editorial. As fontes descrevem os limites e mecanismos citados; não são testes de desempenho do NexusIDE.