Modelos de IA mais capazes estão tornando desnecessária uma parte das instruções criadas para ajudá-los a programar. Regras extensas, planos obrigatórios e exemplos detalhados de uso de ferramentas compensavam limitações de modelos anteriores. Hoje podem apenas aumentar o custo e ocupar contexto.

Isso não significa que o restante da engenharia deva desaparecer junto. Há uma diferença entre a complexidade criada para ajudar o modelo a realizar uma tarefa e os mecanismos criados para limitar as consequências quando ele erra. Modelos melhores podem reduzir a primeira. Não há razão para presumir que eliminem os segundos.

Que instruções podemos retirar?

A Anthropic relata ter retirado mais de 80% das instruções de sistema do Claude Code para modelos mais recentes, sem perda mensurável em suas avaliações de programação. Havia regras repetidas, exemplos que restringiam a exploração e até ordens conflitantes entre as instruções gerais, as habilidades e os arquivos do projeto.

A resposta da empresa não foi eliminar o contexto. Ela recomenda que o CLAUDE.md permaneça leve, com particularidades difíceis de inferir do repositório. Instruções especializadas podem ser carregadas apenas quando necessárias. Testes, código existente, protótipos e critérios de avaliação também podem comunicar uma intenção com mais precisão que páginas de prosa.

Uma pergunta ajuda a revisar cada regra antiga: que erro concreto ela evita hoje? Se ninguém consegue responder, vale testar sua remoção. Uma instrução criada para contornar uma limitação do modelo não precisa sobreviver à limitação.

O código mostra o que fizemos. Não mostra tudo o que decidimos

O código representa com precisão o sistema implementado. Repetir em documentos aquilo que pode ser descoberto diretamente no repositório cria duas fontes que precisam permanecer sincronizadas. O problema começa quando confundimos estado implementado com intenção.

O código pode mostrar que uma validação existe. Não necessariamente mostra por que ela precisa continuar existindo. Não registra de forma confiável uma alternativa rejeitada, uma obrigação externa, quem autorizou uma exceção ou um comportamento que deve permanecer proibido depois de uma reestruturação.

Parte desse conhecimento pode virar algo executável: um teste de contrato, uma restrição no esquema, uma política de acesso. Outra parte precisa permanecer como decisão registrada. Não é necessário documentar cada alteração; é preciso preservar o que não pode ser reconstruído observando apenas o estado atual do sistema.

Isso se torna mais importante quando agentes passam a executar ações. O estudo HANDBOOK.md avaliou agentes seguindo procedimentos empresariais longos em ambientes simulados. Sob o critério estrito dos autores, a melhor das 30 configurações avaliadas cumpriu integralmente 36,2% das tentativas. Alguns agentes realizaram verificações exigidas e depois agiram contra o resultado; outros relataram conformidade que o estado final não confirmava.

O estudo não mede programação com AGENTS.md. Mede se colocar uma política extensa no contexto basta para que um agente a respeite durante uma sequência longa de ações. Os resultados não sustentam essa confiança. Uma instrução pode orientar o comportamento, mas não substitui um controle que impeça uma ação indevida.

Planejar menos não significa verificar menos

Um estudo empírico sobre a estrutura de execução de agentes de código comparou quatro modelos em tarefas dos conjuntos SWE-Bench Verified e Terminal-Bench 2.1. Com o mecanismo de planejamento avaliado, os modelos mais fortes tiveram custo menor com pouca mudança de precisão. Para os mais fracos, o plano também ajudou a acertar. A gestão do contexto tornou-se mais valiosa quando o espaço disponível diminuiu, sobretudo por evitar interrupções por excesso de contexto.

Esses resultados dependem dos modelos, tarefas e mecanismos testados. Eles questionam a imposição das mesmas etapas a toda solicitação; não justificam abandonar o planejamento em geral, muito menos os testes.

O estudo de Addy Osmani, Shubham Saboo e Sokratis Kartakis sobre o novo ciclo de desenvolvimento separa a velocidade aceitável para experimentar da disciplina necessária quando outras pessoas dependem do software. Um protótipo pode parecer convincente e ainda esconder casos-limite, problemas de integração ou premissas de negócio erradas. Produzir mudanças mais rapidamente não reduz o custo dessas falhas. Pode permitir que mais mudanças se acumulem antes de encontrá-las.

Quando a estrutura protege o sistema

A Cloudflare descreve sua infraestrutura interna de engenharia com IA em camadas. Seus arquivos AGENTS.md são curtos e concentram comandos, convenções e limites específicos de cada repositório. Uma camada de conhecimento permite que agentes consultem responsáveis por serviços, dependências, interfaces e bancos de dados. Na camada de controle, autenticação e permissões são centralizadas; propostas de mudança recebem revisão automatizada na integração contínua. A empresa também descreve ambientes isolados para executar código gerado por agentes.

O contexto colocado diante do agente é seletivo. Os controles ao redor de suas ações continuam. Isso ajuda a explicar por que práticas excessivas para a primeira versão de um projeto pessoal podem ser necessárias quando muitas equipes e repositórios compartilham agentes capazes de modificar sistemas.

Complexidade proporcional à consequência

Para experimentar uma página visual, poucas etapas podem bastar: produzir alternativas, escolher uma, conferir o resultado no navegador e descartar o que não funciona. Para alterar o contrato de uma interface usada por outros sistemas, critérios de aceitação e testes que representem seus consumidores passam a importar. Para modificar dados persistentes ou permissões, entram isolamento, autorização, revisão, registro das ações e um caminho de reversão.

Essas etapas não existem para fazer o modelo raciocinar melhor. Existem porque os erros têm consequências diferentes.

Remova a complexidade criada para orientar o modelo antes de remover os controles que protegem o sistema.

Vale retirar regras herdadas de modelos antigos, documentos que repetem o repositório e passagens entre agentes que não acrescentam informação ou independência. Verificações executáveis, isolamento e decisões que não podem ser reconstruídas do código pertencem a outra categoria. Um modelo mais capaz precisa de menos ajuda para realizar uma tarefa. Isso não lhe dá, por si só, autoridade para agir sem limites.