IBM mostra que perguntar ao cliente antes de gerar o código eleva a precisão de smart contracts por transação para 72,9%

Sistemas de agentes que transformam uma descrição em inglês em código já viraram rotina, e o código costuma compilar. Mas quase ninguém mede, com ferramentas validadas, se o comportamento do programa coincide com a intenção do autor. Pesquisadores do IBM T.

J. Watson Research Center estudaram o problema em smart contracts escritos em Solidity: depois do deploy, eles não podem ser corrigidos e movimentam dinheiro, então um erro sai caro. A principal métrica do trabalho é a precisão por transação, isto é, a fatia de transações reproduzidas em que o contrato gerado se comporta como o original.

O pipeline que primeiro faz perguntas ao cliente atingiu 72,9% em 500 contratos reservados para teste. A geração com um único prompt chegou a 53,9%, e o pipeline anterior dos autores, de sete etapas, a 39,3%. A maior parte da intenção se perde antes da geração, e o que mais ajuda é esclarecer os requisitos, não somar etapas de verificação.

Como a precisão foi medida

Os autores usaram 600 contratos reais do conjunto FSM-SCG. Para cada um, o Gemini 2.5 Flash escreveu uma descrição curta, de cerca de 140 palavras, e um documento completo de requisitos, de cerca de 1700 palavras. A métrica principal é a implementation fidelity, ou seja, a fidelidade na reprodução do comportamento do original. Para cada contrato, foram executadas 60 sequências aleatórias de 8 passos em uma máquina virtual EVM local. Um passo só conta se o resultado da chamada e todos os valores observáveis coincidirem. Os autores ressalvam que a métrica reflete a intenção do autor apenas na medida em que o contrato original a incorpora.

Primeiro, as próprias ferramentas de avaliação foram testadas com erros inseridos de propósito. O analisador estático Slither percebeu o novo problema em apenas 3 de 200 verificações de acesso removidas. Um LLM usado como juiz, lendo o código, marca 80% dos contratos intactos como problemáticos, e exigir uma prova executável reduz a taxa de erros encontrados para 30%. Um modelo de referência em Python, escrito a partir da descrição, detecta 94,3% dos erros típicos, como modificadores removidos. Só que um modelo equivalente, escrito apenas a partir dos nomes das funções, detecta 87,5%. Ou seja, boa parte das avaliações clássicas premia o conhecimento de convenções gerais, e não a compreensão da descrição.

Onde a intenção se perde

Em 100 contratos novos e 279 erros específicos de cada contrato, o modelo de referência encontrou 65,9% dos erros com a descrição curta e 87,5% com o documento completo. A diferença foi de 21,6 pontos. O agente extrator e o agente crítico não mudaram nada. Um checklist com dez perguntas fixas ao cliente fechou a lacuna quase por completo: 89,4%, contra 88,9% do documento completo.

Para o gerador GPT-5.4-mini, a precisão por transação é de 55,6% com a descrição curta, 76,0% com as respostas do checklist, 79,4% com as respostas do entrevistador e 91,0% com o documento completo. O checklist tem uma fraqueza: descreve o comportamento, mas não os tipos dos argumentos nem os valores armazenados, e por isso implementa 88,7% das assinaturas necessárias, contra 94,8% do entrevistador. O ganho se repetiu em outras famílias de modelos: no Claude Sonnet 5, a precisão subiu de 56,1% para 75,1%, e no Gemini 3.5 Flash, de 51,8% para 74,5%. Nas três famílias de modelos, os autores estimam o ganho com as respostas do cliente simulado em 19 a 23 pontos.

As descrições também não são confiáveis. O modelo auditor encontrou ao menos uma contradição com o original em 76 de 100 descrições, como uma regra de acesso inexistente. Por isso, o esclarecimento muitas vezes corrige afirmações falsas, e não apenas preenche lacunas. Entre as 24 descrições sem contradições, o ganho do checklist se mantém, mas a amostra é pequena demais para uma comparação rigorosa.

Quantas perguntas são necessárias e o que não funciona

Três a cinco perguntas bem escolhidas recuperam de 60% a 75% de todo o ganho. As etapas posteriores à geração adicionam, no máximo, um ponto, e o ciclo automático de correção de segurança tira 12,8 pontos: ele remove o comportamento necessário junto com as vulnerabilidades. O pipeline final primeiro faz perguntas ao cliente, depois confronta o contrato com um modelo de referência independente e mostra as divergências ao cliente como uma escolha às cegas. Os achados de segurança são apenas sinalizados, sem reescrever o código.

As limitações são relevantes. O cliente é simulado pelo GPT-5.4, que lê o contrato original, de modo que o ganho é uma estimativa otimista do que autores reais proporcionariam. Pessoas reais responderão de forma menos completa e precisa. Os intervalos não levam em conta a variação entre execuções, e os 36 critérios foram avaliados sem correção para comparações múltiplas. Os autores publicam o arcabouço de testes, as 600 tarefas e todas as avaliações.

A conclusão prática para quem constrói agentes de geração de código: invista em esclarecer os requisitos antes da geração e não confie em LLMs como juízes nem em "reparos" automáticos de segurança sem validá-los com erros inseridos de propósito.