Agentes Mantêm o Quê. O Porquê Morre Quando o Projeto Entra no Ar

TV
Thiago Victorino
5 min de leitura
Agentes Mantêm o Quê. O Porquê Morre Quando o Projeto Entra no Ar

Um projeto entra no ar, e a documentação já é ficção. O diagrama de arquitetura mostra três serviços; a produção roda cinco. O README descreve uma estratégia de cache abandonada na sexta semana. O que sobrevive ao lançamento é o quê: o código, o schema, os endpoints que respondem. O porquê quase sempre desapareceu. Vivia nas dailies, em threads de pull request que rolaram para fora da tela, na memória de um arquiteto sobre por que a fila foi escolhida em vez do cron job. Ron Boling, da Atomic Object, nomeia a consequência sem rodeios: a manutenção agêntica de código será impossível sem uma fonte confiável de verdade.

Essa frase reformula um problema que equipes toleraram por décadas. Documentação obsoleta era sobrevivível porque um mantenedor humano compensava. Um engenheiro lê o README desatualizado, percebe que o passo três não corresponde mais ao sistema e se adapta. A razão que nunca foi escrita ainda existia em algum lugar, recuperável por uma conversa de corredor ou uma busca no Slack. Decaimento tolerável. Agora o mantenedor é cada vez mais um agente, e um agente não pode ter a conversa de corredor. Ele herda o quê e inventa o porquê.

O Porquê Nunca Foi um Artefato

A maior parte do conhecimento de engenharia sobre porquê sobra como resíduo do trabalho, fora de qualquer artefato entregue. Uma decisão é tomada em uma reunião. O raciocínio, as alternativas consideradas, a restrição que matou a opção óbvia, tudo isso fica no campo do falado e nunca chega ao armazenado. A mensagem de commit registra o que mudou. O ticket registra o que foi pedido. Nenhum dos dois registra por que o terceiro design foi rejeitado após dois dias de prototipagem, ou por que um padrão reconhecidamente subótimo foi mantido porque um sistema a jusante não podia ser tocado até o terceiro trimestre.

Essa é a razão da decisão, e é o conhecimento mais caro que uma organização produz. Custa julgamento sênior, contexto acumulado e, com frequência, alguns caminhos errados para ser gerado. É também a primeira coisa a evaporar. O ensaio de Boling é o relato de um praticante e não traz um conjunto de dados, então trate o enquadramento como observação, e não como medição. A observação se sustenta diante de evidências mais duras. Em nossa análise da plataforma DrP da Meta, o sistema de memória de um agente pontuou 100% em capturar o que aconteceu e 25% em capturar por quê. A assimetria é estrutural. Sistemas registram eventos porque eventos são fáceis de registrar. A razão exige que alguém pare e escreva um pensamento que pareceu óbvio na hora.

Por Que o Decaimento Deixa de Ser Sobrevivível

Um agente que mantém um sistema sem o porquê não falha de forma barulhenta. Falha fazendo, com confiança, a coisa errada de aparência correta.

Considere um limitador de taxa configurado em um valor incomum, 47 requisições por segundo. Um mantenedor humano que vê 47 presume que existe uma razão e pergunta antes de mudar. A razão era o throttle não documentado de um fornecedor a jusante, descoberto em um incidente doloroso há dois anos. Um agente instruído a “otimizar throughput” vê um número estranho, arredonda para 100 limpos e reabre o incidente. Fez exatamente o que mandaram. A instrução estava errada porque o porquê faltava, e o agente não tinha filtro, nenhum instinto de que 47 era estrutural.

Multiplique isso por uma base de código inteira. Cada número mágico, cada verificação defensiva, cada gambiarra deliberadamente feia codifica um porquê que o agente não enxerga. O agente trata a ausência de razão como ausência de restrição. Lê código limpo como código livre para mudar, quando muitas vezes o código mais feio é o mais restrito. Esse é o modo de falha que transforma um runbook obsoleto de incômodo em passivo no instante em que algo não humano começa a executá-lo.

Capture o Porquê Enquanto Ele Ainda Existe

A solução não é uma wiki melhor. Wikis são onde a razão vai apodrecer, porque são escritas depois do fato, por quem tem tempo, validadas por ninguém. O ponto mais afiado de Boling é sobre o momento: a razão precisa ser capturada durante o desenvolvimento, quando ainda está viva na cabeça de alguém, e precisa ser governada como qualquer outro artefato de produção.

Governada significa três coisas concretas. Primeiro, o porquê é capturado no momento da decisão e anexado à mudança que o encarna, em vez de adiado para uma sprint de documentação que nunca acontece. Um registro de decisão de arquitetura commitado junto ao código é governado; uma página de Confluence escrita no trimestre seguinte é arqueologia. Segundo, a razão passa por validação além do simples registro. Uma segunda pessoa confirma que o motivo declarado é o motivo real, do mesmo modo que a revisão de código confirma a lógica. É o mesmo movimento que a Meta fez ao submeter os analisadores de debugging à revisão de código: conhecimento que não é revisado não é confiável, independentemente de quem o escreveu. Terceiro, e isso é o que a era dos agentes acrescenta, a IA confere cada nova decisão contra o corpo das anteriores já validadas e sinaliza conflitos. Quando alguém propõe mudar o 47, o sistema traz à tona o incidente que o definiu. A razão vira uma proteção ativa em vez de uma nota de rodapé enterrada.

Esse terceiro movimento é a diferença entre documentação e governança. Documentação é lida por quem se lembra de procurar. Um repositório de razões governado é consultado automaticamente antes de uma mudança entrar, pelo agente e pelo humano. É o mesmo princípio por trás de tratar model cards como artefato de produto governado em vez de divulgação única: o artefato só conquista confiança quando é aplicado no ponto da ação, em vez de arquivado e esquecido.

O Custo de Não Fazer Nada

Ignore isso e a trajetória é previsível. O sistema cresce. Os arquitetos originais seguem em frente. O porquê sai com eles, porque nunca esteve em outro lugar além de suas cabeças. Os agentes que herdam o sistema mantêm o quê com fidelidade mecânica e erodem o porquê a cada mudança confiante, razoável e errada. A base de código ainda compila. Os testes ainda passam, porque os testes também codificam apenas o quê. O decaimento é invisível até um incidente torná-lo óbvio, e a essa altura a pessoa que poderia ter explicado o 47 está três empregos adiante.

Organizações conviveram com razões não documentadas porque humanos remendavam a lacuna. Esse subsídio está acabando. O mantenedor que costumava perguntar “por que isso está aqui?” antes de mudar está sendo substituído por um que presume que a ausência de resposta significa ausência de razão.

Faça Isto Agora

Escolha um sistema que você pretende entregar a agentes dentro de um ano. Para as próximas dez mudanças relevantes, exija uma razão de um parágrafo commitada junto à mudança: o que foi decidido, o que foi rejeitado, qual restrição forçou a escolha. Peça a um segundo engenheiro que confirme se o motivo declarado é o verdadeiro. Armazene esses registros onde seus agentes leem, e fuja da wiki que eles ignoram. Dez registros não vão capturar uma década de decisões, mas vão provar se sua equipe consegue capturar o porquê enquanto ele ainda existe, antes que os arquitetos que o carregam saiam pela porta.


Fontes

A Victorino ajuda organizações a capturar e governar a razão das decisões para que agentes de IA mantenham sistemas com segurança: contato@victorino.com.br | www.victorino.com.br

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