A IA vai corrigir seus bugs?

Eu estou nessa indústria de software há tempo suficiente para ver ondas de tecnologia virem e quebrarem na praia. Lembro do hype em torno do "desenvolvimento orientado a componentes", da "arquitetura orientada a serviços (SOA)" e, mais recentemente, dos "microsserviços" como a bala de prata para todos os nossos problemas. Agora, a onda do momento é a Inteligência Artificial, especificamente os Grandes Modelos de Linguagem (LLMs), e a promessa é que eles não apenas escreverão nosso código, mas também consertarão nossos erros. A Microsoft já declarou que, em abril de 2025, 30% do seu código era "escrito por IA". A ideia de um "vibe debugging", onde a IA magicamente corrige falhas, é sedutora. Mas, como um velho cético que já viu muito marketing e pouca entrega, eu me pergunto: será mesmo?

Recentemente, me deparei com um estudo acadêmico fascinante que coloca essa promessa à prova. O artigo "Do AI models help produce verified bug fixes?" (Os modelos de IA ajudam a produzir correções de bugs verificadas?) de pesquisadores do Constructor Institute of Technology na Suíça não se contentou com respostas fáceis. Eles fizeram algo que, na minha opinião, é a única forma de validar de verdade uma correção de software: usaram um ambiente de verificação formal. Esqueça os testes unitários por um momento. Estamos falando de provas matemáticas que garantem a correção do código em relação a uma especificação. Isso, meus amigos, é o padrão ouro.

A premissa do estudo era simples e elegante. Eles dividiram um grupo de programadores em dois: um com acesso a um LLM (especificamente, o GPT-40 mini) e um grupo de controle sem acesso a qualquer ferramenta de IA. A tarefa? Corrigir uma série de programas deliberadamente defeituosos. E o mais importante: a validação de cada correção era feita por um provador de programas chamado AutoProof, que verifica estaticamente se o código atende às suas "contratos" (pré-condições, pós-condições e invariantes de classe), sem executar um único teste.

Eu preciso confessar: parte de mim sorriu ao ler os resultados. Porque eles confirmaram uma suspeita que venho cultivando há tempos: a IA não é uma varinha mágica. Na verdade, os resultados foram, nas palavras dos próprios autores, "uma surpresa em comparação com o que se poderia esperar".

Vamos mergulhar no que eles descobriram e por que isso importa para todos nós que vivemos e respiramos software.

Programador vs. Programador com IA

A grande questão que o estudo se propôs a responder foi dividida em duas partes: "SE" vale a pena usar um LLM para corrigir bugs e "COMO" os programadores o utilizam de forma eficaz. Para responder a isso, eles mediram tudo: quantos bugs cada grupo resolveu, quanto tempo levaram (tanto para os sucessos quanto para os fracassos) e a experiência dos participantes.

E aqui vem o primeiro soco no estômago do hype: em uma visão geral, o grupo sem IA se saiu melhor. Sim, você leu certo. Eles resolveram mais tarefas corretamente e menos tarefas incorretamente do que seus colegas assistidos por IA. O primeiro gráfico que vi no artigo já dava o tom. Ele mostra o número de tarefas resolvidas, e em todas as métricas — mínimo, máximo e mediana — o grupo "laranja" (sem IA) superou o grupo "azul" (com IA).

A conclusão simplista, como os próprios autores admitem, seria dizer que "a ajuda de LLMs para depuração mais atrapalha do que ajuda". Claro, a realidade é mais complexa, mas esse resultado inicial já serve para colocar os pés no chão de quem acredita em soluções fáceis.

O loop de alucinação

Onde a IA parece ter falhado mais miseravelmente foi no tempo gasto em tentativas fracassadas. O estudo revelou um fenômeno preocupante que eles batizaram de "loop de alucinação". Funciona assim: a IA sugere uma correção que parece plausível, mas está fundamentalmente errada. O programador, especialmente o menos experiente, confia na sugestão, a implementa, vê que a verificação falha e, em vez de repensar a abordagem, entra em um ciclo vicioso de pequenas alterações na solução errada, cavando um buraco cada vez mais fundo.

