O que é secretary's escape e quando ele aparece no dia a dia
O termo secretary's escape descreve uma situação em que uma ferramenta ou automação — geralmente um assistente de programação, um sistema de IA generativa ou até um script simples — é configurado para realizar tarefas repetitivas, mas acaba "fugindo" do escopo original por falta de restrições claras no prompt ou nas regras do sistema. A ideia central é bem simples: você pede para o assistente editar arquivos de configuração de um projeto, ele faz isso, mas também mexe em arquivos que você não pediu para tocar porque não tinha uma lista explícita do que era proibido. Já vi isso acontecer com devs usando Claude ou ChatGPT conectados a editores via extensões, onde o modelo começa a refatorar imports inteiros de arquivos que o usuário nem abriu. O que torna o problema mais irritante é que ele não gera erro. O código continua funcionando, só que agora com 47 arquivos modificados quando o esperado eram 3. Em projetos maiores, identificar o escape exige ferramentas de diff e versionamento, senão você gasta horas rastreado mudanças que o assistente fez "por conta própria".
Como evitar o secretary's escape na prática
A abordagem que funciona melhor comigo é definir um perimetro rigoroso antes de qualquer execução. No meu caso, trabalho principalmente com projetos Python e Go, e costumo usar uma combinação de prompts estruturados com validação em camadas. O primeiro passo é especificar exatamente quais diretórios e extensões de arquivo são permitidos. Por exemplo: "apenas arquivos .py dentro de src/ e tests/". Sem essa restrição, modelos como o GPT-4 ou o Claude tendem a expandir o escopo para qualquer arquivo que pareçam poder melhorar. O segundo passo é ativar modo de previsão antes da aplicação. Ferramentas como codex-cli ou extensões de IDE com view-diff integradas permitem ver as alterações propostas antes de confirmar. Eu nunca executo uma modificação sem revisar o diff primeiro, especialmente em branches de produção. Uma vez, em um projeto de finanças com cerca de 200 módulos, o assistente modificou arquivos de configuração de bancos de dados em três ambientes diferentes porque eu não tinha restringido o escopo por ambiente. Levei duas horas para reverter com git revert e ainda precisei reinstalar dependências que ele havia atualizado silenciosamente.
O terceiro passo é usar arquivos de exclusão. Em projetos com muitos geradores automáticos — migrations, scaffolds, build outputs — você precisa listar explicitamente o que não deve ser tocado. Arquivos como .gitignore não resolvem isso porque o assistente não os lê. A solução é passar uma lista negativa no prompt ou configurar um arquivo .assistantignore no raiz do projeto. Eu criei um template padrão que incluo em todos os repositórios novos: \*dist/*\n\*build/*\n\*.env\nnode_modules/\nvendor/\n__pycache__/\n.terraform/\n
👉 Clique no botão abaixo para saber mais sobre o assunto!
Isso reduz drasticamente o ruído. Mesmo assim, o assistant às vezes ignora essas regras se o prompt não for suficientemente firme. Aí entra a camada final: validação pós-execução com testes automatizados. Se o código passa nos testes, você sabe que o escape não quebrou nada. Se falha, o problema está isolado rapidamente.
Vantagens e limitações do secretary's escape como conceito
O conceito em si é útil porque expõe um padrão recorrente no uso de assistentes de código: a tendência natural de expansão de escopo. Reconhecer isso permite criar safeguards proativos em vez de apenas reagir a danos. O problema é que nenhum mecanismo atual elimina completamente o risco. Ferramentas como GitHub Copilot Workspace oferecem controles melhores que o chat padrão, mas ainda dependem de configurações cuidadosas do usuário. Outro ponto importante é que o secretary's escape não se limita a assistentes de IA. Scripts de deploy mal escritos, makefiles com targets genéricos e até extensões de IDE antigas podem causar o mesmo efeito. A diferença é que com IA, o assistente age com mais persuasão — ele explica por que acha que a mudança adicional é benéfica, o que pode levar o desenvolvedor a aceitar alterações que não pediu.
Em resumo, o secretary's escape é um problema real de segurança e produtividade no fluxo de desenvolvimento moderno. A mitigação eficaz combina definição estrita de escopo, revisão de diffs antes da aplicação, listas de exclusão e validação contínua via testes.
