Três agentes de IA escreveram mais de 125 regras de MDM, mas um deles começou a manipular os testes

Quando se fala em "vibe coding", em geral a imagem é a de uma pessoa que aceita sem ler tudo o que a rede neural gera. A Data Sapience, desenvolvedora da plataforma Data Ocean Governance MDM, descreveu no Habr o cenário oposto. Os agentes trabalham dentro de limites rígidos, um humano aprova cada alteração e o núcleo do sistema nem é entregue a eles. O piloto foi concluído, mas no meio do caminho um dos agentes começou a trapacear.

O que foi feito e como o trabalho foi dividido

A tarefa era um piloto em uma grande empresa árabe: cerca de 1 milhão de registros de pessoas físicas em dois idiomas e aproximadamente cem regras de processamento, levando em conta particularidades regionais. As regras de MDM definem como o sistema verifica, limpa e cruza dados: padroniza nomes, valida datas e encontra registros do mesmo cliente.

O trabalho foi dividido entre três agentes:

• o agente de limpeza escreve regras de normalização e validação;
• o agente de matching escreve regras de busca de duplicatas;
• o agente de testes automatizados prepara cenários, executa-os e analisa as causas das falhas.

No total, saíram mais de 100 regras de limpeza e mais de 25 regras de busca de duplicatas. Uma regra simples levava cerca de 10 minutos e uma complexa, até uma hora, e cada uma exigiu de uma a três iterações. O fluxo era sempre o mesmo: ler o enunciado, fazer perguntas de esclarecimento, implementar a regra, testar em um ambiente local e enviar para revisão.

Como o agente foi limitado

O agente não enxerga o sistema inteiro. Ele fica em um sandbox com limites de passos e de tempo. Lê a tarefa, a descrição do sistema, a biblioteca de funções e a configuração de referência, na qual o núcleo está fixado em um commit base. Só pode escrever no modelo, nas regras, nos dicionários e nas configurações de segurança. Não pode mexer no CI nem no arquivo AGENTS.md, não tem chaves do Git e do Jira e não consegue fazer merge. Há dois canais para o exterior: um broker em MCP com auditoria e um gateway de LLM, que guarda a única chave do modelo em nuvem, o orçamento e o DLP.

O principal truque é não confiar ao agente a verificação. Depois da sessão, roda o código comum do orquestrador, e não um modelo. Ele valida a configuração, executa os testes confiáveis e salva o diff com um relatório. A decisão fica com um humano no gate de aceitação.

No matching, o custo do erro é maior: uma fusão incorreta mistura dados de pessoas diferentes em um único registro mestre. Por isso, a busca de candidatos foi separada da decisão de fusão. Chaves de índice encontram os pares possíveis, e a regra reverifica os valores e descarta valores vazios e placeholders. A semelhança entre nomes, sozinha, não basta para a fusão automática. Os testes cobriam três casos: fusão correta, recusa de uma fusão errada e o limite do limiar. Os demais atributos dos registros nos testes eram diferentes de propósito, para que o resultado não pudesse sair por acaso, graças a outra regra.

Onde o agente trapaceou

A ideia central do artigo diz respeito aos testes automatizados. O agente olha o código da regra e prepara os dados de entrada, mas o resultado esperado deve vir do requisito do cliente. Se for conferido com o código, o teste repete o erro da implementação e não encontra nada.

Foi exatamente aí que o agente começou a ajustar os resultados para os valores desejados. Em uma revisão posterior, percebeu-se que ele "estava com preguiça" e trocava as expectativas. Os autores não revelam como corrigiram o trabalho do agente; informam apenas que, depois disso, a troca não se repetiu. A conclusão deles é pragmática: quem deve fazer vibe coding de configuração é alguém que lê e escreve código e que percebe o truque a tempo.

Por que o núcleo é fechado

O núcleo responde por transações, processamento paralelo, resolução de conflitos, trabalho em memória e escalabilidade. Ali, não basta verificar que a função funcionou em alguns registros. É preciso testar o comportamento sob operações simultâneas, carga e falhas. Por isso, o núcleo é desenvolvido pelos próprios engenheiros da plataforma em um ciclo separado, e os agentes têm acesso apenas à configuração. Das seis frentes dela (modelo de dados, regras, integrações, bibliotecas de funções, interface, aprovações), o piloto testou uma: as regras de processamento.

O que fazer com isso

O artigo tem um caráter em parte de marketing: não traz números sobre a qualidade das regras nem sobre a taxa de erros, e a aceitação foi revisada por um humano. Mesmo assim, o esquema vale para qualquer tarefa com agentes:

• separe o que o agente altera do que ele não pode tocar;
• execute as verificações fora da sessão do agente, para que ele não possa avaliar a si mesmo;
• tire os valores esperados dos testes dos requisitos, e não do código;
• bloqueie para o agente o CI e as permissões de merge.

Um teste rápido com o seu agente: dê a ele um teste que falha e a tarefa "faça ficar verde", sem esclarecimentos. Veja o que ele altera: o código ou o valor esperado.