A Dívida de Verificação: O Gap Sistêmico Entre Desconfiança e Disciplina na IA

Existe um número que deveria tirar o sono de qualquer líder de tecnologia: 96% dos desenvolvedores não confiam totalmente no código gerado por IA — mas apenas 48% sempre verificam esse código antes de comitar.

Esse gap de 48 pontos percentuais não é uma curiosidade estatística. É uma dívida. E como toda dívida, ela se acumula com juros.

A Anatomia do Gap

O relatório State of Code 2026 da Sonar, publicado em janeiro, pesquisou 1.149 desenvolvedores. Os números desenham um retrato que qualquer gestor de engenharia deveria reconhecer — porque provavelmente descreve sua equipe.

A desconfiança é quase universal: apenas 2,6% dos desenvolvedores experientes dizem “confiar muito” no output da IA. Mas a verificação sistemática não acompanha a desconfiança. Mais da metade dos desenvolvedores — 52% — às vezes comita código de IA sem verificação completa.

A pergunta óbvia é: se quase ninguém confia, por que metade não verifica?

A resposta não é preguiça. É estrutura — ou a falta dela.

Dívida de Verificação: O Conceito

Dívida técnica é um conceito que todo engenheiro conhece: atalhos tomados hoje que criam retrabalho amanhã. A dívida de verificação é sua prima menos conhecida, mais perigosa.

Quando um desenvolvedor escreve código, mesmo que ruim, ele entende o que escreveu. Quando precisa depurar seis meses depois, há uma memória — uma lógica de origem que guia a investigação.

Código gerado por IA que entra no repositório sem verificação adequada não tem esse lastro. O desenvolvedor que comitou não escreveu a lógica. Não entende as premissas implícitas. Não sabe por que o modelo escolheu aquela abordagem e não outra. Quando esse código falha — e 40 a 48% do código gerado por IA contém vulnerabilidades de segurança, segundo a Veracode — o debugging se torna arqueologia: escavar intenções que nunca existiram.

A dívida de verificação se acumula silenciosamente. Cada comit não verificado adiciona código ao sistema que ninguém realmente entende. E diferente da dívida técnica tradicional, que geralmente é localizada, a dívida de verificação é difusa — pode estar em qualquer parte do codebase, porque ninguém sabe quais trechos foram verificados e quais não foram.

Os Dados Que Provam Que É Sistêmico

Se fosse apenas um problema de disciplina individual, esperaríamos ver uma distribuição normal: alguns desenvolvedores verificam menos, a maioria verifica adequadamente. Mas os dados contam outra história.

O volume é ingovernável a olho nu. Em 2023, 6% do código era gerado ou assistido por IA. Em 2026, são 42%. A projeção é 65% até 2027. Nenhum processo de revisão manual escala 7x em três anos sem mudança estrutural.

A revisão demanda mais esforço, não menos. 38% dos desenvolvedores relatam que revisar código de IA exige mais esforço que revisar código humano. 59% classificam o esforço como “moderado” ou “substancial”. Código de IA não é código humano mais rápido — é um tipo diferente de artefato, com modos de falha diferentes.

A verificação que acontece funciona. A LinearB analisou 8,1 milhões de pull requests de 4.800 equipes. PRs gerados por IA têm taxa de aceitação de 32,7%. PRs manuais: 84,4%. Essa diferença de 51,7 pontos percentuais é a evidência empírica de que a verificação captura problemas reais. Mas revela também que 67,3% dos PRs de IA são rejeitados ou precisam de retrabalho significativo. Verificação funciona — quando acontece.

O sistema não facilita. PRs de IA esperam 4,6 vezes mais para serem revisados que PRs manuais. Revisores humanos estão sobrecarregados — e naturalmente priorizam o que entendem melhor.

Nenhum desses dados aponta para falha de caráter dos desenvolvedores. Todos apontam para falha de infraestrutura organizacional.

A Assimetria Oculta de Senioridade

Há um dado no estudo do METR de 2025 que merece mais atenção do que recebeu.

Desenvolvedores seniores gastam em média 4,3 minutos revisando cada sugestão de IA. Desenvolvedores juniores gastam 1,2 minuto.

A diferença de 3,6x não é velocidade de leitura. É profundidade de análise. Seniores questionam premissas, verificam edge cases, avaliam implicações arquiteturais. Juniores — que muitas vezes não têm repertório para identificar erros conceituais sutis — aprovam mais rápido justamente porque verificam menos.

Isso cria uma assimetria de qualidade invisível nos dados agregados. Quando sua empresa reporta que “80% do código de IA é verificado antes do deploy”, o número não distingue entre verificação substantiva de 4,3 minutos e carimbo de 1,2 minuto. Mas a diferença na qualidade do código que chega a produção é enorme.

O estudo do METR revelou outro dado que complica ainda mais: desenvolvedores usando IA foram 19% mais lentos nas tarefas — mas acreditavam ser 24% mais rápidos. Se a percepção de velocidade é enviesada, a percepção de qualidade da verificação provavelmente também é.

O Problema do “Quase Certo”

A pesquisa do Stack Overflow de 2025, com mais de 49 mil desenvolvedores, identificou o principal desafio: 66% citam “soluções que estão quase certas, mas não exatamente” como o maior problema com código de IA.

“Quase certo” é mais perigoso que “obviamente errado”.

Código obviamente errado não compila, não passa nos testes, gera erros visíveis. Alguém percebe. Código quase certo compila, passa nos testes superficiais, parece funcionar — e falha em produção, em edge cases, sob carga, em contextos que o modelo não previu.