O gráfico que mostra o tempo gasto em correções mal-sucedidas é assustador. Para as tarefas mais difíceis (da 7 à 9), o tempo que os usuários de IA gastaram perseguindo fantasmas foi drasticamente maior. Em um dos casos, na tarefa 7, a média de tempo perdido do grupo com IA chegou a mais de 35 minutos, enquanto o grupo sem IA, quando falhava, desistia muito mais rápido. Isso é um custo real. É o programador preso em um "beco sem saída de depuração", como outro estudo citado pelos autores descreve.

Esse "loop de alucinação" é o lado sombrio do que muitos chamam de "princípio da autoridade algorítmica". Tendemos a dar um peso indevido às respostas de uma máquina, especialmente quando elas são apresentadas com a confiança inabalável que os LLMs costumam exibir. Um programador experiente pode "cheirar um rato" e descartar uma sugestão absurda, mas um novato é uma presa fácil para essa confiança fabricada.

A experiência faz a diferença (e como!)

Aqui as coisas ficam ainda mais interessantes. O estudo cruzou os dados de desempenho com a experiência dos programadores, tanto a experiência geral em programação quanto a específica na linguagem utilizada (Eiffel). E os resultados são um belo tapa na cara da ideia de que a IA é o grande equalizador.

• Para os novatos: A IA realmente parece ajudar. Programadores com menos de 5 anos de experiência se beneficiaram claramente do auxílio do LLM, resolvendo mais problemas do que seus pares novatos no grupo de controle. Isso faz sentido. Para bugs mais simples, a IA pode apontar o caminho e acelerar o aprendizado.
• Para os experientes: A situação se inverte completamente. Programadores veteranos tiveram um desempenho melhor sem a IA. Minha hipótese, que ecoa a dos autores, é que nós, os "dinossauros", desenvolvemos ao longo de anos um faro apurado para bugs. Somos capazes de filtrar o ruído, identificar o "joio do trigo" em uma sugestão de código e, muitas vezes, o processo de consultar a IA, analisar sua resposta (e suas potenciais alucinações) acaba sendo mais lento do que apenas resolver o problema nós mesmos.

Há uma exceção notável: programadores com vasta experiência na linguagem específica do problema (Eiffel, no caso) parecem ser os que mais se beneficiam da IA. Isso sugere que a combinação de um conhecimento profundo da linguagem com a capacidade de usar a IA como uma ferramenta de brainstorming é a fórmula do sucesso. Esses profissionais não pedem uma solução, eles dialogam com a ferramenta.

Os padrões de uso: do copiador ao colaborador

A parte mais rica do estudo, para mim, veio da análise qualitativa, onde os pesquisadores assistiram a quase 50 horas de gravações das sessões dos programadores. Isso permitiu que eles identificassem "personalidades" no uso da IA, que eu achei geniais e totalmente reconhecíveis.

1. O independente: Simplesmente não usa a IA, mesmo quando disponível.
2. O preconceituoso: Já tem uma hipótese ("o bug deve estar no contrato") e usa a IA apenas para confirmar seu viés, muitas vezes levando a ferramenta para o caminho errado.
3. O pesquisador: Usa o LLM como um Google glorificado, para tirar dúvidas pontuais sobre a linguagem ("O que significa a palavra-chave detachable?"), mas não pede correções de código.
4. O copiador (the copy-paster): O mais perigoso. Pede o código, copia e cola a resposta sem muita análise e é a vítima preferencial dos "loops de alucinação". O estudo observou que essa era uma abordagem comum, mas com baixo retorno.
5. O seguidor: Aceita as sugestões da IA e as experimenta uma a uma, mas ainda trabalha a partir delas, em vez de aceitá-las cegamente.
6. O colaborador: O padrão de maior sucesso. Este programador trata a IA como um par, um parceiro de "pair programming". Ele fornece o código, o output das ferramentas de verificação, interpreta as sugestões, as adapta e enriquece os prompts progressivamente. Este é o usuário que entende que a IA é uma ferramenta, não um oráculo. A taxa de sucesso observada para os "colaboradores" foi de 91%.

