- Início
- The Thinking Wire
- Deriva Silenciosa: O Modo de Falha que Ninguém Nomeou
Deriva Silenciosa: O Modo de Falha que Ninguém Nomeou
Um desenvolvedor revisa um pull request gerado por um agente de IA. O código compila. Os testes passam. O linting está limpo. Ele aprova e faz merge.
Três semanas depois, alguém percebe que a página está estranha. O agente havia adicionado um componente Ant Design <Form.Item> em uma codebase que estava migrando para shadcn/ui. Nada quebrou. O sistema de tipos não reclamou. Os testes — que validavam comportamento, não intenção arquitetural — passaram. Mas a migração de framework de UI acabou de regredir em um arquivo. Depois outro. Depois doze.
Isso é deriva silenciosa. Código correto por todas as métricas automatizadas e errado por todas as métricas arquiteturais.
O Problema de Confiança
A CodeRabbit analisou 470 pull requests no GitHub e descobriu que código gerado por IA contém 1,7x mais bugs que código humano e 2,74x mais vulnerabilidades de segurança. A DryRun Security testou PRs do Claude Code, Codex e Gemini: 87% continham pelo menos uma vulnerabilidade.
Esses números descrevem falhas detectáveis. A deriva silenciosa é a categoria que eles não capturam.
Quando um agente copia p-[24px] em vez de usar o token do design system p-6, nenhum teste detecta. Quando importa um utilitário depreciado que ainda funciona, nenhum linter sinaliza. Quando adiciona uma chamada ao banco dentro de um loop porque o padrão existe em outro lugar da codebase, a regressão de performance é real, mas o code review parece limpo.
Como a CodeRabbit colocou: “Não temos mais um problema de criação. Temos um problema de confiança.”
O problema de criação era sobre se IA conseguia escrever código. Isso está resolvido. O problema de confiança é sobre se você pode confiar no que ela escreve sem inspecionar cada linha — e na escala de agentes, você não consegue inspecionar cada linha.
A Escala que Torna Perigoso
O agente Honk da Spotify faz merge de mais de 650 pull requests em produção todo mês. Isso não é um experimento. É um pipeline de produção onde o volume de mudanças excede o que revisores humanos conseguem auditar de forma significativa.
Nessa escala, a deriva silenciosa não é um incômodo. É erosão estrutural. Cada mudança individual é defensável isoladamente. O padrão só se torna visível quando alguém mapeia a trajetória — e nesse ponto a codebase já se afastou significativamente da arquitetura pretendida.
Isso é diferente do paradoxo das operações com agentes que descrevemos anteriormente, onde escalar agentes cria problemas de coordenação. A deriva silenciosa é mais sutil. Os agentes não estão conflitando entre si. Estão individualmente fazendo escolhas que são localmente corretas e globalmente corrosivas.
Contexto É a Alavanca, Não o Modelo
A taxa de merge do Devin dobrou de 34% para 67% — não por trocar para um modelo melhor, mas por melhorar o contexto da codebase que o agente recebia. Este é o dado mais importante na conversa sobre deriva silenciosa.
O modelo não era o gargalo. O contexto era.
Quando um agente não sabe que o time está migrando de Ant Design para shadcn/ui, ele vai usar o framework que tem mais exemplos na codebase. Isso não é um bug no modelo. É uma restrição arquitetural ausente. O agente tomou uma decisão estatisticamente razoável com base na informação que tinha. A informação estava incompleta.
Isso reenquadra o desafio de governança. Você não resolve a deriva silenciosa escolhendo um modelo melhor ou adicionando mais code review. Resolve codificando a intenção arquitetural em um formato que agentes conseguem consumir — manifestos de design system, arquivos de status de migração, registros de decisão arquitetural que fazem parte da janela de contexto, não enterrados em uma página do Confluence que ninguém lê.
Quando a Deriva Vira Desastre
A deriva silenciosa é erosão. Mas operações de agentes sem governança também podem produzir falhas catastróficas.
Um desenvolvedor configurou um hook SessionStart do Claude Code que criava duas instâncias em background por sessão. Cada instância disparava o mesmo hook. O resultado: criação exponencial de processos — um fork bomb. A máquina rodou sem controle por aproximadamente nove horas durante a noite. O único “disjuntor” foi a máquina ficar sem memória. Conta total da API: $3.800, com $600 atribuíveis somente ao incidente do fork bomb.
O hook não era malicioso. Era uma automação razoável que não tinha uma guarda de recursão. O sistema não tinha limite superior para criação de agentes. Nenhum monitoramento disparou. Nenhum limite de custo interrompeu a execução. O modo de falha era arquitetural — uma restrição ausente no ambiente operacional.
Na Microsoft, um ex-engenheiro de kernel do Windows documentou que 173 agentes de software gerenciavam nós do Azure, e nenhum funcionário conseguia explicar o propósito coletivo deles. Uma limitação de memória FPGA dual-ported de 4KB restringia o stack a poucas dezenas de VMs por nó, contra uma capacidade de 1.024 VMs. O Secretário de Defesa declarou publicamente uma quebra de confiança com o governo dos EUA.
Esses não são problemas de qualidade de código. São problemas de imposto operacional — o custo acumulado de rodar agentes sem infraestrutura de governança.
Testes Baseados em Propriedades como Resposta Parcial
Suítes de teste tradicionais verificam comportamento esperado. Não verificam conformidade arquitetural. Testes baseados em propriedades chegam mais perto.
Em uma implementação, 933 módulos foram testados com abordagens baseadas em propriedades, gerando 984 relatórios de bugs. Cinquenta e seis por cento eram válidos — aproximadamente $10 por bug real encontrado. É uma mudança econômica significativa. Mas testes baseados em propriedades ainda exigem que alguém defina as propriedades. Se ninguém codifica “usamos tokens do design system, não valores brutos” como uma propriedade testável, a suíte de testes não vai capturar a deriva.
O padrão que funciona é em camadas: linting arquitetural (regras customizadas que codificam convenções do time), testes baseados em propriedades (invariantes que capturam violações estruturais) e agentes de revisão que comparam mudanças contra registros de decisão arquitetural. Nenhuma camada sozinha captura tudo. A combinação captura o suficiente.
Como É a Governança de Deriva Silenciosa
A deriva silenciosa é um problema de governança, não de ferramentas. As ferramentas existem. A lacuna é organizacional.
Codifique a intenção arquitetural como restrições legíveis por máquina. Se agentes não conseguem ler, não conseguem seguir. Status de migração, regras de design system, políticas de dependência — precisam estar no repositório, em formatos que agentes consomem, não em wikis de time.
Meça conformidade arquitetural separadamente da passagem de testes. Testes verificam comportamento. Linting arquitetural verifica intenção. Um PR pode passar em todos os testes e ainda violar o plano de migração. Você precisa dos dois sinais.
Estabeleça orçamentos de deriva. Quantos arquivos podem usar o framework antigo antes de a migração ser considerada parada? Quantos valores CSS brutos antes de o design system ser considerado abandonado? Quantifique a deriva aceitável e alerte quando exceder.
Trate contexto de agentes como infraestrutura. A taxa de merge do Devin dobrou com melhoria de contexto, não de modelo. O contexto que seus agentes recebem é tão importante quanto os modelos que executam. Invista de acordo.
Descrevemos quatro modos de falha de codificação IA sem governança anteriormente. A deriva silenciosa é o quinto — e possivelmente o mais perigoso, porque é o que parece que tudo está funcionando.
Fontes
Esta análise sintetiza dados de The Feedback Loop Is All You Need (zernie.com, março de 2026) — incluindo a análise de 470 PRs da CodeRabbit, os achados de vulnerabilidade da DryRun Security e as métricas de produção do Spotify e Devin — com How Microsoft Vaporized a Trillion (Axel Rietschin, março de 2026) sobre proliferação desgovernada de agentes em escala, e o incidente do fork bomb de $3.800 (droppedasbaby, fevereiro de 2026) documentando falhas em cascata de agentes sem disjuntores.
O Victorino Group ajuda organizações a detectar e governar a deriva silenciosa antes que a erosão arquitetural se torne irreversível. Vamos conversar.
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa