IA conserta o bug, mas sabe encontrá-lo?

{ "resumo": "## A tese: consertar não é descobrir\n\nO autor, Leonid Bugaev, relata experimentos para descobrir se modelos de linguagem conseguem encontrar bugs apenas olhando o código, sem pistas - diferentemente do que benchmarks como o SWE-bench medem. Sua conclusão central: quando a tarefa tem definição clara ou pistas suficientes (um relatório de usuário, logs, descrição do defeito), modelos baratos fazem trabalho sério. Quando é preciso inventar as perguntas certas - notar uma suposição que merece ser desafiada e escolher um input que a teste - os modelos pequenos falham, e até modelos de fronteira podem parecer fracos em codebases privadas.\n\n## O problema com os benchmarks\n\nAo bissecar como o SWE-bench funciona, o autor observou que o eval não pede para encontrar o bug: entrega muitas pistas antecipadas e pede apenas a correção. Além disso, os benchmarks usam projetos de código aberto populares como Django, cujas respostas já estão na internet pública - e que por isso fazem parte do pré-treino e pós-treino dos modelos, o que ele caracteriza como uma forma de trapaça, mesmo sem busca na internet ativada. Como reforço, ele cita a explicação da OpenAI, em 23 de fevereiro de 2026, de que parou de reportar notas no SWE-bench Verified por contaminação e evals falhos: as três famílias de modelos testadas conseguiam reproduzir correções originais ou detalhes específicos de problemas.\n\n## Os experimentos\n\nO autor testou o GLM-5.3-flash - o modelo mistificado como "Ox Alpha" - e o Grok 4.6 (cerca de 5 vezes maior), usando Django 3.0 e casos em que Claude e Codex haviam recusado o trabalho relacionado a segurança. Ele apresenta três bugs, admitindo que as histórias públicas desses casos impedem de tratar os acertos do Grok como prova de descoberta em código inédito.\n\n1. A guarda que não trata nada: na construção de nomes de arquivo, um hash customizado que retorna None gera stylesNone.css, sem exceção. As revisões do GLM discutiram erros de diretório e corridas, chegaram à função certa mas perderam o nome de arquivo corrompido; o Grok encontrou.\n\n2. A vírgula dentro do expoente: o formatador de números do Django agrupa a parte inteira, mas 1e25 vira a string \"1e+25\", sem ponto decimal; o loop insere separador a cada três caracteres e produz '1e,+25'. O GLM apontou achados irrelevantes; encontrar esse bug exige carregar a string por todo o código sem substituí-la pelo decimal esperado - o fato relevante é algo que não está lá: um ponto.\n\n3. "Just use self": o atalho de copiar o objeto ao combinar Q() vazio com outra consulta dispara um deepcopy que falha com um TypeError em _thread.lock - e também com chaves de dicionário, algo comum. Esse caso pegou até o Grok, que propôs o gatilho errado; um modelo mais barato o achou em uma sessão em que o comentário foi apresentado como afirmação a desafiar, mas o sucesso não se repetiu de forma confiável.\n\n## Prompts melhores não resolveram\n\nO autor tentou instruções revisadas, mais pistas, revisão em fases e verificações explícitas: em três versões, o GLM-5.3-flash encontrou zero dos sete defeitos difíceis selecionados (amostra deliberada, não aleatória). Em um experimento com traces linha a linha, 38 de 48 saídas seguiram o formato pedido, mas os achados continuaram ausentes - traces confiantes e bem-formados que estavam errados. Melhor conformidade foi mensurável, porém insuficiente.\n\n## Conclusão\n\nUm placar único de código esconde exatamente a distinção que importa ao decidir o que delegar: implementar uma descrição precisa de bug não é produzir essa descrição. O autor sugere um exercício: dar a versão com bug e uma versão corrigida do mesmo código e ver se o modelo encontra a falha na primeira e deixa de reportá-la na segunda. Para ele, ainda é cedo para afirmar que modelos locais igualem os de fronteira - isso só vale quando o humano fez a parte da "inteligência" e entregou as pistas.", "hook": "Um engenheiro pediu a modelos de linguagem que encontrassem bugs em Django sem dar nenhuma pista. O modelo pequeno errou sete de sete casos difíceis, mesmo com instruções aprimoradas, enquanto o Grok 4.6 achou parte deles. A crítica: benchmarks como o SWE-bench entregam o relatório do bug pronto - e as respostas dos projetos populares já estão nos dados de treino.", "entities": ["GLM-5.3-flash", "Grok 4.6", "Django", "SWE-bench", "OpenAI", "Claude", "Codex"], "themes": ["pesquisa-e-benchmarks", "engenharia-com-ia"], "story_key": "encontrar-bug-vs-consertar-bug", "reasoning": { "story_key": "Tese central do artigo: consertar bug descrito é tarefa distinta de descobrir o bug sem pistas; benchmarks escondem essa diferença.", "themes": { "pesquisa-e-benchmarks": "Assunto central é crítica ao SWE-bench, contaminação de treino e limitação de evals, não lançamento de modelo.", "engenharia-com-ia": "IA é o assunto: capacidade de modelos em code review e descoberta de bugs em código." }, "entities": { "GLM-5.3-flash": "Modelo pequeno testado, falhou nos sete casos difíceis.", "Grok 4.6": "Modelo maior que encontrou parte dos bugs; contraste central.", "Django": "Codebase usada nos três exemplos de bugs.", "SWE-bench": "Benchmark criticado quanto a pistas antecipadas e contaminação.", "OpenAI": "Citada por encerrar reporte de notas no SWE-bench Verified por contaminação.", "Claude": "Recusou o trabalho de segurança, motivo do uso de Grok/GLM.", "Codex": "Também recusou o trabalho relacionado a segurança." }, "excluded": { "Leonid Bugaev": "Autor, excluído por regra.", "Substack": "Plataforma de publicação, menção secundária.", "Ox Alpha": "Apelido do GLM-5.3-flash, não entidade separada." } } }