---
title: "O que o CodeRQ-Bench revela sobre o raciocínio falho das IAs em código que \"funciona\""
author: "Ricardo Pupo Larguesa"
date: "2026-04-28 09:00:00-03"
category: "Na Prática"
url: "http://scale.press/portal/aintuicao/post/2026/04/28/o-que-o-coderq-bench-revela-sobre-o-raciocinio-falho-das-ias-em-codigo-que-funciona/md"
---

Na última semana, estava validando um pull request gerado por um LLM. O código passou em todos os testes unitários. A sintaxe era impecável. Mas, quando li o bloco de documentação gerado junto com a lógica, percebi o desastre. O modelo acertou a implementação por pura coincidência, fundamentando a arquitetura em uma premissa completamente falsa sobre o fluxo de dados da nossa API.

Esse descompasso entre a saída funcional e o raciocínio que a produziu cria uma falsa segurança. Isso agrava um sintoma que discuti recentemente sobre [como o Copilot cria programadores frágeis](https://scale.press/portal/aintuicao/post/2026/02/25/o-perigo-da-divida-epistemica-por-que-o-copilot-esta-criando-programadores-frageis): o desenvolvedor júnior aceita a saída porque ela compila, ignorando o abismo lógico estrutural por trás dela.

## A ilusão do código compilado

É exatamente essa fragilidade que um [preprint](https://arxiv.org/abs/2604.12379) publicado em 14 de abril de 2026 no arXiv combate. O grupo de Yuangang Li e pesquisadores associados introduziu o CodeRQ-Bench, o primeiro benchmark desenhado para avaliar a qualidade de raciocínio de LLMs em tarefas de codificação. Os autores analisaram 1.069 casos de mismatch, o fenômeno onde a resposta final está correta, mas a lógica que levou a ela está errada ou alucinada.

A consequência de não rastrear esse erro é terrível. Quando um desenvolvedor acopla esse código em produção, a arquitetura ganha uma peça que resolve o problema imediato, mas quebra no primeiro caso diferente do conjunto de testes porque o modelo otimizou apenas para a saída, não para o invariante do sistema.

## VERA e a arquitetura do Chain-of-Thought para código

Para mitigar isso, Li e sua equipe propuseram o VERA, um avaliador de dois estágios. Ele não olha apenas para o resultado. O VERA realiza uma verificação baseada em evidências (ancorando o passo a passo lógico) e aplica uma correção de nota consciente de ambiguidades. Nos testes sobre quatro datasets diferentes, o VERA superou as linhas de base tradicionais, melhorando o AUCROC ( métrica de desempenho amplamente utilizada para avaliar a qualidade de modelos de classificação) em até 0,26.

O raciocínio para codificação difere drasticamente da linguagem natural. Em PNL, uma cadeia de pensamento (CoT) sobrevive apenas com plausibilidade linguística e coerência argumentativa. Em engenharia de software, avaliar inteligência de código virou [um jogo sobre arquitetura sistêmica, não sintaxe](https://scale.press/portal/aintuicao/post/2026/04/23/engenharia-de-software-20-como-os-novos-benchmarks-do-arxiv-escancaram-a-morte-do-dev-digitador). A validação exige ancoragem semântica na execução do sistema e circuitos de feedback para autocorreção. No meu livro, [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt), detalho que fornecer restrições lógicas específicas no prompt é a única forma de forçar o modelo a expor suas premissas antes de digitar a primeira linha de código funcional.

## Previsibilidade de falha e economia de inferência

Curiosamente, [outro preprint](https://arxiv.org/html/2604.12634v1) do mesmo dia cruza com esse problema de forma complementar. Dylan Ashley e pesquisadores publicaram o paradigma RPRA, que testa a capacidade dos modelos preverem a nota de um avaliador (LLM-judge) antes de começarem a gerar a resposta. Se sabemos que a qualidade do raciocínio cai, podemos usar modelos menores que avisam antecipadamente que vão falhar, roteando a inferência para modelos maiores apenas quando necessário. Nos testes de Ashley, a adoção de fine-tuning ou report cards embutidos no contexto gerou melhorias de eficiência e qualidade de até 55%.

Isso altera a dinâmica de custo. Em vez de desperdiçar tokens gerando um código gigante que compila pelos motivos errados, o sistema prediz sua própria incompetência no raciocínio arquitetural e delega a tarefa.

Se o modelo acerta a sintaxe, mas erra a lógica de negócio, ele não escreveu software. Ele jogou dados e teve sorte. Em produção, a sorte acaba no primeiro pico de tráfego. Para continuar essa discussão sobre arquitetura, restrições em ML e como construir IAs que realmente escalam sem destruir bases de código, conecte-se comigo nas minhas redes sociais: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo).