- Durante a implementação em Go do ML-DSA, um algoritmo de assinatura resistente a computadores quânticos padronizado pelo NIST, surgiu um problema em que a verificação de assinaturas falhava
- O Claude Code v2.0.28 encontrou rapidamente um bug complexo de baixo nível apenas com o código de teste e o caminho do código-fonte
- A causa foi confirmada como um erro de fusão de funções em que, na etapa
Verify, os bits altos de w1 eram calculados em duplicidade
- Em um segundo experimento em seguida, Claude também encontrou um erro no cálculo da constante de Montgomery e um bug de incompatibilidade no comprimento da assinatura
- As três tentativas identificaram os bugs com sucesso, mostrando o potencial de uso de IA na depuração de baixo nível
Implementação do ML-DSA e problema inicial
- O autor implementou do zero em Go o ML-DSA (algoritmo de assinatura pós-quântica) padronizado pelo NIST
- Após 4 dias de live coding, os testes passaram a falhar com um problema em que a função
Verify rejeitava todas as assinaturas
- Nos logs de teste, o erro
invalid signature era exibido repetidamente
- Por cansaço, ele interrompeu a depuração e pediu ao Claude Code que analisasse o problema
Primeira depuração com Claude Code
- Ao Claude Code v2.0.28 (modelo Opus 4.1, sem system prompt), foram fornecidas as seguintes informações
- comando para executar os testes (
bin/go test crypto/internal/fips140/mldsa)
- localização do código (
src/crypto/internal/fips140/mldsa)
- a explicação de que “a assinatura é sempre rejeitada” e a dica de que “w1 é diferente”
- Em poucos minutos, Claude retornou uma proposta completa de correção
- A causa foi que, depois de unir
HighBits e w1Encode em uma só função, no Verify o resultado de UseHint, que já produzia os bits altos, tinha seus bits altos extraídos novamente
- Ou seja, tratava-se de um erro estrutural em que os bits altos de w1 eram calculados duas vezes
- Claude identificou a causa logo após carregar o código e escreveu seus próprios testes para validar a hipótese
- A correção proposta não era perfeita, mas reduziu o tempo de depuração ao identificar a causa central
- Depois disso, o autor refatorou
w1Encode para uma estrutura que recebe os bits altos como entrada e também encurtou o processo de conversão da representação de Montgomery
Segundo experimento: bug na etapa de geração da assinatura
- Também houve falha nos testes da implementação de geração de assinaturas
- Primeiro bug: erro no cálculo das constantes (1, -1) no domínio de Montgomery
- Era um problema difícil de encontrar, exigindo vários
printf e hipóteses, levando cerca de 1 a 2 horas
- Segundo bug: erro no tamanho do valor incluído na assinatura (32 bits em vez de 32 bytes)
- Foi relativamente fácil de encontrar por causa da diferença no tamanho da assinatura
- O autor considerou esses dois bugs adequados para verificar o desempenho do Claude e executou novamente o Claude Code com uma versão anterior do código
Resultado da segunda depuração com Claude Code
- No primeiro prompt, Claude fez depuração com
printf e rastreamento de valores, encontrou a constante incorreta e a corrigiu
- O tempo de processamento foi menor que o de um humano e a causa da falha no teste foi identificada com precisão
- No segundo prompt, encontrou o problema de incompatibilidade no comprimento da assinatura
- Depois de explorar vários caminhos, Claude apresentou uma proposta que corrigia apenas o tamanho da alocação
- A correção proposta não era perfeita, mas apontou com precisão a localização do erro central
- Nas três tentativas independentes, Claude encontrou sozinho a causa correta dos bugs
Eficiência e implicações da depuração com IA
- A abordagem do Claude foi eficaz como um assistente automatizado especializado em localizar a causa de falhas em testes
- O usuário não aplicou diretamente as correções do Claude e apenas confirmou a localização do bug antes de corrigir manualmente
- O autor menciona a necessidade de uma ferramenta que analise automaticamente a causa quando um teste falha usando um LLM
- Ele avalia que o formato ideal seria um agente de depuração baseado em testes, mais do que um chat simples ou a geração automática de PRs
Patrocínio e outras informações
- A manutenção open source do autor recebe apoio via Geomys, com patrocínio de
Smallstep, Ava Labs, Teleport, Tailscale e Sentry
- A Ava Labs destaca a importância do desenvolvimento open source sustentável de protocolos criptográficos
- A Teleport apresenta a plataforma Teleport Identity para prevenir o comprometimento de contas de usuário e reforçar o controle de acesso
Apêndice: imagem e menções pessoais
- O texto inclui Clippy, o assistente do Microsoft Office, em um balão dizendo que “pegou os bits altos de w1 duas vezes”
- No final, há uma foto de gato, apresentada como humor para aliviar debates emocionais sobre IA
2 comentários
Recentemente tenho desenvolvido bastante kernels de GPU usando triton e cuda; até a 3.5 eu quase não via nada que realmente executasse direito, mas na 4.5 já dá para ver que ela gera código e otimizações razoavelmente corretos.
Comentários do Hacker News
Usar agentes de código para rastrear a causa raiz de bugs funciona muito bem
As três tentativas de depuração em uma única rodada deram certo. O ponto principal é que o LLM não corrige o código diretamente; ele atua como um assistente que só indica onde está o bug, para que eu mesmo possa julgar e corrigir
Essa abordagem também pode ser um bom ponto de partida para céticos em relação a LLMs. Em vez de pedir que escrevam o código, basta deixá-los apenas encontrar bugs difíceis
A sugestão de “isso precisa ser corrigido” não está exatamente errada, mas muitas vezes é irrelevante para o ponto central. No fim, acumulam-se sugestões de mudanças desnecessárias e, se um desenvolvedor júnior aplicar tudo como está, só aumenta o trabalho desnecessário
Eu também uso essas ferramentas, mas às vezes tenho a sensação de que “explicar para um júnior acaba levando ainda mais tempo”
Também vão bem na geração de testes para algoritmos, mas têm limitações em cenários de concorrência. Mesmo assim, já têm bastante valor para “geração de testes” ou “depuração”
Do ponto de vista de refatoração de código ou manutenção de longo prazo, ainda deixam a desejar
Mas, usando como o blog recomendou, como caçador de bugs, foi surpreendentemente eficaz. Em poucas semanas, encontrou vários bugs em produção
Se você pedir para ele escrever bastante documentação relacionada antes de mergulhar de verdade no código, o custo de possíveis erros é menor e isso também vira um bom ponto de partida para quem é mais cético
Eu acharia uma pena entregar esse processo para uma máquina. Caçar bugs leva a uma compreensão profunda da arquitetura do sistema e, no longo prazo, ajuda a pessoa a se tornar uma programadora melhor
Sem esse tipo de experiência, existe o risco de acabar dependendo do LLM até para julgar o próprio código
Meu conselho é um só: AI First
Se você jogar primeiro o problema para a IA, aprende os limites do modelo ao mesmo tempo em que desenvolve a capacidade de estruturar prompts
Os modelos mais recentes são poderosos o bastante para serem tratados como colegas na maioria dos problemas. Mas é importante entender os padrões de falha e construir intuição
Sempre que surgir uma nova geração de modelos, recomendo abandonar o processo antigo e experimentar os modelos mais recentes, como GPT-5-Codex ou Sonnet 4.5
Se você for especialista no domínio, consegue distinguir alucinações e erros do LLM, mas, se não for, isso pode acabar sendo só perda de tempo
No fim, essas ferramentas são mais úteis para especialistas, e para iniciantes a qualidade ainda é inconsistente
Eu também testei o Sonnet 4.5, mas foi só uma leve melhora em relação à versão anterior. Ainda há muita perda de tempo
A Anthropic me ofereceu Claude Max de graça por alguns meses
Ultimamente até no Instagram está cheio de anúncios relacionados ao Claude. Continuam aparecendo anúncios do tipo “instale o Claude Code”, então parece que o time de marketing está realmente trabalhando pesado
Os desenvolvedores acham o Claude Code muito útil, e há bastante gente pagando a assinatura de 200 dólares por mês. Se está dando retorno, é natural investir pesado em marketing
LLMs ajudam a encontrar bugs, mas às vezes também dão explicações sem sentido, fazendo você perder tempo
No fim, o importante é manter o pensamento crítico
O LLM é uma ótima ferramenta, mas tira conclusões precipitadas com facilidade. No momento em que a pessoa para de pensar, o modelo dispara na direção errada
Concordo com a opinião de que “usar LLM só em formato de chat ou autocompletar não é grande coisa”
Eu também só comecei a sentir o potencial de verdade usando Claude Code/Codex. Se existisse um modo de execução contínua, seria ainda mais interessante
Ele pode apagar arquivos por engano ou estragar um repositório Git. Por isso, eu só experimento em um ambiente sandbox
Quero uma ferramenta de colaboração em modo socrático, em que o modelo me faça perguntas e eu intervenha diretamente enquanto aprendo
A abordagem atual, centrada em automação, corre o risco de transformar desenvolvedores em analfabetos de código. Por outro lado, se for bem projetada, pode virar uma ferramenta que amplifica entendimento e intuição
O terminal CLI continua sendo uma interface poderosa
Gemini CLI e Qwen Code são gratuitos, e também é fácil conectar APIs compatíveis com OpenAI.
Dá para automatizar tarefas simples e resolver partes difíceis em uma única rodada com Grok. Só com CLI + servidor MCP + arquivos MD já dá para criar programas inteligentes
A ideia de fazer o LLM analisar automaticamente a causa sempre que um teste falha é interessante
Dá para fazer isso executando o Claude CLI com um hook do Git.
Exemplos e cola podem ser vistos neste guia
Parece que em breve veremos casos de ataques adversariais contra dados de treinamento de LLMs induzindo erros criptográficos
A ideia de que “a correção inclui adicionar uma função totalmente nova” parece perigosa em implementações criptográficas
Sinto que o texto dá um conselho errado
O código de correção foi descartado, e a pessoa escreveu a correção manualmente. Na verdade, isso parece um caso de uso conservador e responsável
O LLM não deve ser usado como “mecânico”, mas como um detector de vazamento de gás que indica onde está o problema
LLMs passaram a reconhecer padrões ambíguos no código e eliminaram muitos problemas tediosos
Mas isso também pode virar um efeito colateral. Minha base de código parece Node.js, mas na prática não é, então o modelo continua confundindo tudo com um projeto Node