Dívida técnica de software feita por agente de IA: como medir a conta antes de 2027

A dívida técnica de software criada por agente não aparece no lead time. Três contagens que cabem numa tarde, o custo em prazo e receita, e o que mudar no code review.

A dívida nova entra pelo pull request aprovado em quatro minutos

A dívida técnica de software que vai apertar o seu próximo ano foi escrita nesta semana. Entrou no repositório por um agente, passou por uma revisão de uns quatro minutos e foi aprovada porque o teste ficou verde. Para medir o tamanho dela você não precisa de ferramenta nova, precisa de três contagens que cabem numa tarde: quanto do código mergeado nos últimos 90 dias alguém do time explica sem abrir o arquivo, quantos trechos quase iguais nasceram no período resolvendo a mesma coisa em lugares diferentes, e quantas regras de negócio entraram sem que uma pessoa tenha decidido a regra.

Essas três respostas são a sua dívida real, e ela não chega em forma de bug. Chega como prazo. A mudança que levava duas semanas passa a levar seis, o time não sabe explicar direito o motivo, e a explicação honesta é que ninguém no prédio entende o pedaço do sistema que precisa mudar. A conta cai no colo de quem abrir aquele arquivo daqui a uns catorze meses, e essa pessoa provavelmente ainda não foi contratada.

O resultado é fraco e mesmo assim o orçamento cresce

Quando ninguém sabe explicar a regra, a reunião de roadmap vira arqueologia

O CIO Dive publicou ontem que as empresas continuam ampliando a aposta em agentes de código mesmo com resultado abaixo do prometido, citando dado da McKinsey sobre o orçamento de IA estourando na maior parte delas. O estouro do orçamento é a parte que aparece na planilha. O que ele compra aparece bem depois: volume de código entrando mais rápido do que a capacidade do time de entender o que entrou.

O The New Stack publicou uma conta que dá forma a isso. Com IA, o volume de código cresceu uns 25%, e a duplicação subiu 81%. O primeiro número vira slide de trimestre. O segundo aparece no dia em que uma regra de comissão muda e você descobre que ela está escrita em quatro lugares, com três comportamentos ligeiramente diferentes, e que o teste de cada um deles passa. Já escrevi aqui sobre o que medir quando o time entrega mais código e o produto não anda, e a diferença agora é de velocidade: o mesmo erro de fundação, produzido em escala industrial.

Essa é a dívida técnica de software no sentido que importa para quem toca o negócio. Custo, prazo e receita presos num detalhe que não aparece em nenhum relatório de engenharia.

Três contagens que cabem numa tarde

1. Pegue os pull requests dos últimos 90 dias, sorteie dez e peça a quem aprovou que explique, sem abrir o arquivo, o que aquele código faz e por que foi feito daquele jeito. A proporção de "não lembro" é a sua taxa de código órfão, e quando ela passa de um terço você já está mantendo dentro de casa um sistema de terceiros.
2. Some os blocos duplicados criados no período com qualquer detector simples, e olhe só para os que nasceram depois que o agente entrou no fluxo. Duplicação antiga é história conhecida, duplicação nova é decisão que alguém aprovou esta semana sem perceber.
3. Liste as regras de negócio que mudaram comportamento no trimestre, preço, comissão, desconto, limite de crédito, elegibilidade, e ache o nome da pessoa que decidiu cada uma. Regra sem dono humano é a que trava a próxima negociação comercial, porque ninguém consegue afirmar o que o sistema faz quando o cliente pergunta.

Depois dessas três contagens a conversa deixa de ser sobre qualidade de código e passa a ser sobre risco, que é a língua em que diretoria decide. A parte da dívida que não está no código, e que é a mais cara de todas, eu tratei em como medir a dívida cognitiva do time.

A regra de comissão que ninguém lembra por que está assim

Quem abrir esse arquivo daqui a catorze meses não estava na sala quando o agente escreveu

Contei as ramificações de um serviço de preço que herdei: 1.043 condicionais. No último ano, 34 delas mudaram, perto de 3%. As outras estavam lá porque alguém, em alguma reunião, precisou atender a um caso específico e não escreveu em lugar nenhum qual era o caso. Esse serviço foi construído por gente, ao longo de anos. Um agente produz o mesmo volume em semanas, com uma diferença que muda tudo: o autor não pode ser chamado na mesa para lembrar.

Eu vivo isso dos dois lados. Sou fundador da Revin e também gerente de tecnologia numa empresa listada, cuidando de dois ecossistemas grandes onde o meu papel é abrir caminho para o time executar. O pedido que chega na minha mesa quase nunca é "refatora aquilo". É "por que isso agora demora tanto". São a mesma frase, ditas com uns doze meses de distância. E o momento de decidir onde a regra vai morar, no código, num motor de regras ou na planilha do financeiro, é antes do agente escrever, não depois.

"Mas o agente escreve os testes também"

Escreve. E é exatamente aí que a conta engorda sem disparar alarme. O teste gerado cobre o que o modelo entendeu do seu código, que é uma coisa, enquanto o que o seu negócio precisa garantir é outra. Já vi cobertura alta sustentada por teste sem expect: o arquivo roda, o número sobe no painel, e nenhuma asserção verifica nada. A métrica existe, a garantia não.

O efeito prático disso aparece em dois momentos ruins. No incidente, quando o time descobre que a suíte inteira estava verde enquanto o cliente não conseguia fechar a compra. E na mesa de auditoria, onde o código que passa no pitch reprova na due diligence porque ninguém consegue demonstrar como a regra que sustenta a receita foi validada.

O que muda no code review quando quem escreveu não é gente

Três mudanças baratas, que não exigem parar o roadmap:

• O humano que abre o pull request responde por ele como se tivesse digitado cada linha. Se não consegue explicar em voz alta, o PR volta, independente do que o teste diz.
• Toda regra de negócio nova entra com uma linha de "por quê" em português, no commit ou na descrição. Custa quinze segundos hoje e é a única coisa que sobrevive à rotatividade do time.
• Duplicação criada por conveniência do agente volta para a fila, mesmo quando funciona. É o item que parece implicância no sprint e é o que decide se a próxima mudança de comissão leva dois dias ou três semanas.

Nada disso torna o agente mais lento de um jeito que apareça no gráfico. O que muda é quem fica com a informação: o time, e não o histórico de conversa de uma ferramenta que você talvez nem use no ano que vem.

Onde esse conselho não serve

Se você tem três pessoas, nenhum contrato grande assinado e está tentando descobrir se o produto tem mercado, ignore quase tudo aqui. Nessa fase a dívida é escolha consciente e velocidade vale mais que rastreabilidade. O que vale é saber o prazo de validade dessa escolha: ele vence no dia do primeiro contrato que exige auditoria, integração com ERP de cliente grande ou SLA escrito. Aí a conta que você adiou vira o item mais caro do trimestre, e o prazo de resposta ao cliente vira aquela conversa desconfortável que eu descrevi em "quanto tempo leva" era a pergunta errada.

A pergunta que você leva para a próxima reunião de roadmap

Na próxima revisão de trimestre, antes de aprovar mais assento de agente, pergunte quanto do código que entrou nos últimos 90 dias o time consegue explicar sem abrir o arquivo. Não peça relatório, peça a conta na hora, com os dez pull requests sorteados na frente de todo mundo.

Se vier silêncio, você acabou de descobrir o tamanho da sua dívida técnica de software, e ainda em tempo de cobrar barato. Se vier resposta firme, você comprou velocidade de verdade, e vale dobrar a aposta. O que não dá é seguir decidindo pelo número que sobe no painel enquanto a parte cara cresce fora dele.