IBM muestra que preguntar al cliente antes de generar eleva al 72,9% la fidelidad de los contratos inteligentes por transacciones

Los sistemas de agentes que convierten una descripción en inglés en código ya son rutina, y el código suele compilar. Pero casi nadie mide con herramientas validadas si el comportamiento del programa coincide con la intención del autor. Investigadores de IBM T.

J. Watson Research Center lo estudiaron en contratos inteligentes de Solidity: no se pueden corregir tras el despliegue y manejan dinero, así que un error sale caro. La métrica principal del trabajo es la fidelidad por transacciones, es decir, la proporción de transacciones reproducidas en las que el contrato generado se comporta igual que el original.

Un pipeline que primero hace preguntas al cliente alcanzó un 72,9% en 500 contratos reservados para la prueba. La generación con una sola consulta logró un 53,9% y el anterior pipeline de siete etapas de los autores, un 39,3%. La mayor parte de la intención se pierde antes de la generación, y lo que más ayuda es aclarar los requisitos, no añadir etapas de verificación.

Cómo se midió la fidelidad

Los autores tomaron 600 contratos reales del conjunto FSM-SCG. Para cada uno, Gemini 2.5 Flash redactó una descripción breve de unas 140 palabras y un documento completo de requisitos de unas 1700 palabras. La métrica principal es la implementation fidelity, esto es, la exactitud con que se reproduce el comportamiento del original. Para cada contrato se ejecutaron 60 secuencias aleatorias de 8 pasos en una máquina virtual EVM local. Un paso cuenta solo si coinciden el resultado de la llamada y todos los valores observables. Los autores advierten de que la métrica refleja la intención del autor únicamente en la medida en que el contrato original la encarna.

Primero evaluaron las propias herramientas de medición con errores insertados. El analizador estático Slither detectó un problema nuevo solo en 3 de 200 comprobaciones de acceso eliminadas. Un juez LLM que lee el código marca como problemáticos el 80% de los contratos intactos, y exigir una prueba ejecutable reduce al 30% la proporción de errores que encuentra. Un modelo de referencia en Python, escrito a partir de la descripción, detecta el 94,3% de los errores típicos, como los modificadores eliminados. Pero el mismo modelo, escrito solo a partir de los nombres de las funciones, detecta el 87,5%. Es decir, buena parte de las evaluaciones clásicas premia el conocimiento de convenciones generales, no la comprensión de la descripción.

Dónde se pierde la intención

En 100 contratos nuevos y 279 errores específicos de cada contrato, el modelo de referencia encontró el 65,9% de los errores con la descripción breve y el 87,5% con el documento completo. La diferencia fue de 21,6 puntos. Un agente extractor y un agente crítico no cambiaron nada. Una lista de diez preguntas fijas al cliente cerró la brecha casi por completo: 89,4% frente al 88,9% del documento completo.

Con el generador GPT-5.4-mini, la fidelidad por transacciones es del 55,6% con la descripción breve, del 76,0% con las respuestas a la lista, del 79,4% con las respuestas del entrevistador y del 91,0% con el documento completo. La lista tiene un punto débil: describe el comportamiento, pero no los tipos de los argumentos ni los valores almacenados, por lo que implementa el 88,7% de las firmas necesarias frente al 94,8% del entrevistador. La mejora se repitió en otras familias de modelos: Claude Sonnet 5 pasó del 56,1% al 75,1% y Gemini 3.5 Flash, del 51,8% al 74,5%. En las tres familias de modelos, los autores estiman la ganancia de las respuestas del cliente simulado en 19–23 puntos.

Las descripciones tampoco son fiables. Un modelo auditor encontró al menos una contradicción con el original en 76 de 100 descripciones, por ejemplo una regla de acceso inexistente. Por eso, aclarar a menudo corrige afirmaciones falsas, y no solo rellena huecos. Entre las 24 descripciones sin contradicciones se mantiene la mejora de la lista, pero la muestra es demasiado pequeña para una comparación rigurosa.

Cuántas preguntas hacen falta y qué no funciona

Tres a cinco preguntas cuidadosamente elegidas recuperan entre el 60% y el 75% de la mejora total. Las etapas posteriores a la generación añaden como máximo un punto, y un ciclo automático de corrección de seguridad resta 12,8 puntos: elimina comportamiento necesario junto con las vulnerabilidades. El pipeline final primero hace preguntas al cliente, después contrasta el contrato con un modelo de referencia independiente y muestra las discrepancias al cliente como una elección a ciegas. Los hallazgos de seguridad solo los señala, sin reescribir el código.

Las limitaciones son importantes. El cliente lo simula GPT-5.4, que lee el contrato original, así que la mejora es una estimación optimista de lo que aportarían autores reales. Las personas reales responderán de forma menos completa y precisa. Los intervalos no tienen en cuenta la variación entre ejecuciones, y 36 criterios se evaluaron sin corrección por comparaciones múltiples. Los autores publican el entorno de pruebas, las 600 tareas y todas las puntuaciones.

La conclusión práctica para quienes construyen agentes de generación de código: invertir en aclarar los requisitos antes de generar, y no confiar en jueces LLM ni en la «reparación» automática de seguridad sin comprobarlos antes con errores insertados.