Qué hace el método
Un artículo publicado en arXiv el 28 de septiembre describe LEGO-Anything, un marco en el que un agente de código reconstruye una escena tridimensional a partir de una sola fotografía escribiendo y ejecutando código de Blender, observando el resultado y revisando el programa.
La salida no es una imagen renderizada ni una malla. Es un programa de escena: código ejecutable cuyos objetos, geometría y posición de cámara son explícitos y pueden inspeccionarse, editarse y consultarse después. Los autores defienden esa representación de forma directa: una reconstrucción “resulta más útil representada no como un renderizado ni como una salida 3D fija, sino como un programa de escena explícito cuya ejecución produce una escena que puede inspeccionarse, editarse y consultarse”.
El banco de pruebas y por qué importa su puntuación
El mismo trabajo presenta LEGO-Bench: 208 imágenes tomadas de 104 escenas de interior y exterior, puntuadas por separado en tres ejes: si el artefacto es válido, si la geometría de las superficies visibles coincide y si el renderizado se parece a la fotografía.
Mantener esos tres ejes separados es la decisión de diseño que produce el resultado del artículo. Una puntuación única y mezclada permitiría que un renderizado convincente tapase una geometría equivocada, que es justamente el fallo que cometen estos sistemas.
En ese banco de pruebas, GPT-6 Astra fue el agente más fuerte de los evaluados, con un 53,4% en interiores y un 39,6% en exteriores. LEGO-Plugin, un añadido que no requiere entrenamiento, mejoró los resultados en seis modelos con ganancias de hasta el 62,7%.
El hallazgo que conviene retener
La cifra principal es la de la autoevaluación. Cuando se pidió a los agentes que juzgaran la precisión geométrica de sus propias reconstrucciones, rindieron al nivel del azar o por debajo.
Eso es un fallo distinto de ser inexacto. Un agente que construye una escena equivocada y lo sabe puede iterar hacia una correcta; uno que no lo distingue no tiene gradiente que seguir. Los autores identifican tres problemas recurrentes en las trazas de construcción —inicialización débil de la escena, ediciones durante la iteración que empeoran en vez de mejorar, y autoevaluación poco fiable— y el tercero es lo que hace posible el segundo.
La lectura práctica es que el bucle que ejecutan estos agentes —escribir código, mirar el resultado, revisar— solo se cierra si el paso de mirar funciona. Aquí no funciona.
Qué vigilar
El artículo es un preprint y el banco de pruebas es nuevo, así que las puntuaciones son un punto de partida, no una clasificación. Lo más útil que vigilar es si un verificador aparte —una comprobación geométrica que el agente no se aplica a sí mismo— cierra la brecha. Es la misma forma que ha adoptado otro trabajo de ciencia con agentes: el modelo propone y algo distinto decide si acertó.
