E se um agente pudesse refatorar uma função, escrever os próprios testes, executar tudo em um ambiente isolado e rejeitar a mudança quando o resultado não fosse verificável? Esse é o ponto de um agente de teste auto-contido para drift de código: não pedir ao modelo que acerte de primeira, mas construir um ciclo em que cada alteração precisa sobreviver a uma prova executável.
O resultado final é visível. Um arquivo modificado, uma suíte de testes rodando e um veredito binário: passou ou falhou. Essa simplicidade é justamente a vantagem. Em vez de tentar monitorar a intenção interna do modelo, observamos o que ele fez e submetemos o trabalho a uma condição externa.
O problema não é escrever código
Código sofre drift quando a implementação se afasta do contrato original. Uma função muda de nome, uma regra de negócio ganha uma exceção, um formato de entrada deixa de ser aceito. O sistema continua compilando, mas passa a fazer algo diferente.
Um modelo de linguagem pode acelerar essa mudança. Também pode agravá-la. Ele lê o contexto disponível, propõe uma alteração plausível e preenche lacunas com padrões aprendidos. Se o repositório não oferece testes claros, o agente não tem uma régua confiável para distinguir refatoração de regressão.
A saída é transformar o trabalho em um circuito fechado:
- observar o repositório e o objetivo;
- propor uma alteração pequena;
- criar ou atualizar testes;
- executar a suíte em isolamento;
- ler os resultados;
- corrigir a alteração ou encerrar com falha.
O agente não recebe autorização porque sua explicação parece boa. Recebe autorização porque o código passou por uma verificação que pode ser repetida.
A arquitetura parece uma oficina com parede de vidro
Imagine uma oficina em que o agente pode pegar ferramentas, modificar peças e testar o resultado, mas não consegue mexer no prédio inteiro. A sandbox é essa parede de vidro. Ela permite observar o trabalho sem entregar acesso irrestrito ao sistema.
Na prática, o orquestrador cria uma cópia temporária do repositório, instala apenas as dependências permitidas, limita acesso à rede e define quais comandos podem ser executados. O modelo recebe ferramentas explícitas, como listar arquivos, ler conteúdo, editar arquivos e rodar testes. Cada chamada produz uma saída que volta para o contexto da próxima decisão.
A analogia deixa de valer em um ponto importante: uma oficina física não inventa instruções. O modelo inventa. Por isso, a sandbox controla o dano possível, mas não prova que o comportamento implementado corresponde ao produto desejado. Ela contém a execução; os testes definem a verdade operacional.
Uma configuração possível separa essas funções, mesmo que um único modelo execute todos os papéis em momentos diferentes. O primeiro analisa o código e refatora. O segundo revisa o diff e procura violações do contrato. O terceiro executa os testes e decide se o ciclo termina. Pode reduzir a chance de o sistema aceitar a primeira resposta apenas porque ela foi gerada pelo próprio agente.
O prompt precisa descrever um procedimento, não um desejo
Um pedido como “melhore este módulo e não quebre nada” é uma intenção, não um protocolo. O agente precisa saber o que observar, o que pode alterar e qual evidência encerra o trabalho.
Um prompt de sistema útil começa com limites concretos:
Você trabalha em uma cópia temporária do repositório.
Leia as instruções do projeto antes de editar.
Não altere contratos públicos sem registrar a mudança.
Faça a menor alteração que atenda ao objetivo.
Adicione testes para o comportamento preservado e para o novo comportamento.
Execute os comandos de validação antes de responder.
Se um teste falhar, investigue a causa e corrija o código ou declare falha.
Nunca marque a tarefa como concluída sem saída dos testes.
Depois, o orquestrador deve enviar o objetivo junto com o estado real do trabalho: arquivos alterados, saída do último comando, lista de testes e limite de tentativas. Esse detalhe importa. Sem estado explícito, cada rodada força o modelo a reconstruir o que aconteceu a partir de uma memória parcial da conversa.
A regra mais importante é separar observação de interpretação. O agente pode dizer que uma mudança “parece segura”, mas o sistema precisa registrar fatos diferentes: quais arquivos foram modificados, qual comando foi executado, quantos testes passaram e qual código de saída foi produzido.
O ciclo de validação é o produto
O feedback é uma parte central da confiabilidade do fluxo. A parte agêntica é escolher o próximo passo; a validação fornece sinais observáveis para essa escolha.
Um fluxo mínimo proposto pode ser escrito assim:
criar sandbox
copiar repositório
pedir plano de mudança
aplicar alteração
pedir testes
executar formatador e suíte
se passar: gerar relatório e encerrar
se falhar: devolver erro ao agente e repetir
se exceder o limite: encerrar com falha
Várias rodadas de inferência, execução e correção aumentam o tempo total do processo. O limite de tentativas também é obrigatório. Sem ele, um teste mal especificado cria um loop infinito de alterações cosméticas. O sistema precisa distinguir três saídas: sucesso verificável, falha reproduzível e interrupção por limite operacional. “O modelo parou de responder” não é equivalente a “o código passou”.
Teste que passa ainda pode estar errado
Aqui está o limite que não pode ser escondido. Uma suíte pode passar e não testar o comportamento importante. O agente também pode escrever um teste que confirma a própria implementação, em vez de confirmar o contrato do sistema.
Por isso, o segundo papel deve revisar a relação entre teste e requisito. Ele deve perguntar: o teste falharia se a regra fosse removida? O caso cobre uma entrada inválida? O resultado verifica efeito observável ou apenas uma chamada interna? A mudança preserva compatibilidade com os consumidores existentes?
Essa revisão automática é promissora, mas a evidência ainda é inicial. Testes executáveis podem detectar algumas regressões, e sandboxes podem limitar o alcance de determinadas ações. Nada disso demonstra que um agente compreende o sistema inteiro.
Também existe discordância prática sobre quanto separar os papéis. Um agente único tem menos custo de contexto e pode iterar rápido. Vários agentes criam perspectivas independentes, mas repetem leitura, gastam mais inferência e podem concordar com o mesmo erro. A escolha depende do risco da mudança e da qualidade dos testes, não de uma regra universal.
O que vale construir primeiro
Comece com um repositório pequeno e uma única operação: refatorar uma função sem alterar sua interface. Exija um teste de comportamento antes da mudança, execute a suíte depois e salve o diff junto com os logs. Só então adicione geração de novos casos, revisão por outro papel e tentativas de correção.
Meça quatro coisas: taxa de sucesso, tempo até o veredito, número de tentativas e falhas que escaparam dos testes. O último indicador é o mais valioso. Um agente que passa sempre porque testa pouco não é confiável; é apenas permissivo.
Uma plataforma de orquestração pode servir como caminho prático para montar esse fluxo com uma integração entre modelos, execução de código e orquestração. Mas a ferramenta não substitui o desenho do contrato. O sistema só fica confiável quando cada etapa deixa uma evidência que outra etapa consegue verificar.
O próximo salto não está em fazer o agente explicar melhor por que alterou o código. Está em tornar mais difícil para ele alterar o código sem deixar uma prova. Quando essa prova é curta, reproduzível e independente da eloquência do modelo, a automação deixa de depender de confiança e começa a depender de engenharia.
