Eu pedi a uma IA para verificar a auditoria de outra IA do meu próprio código

Eu não sou um programador. Minha formação é em engenharia de construção, e entrei na programação quase por acidente: eu queria entender como funcionavam os bots do Telegram, então comecei a montar um a partir de pedaços de código que encontrei no Google e que foram gerados por IA. O resultado foi um monólito que eu continuava quebrando — eu nem sabia que o Python se importava com a indentação, e eu realmente não entendia por que o código continuava travando por causa de espaços em branco. Através de tentativa e erro, lentamente descobri onde a IA tende a errar e como contornar isso — com a própria IA me ajudando a descobrir isso. Eventualmente, reconstruí o bot do zero, totalmente modular desta vez.

Mais tarde, experimentei o Cursor, e foi uma boa experiência — ele escreveu um código sólido, mesmo que às vezes se desviasse do objetivo. Quando minha assinatura expirou, procurei uma alternativa gratuita e encontrei o Zed. Foi então que eu queria que o Zed se sentisse tão capaz quanto o Cursor — com o mesmo nível de compreensão da minha base de código. Então comecei a descobrir como construir isso eu mesmo. Assim nasceu a Inteligência MSCodeBase: um servidor MCP que dá aos assistentes de IA mais contexto sobre uma base de código dentro do Zed IDE.

Já escrevi sobre o projeto em si antes. Desta vez, quero falar sobre outra coisa — um hábito que adquiri ao longo do caminho que, em retrospecto, importa mais do que qualquer recurso único.

Como eu realmente trabalho

Eu não escrevo código à mão. Eu delego tarefas a diferentes modelos de IA — Claude, Gemini, DeepSeek e outros — eles escrevem e corrigem o código, e eu verifico o resultado. Não porque eu seja especialmente disciplinado, mas porque eu realmente não consigo apenas olhar para o código e dizer se está correto. Eu preciso de algo — ou alguém — para verificar isso.

Por muito tempo, isso significou: um modelo escreve, eu leio por conta própria e faço perguntas quando algo parece errado.

Então comecei a fazer de forma diferente: um modelo escreve um relatório sobre o que fez ou o que encontrou no código, e um segundo modelo — com acesso à base de código real — verifica esse relatório em relação à realidade. Não porque eu desconfie da IA em princípio, mas porque aprendi na prática que a IA pode soar completamente confiante e estar completamente errada ao mesmo tempo.

Um caso específico

Recebi uma auditoria externa do meu projeto — várias páginas de comprimento, com descobertas, recomendações e uma lista de vulnerabilidades suspeitas. Parecia sólida. Três descobertas foram sinalizadas como prioridade máxima.

Eu não me apressei para corrigir nada. Em vez disso, pedi a um modelo diferente — um com acesso à base de código ao vivo — para analisar o relatório linha por linha e verificar contra o repositório real. Não "isso soa plausível", mas literalmente: abrir o arquivo, abrir a linha, verificar se o que o relatório afirma realmente está lá.

O resultado foi misto, e essa é a parte interessante.

Três descobertas reais se mantiveram. Havia genuinamente um bug de bloqueio de processo no Windows, um caso em que uma gravação de dados poderia ficar em um estado não atômico, e uma condição de corrida em uma fila de tarefas que poderia deixar uma tarefa em segundo plano presa para sempre. Esses não eram riscos imaginários — eram reais, valendo a pena corrigir.

Mas, ao lado disso, algumas outras coisas surgiram:

• o relatório referenciava um nome de função que não existe no código — o modelo que escreveu a auditoria provavelmente o inventou por analogia ou o retirou de uma versão desatualizada;
• um dos caminhos de arquivo no relatório estava errado — o arquivo real estava em outro lugar;
• o relatório mencionou um teste que deveria capturar o bug — nenhum teste desse tipo existia no repositório;
• os números de cobertura de teste e as contagens de teste estavam desatualizados, de um estado anterior do projeto;
• para um dos CVEs sinalizados, o relatório citou a versão errada da biblioteca "corrigida" — a versão segura real era posterior ao que foi afirmado.

