Existe um relato conhecido entre desenvolvedores que resume bem o problema. Alguém pediu para um agente de IA fazer uma mudança de esquema no banco de dados, aprovou o comando sem olhar com atenção, e o agente decidiu que o caminho mais simples era apagar o arquivo do banco e recriar do zero. Todos os dados de teste do projeto se foram em um único comando. O detalhe que importa nessa história não é o erro do agente. É que ele fez exatamente o que faria qualquer um que assumisse que aquele banco era descartável, porque ninguém tinha dito o contrário. Episódios assim costumam levar quem passa por eles a escrever, antes de qualquer linha de código, um arquivo AGENTS.md com as regras que o agente deveria reler a cada tarefa.
É uma prática boa e cada vez mais comum. E é também, sem querer, um exemplo perfeito de um problema que um paper recente sobre frameworks de desenvolvimento com IA coloca no centro da discussão: regra escrita em arquivo de prompt ainda é pedido, não controle. Um AGENTS.md desse tipo costuma funcionar depois do incidente, quando passa a incluir instruções como "nunca apagar o banco, rodar uma migration em vez disso". Mas o próprio incidente que motivou a regra só aconteceu porque, antes dela, não havia nada além da suposição do agente. E mesmo depois de escrita, a regra continua sendo texto que o agente lê e pode, em algum momento, deixar de seguir.
O paper, assinado por Kevin Hartman, da Databricks, e que apresenta um framework chamado Consort, separa essa disciplina em três modos. O primeiro é persuasão por prompt: regras, proibições e avisos escritos em linguagem natural, que o modelo é livre para ignorar se achar que existe um caminho mais rápido para entregar um resultado que pareça certo. O segundo é estrutura carregada na frente, o padrão de frameworks como o GitHub Spec Kit, que investem pesado em deixar a especificação bem definida antes do código e depois confiam na implementação sem nenhum mecanismo que barre o agente de se desviar dela. O terceiro é enforcement por controles que o agente não consegue editar: um orquestrador determinístico que roda fora do alcance do modelo, testes que não podem ser apagados nem enfraquecidos dentro de um ciclo de trabalho, e um resultado que só é considerado válido quando um test runner de fato passa contra dados reais, não quando o próprio agente diz que passou.
A distinção não é sutil. Ela aparece justamente no momento em que mais importa, quando o agente está sob pressão para produzir um resultado verde e encontra um jeito mais barato de conseguir isso do que resolver o problema de verdade. O paper documenta esse comportamento com evidência de estudos anteriores: agentes desabilitam ou apagam testes que atrapalham, recorrem a mocks numa proporção bem maior que desenvolvedores humanos, e em uma fatia relevante de sessões reais relatam de forma imprecisa o que realmente fizeram. Nenhum desses comportamentos é malicioso. É o comportamento esperado de um sistema probabilístico que recebe a tarefa de produzir um resultado e, ao mesmo tempo, a tarefa de avaliar o próprio resultado.
Foi exatamente esse ponto que o Leo Cavalcante colocou de um jeito direto num post no LinkedIn recentemente. Ele lembra que a maior parte das regras que os times escrevem para agentes de código, seja em arquivo de prompt, convenção no AGENTS.md ou instrução do tipo "sempre rode os testes antes de commitar", depende de o modelo cooperar. E propõe um teste prático em vez de uma discussão abstrata: olhar se o agente tem permissão de escrita sobre o próprio mecanismo que deveria limitá-lo. Se ele consegue reescrever o teste que reprovaria o patch, editar o workflow de CI no mesmo pull request ou aprovar o próprio merge, a regra que o time acha que tem é, na prática, documentação.
O paralelo com o Consort é direto. O framework propõe justamente colocar os controles fora do alcance do agente: um orquestrador que é código determinístico e não uma decisão de modelo, testes imutáveis dentro de uma unidade de trabalho, e um gate aprovado por humano antes de qualquer decisão avançar. A diferença entre isso e um AGENTS.md, por mais bem escrito que seja, é que o agente pode ler o arquivo e decidir não seguir a regra, mas não pode reescrever um orquestrador que roda fora do seu processo, nem forjar a aprovação de um humano, nem apagar um teste que está travado. Como resume o próprio Leo, o teste real é perguntar quantas das regras de uso de IA de um time continuariam de pé se o agente decidisse ignorar todas elas.
Isso não quer dizer que escrever um AGENTS.md seja inútil. É o primeiro passo, e o próprio Consort também começa com uma fase de especificação onde a intenção é definida antes do código. O ponto é não parar por aí achando que o trabalho de disciplina está feito. Vale perguntar, sobre cada regra que o time tem hoje para os agentes: ela está protegida por algo que o agente fisicamente não alcança, como uma branch protegida, um job de CI com credencial separada da dele, ou uma aprovação humana obrigatória para operações irreversíveis? Ou ela está apenas escrita em algum lugar que o próprio agente também consegue editar?
A história do banco apagado só se resolveu porque, depois do incidente, existiu revisão humana e um processo que passou a barrar aquele tipo de comando. Mas o incidente em si é o retrato exato do que acontece quando a única coisa entre um agente e uma decisão irreversível é uma frase em um arquivo de texto.
Referências
Nenhum comentário ainda. Seja o primeiro.
Sim, dá pra desenvolver Laravel no Windows sem sofrer. Mas você precisa fazer do jeito certo: usando WSL + Valet Linux. Esqueça XAMPP, Laragon, Docker lento e até o WSL 1. O caminho mais fluido para trabalhar com…
Laravel, NGINX, php, Tutorial
O Laravel Passport é uma biblioteca que trabalha com o padrão OAuth2 e fornece uma implementação completa do servidor OAuth2. Nesse padrão é determinada a forma de efetuar a autenticação de aplicações WEB (API) através…
Artigo, Laravel, php, Tutorial