Código de IA parece melhor na revisão e quebra mais em produção. Isso é dívida de agente

TV
Thiago Victorino
6 min de leitura
Código de IA parece melhor na revisão e quebra mais em produção. Isso é dívida de agente

Dois números do round-up de junho de 2026 da New Relic ficam lado a lado e se recusam a fechar. 93,5% dos líderes avaliam o código gerado por IA como de qualidade superior no momento da revisão. 78% relatam mais incidentes em produção depois que esse mesmo código entra no ar. O veredito da revisão e o veredito da produção descrevem o mesmo código e chegam a conclusões opostas.

Trate os percentuais como direcionais. É um round-up de fornecedor, a amostra e o método da pesquisa permanecem sem publicação, e todo número aqui é afirmação da New Relic, sem validação de pesquisa independente. A direção ainda importa, porque ela aponta para um problema no nível do mecanismo, bem longe de qualquer ruído de arredondamento. Quando aquilo que passa na revisão é aquilo que quebra em produção, a revisão deixou de prever a produção. O sinal em que a engenharia confia e o sinal que o cliente sente se descolaram.

O Que os Dois Sinais Costumavam Compartilhar

Por boa parte da história do software, qualidade de revisão e estabilidade em produção estiveram correlacionadas por um único mecanismo: o mesmo humano que aprovava o código entendia como ele iria se comportar. Um revisor que lê um diff está construindo um modelo mental do runtime, e é esse modelo que pega o nulo que chega às 3 da manhã ou a query que varre uma tabela inteira em escala. A revisão era um proxy da produção porque o revisor carregava a produção na cabeça.

O código gerado por IA quebra esse proxy de um jeito específico. O código parece de qualidade superior porque é bem formado: nomes consistentes, estrutura plausível, padrões idiomáticos, comentários organizados. Essas são exatamente as características de superfície que uma revisão rápida premia. O sinal da revisão mede legibilidade e correção local. Ele nunca mediu comportamento distribuído, tempestade de retentativas, esgotamento do pool de conexões ou o timeout de terceiro que só dispara sob carga. No código escrito por humanos, a bagunça do diff era ela mesma informação; o revisor desacelerava onde o código parecia incerto. A IA remove a incerteza visível e mantém intacta a incerteza de runtime.

Então os 93,5% são honestos. Os revisores não estão errados ao dizer que o código parece melhor. Eles estão medindo a coisa errada com mais confiança do que antes. Já fizemos um argumento próximo sobre por que os sinais de qualidade empresarial no código de LLM precisam de medição própria: as métricas de superfície que parecem tranquilizadoras não são as que governam o runtime.

Dívida de Agente É o Passivo Nomeado

Dívida técnica é o custo dos atalhos que você consegue ver no código. Dívida de agente é diferente. É o custo que se acumula quando a telemetria de produção nunca volta para o loop que gerou o código. Um agente escreve uma função, a função passa na revisão, entra no ar, causa incidentes, e o sinal do incidente morre num painel que o agente nunca lê e que o próximo prompt nunca referencia. O agente escreve a próxima função com zero conhecimento de que a anterior está acordando alguém de madrugada.

Esse é o passivo, e ele é estrutural: a IA escreve código dentro de um loop cujo caminho de volta foi cortado. 62% dos times, pelos números da New Relic, colocam código gerado por IA no ar sem verificação manual. Some isso a um sinal de revisão que não prevê mais a produção e você terá colocado no ar um sistema que não aprende nada com as próprias falhas. Cada deploy soma a um saldo que se compõe, porque o mesmo ponto cego produz o próximo defeito, e o próximo.

O custo não é teórico. A New Relic estima o preço de uma indisponibilidade em cerca de 2 milhões de dólares por hora, e relata esse valor praticamente dobrando ano a ano. Valendo ou não esse montante exato para o seu negócio, o que conta é o formato: o custo de incidente está subindo enquanto a etapa de verificação que costumava contê-lo está sendo pulada em escala.

Observabilidade Vira a Camada de Confiança

95% dos líderes no round-up avaliam observabilidade como importante para código gerado por IA, o número de maior convicção do conjunto. A parte interessante é o que essa convicção implica. Se a revisão não prevê mais a produção, então a telemetria de produção é o único sinal que sobrou para dizer se o código de fato funciona. A observabilidade deixa de ser o lugar para onde você olha depois de um incidente e passa a ser o lugar onde a confiança é estabelecida ou negada.

Isso reposiciona para que serve uma plataforma de observabilidade. Um painel é um humano lendo telas. A camada de confiança é outra coisa: comportamento de produção, estruturado e roteado de volta para o sistema que escreve e aprova código, de modo que a próxima geração fique ancorada no que a geração anterior de fato fez na frente dos usuários. A própria direção de produto da New Relic se lê como uma aposta exatamente nisso. O Autopilot faz investigação autônoma de incidentes, e o Ground Truth expõe dados de observabilidade num formato otimizado para consumo por IA em vez de painéis para humanos. Ambos são tentativas de fechar o caminho de volta, de tornar a telemetria de produção legível para os agentes em vez de deixá-la encalhada numa tela.

Se esses produtos específicos entregam é uma questão separada de se a direção está certa. A direção está certa. O mesmo raciocínio levou o harness de verificação para dentro da resposta a incidentes e molda até onde um postmortem de IA pode responsavelmente alcançar: quando o loop fecha, o runtime deixa de ser um lugar que você visita depois do estrago e passa a ser um lugar que ensina.

Faça Isto Agora

Escolha o seu serviço de maior tráfego e meça uma coisa esta semana: a correlação entre o seu sinal de aprovação em revisão e a sua taxa de incidentes pós-deploy para mudanças assistidas por IA. Se as aprovações estão altas e os incidentes estão subindo sobre o mesmo código, você confirmou dívida de agente localmente, com os seus próprios números em vez dos da New Relic. Essa medição é a versão mais barata da camada de confiança, e ela diz se o seu processo de revisão ainda prevê alguma coisa.

Depois feche um loop. Pegue o sinal de incidente desse serviço e roteie-o para algum lugar que a próxima mudança consiga enxergar: para dentro do contexto do prompt, do template de PR, da checagem pré-merge, qualquer lugar onde o caminho de volta hoje termina num painel sem saída. Um loop fechado em um serviço já é prova de que a produção consegue ensinar o código. Dívida de agente se compõe no escuro. A correção é parar de gerar no escuro.


Fontes

A Victorino ajuda líderes de engenharia e operação a fechar o caminho de volta entre a telemetria de produção e o loop de geração de código, para que a revisão pare de mentir sobre a produção: 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