Essa taxonomia é ouro puro. Ela muda o foco da pergunta "A IA é boa para debugging?" para "Como ser bom em usar a IA para debugging?". A conclusão dos autores, e a minha, é que a IA favorece os diligentes. Não há almoço grátis. Esperar que um LLM conserte seu código magicamente é uma receita para a frustração e para o fracasso.

Limites e outras realidades

Apesar de eu ter adorado este estudo, meu lado "provocador" precisa apontar algumas questões. O próprio artigo é honesto sobre suas limitações, principalmente o número relativamente pequeno de participantes (25 pessoas), o que impede análises estatísticas mais robustas.

A maior limitação, no meu ponto de vista, é o uso de um único LLM, o GPT-40 mini. O mundo dos modelos de IA é vasto e evolui rapidamente. Outros estudos e benchmarks mais recentes, como os compilados por publicações como a PromptLayer e a ApX Machine Learning, mostram uma competição acirrada entre modelos como a série Claude da Anthropic, Gemini do Google e as próprias evoluções do GPT da OpenAI. Alguns benchmarks de codificação, como o SWE-bench, sugerem que modelos como o Claude 4 podem ter uma performance superior em tarefas de engenharia de software do mundo real.

A pesquisa no campo do Reparo Automático de Programas (APR) também é mais ampla. Há abordagens que não se baseiam apenas em prompts, mas em um "estilo conversacional", onde a IA e as ferramentas de feedback interagem em um ciclo para refinar a solução. Outros exploram a combinação de LLMs com técnicas mais clássicas de análise de programas. O estudo que analisamos foca em um cenário muito específico: um programador, um bug, uma ferramenta de verificação formal e um LLM específico. É um recorte valioso, mas não é toda a paisagem.

Ainda assim, a principal lição do estudo transcende o modelo de IA utilizado. A descoberta do "loop de alucinação", os diferentes padrões de uso e o impacto da experiência do desenvolvedor são insights comportamentais e de processo. Eles não são sobre a capacidade de um algoritmo específico, mas sobre a interação humano-computador em uma tarefa criativa e complexa como a depuração de software. E isso, para mim, é o que torna esta pesquisa tão relevante, independentemente de qual LLM esteja no topo dos benchmarks amanhã.

Conclusão óbvia: a ferramenta não faz o artesão

Então, a IA vai tomar o nosso lugar na arte de caçar e esmagar bugs? A resposta, baseada neste estudo e na minha própria experiência, é um retumbante não. Pelo menos, não da forma como o hype nos faz acreditar.

O que estamos vendo é a emergência de uma ferramenta poderosa, mas que exige habilidade, discernimento e, acima de tudo, pensamento crítico. A IA não substitui o raciocínio, ela o aumenta — mas apenas se você já tiver uma base sólida de raciocínio para aumentar. Ela pode acelerar o experiente e guiar o novato, mas também pode aprisionar o incauto em labirintos de código sem sentido.

A lição deste estudo é clara como cristal: a IA ajuda os diligentes. Ela beneficia o "Colaborador", aquele que a trata como um parceiro de sparring intelectual, e pune o "Copiador", que busca atalhos e respostas fáceis. Ela nos força a sermos melhores engenheiros, a entendermos profundamente o problema e a avaliar criticamente as soluções propostas, venham elas de um cérebro de silício ou de carbono.

No final das contas, a pergunta mais importante talvez não seja o que a IA pode fazer por nós, mas o que nós estamos dispostos a fazer para usar a IA bem. A tecnologia pode mudar, os modelos podem evoluir, mas a necessidade de um programador pensante, crítico e diligente ao leme do processo parece mais fundamental do que nunca.

E você, de que lado dessa história você se vê: o do Copiador, esperando a mágica acontecer, ou o do Colaborador, pronto para arregaçar as mangas e pensar junto com a máquina?

Fonte: artigo completo aqui.