Nota del editor: En los últimos años, la competencia en IA visual se ha centrado casi exclusivamente en una pregunta: ¿quién genera imágenes más realistas, quién produce vídeos más fluidos? Los modelos de difusión han convertido las instrucciones de texto en imágenes, vídeos y escenas realistas, acostumbrando también al público a juzgar la capacidad de los modelos por "lo parecido que es" o "lo bonito que es".
Pero este artículo de a16z señala que la próxima etapa de la IA visual puede que no consista únicamente en generar píxeles más atractivos, sino en generar los artefactos de código (code artifact, archivos estructurados que se pueden seguir editando, probar y entregar) que hay detrás de esos píxeles.
Esta diferencia, aunque técnica, determina si la IA puede integrarse realmente en los flujos de trabajo de producción. Un diseñador no necesita solo una captura de pantalla de una interfaz de usuario, necesita HTML/CSS, componentes de React, capas y archivos entregables; un animador no necesita solo un vídeo, necesita fotogramas clave, curvas de tiempo y parámetros de movimiento editables; un artista 3D no necesita solo una imagen renderizada, necesita estructuras geométricas, materiales, iluminación, cámaras y jerarquía de escena.
Por lo tanto, el artículo divide la generación visual en dos caminos: la generación nativa de píxeles (generar imágenes o vídeos directamente) es adecuada para el realismo, la atmósfera y la exploración; la generación nativa de código (generar SVG, Lottie, scripts de Blender, escenas USD, etc.) es más adecuada para la edición, iteración y producción. Lo realmente importante de esta última es que puede formar un ciclo cerrado de "código → renderizado → comprobación → modificación". El modelo ya no se limita a remuestrear una y otra vez, sino que está depurando un programa visual verificable.
Por eso el autor tiene especial optimismo con el 3D. Porque una imagen renderizada de una silla no es una silla, es solo una imagen de una silla. Un activo realmente utilizable en un juego, un simulador o una herramienta 3D debe tener una estructura geométrica estable, una jerarquía de componentes, materiales y restricciones funcionales: una puerta debe poder abrirse, un cajón debe poder deslizarse, una rueda debe poder girar. En otras palabras, el valor futuro de la IA visual no radica en "parecerse", sino en "poder seguir utilizándose".
Este artículo proporciona un buen marco de juicio: la primera ola de IA visual resolvió el problema de la generación; la próxima debe resolver el problema de la producción. Cuando la IA visual pase de la salida final al código fuente, lo que realmente cambiará no serán solo las herramientas de diseño, sino toda la cadena de producción de contenido visual.
A continuación, el texto original:
En los últimos años, la IA visual se ha juzgado principalmente por sus "píxeles". Cuanto mejor se vea la imagen o el vídeo generado, más potente parece el modelo.
Esto no es sorprendente. Los modelos de difusión primero convirtieron las instrucciones de texto en imágenes atractivas, luego se expandieron a vídeos y después a mundos cada vez más realistas. Es natural compararlos con Photoshop o una cámara.
Pero para muchas tareas relacionadas con lo visual, como el diseño gráfico, el diseño de UI o el modelado 3D, la representación final que los usuarios realmente necesitan no es solo los píxeles que se muestran. Necesitan un artefacto que pueda iterar continuamente según los comentarios y las nuevas ideas. Un diseñador no necesita solo un mockup (boceto de diseño), necesita capas, componentes y archivos entregables; un animador no necesita solo un vídeo, necesita curvas de tiempo, fotogramas clave y trayectorias de movimiento editables; un artista 3D no necesita solo una imagen renderizada, necesita estructuras geométricas, materiales, iluminación, cámaras y estructura de escena.
Las herramientas de IA visual más interesantes hoy en día ya no intentan generar directamente la salida final. Están empezando a generar el código fuente que hay detrás de esa salida final. Este cambio está liberando la editabilidad, la capacidad de iteración y los ciclos de retroalimentación, que son difíciles de igualar para los modelos nativos de píxeles.
Dos pilas tecnológicas para la generación visual
Podemos entender la generación visual de dos formas principales.
La primera es la generación nativa de píxeles. Estos sistemas suelen generar imágenes o vídeos directamente, a menudo en un espacio latente. Son buenos en texturas, atmósfera, iluminación y realismo. Si el objetivo es generar una toma cinematográfica, un moodboard (tablero de inspiración) atractivo o una imagen fotorrealista, los modelos de difusión siguen siendo el método dominante.
La segunda es la generación nativa de código. Estos sistemas generan una representación que luego es ejecutada o renderizada por otro motor. El modelo no genera directamente los píxeles finales, sino que genera un programa capaz de producir esos píxeles.
Este programa puede ser un archivo SVG, un esquema de maquetación HTML/CSS, un componente React, un archivo JSON Lottie, un script de Blender, un gráfico de escena USD, un shader (sombreador) o una escena de motor de juego. La salida visual final siguen siendo píxeles, pero la verdadera "fuente de verdad" es una representación estructurada.
Esta diferencia es importante porque los flujos de trabajo de producción se preocupan mucho por "lo que ocurre después de la generación". Una imagen generada puede usarse como salida, pero un programa visual generado puede usarse como un artefacto: puede ser editado, reutilizado, mejorado, versionado; puede integrarse en la pila tecnológica de software y validarse según restricciones; puede renderizarse repetidamente bajo diferentes condiciones y pasarse entre diseñadores, ingenieros y agentes.
Creo que ya está ocurriendo un cambio importante: para una parte de los problemas visuales, aprenderemos a replantear la tarea de generación visual como una tarea de codificación, y al resolver un problema de codificación bien definido y verificable, obtendremos mejoras altamente eficientes.
El código es un buen vehículo para resolver problemas visuales
La forma más sencilla de entender el valor de la generación de código visual es ver qué ocurre después del primer borrador.
Supongamos que un modelo genera un logotipo. Si la salida es una imagen rasterizada y una curva está mal, el usuario debe enmascarar, retocar localmente, regenerar o redibujar manualmente. Pero si la salida es SVG, el usuario puede editar directamente los trazados, formas básicas, degradados, trazos o elementos de texto. Así es ya como diseñan logotipos en Quiver.
En el ámbito del diseño de UI, si la salida es una captura de pantalla, sirve más como referencia de inspiración. Pero si la salida es HTML/CSS o React, el diseñador puede inspeccionar el DOM, reemplazar componentes reales, probar estados responsivos, comprobar la accesibilidad e integrarlo en una aplicación.
Por eso la generación de código visual es especialmente adecuada para la computación en tiempo de prueba (test-time compute). En la generación nativa de píxeles, aumentar el cómputo de inferencia suele significar muestrear más salidas: generar 20 imágenes, elegir la mejor, quizás intentarlo de nuevo. Es útil, por supuesto, pero cada intento es esencialmente como volver a tirar los dados. El modelo puede responder a los comentarios, pero estos suelen ser generales y poco precisos.
Técnicamente, los modelos de difusión también pueden beneficiarse de la computación en tiempo de prueba. Por ejemplo, "Inference-time Scaling of Diffusion Models through Classical Search" muestra que la búsqueda en fase de inferencia puede mejorar el rendimiento de los modelos de difusión en planificación, aprendizaje por refuerzo y generación de imágenes. Pero el mecanismo de ciclo es diferente aquí. En los modelos de difusión, el sistema suele buscar entre trayectorias latentes o muestras finales. Una señal de recompensa puede decirle al modelo que una salida es mejor que otra, pero no puede mapear claramente la retroalimentación a una modificación concreta a nivel de código fuente.
La generación nativa de código crea un ciclo más preciso: código → renderizado → comprobación → modificación.
El modelo genera el artefacto, lo renderiza, observa dónde falla y luego corrige el archivo fuente. Si el espaciado está mal, modifica el CSS; si una curva del logotipo se desvía, edita el trazado SVG; si el ritmo de una animación es demasiado lento, ajusta los parámetros de tiempo. La clave está en que cada iteración mejora el artefacto subyacente, no solo la salida renderizada. Por eso la generación de código visual se beneficia naturalmente de la generación de más tokens y de la computación en tiempo de prueba. El modelo está depurando un programa visual en un entorno cerrado y verificable, no solo muestreando más imágenes.
Pila tecnológica de generación visual centrada en código
Detrás de estos ejemplos hay una pila tecnológica: modelo de codificación + representación simbólica + renderizador o motor.
El modelo de codificación es el autor y editor del artefacto. Es responsable de escribir HTML, SVG, JSON Lottie, scripts de Blender, escenas USD o programas personalizados para activos 3D.
La representación simbólica es la fuente de verdad. Esto es lo que hace que el artefacto sea editable. Una UI tiene nodos DOM, reglas de maquetación y componentes; una animación Lottie tiene capas, formas vectoriales, curvas de tiempo, fotogramas clave y parámetros de movimiento; un activo 3D tiene estructuras geométricas, materiales, articulaciones, restricciones y relaciones jerárquicas.
El renderizador o motor convierte estas estructuras en píxeles. El navegador renderiza HTML/CSS, un renderizador SVG renderiza gráficos vectoriales, un reproductor Lottie renderiza animaciones, Blender o un motor de juego renderiza escenas 3D, y un simulador verifica si un activo articulado realmente puede moverse o interactuar.
OmniLottie es un buen ejemplo de por qué es importante la representación simbólica. Lottie es un formato de animación ligero basado en JSON; no representa la animación como un vídeo plano, sino como formas vectoriales editables, capas, fotogramas clave y parámetros de tiempo que representan el movimiento. OmniLottie propone convertir el JSON Lottie original en una secuencia de comandos más adecuada para la comprensión del modelo, permitiendo que el modelo genere y edite animaciones Lottie de forma más fiable. El foco de este artículo no es construir un ciclo de agente completo, sino hacer que Lottie sea más adecuado para la generación por modelos: convierte el JSON Lottie original en un conjunto compacto de secuencias de comandos y parámetros. Este paso es clave porque Lottie ya es en sí mismo un formato de animación editable. Una vez que el movimiento se representa como formas, capas, tiempo y parámetros de animación, los comentarios se pueden mapear a modificaciones a nivel de archivo fuente. Si un objeto se mueve demasiado lento, se ajusta el tiempo; si un trazado está mal, se modifica el vector; si una transformación se desvía, se actualiza la secuencia de formas.
Esta pila tecnológica se corresponde precisamente con el ciclo de computación en tiempo de prueba que los agentes de codificación pueden utilizar para mejorar la calidad de la salida: en cada ciclo de "código → renderizado → comprobación → modificación", el modelo no está simplemente generando una nueva muestra, sino que está utilizando la retroalimentación proporcionada por el renderizador para mejorar el artefacto subyacente. Puede modificar reglas CSS, ajustar trazados SVG, corregir tiempos de animación o actualizar restricciones 3D, luego renderizar de nuevo y seguir mejorando.
Esto hace que el ciclo pueda converger. En la generación nativa de píxeles, cada reintento suele producir una nueva salida. En la generación nativa de código, cada reintento puede mejorar el propio artefacto fuente. El modelo no solo muestrea más imágenes o vídeos, sino que depura un programa visual en un entorno cerrado y renderizable.
Mapa del mercado: puntos de entrada formados en torno al runtime
El mercado de generación de código visual se está organizando en torno al "runtime", es decir, el lugar donde se renderiza o ejecuta el artefacto. En la generación visual nativa de código, el modelo genera un artefacto simbólico que luego se ejecuta en algún entorno: un navegador, un renderizador SVG, un reproductor Lottie, Blender, un motor de juego o un simulador.
Cada runtime formará un punto de entrada diferente, porque cada uno tiene su propia representación fuente, ciclo de retroalimentación y flujo de trabajo de producción.
La aplicación más evidente hoy en día está en el diseño 2D, especialmente en el diseño de UI y gráfico. Pero la generación de código visual no se limita a las herramientas de diseño. Siempre que exista una representación subyacente detrás de un artefacto visual que pueda ser generada, renderizada, inspeccionada y optimizada, es posible que aparezca.
Por qué el 3D es la próxima frontera importante
Aunque el diseño de productos y el diseño 2D son los casos de uso más intuitivos hoy en día, los artefactos 3D probablemente sean los que más se beneficien de este enfoque de "replantear los problemas de consistencia como problemas de codificación".
A veces, un diseño 2D ya es útil simplemente si parece correcto. Pero un activo 3D no. Una imagen renderizada de una silla no es una silla, es solo una imagen de una silla. Para que ese activo sea realmente utilizable en un juego, un simulador o una herramienta de edición 3D, debe tener una representación 3D subyacente consistente, incluyendo la estructura geométrica correcta, materiales, jerarquía de componentes y contexto de escena.
Por eso el 3D se adapta naturalmente a la generación de código visual. Su valor no es solo generar algo que parezca 3D desde un ángulo, sino generar una estructura 3D consistente que sea válida bajo diferentes perspectivas, ediciones e interacciones. Esto requiere un ciclo iterativo: proponer un objeto, renderizarlo, comprobar si la estructura geométrica y los componentes son razonables, y luego modificar la representación subyacente. Pero este ciclo solo es eficaz si el agente tiene las herramientas y el contexto correctos. Simplemente ejecutar Blender repetidamente hasta que algo se vea mejor no es suficiente. El agente necesita poder cambiar la vista de la cámara, consultar el estado de la escena, aislar objetos, comparar con objetivos, recordar intentos anteriores y convertir diferencias visuales en modificaciones a nivel de archivo fuente. Son estas capacidades las que dan al cómputo en tiempo de prueba la oportunidad de converger.
Para muchos activos, la consistencia visual es solo el requisito mínimo. Los objetos también necesitan una semántica de componentes correcta y restricciones funcionales: una puerta debería poder abrirse, una bisagra debería poder girar, un cajón debería poder deslizarse, una rueda debería poder girar. En otras palabras, la salida no puede ser solo una forma que parezca razonable, también debe funcionar como lo que representa.
Por eso son tan interesantes proyectos como VIGA y Articraft3D. Esperamos ver más trabajos relacionados este año, tanto comerciales como de código abierto. VIGA utiliza Blender como entorno de renderizado y retroalimentación, transformando la reconstrucción visual en un ciclo de "código—renderizado—comprobación"; pero VIGA no simplemente expone el Blender crudo a un ciclo de agente. Proporciona al agente herramientas semánticas para observar y modificar, y mantiene un recuerdo de intentos anteriores, permitiéndole inspeccionar objetos desde mejores perspectivas, diagnosticar problemas y realizar modificaciones específicas. Articraft3D aborda más directamente la estructura del activo: plantea la generación 3D articulada como la escritura de programas que definen componentes, estructuras geométricas, articulaciones y pruebas.
Impacto futuro y preguntas sin resolver
Si la generación de código visual realmente se consolida, los productos ganadores no solo generarán salidas más bonitas. Dominarán todo el ciclo: generar el artefacto, renderizarlo, comprobar dónde falla y modificar el archivo fuente.
Esto tendrá varias consecuencias.
En primer lugar, los renderizadores se convertirán en entornos de retroalimentación. Los navegadores, renderizadores SVG, reproductores Lottie, Blender, motores de juego y simuladores se convertirán en entornos donde los agentes prueban y mejoran sus creaciones, tal como los agentes de codificación están utilizando hoy en día sandboxes y máquinas virtuales.
En segundo lugar, la calidad del contexto de iteración será más importante que nunca. Para que un agente entre en la versión de código visual del "ciclo Ralph", la representación intermedia debe ser lo suficientemente precisa como para guiar el siguiente paso. El modelo necesita saber no solo que "algo no se ve bien", sino también qué parte del archivo fuente debe modificarse y por qué. Pequeños errores en la estructura, el renderizado o la retroalimentación pueden acumularse rápidamente en múltiples iteraciones.
En tercer lugar, el futuro probablemente será híbrido. Los modelos nativos de píxeles seguirán siendo los mejores en realismo, texturas y exploración; los sistemas nativos de código serán más adecuados para la estructura, iteración y producción. Los flujos de trabajo más útiles combinarán ambos.
Por supuesto, aún quedan muchas preguntas abiertas. ¿Qué representación adoptará finalmente cada campo? ¿Necesitaremos rediseñar motores y renderizadores en lugar de seguir utilizando las herramientas de la generación anterior? ¿Hasta qué punto se pueden capturar el gusto visual, las restricciones, las pruebas y los ciclos de retroalimentación?
Pero la dirección ya está clara: la IA visual está pasando de la salida a los artefactos de código. La primera ola hizo que generar imágenes fuera más fácil; la próxima ola hará que generar artefactos visuales editables, probables, entregables y mejorables sea más fácil.
