{"id":1322,"date":"2026-10-12T04:01:29","date_gmt":"2026-10-12T07:01:29","guid":{"rendered":"https:\/\/adrianosantostreina.com.br\/blog\/debugging-com-ia-tecnicas-que-economizam-horas-3\/"},"modified":"2026-10-12T04:01:38","modified_gmt":"2026-10-12T07:01:38","slug":"debugging-com-ia-tecnicas-que-economizam-horas-3","status":"publish","type":"post","link":"https:\/\/adrianosantostreina.com.br\/blog\/debugging-com-ia-tecnicas-que-economizam-horas-3\/","title":{"rendered":"O Stack Trace N\u00e3o Mente, Mas o Modelo Pode Inventar: T\u00e9cnicas de Debugging com IA que Realmente Economizam Horas"},"content":{"rendered":"

S\u00e3o dezenove horas de uma sexta-feira. Um teste de integra\u00e7\u00e3o que passava h\u00e1 meses come\u00e7ou a falhar de forma intermitente \u2014 \u00e0s vezes verde, \u00e0s vezes vermelho, sem nenhuma mudan\u00e7a aparente no c\u00f3digo. Voc\u00ea cola o stack trace inteiro no chat da IA, pede para ela “resolver o problema”, e recebe de volta um patch que silencia o sintoma: um try\/catch<\/code> gen\u00e9rico envolvendo a chamada que falha, ou um retry<\/code> arbitr\u00e1rio de tr\u00eas tentativas. O teste passa na pr\u00f3xima execu\u00e7\u00e3o. Duas semanas depois, o mesmo bug reaparece em produ\u00e7\u00e3o, agora sem stack trace nenhum, porque o catch<\/code> engoliu a exce\u00e7\u00e3o.<\/p>\n

Esse cen\u00e1rio \u00e9 mais comum do que parece, e n\u00e3o \u00e9 culpa da IA em si \u2014 \u00e9 culpa de como ela foi usada. Debugging \u00e9 a tarefa mais afetada por prompts mal estruturados, porque o modelo tem um incentivo estrutural para devolver “uma resposta que resolve”, mesmo quando a resposta correta seria “preciso de mais informa\u00e7\u00e3o antes de propor qualquer coisa”. Este artigo apresenta t\u00e9cnicas concretas para transformar a IA em uma ferramenta de investiga\u00e7\u00e3o de causa raiz, n\u00e3o em um gerador de remendos \u2014 com exemplos de c\u00f3digo e armadilhas que voc\u00ea vai reconhecer da pr\u00f3pria rotina.<\/p>\n

Por que o debugging \u00e9 diferente da gera\u00e7\u00e3o de c\u00f3digo<\/h2>\n

Quando voc\u00ea pede para a IA escrever uma fun\u00e7\u00e3o nova, o espa\u00e7o de solu\u00e7\u00f5es corretas \u00e9 relativamente amplo: existem v\u00e1rias implementa\u00e7\u00f5es aceit\u00e1veis para o mesmo requisito. Debugging \u00e9 o oposto. Existe exatamente uma causa raiz, e qualquer coisa que n\u00e3o seja ela \u00e9, na melhor das hip\u00f3teses, in\u00fatil, e na pior, um disfarce que atrasa a descoberta do problema real.<\/p>\n

Isso muda completamente a forma como voc\u00ea deve conduzir a conversa. Segundo o artigo Desenvolvimento de Software Assistido por IA: Princ\u00edpios, Pr\u00e1ticas e o Futuro da Engenharia<\/a>, a IA reduz significativamente o tempo gasto em tarefas repetitivas de codifica\u00e7\u00e3o \u2014 mas essa economia s\u00f3 se mant\u00e9m quando o problema est\u00e1 bem delimitado. Em debugging, a delimita\u00e7\u00e3o do problema \u00e9 o pr\u00f3prio trabalho dif\u00edcil, e \u00e9 justamente a\u00ed que a maioria dos desenvolvedores pula etapas.<\/p>\n

O vi\u00e9s da resposta plaus\u00edvel<\/h3>\n

Modelos de linguagem s\u00e3o otimizados para produzir texto coerente e convincente, n\u00e3o para admitir incerteza. Diante de um stack trace incompleto, a tend\u00eancia \u00e9 o modelo preencher as lacunas com a explica\u00e7\u00e3o estatisticamente mais prov\u00e1vel \u2014 que nem sempre \u00e9 a explica\u00e7\u00e3o correta para o seu caso espec\u00edfico. Isso \u00e9 equivalente a um m\u00e9dico que, sem pedir exames, j\u00e1 come\u00e7a a prescrever rem\u00e9dio com base nos sintomas mais comuns da popula\u00e7\u00e3o em geral, ignorando o hist\u00f3rico do paciente \u00e0 sua frente.<\/p>\n

\ud83d\udca1 Dica do Mestre:<\/strong> uma pesquisa de Stanford, comentada no post sobre produtividade com IA sem m\u00e9todo<\/a>, mostra que usar IA sem um processo estruturado n\u00e3o aumenta a produtividade \u2014 em debugging esse efeito \u00e9 ainda mais evidente, porque o custo de uma corre\u00e7\u00e3o errada n\u00e3o \u00e9 apenas o tempo perdido, \u00e9 o tempo perdido mais a confian\u00e7a abalada no pr\u00f3ximo diagn\u00f3stico.<\/p><\/blockquote>\n

T\u00e9cnica 1: isolar o contexto antes de pedir diagn\u00f3stico<\/h2>\n

A primeira economia de horas vem de resistir ao impulso de colar o stack trace inteiro e perguntar “por que isso est\u00e1 acontecendo?”. Em vez disso, reduza o problema ao menor reprodutor poss\u00edvel antes de envolver a IA. Isso vale tanto para humanos quanto para modelos, mas para modelos \u00e9 ainda mais cr\u00edtico, porque contexto excessivo e irrelevante dilui a aten\u00e7\u00e3o do modelo sobre o que de fato importa.<\/p>\n

Um exemplo pr\u00e1tico em Node.js: imagine um endpoint que ocasionalmente retorna dados de outro usu\u00e1rio sob carga concorrente.<\/p>\n

\/\/ Antes: contexto difuso, f\u00e1cil de confundir a IA\napp.get('\/profile', async (req, res) => {\n  const userId = req.session.userId;\n  const cache = await getCachedProfile(userId);\n  if (cache) return res.json(cache);\n  const profile = await db.profiles.findOne({ userId });\n  cacheStore[userId] = profile; \/\/ suspeito: vari\u00e1vel de escopo de m\u00f3dulo\n  res.json(profile);\n});\n<\/code><\/pre>\n
Em vez de colar a rota inteira com middlewares, autentica\u00e7\u00e3o e logging, isole a hip\u00f3tese: “este cacheStore<\/code> \u00e9 uma vari\u00e1vel de m\u00f3dulo compartilhada entre requisi\u00e7\u00f5es concorrentes; existe algum cen\u00e1rio de race condition onde o userId<\/code> de uma requisi\u00e7\u00e3o sobrescreve o cache antes de outra terminar de ler?”. Um prompt assim direciona o modelo para analisar concorr\u00eancia, n\u00e3o para procurar erros de sintaxe ou de tipagem que n\u00e3o existem.<\/p>\n
\/\/ Depois: reprodutor m\u00ednimo isolado\nconst cacheStore = {};\n\nasync function handleRequest(userId, delay) {\n  await sleep(delay);\n  const profile = await fakeDb(userId);\n  cacheStore[userId] = profile;\n  return cacheStore[userId];\n}\n\n\/\/ Simulando duas requisi\u00e7\u00f5es concorrentes\nPromise.all([\n  handleRequest('user-1', 50),\n  handleRequest('user-2', 10)\n]).then(console.log);\n<\/code><\/pre>\n
Com esse reprodutor isolado, o diagn\u00f3stico fica objetivo: se cacheStore<\/code> for de fato por usu\u00e1rio (chave \u00fanica), a race condition n\u00e3o est\u00e1 ali \u2014 o problema est\u00e1 em outro lugar, como um middleware de sess\u00e3o compartilhando estado entre requisi\u00e7\u00f5es. A IA s\u00f3 consegue ser precisa quando o espa\u00e7o de busca est\u00e1 reduzido.<\/p>\n
T\u00e9cnica 2: pe\u00e7a hip\u00f3teses, n\u00e3o solu\u00e7\u00f5es<\/h2>\n
A mudan\u00e7a de prompt mais efetiva em debugging \u00e9 trocar “conserte isso” por “liste as tr\u00eas hip\u00f3teses mais prov\u00e1veis para esse comportamento, em ordem de probabilidade, e para cada uma, diga qual log ou teste eu preciso adicionar para confirm\u00e1-la ou descart\u00e1-la”. Essa formula\u00e7\u00e3o for\u00e7a o modelo a expor seu racioc\u00ednio antes de agir, e te d\u00e1 a chance de interromper um caminho de investiga\u00e7\u00e3o ruim antes que ele vire c\u00f3digo.<\/p>\n
Prompt:\n\"Este teste falha de forma intermitente, aproximadamente 1 em cada 20 execu\u00e7\u00f5es.\nStack trace: [cole aqui]\nC\u00f3digo da fun\u00e7\u00e3o testada: [cole aqui]\nC\u00f3digo do teste: [cole aqui]\n\nN\u00e3o proponha corre\u00e7\u00e3o ainda.\nListe as 3 hip\u00f3teses mais prov\u00e1veis para a falha intermitente,\nordenadas por probabilidade, e para cada uma indique:\n1. Um log espec\u00edfico que eu deveria adicionar para confirmar\n2. Um teste isolado que reproduziria o problema de forma determin\u00edstica\"\n<\/code><\/pre>\n
Esse formato tem um efeito colateral valioso: ele exp\u00f5e quando o pr\u00f3prio modelo est\u00e1 incerto. Se as tr\u00eas hip\u00f3teses forem gen\u00e9ricas (“pode ser race condition”, “pode ser timeout de rede”, “pode ser ordem de execu\u00e7\u00e3o dos testes”), isso \u00e9 um sinal de que falta contexto, n\u00e3o que a IA \u00e9 ruim em debugging. \u00c9 a deixa para voc\u00ea voltar \u00e0 T\u00e9cnica 1 e isolar mais o problema antes de prosseguir.<\/p>\n
Exemplo com Python: falha intermitente em testes ass\u00edncronos<\/h3>\n
import pytest\nimport asyncio\n\n@pytest.mark.asyncio\nasync def test_concurrent_writes():\n    store = SharedStore()\n    tasks = [store.write(f\"key-{i}\", i) for i in range(100)]\n    await asyncio.gather(*tasks)\n    assert len(store.data) == 100  # falha ~5% das vezes\n<\/code><\/pre>\n
Pedir hip\u00f3teses aqui, em vez de corre\u00e7\u00e3o direta, costuma apontar para o candidato \u00f3bvio \u2014 aus\u00eancia de lock em uma estrutura de dados compartilhada \u2014 mas tamb\u00e9m pode revelar candidatos menos \u00f3bvios, como o event loop do pytest-asyncio<\/code> sendo recriado entre execu\u00e7\u00f5es, ou uma condi\u00e7\u00e3o de corrida no pr\u00f3prio gather<\/code> se write<\/code> n\u00e3o for verdadeiramente at\u00f4mico. A IA s\u00f3 chega a essas alternativas quando \u00e9 instru\u00edda a n\u00e3o se comprometer com a primeira explica\u00e7\u00e3o plaus\u00edvel.<\/p>\n
T\u00e9cnica 3: use a IA para instrumentar, n\u00e3o s\u00f3 para explicar<\/h2>\n
Uma das aplica\u00e7\u00f5es mais subestimadas de IA em debugging n\u00e3o \u00e9 pedir a causa do bug, \u00e9 pedir instrumenta\u00e7\u00e3o cir\u00fargica. Em sistemas legados ou em c\u00f3digo que voc\u00ea n\u00e3o escreveu, adicionar logging manual em todos os pontos suspeitos consome tempo desproporcional. Pe\u00e7a \u00e0 IA para gerar pontos de instrumenta\u00e7\u00e3o tempor\u00e1rios, com remo\u00e7\u00e3o f\u00e1cil.<\/p>\n
\/\/ Prompt: \"Adicione logging tempor\u00e1rio marcado com DEBUG_TEMP\n\/\/ em todos os pontos onde este objeto \u00e9 mutado, para eu rastrear\n\/\/ a origem da muta\u00e7\u00e3o inesperada\"\n\nclass OrderProcessor {\n  process(order) {\n    console.log('[DEBUG_TEMP] entrada:', JSON.stringify(order));\n    this.applyDiscount(order);\n    console.log('[DEBUG_TEMP] p\u00f3s-desconto:', JSON.stringify(order));\n    this.applyTax(order);\n    console.log('[DEBUG_TEMP] p\u00f3s-imposto:', JSON.stringify(order));\n    return order;\n  }\n}\n<\/code><\/pre>\n
O ganho de produtividade aqui vem da conven\u00e7\u00e3o: marcar cada log com uma tag \u00fanica (DEBUG_TEMP<\/code>) permite que, ao final da investiga\u00e7\u00e3o, voc\u00ea rode um \u00fanico comando de busca e remo\u00e7\u00e3o \u2014 grep -rn \"DEBUG_TEMP\"<\/code> \u2014 sem risco de esquecer um console.log<\/code> perdido em produ\u00e7\u00e3o, erro cl\u00e1ssico que todo desenvolvedor j\u00e1 cometeu pelo menos uma vez.<\/p>\n
Em Delphi: instrumentando um pipeline de processamento em lote<\/h3>\n
O mesmo princ\u00edpio se aplica fora do universo JavaScript. Em um sistema legado Delphi processando lotes financeiros, a instrumenta\u00e7\u00e3o tempor\u00e1ria segue a mesma l\u00f3gica de marca\u00e7\u00e3o e remo\u00e7\u00e3o f\u00e1cil:<\/p>\n
procedure TLoteProcessor.ProcessarItem(const Item: TItemLote);\nbegin\n  {$IFDEF DEBUG_TEMP}\n  Log.Debug('Entrada: Valor=%f Status=%s', [Item.Valor, Item.Status]);\n  {$ENDIF}\n\n  AplicarDesconto(Item);\n\n  {$IFDEF DEBUG_TEMP}\n  Log.Debug('P\u00f3s-desconto: Valor=%f', [Item.Valor]);\n  {$ENDIF}\n\n  ValidarRegrasNegocio(Item);\nend;\n<\/code><\/pre>\n
Usar uma diretiva de compila\u00e7\u00e3o em vez de coment\u00e1rios soltos garante que o c\u00f3digo de instrumenta\u00e7\u00e3o sequer entre no bin\u00e1rio de produ\u00e7\u00e3o se a flag n\u00e3o estiver definida \u2014 uma garantia estrutural que o console.log<\/code> solto em JavaScript n\u00e3o oferece.<\/p>\n
T\u00e9cnica 4: trate a sugest\u00e3o da IA como uma hip\u00f3tese test\u00e1vel, nunca como verdade<\/h2>\n
O erro mais caro em debugging assistido por IA \u00e9 aplicar a corre\u00e7\u00e3o sugerida sem escrever primeiro um teste que comprove a causa raiz. Isso \u00e9 especialmente verdadeiro quando o modelo sugere mudan\u00e7as que “parecem razo\u00e1veis” \u2014 adicionar um null check<\/code>, aumentar um timeout, adicionar um await<\/code> que faltava \u2014 sem que voc\u00ea tenha confirmado que aquele ponto espec\u00edfico \u00e9, de fato, a origem do problema.<\/p>\n
O artigo A verdade sobre o impacto da IA no desenvolvimento de software<\/a> discute como a redu\u00e7\u00e3o da escrita manual de c\u00f3digo desloca o trabalho do desenvolvedor para outra camada \u2014 e em debugging essa camada \u00e9 exatamente a valida\u00e7\u00e3o. Antes de aceitar qualquer corre\u00e7\u00e3o, escreva o teste que falha sem a corre\u00e7\u00e3o e passa com ela:<\/p>\n
def test_desconto_nao_aplica_duas_vezes_para_mesmo_item():\n    \"\"\"\n    Hip\u00f3tese da IA: o bug ocorre porque `aplicar_desconto`\n    \u00e9 chamado duas vezes no fluxo de reprocessamento de erro,\n    aplicando o desconto cumulativamente.\n    \"\"\"\n    item = Item(valor=100.0, desconto_aplicado=False)\n    aplicar_desconto(item, percentual=10)\n    aplicar_desconto(item, percentual=10)  # simula reprocessamento\n    assert item.valor == 90.0  # deveria ser idempotente, n\u00e3o 81.0\n<\/code><\/pre>\n
Se esse teste falhar antes da corre\u00e7\u00e3o e passar depois, voc\u00ea tem confirma\u00e7\u00e3o objetiva da causa raiz. Se passar mesmo sem a corre\u00e7\u00e3o, a hip\u00f3tese da IA estava errada, e voc\u00ea acabou de economizar o tempo que gastaria debugando um sintoma que nunca existiu.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> o v\u00eddeo Does programming without AI still make sense in 2026?<\/a> e o artigo relacionado, Por que voc\u00ea deveria programar com IA em 2026<\/a>, refor\u00e7am um ponto central: a IA n\u00e3o substitui o racioc\u00ednio de verifica\u00e7\u00e3o, ela acelera a gera\u00e7\u00e3o de hip\u00f3teses. Quem transforma essa acelera\u00e7\u00e3o em produtividade real \u00e9 quem mant\u00e9m a disciplina de testar cada hip\u00f3tese antes de confiar nela.<\/p><\/blockquote>\n
T\u00e9cnica 5: pe\u00e7a o diff m\u00ednimo, n\u00e3o a reescrita<\/h2>\n
Uma armadilha recorrente \u00e9 pedir “corrija esse arquivo” e receber de volta uma reescrita completa da fun\u00e7\u00e3o ou do m\u00f3dulo. Al\u00e9m de dificultar a revis\u00e3o \u2014 voc\u00ea perde a capacidade de ver exatamente o que mudou \u2014 reescritas completas aumentam a chance de regress\u00f5es silenciosas em partes do c\u00f3digo que n\u00e3o tinham nada a ver com o bug original.<\/p>\n
Prompt:\n\"N\u00e3o reescreva a fun\u00e7\u00e3o inteira. Me d\u00ea apenas o diff m\u00ednimo\nnecess\u00e1rio para corrigir a race condition identificada,\nno formato unified diff, preservando toda a l\u00f3gica n\u00e3o relacionada.\"\n<\/code><\/pre>\n
Esse pedido expl\u00edcito de formato muda o comportamento do modelo de forma mensur\u00e1vel: diffs m\u00ednimos s\u00e3o mais f\u00e1ceis de revisar linha a linha, e qualquer altera\u00e7\u00e3o fora do escopo esperado salta aos olhos imediatamente \u2014 o que n\u00e3o acontece quando voc\u00ea compara mentalmente duas vers\u00f5es inteiras de um arquivo de duzentas linhas.<\/p>\n
T\u00e9cnica 6: quando o bug est\u00e1 na integra\u00e7\u00e3o, n\u00e3o no c\u00f3digo<\/h2>\n
Muitos bugs “misteriosos” n\u00e3o est\u00e3o na l\u00f3gica que voc\u00ea escreveu, mas na forma como duas pe\u00e7as do sistema se encaixam \u2014 uma API externa que mudou o formato de resposta, uma biblioteca atualizada com comportamento diferente, uma configura\u00e7\u00e3o de ambiente divergente entre homologa\u00e7\u00e3o e produ\u00e7\u00e3o. Nesses casos, pedir \u00e0 IA para “debugar o c\u00f3digo” \u00e9 o prompt errado; o prompt certo \u00e9 pedir para comparar comportamentos esperados versus observados em cada fronteira do sistema.<\/p>\n
Prompt:\n\"Este c\u00f3digo funcionava at\u00e9 a atualiza\u00e7\u00e3o da biblioteca X da vers\u00e3o 2.3 para 3.0.\nAqui est\u00e1 o changelog relevante: [cole trecho do changelog]\nAqui est\u00e1 o c\u00f3digo que usa a biblioteca: [cole c\u00f3digo]\nQual mudan\u00e7a de comportamento no changelog \u00e9 mais compat\u00edvel\ncom o erro observado: [cole erro]?\"\n<\/code><\/pre>\n
Esse tipo de prompt direciona a IA para correlacionar uma fonte externa (o changelog) com o sintoma, em vez de tentar adivinhar a causa olhando s\u00f3 para o seu c\u00f3digo \u2014 que, nesse cen\u00e1rio, n\u00e3o mudou e n\u00e3o \u00e9 o problema.<\/p>\n
Montando o fluxo completo: um checklist operacional<\/h2>\n
Reunindo as t\u00e9cnicas anteriores em um processo que voc\u00ea pode aplicar na pr\u00f3xima sess\u00e3o de debugging:<\/p>\n