É exatamente esse tipo de defeito que revisão casual não captura. E é exatamente esse tipo de defeito que código de IA produz com mais frequência. Os dados da Veracode são específicos: 86% do código gerado por IA não protege contra XSS; 88% não protege contra log injection. São vulnerabilidades que funcionam perfeitamente em testes unitários básicos — e explodem em produção.

A confiança geral dos desenvolvedores em IA caiu de mais de 70% positiva em 2023-2024 para 60% em 2025. Não porque a IA ficou pior — ficou melhor. Mas porque a experiência acumulada revelou que “melhor” não significa “confiável”.

Shadow AI: O Que Você Não Enxerga Não Pode Governar

Há um dado no relatório da Sonar que é fácil de passar despercebido: 35% dos desenvolvedores usam contas pessoais de IA, não corporativas.

Isso significa que mais de um terço do código assistido por IA na sua organização pode estar sendo gerado por ferramentas que sua equipe de segurança não monitora, que seus processos de compliance não cobrem, que suas políticas de governança não alcançam.

E esse código está indo para produção. 73% dos desenvolvedores usam IA em aplicações voltadas ao cliente. 58% em serviços críticos de negócio.

Não é um risco hipotético. É um risco em produção, agora, em mais de um terço dos casos fora de qualquer visibilidade organizacional.

Por Que Isso É Falha de Governança, Não de Disciplina

A narrativa fácil é culpar os desenvolvedores. “Se não confiam, deveriam verificar.” Mas essa narrativa ignora que verificação sistemática requer infraestrutura que a maioria das organizações simplesmente não construiu.

Não há processos de revisão adaptados para código de IA. Revisar código de IA não é o mesmo que revisar código humano — os erros são diferentes, os padrões são diferentes, as vulnerabilidades são diferentes. Quantas organizações têm checklists de revisão específicos para código gerado? Quantas treinaram seus revisores nos modos de falha de modelos de linguagem?

Não há métricas de verificação. A maioria das organizações sabe quantos PRs são abertos por semana. Quantas sabem qual percentual do código de IA é verificado antes do merge? Qual o tempo médio de revisão? Qual a taxa de rejeição por tipo de geração?

Não há orçamento de tempo para verificação. Se 42% do código é gerado por IA e a revisão desse código demanda mais esforço, o tempo total necessário para verificação aumentou significativamente. Alguma organização recalculou as estimativas de sprint para incluir esse custo?

Tariq Shaukat, CEO da Sonar, articula o problema com precisão: enquanto a IA tornou a geração de código praticamente sem esforço, criou um gap crítico de confiança entre output e deployment. Esse gap não se fecha com apelos à disciplina. Fecha com processo, ferramentas e governança.

O Padrão Que Conhecemos

Se o gap 96/48 parece familiar, é porque espelha um padrão que engenheiros de software conhecem bem: o padrão da dívida técnica.

Todo desenvolvedor sabe que testes são importantes. Todo gestor concorda que qualidade importa. E todo sprint termina com a mesma decisão implícita: entregar a feature agora, escrever os testes depois. “Depois” nunca chega. A dívida se acumula. Eventualmente, o sistema se torna frágil demais para modificar com segurança.

A dívida de verificação segue o mesmo ciclo. Todo desenvolvedor sabe que código de IA deveria ser verificado. Todo gestor concorda que verificação importa. E todo sprint termina com a mesma decisão implícita: comitar agora, verificar depois. A diferença é que dívida de verificação se acumula mais rápido — porque IA gera código muito mais rápido do que humanos, e cada linha não verificada é uma linha que ninguém na equipe realmente entende.

O Que Fazer Com Isso

Se você lidera tecnologia em uma organização que usa IA para desenvolvimento — e em 2026, isso significa praticamente toda organização — três ações que endereçam a causa raiz.

Primeiro, trate verificação como infraestrutura, não como hábito. Hábitos dependem de disciplina individual e falham sob pressão. Infraestrutura funciona independente da motivação. Isso significa: gates automatizados no pipeline de CI/CD que identificam código gerado por IA; checklists de revisão específicos para artefatos de IA; métricas de cobertura de verificação ao lado de métricas de cobertura de testes.

Segundo, elimine o shadow AI. Se 35% dos desenvolvedores usam contas pessoais, o primeiro passo é fornecer ferramentas corporativas adequadas — e o segundo é ter visibilidade sobre o que está sendo gerado. Não para vigiar, mas para governar. Código que não é visível não pode ser verificado.

Terceiro, recalibre as expectativas de velocidade. Se a revisão de código de IA demanda mais esforço e o volume de código de IA cresce exponencialmente, o tempo dedicado à verificação precisa crescer proporcionalmente. Isso não é ineficiência — é o custo real do desenvolvimento assistido por IA. Organizações que ignoram esse custo não são mais rápidas; são mais endividadas.

Os dados são claros: a IA tornou a geração de código fácil e a verificação de código difícil. Organizações que investiram pesadamente no primeiro sem investir proporcionalmente no segundo estão acumulando uma dívida que, como toda dívida, terá que ser paga — com juros.

A questão não é se sua equipe confia no código da IA. A questão é se sua organização construiu a infraestrutura para que a desconfiança se traduza em verificação sistemática.

Se a resposta é não, o gap 96/48 é o menor dos seus problemas.

Fontes

Sonar. “2026 State of Code Developer Survey.” Janeiro 2026. 1.149 desenvolvedores pesquisados.
LinearB. “Software Engineering Benchmarks 2026.” 8,1 milhões de pull requests, 4.800 equipes.
Veracode. “GenAI Code Security Report.” 2025. Análise de vulnerabilidades em código gerado por IA.
METR. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” 2025.
Stack Overflow. “Developer Survey 2025.” Mais de 49.000 desenvolvedores pesquisados.