Portanto, o relatório foi genuinamente útil e parcialmente fabricado — e não fabricado aleatoriamente. Os detalhes inventados foram entrelaçados com problemas reais, corretamente identificados. Isso, eu acho, é o tipo mais perigoso de erro de IA: não "tudo é falso", mas "verdadeiro, com detalhes fabricados misturados que você não consegue distinguir sem verificar cada linha você mesmo."

Por que isso importa, não é apenas uma anedota

Se eu simplesmente tivesse copiado as recomendações e pedido a um agente para aplicá-las, parte do trabalho não teria ido a lugar nenhum — o agente teria procurado uma função que não existe, referenciado um teste que não está lá, fixado uma biblioteca na versão errada. E pior: os três problemas reais poderiam facilmente ter sido descartados junto com tudo o mais, uma vez que os detalhes fabricados tornaram todo o relatório parecer não confiável.

A lição que tirei: a confiança em um relatório de IA não deve ser binária — "acredite" ou "não acredite." Um relatório precisa ser decomposto em reivindicações individuais, e cada reivindicação verificada separadamente em relação ao estado atual do código, não em relação à memória do modelo sobre como o código costumava ser.

Um segundo experimento: verificando as instruções, não o código

Eu mantenho um arquivo de regras para os agentes de IA que trabalham neste projeto — algo como uma descrição de trabalho: como se comportar, o que sempre verificar, como rotular a fonte de uma reivindicação ("Eu verifiquei isso no código" vs. "Estou assumindo isso"). Com o tempo, esse arquivo cresceu — muito.

Isso levantou uma questão: se eu comprimisse essas regras para cerca da metade do comprimento, o agente ainda as seguiria com a mesma atenção, ou começaria a cortar caminhos?

Eu não adivinhei. Executei o mesmo conjunto de tarefas duas vezes — uma vez contra as instruções completas, outra vez contra a versão comprimida — e para cada tarefa anotei quais regras específicas foram realmente seguidas e quais não foram.

O resultado: a versão comprimida teve um desempenho pior, mas não dramaticamente, e não de forma uniforme. O que mais sofreu foi o que eu chamaria de "disciplina no momento" — coisas como atualizar um log de decisões logo após cada passo em vez de tudo de uma vez no final. As regras em si ainda estavam tecnicamente presentes no arquivo comprimido. O agente apenas se lembrou de aplicá-las com menos frequência durante a tarefa.

Isso não era óbvio para mim antes também. Eu assumi que se uma regra está escrita, ela é seguida. Acontece que o que importa não é apenas se está escrito, mas com que frequência — e onde no texto — o agente é lembrado disso.

O que estou levando disso

Eu não sou um programador, e não sinto que entenda código melhor do que os modelos com os quais trabalho. Mas na prática, aprendi uma coisa: o principal valor que acrescento a esse processo como humano não é escrever código — é recusar confiar em um relatório sobre código até que tenha sido verificado em relação à realidade.

Isso é mais lento do que simplesmente acreditar. Mas a alternativa é enviar silenciosamente três bugs reais envoltos em dois fatos fabricados, e nunca notar a diferença.

Eu mantenho um registro de experimentos em andamento diretamente no repositório — hipótese, o que foi realmente testado, o resultado bruto, a conclusão e, separadamente, o que eu errei da primeira vez. Não porque pareça bonito, mas porque sem isso, um mês depois eu não lembraria quais conclusões foram realmente verificadas e quais foram apenas afirmadas com confiança por algo.

O repositório é de código aberto, licenciado sob MIT: https://github.com/ManSio/mscodebase-intelligence

Se você já se deparou com algo semelhante — uma auditoria ou relatório de IA que acabou sendo metade verdadeiro, metade inventado — eu ficaria curioso para saber como você o pegou.