IBM: preguntar al cliente antes de generar elevó la precisión de los contratos inteligentes del 54% al 73%

Los agentes basados en grandes modelos de lenguaje saben convertir una descripción en inglés corriente en código que compila y se ejecuta. Pero casi nadie mide de forma rigurosa si ese código hace lo que quería su autor. En los contratos inteligentes la pregunta es especialmente delicada: son programas en una blockchain que almacenan y transfieren dinero por sí mismos y que no se pueden corregir una vez lanzados.

Investigadores de IBM T.J. Watson Research Center tomaron 600 contratos existentes en Solidity, pidieron a un modelo que describiera cada uno con palabras y luego encargaron a agentes de IA que escribieran el contrato de nuevo.

La precisión se calculó como la proporción de transacciones en las que el nuevo contrato se comporta igual que el original. El mejor pipeline obtuvo un 72,9% en 500 contratos reservados para la prueba. La generación «en un solo intento» dio un 53,9% y el pipeline anterior de los propios autores, un 39,3%.

Lo que más ayudó fueron las preguntas al cliente antes de escribir el código.

Qué se midió realmente como «comprensión»

La primera parte del trabajo se centra en los propios instrumentos de medición, y sus conclusiones son incómodas. Los investigadores introdujeron a mano una única regla errónea en contratos reales y comprobaron si el verificador lo detectaba.

• El analizador estático Slither, especializado en clases conocidas de vulnerabilidades, solo emitió una observación nueva en 3 de 200 comprobaciones de acceso eliminadas. • Un modelo de lenguaje que actúa como juez y lee el código encuentra muchos errores, pero marca como defectuosos el 80% de los contratos sin modificar. Si se le exige una prueba ejecutable, hay menos falsas alarmas, pero solo detecta el 30%. • Un modelo de referencia en Python, escrito a partir de la descripción, detecta el 94,3% de los errores típicos, como un modificador eliminado o una comparación invertida. Sin embargo, un modelo equivalente escrito solo a partir de los nombres de las funciones detecta el 87,5%.

La última cifra es importante. Significa que buena parte de lo que las pruebas habituales toman por comprensión de la tarea es, en realidad, conocimiento de patrones generalizados que tiene cualquier modelo potente. Por eso los autores evaluaron después únicamente las reglas específicas de cada contrato.

La precisión de reproducción se calculó con criterios estrictos. De cada contrato se generaron 60 secuencias aleatorias de 8 llamadas. Esas mismas llamadas se ejecutaron sobre el original y sobre la copia, y un paso solo se daba por válido si coincidía el resultado y cambiaban los mismos valores observables. Una función ausente o una firma distinta contaban como fallo del paso.

Dónde se pierde la intención

La descripción corta, de 140 palabras, omite muchos detalles. La comprobación mostró que 76 de cada 100 descripciones de ese tipo contienen al menos una contradicción directa con el contrato; por ejemplo, «el administrador puede abrir la subasta», cuando en realidad puede abrirla cualquiera. En promedio faltan 14,9 reglas. La descripción completa, de 1700 palabras, elimina el problema.

En el experimento, el modelo de referencia detectó el 65,9% de los errores específicos del contrato con la descripción corta y el 87,5% con la completa. La diferencia fue de 21,6 puntos. Los contratos escritos por el generador (GPT-5.4-mini, 92 contratos) mostraron el mismo patrón:

• descripción corta: 55,6%; • más respuestas a las preguntas de un agente entrevistador: 79,4%; • más respuestas a diez preguntas fijas: 76,0%; • descripción completa: 91,0%.

Con Claude Sonnet 5 el resultado subió del 56,1% al 75,1%, y con Gemini 3.5 Flash, del 51,8% al 74,5%. Un ejemplo del estudio: la descripción de un contrato de gestión de liquidez enumera estados y operaciones, pero no indica quién puede invocarlos. El modelo añadió el rol de propietario y el contrato coincidió solo con el 25% de las transacciones. Una única respuesta del cliente, «todas las operaciones están abiertas a cualquier cuenta», elevó la coincidencia al 100%.

Las comprobaciones posteriores a la generación casi no ayudan: todas las etapas probadas juntas suman alrededor de un punto. Un ciclo automático que reescribe el código según las observaciones de un auditor de seguridad resta 12,8 puntos, porque elimina tanto el comportamiento arriesgado como el necesario.

Cuántas preguntas hacen falta y qué salvedades hay

El pipeline con preguntas empieza interrogando al cliente con una lista de verificación. Después contrasta el contrato con un modelo de referencia escrito de forma independiente y presenta cada discrepancia al cliente como una elección a ciegas entre dos variantes. Las observaciones de seguridad solo las comunica; no reescribe el código. Bastan de tres a cinco preguntas bien elegidas para recuperar entre el 60% y el 75% de la mejora.

La principal salvedad: el papel del cliente lo hizo GPT-5.4, que tenía delante el contrato original. Por tanto, la mejora de 19–23 puntos en las tres familias de generadores es una estimación optimista de lo que aportaría un autor real. Además, los originales tampoco son perfectos: en el conjunto de datos de partida, el 35,1% de los 21 976 contratos tiene funciones vacías a modo de relleno y el 27,8% tiene cuerpos de función compuestos solo por comentarios; esos casos se filtraron. La mejora se mantuvo también en 24 descripciones sin contradicciones, aunque con una muestra así no es posible distinguir los subgrupos.

Para los ingenieros, la conclusión es sencilla. Si un agente escribe código que mueve dinero, conviene invertir primero en aclarar los requisitos y no en etapas adicionales de verificación. La «reparación» automática a partir de informes de seguridad hay que medirla por separado: puede romper el comportamiento necesario. Los autores han publicado el banco de pruebas, las tareas y todas las evaluaciones.