IBM: perguntas ao cliente antes da geração elevaram a precisão de smart contracts de 54% para 73%

Agentes baseados em grandes modelos de linguagem sabem transformar uma descrição em inglês simples em código que compila e roda. Mas, em geral, ninguém mede direito se esse código faz o que o autor queria. Para smart contracts, a questão é crítica: são programas em blockchain que guardam e transferem dinheiro por conta própria e não podem ser corrigidos depois de implantados.

Pesquisadores do IBM T.J. Watson Research Center pegaram 600 contratos existentes em Solidity, pediram a um modelo que descrevesse cada um em palavras e, em seguida, instruíram agentes de IA a escrever o contrato novamente.

A precisão foi calculada pela fração de transações em que o novo contrato se comporta como o original. O melhor pipeline atingiu 72,9% em 500 contratos reservados para teste. A geração "de uma só vez" ficou em 53,9%, e o pipeline anterior dos próprios autores, em 39,3%.

O que mais ajudou foram as perguntas ao cliente antes de escrever o código.

O que, na prática, se media como "compreensão"

A primeira parte do trabalho trata dos próprios instrumentos de medição, e as conclusões são desconfortáveis. Os pesquisadores inseriram manualmente uma única regra errada em contratos reais e observaram se o verificador percebia.

• O analisador estático Slither, voltado a classes conhecidas de vulnerabilidades, só emitiu um novo alerta em 3 das 200 remoções de verificação de acesso. • Um modelo de linguagem atuando como juiz, que lê o código, encontra muitos erros, mas marca 80% dos contratos intactos como problemáticos. Quando se exige dele uma prova executável, há menos falsos alarmes, mas ele detecta apenas 30%. • Um modelo de referência em Python, escrito a partir da descrição, detecta 94,3% dos erros típicos, como um modifier removido ou uma comparação invertida. Mas um modelo equivalente, escrito apenas a partir dos nomes das funções, detecta 87,5%.

O último número é importante. Ele indica que boa parte do que os testes comuns tomam por compreensão da tarefa é, na verdade, conhecimento de padrões consagrados, algo que qualquer modelo forte possui. Por isso, daí em diante os autores avaliaram apenas as regras específicas de cada contrato.

A precisão de reprodução, por sua vez, foi calculada de forma estrita. De cada contrato, foram geradas 60 sequências aleatórias de 8 chamadas. As mesmas chamadas rodaram no original e na cópia, e um passo só contava como acerto se o resultado fosse igual e os mesmos valores observáveis tivessem mudado. Uma função ausente ou uma assinatura diferente significava falha no passo.

Onde a intenção se perde

A descrição curta, de 140 palavras, omite muitos detalhes. A verificação mostrou que 76 de 100 descrições desse tipo contêm ao menos uma contradição direta com o contrato, por exemplo "o administrador pode abrir o leilão", quando na prática qualquer pessoa pode abri-lo. Em média, faltam 14,9 regras. A descrição completa, de 1700 palavras, elimina o problema.

No experimento, o modelo de referência, a partir da descrição curta, pegou 65,9% dos erros específicos do contrato; a partir da completa, 87,5%. A diferença foi de 21,6 pontos. Os contratos escritos pelo gerador (GPT-5.4-mini, 92 contratos) mostraram o mesmo quadro:

• descrição curta: 55,6%; • mais respostas às perguntas de um agente entrevistador: 79,4%; • mais respostas a dez perguntas fixas: 76,0%; • descrição completa: 91,0%.

Com o Claude Sonnet 5, o resultado subiu de 56,1% para 75,1%; com o Gemini 3.5 Flash, de 51,8% para 74,5%. Um exemplo do estudo: a descrição de um contrato de gestão de liquidez listava estados e operações, mas não dizia quem podia chamá-los. O modelo acrescentou o papel de proprietário, e o contrato coincidiu com apenas 25% das transações. Uma única resposta do cliente, "todas as operações estão abertas a qualquer conta", elevou a coincidência a 100%.

As verificações após a geração quase não ajudam: todas as etapas testadas juntas somam cerca de um ponto. O ciclo automático que reescreve o código com base nos alertas de um auditor de segurança tira 12,8 pontos, porque, junto com o comportamento arriscado, remove também o comportamento necessário.

Quantas perguntas são necessárias e quais as ressalvas

O pipeline com perguntas começa interrogando o cliente com base em um checklist. Depois, compara o contrato com um modelo de referência escrito de forma independente e mostra ao cliente cada divergência como uma escolha às cegas entre duas opções. Os alertas de segurança são apenas reportados; o pipeline não reescreve o código. De três a cinco perguntas bem escolhidas bastam para recuperar de 60% a 75% do ganho.

A principal ressalva: o cliente foi simulado pelo GPT-5.4, que tinha diante de si o próprio contrato original. O ganho de 19 a 23 pontos nas três famílias de geradores é, portanto, uma estimativa otimista do que um autor humano proporcionaria. Além disso, os originais também são imperfeitos: no conjunto de dados de origem, 35,1% dos 21 976 contratos têm stubs e 27,8% têm corpos de função compostos só de comentários, e esses casos foram filtrados. O ganho se manteve também em 24 descrições sem contradições, embora, com uma amostra desse tamanho, não seja possível distinguir os subgrupos.

Para engenheiros, a conclusão é simples. Se um agente escreve código que movimenta dinheiro, vale investir primeiro no esclarecimento dos requisitos, e não em etapas extras de verificação. A "correção" automática com base em relatórios de segurança precisa ser medida separadamente, porque pode quebrar o comportamento necessário. Os autores publicaram o ambiente de testes, as tarefas e todas as avaliações.