Noventa por cento dos profissionais de tecnologia ouvidos pelo relatório DORA de 2025 usam IA no trabalho, e mais de 80% dizem ter ficado mais produtivos. A conta dessa velocidade não chega no fim da sprint. Chega meses depois, com outro nome: dívida técnica.
Não é um problema de programador. É o motivo pelo qual uma funcionalidade que levava três dias passa a levar três semanas, e pelo qual uma empresa que entrega rápido descobre que não consegue mais mexer em nada sem quebrar outra coisa.
O que é dívida técnica, sem jargão
A metáfora é financeira e tem mais de 30 anos. Ward Cunningham, criador do conceito de wiki, usou a ideia em 1992 para explicar por que código apressado cobra juros. Existe um principal, que é o trabalho de arrumar o que ficou torto, e existem juros, que é o custo de conviver com o problema todos os dias. Quem só paga juros nunca sai da dívida.
Martin Fowler organizou o conceito em quatro quadrantes. A dívida pode ser deliberada, quando o time decide entregar agora e arrumar depois, ou inadvertida, quando só aparece com o aprendizado. E pode ser prudente, se o atalho tinha um motivo, ou imprudente, quando nasce de pressa, negligência ou recusa em adotar boas práticas. A inadvertida é a que costuma cobrar mais caro, porque ninguém sabe que ela existe até o problema estourar.
Pesquisadores do MIT Sloan Management Review descrevem a conta do mesmo jeito. O principal é o esforço de modernizar e refatorar o código. Os juros são o imposto de complexidade que atrasa a manutenção, atrapalha o crescimento e aumenta a chance de falha. A conclusão do estudo é incômoda: implementar código gerado por IA costuma ser um empréstimo a juros mais altos.
A escala já não é detalhe de engenharia. O CISQ estimou em 2022 que a dívida técnica acumulada no software corporativo dos Estados Unidos somava US$ 1,52 trilhão. O número é base histórica, medido antes da adoção em massa dos LLMs que escrevem código, e não o retrato do estrago da IA. Só que é ele que dá a medida do risco: se o acumulado já era esse antes, pular etapa com vibe coding, ainda mais na mão de um CEO emocionado, tende a engordar a conta. No IBM Institute for Business Value, 81% dos executivos dizem que a dívida já limita o sucesso das iniciativas de IA.
O que a IA mudou nessa conta
A IA não inventou a dívida técnica. Mudou a velocidade com que ela nasce, e isso está medido.
A GitClear acompanhou 211 milhões de linhas de código alteradas entre 2020 e 2024. A fatia de linhas refatoradas caiu de 25% em 2021 para menos de 10% em 2024, enquanto as linhas copiadas e coladas subiram de 8,3% para 12,3%: pela primeira vez na série, copiar e colar superou mover código. A edição de 2026, com 623 milhões de mudanças, achou o mesmo padrão, com a duplicação de blocos 81% maior e as linhas refatoradas em 3,8%.
O relatório DORA mediu o efeito no dia a dia. Em 2024, cada aumento de 25% na adoção de IA veio com uma queda de 7,2% na estabilidade das entregas. Em 2025, a IA passou a se correlacionar com mais volume entregue, mas a instabilidade continuou. A leitura do próprio DORA é que a ferramenta amplifica o que a equipe já é.
A percepção de quem programa também engana. Em um experimento da METR de 2025, 16 desenvolvedores experientes levaram 19% mais tempo com IA em 246 tarefas reais, mas acreditavam ter sido 20% mais rápidos. O teste usou tarefas de manutenção em projetos maduros de código aberto, um cenário em que ler o contexto inteiro pesa mais do que digitar rápido. A METR revisou o estudo em 2026 e chama os próprios dados de evidência fraca, mas o ponto sobre a autoavaliação continua de pé: sensação de produtividade não é produtividade medida.
Na segurança, a conta aparece mais rápido. A Veracode testou mais de 100 modelos em tarefas que admitem solução segura ou insegura: 45% das amostras trouxeram alguma vulnerabilidade do OWASP Top 10, e a taxa de soluções seguras seguia perto de 55% em 2026. A diferença por linguagem é grande, com 29% de aprovação em Java contra 62% em Python, o que pesa em arquitetura legada. Na mão de um CEO emocionado, a linguagem é o de menos. Um levantamento da CodeRabbit com 470 pull requests achou 1,7 vez mais problemas graves em código com coautoria de IA, e a GitGuardian registrou vazamento de segredos em 6,4% dos repositórios públicos que usam GitHub Copilot, contra 4,6% na média.
O motivo é estrutural, não é o modelo ser ruim. Um assistente de IA enxerga os arquivos que você abriu, não a arquitetura do sistema. Ele não sabe que aquele campo alimenta o faturamento nem que existe uma regra fiscal escondida em outro módulo. Como resumiu um engenheiro entrevistado pelo MIT Sloan, a IA não vê como a sua base de código é, então não segue o jeito como as coisas sempre foram feitas. Mesmo Linus Torvalds, cético conhecido do hype, já disse em público que os LLMs geram mais código genérico do que produtividade real.
É aqui que a diferença entre usar IA e fazer vibe coding vira dinheiro. No desenvolvimento assistido, a pessoa revisa, testa e entende o que aceitou. No vibe coding, o código entra porque funcionou na tela. O engenheiro Simon Willison separa os dois casos pela compreensão: com revisão e entendimento, é desenvolvimento assistido. E o MIT Sloan lembra que, com IA, um profissional júnior escreve tão rápido quanto um sênior sem ter repertório para perceber que a velocidade está criando um problema.
Como a dívida aparece, e como reduzir o valor
Ela não chega como um erro claro, chega como padrão. As entregas ficam mais lentas, um bug corrigido faz outro voltar, o suporte enche, os novos desenvolvedores demoram meses para entender o sistema e ninguém tem coragem de mexer nas partes críticas. Muitas vezes existe uma pessoa só que entende o código, e quando ela sai a empresa descobre o tamanho da conta de uma vez.
A Fast Company descreveu esse estágio em setembro de 2025 com um nome apropriado: ressaca do vibe coding. Engenheiros seniores relataram projetos que funcionavam na demonstração e ficavam difíceis de manter em produção. Há casos piores. Em julho de 2025, o agente da Replit ignorou um congelamento de código no ambiente de produção da SaaStr e apagou o banco usado em um teste do fundador, Jason Lemkin, com registros de mais de 1.200 executivos. No mesmo mês, a plataforma de desenvolvimento sketch.dev publicou o primeiro post-mortem de uma indisponibilidade causada por código escrito por LLM.
O caminho não é proibir IA, e ninguém sério está propondo isso. O que funciona é separar zonas de uso. Em protótipo, teste de ideia e script descartável, velocidade vale mais que rigor e a dívida sai barata, porque o código será jogado fora. Em sistema que processa pagamento, dado de cliente ou informação sob a LGPD, cada linha aceita sem revisão é uma parcela que vence depois. E a lei não muda de dono: quem trata o dado continua sendo o controlador, mesmo que o código tenha saído de um modelo.
Na prática, é o que a engenharia já faz quando trabalha bem: revisar código gerado como pull request de um estranho, escrever o teste antes de aceitar a sugestão, rodar análise estática e varredura de dependências, pedir lotes pequenos e marcar no repositório o que veio de IA. E reservar tempo fixo no planejamento, entre 15% e 20% de cada ciclo, para arrumar o que ficou torto. É o princípio por trás do Spec-Driven Development, que troca o improviso por uma especificação escrita antes de gerar o código.
Esse último item é o mais difícil de aprovar e o que mais paga. Ainda no IBM Institute for Business Value, empresas que colocam o custo de tratar a dívida técnica dentro do caso de negócio da IA projetam retorno sobre investimento 29% maior do que as que ignoram o assunto.
Nenhum estudo sério diz que a IA produz software pior. O que eles medem é o que acontece quando a saída é aceita sem verificação. A ferramenta acelera a digitação. A revisão continua sendo de quem assina o deploy, e essa parte não é automatizável.
Fonte: GitClear · Google DORA · Veracode · METR · MIT Sloan Management Review · IBM Institute for Business Value · CISQ · CodeRabbit · GitGuardian
