Codex ahora puede ver su propio código — y eso lo cambia todo
La semana pasada vi a un asistente de programación con IA mirar un boceto en pizarra — un rectángulo tosco, dibujado a mano, con algunos círculos ondulados y flechas — y convertirlo en un globo 3D interactivo y funcional con pines de destino clicables, animaciones fluidas y diseños responsivos para móvil. Después abrió un navegador, tomó una captura de pantalla de lo que había construido, notó que las etiquetas de los pines se superponían en pantallas más pequeñas y corrigió el CSS sin que nadie se lo pidiera.
Esa última parte fue lo que me dejó helado. No la generación de código — llevo dos años viendo generación de código impresionante. La parte donde la IA miró su propia salida, identificó un problema visual y lo corrigió de forma autónoma. Eso no es un asistente de programación. Es un asistente de programación con ojos.
Codex de OpenAI lleva un tiempo con capacidades multimodales, pero las últimas demostraciones muestran algo cualitativamente diferente de lo que había probado antes. El sistema ahora ejecuta un bucle continuo: generar código, renderizar el resultado, capturar la salida en pantalla, analizar la captura en busca de problemas, corregir los problemas, volver a capturar. Imita — y en algunos casos supera — el flujo de trabajo que un desarrollador front-end humano sigue naturalmente: escribir código, revisar el navegador, ajustar, revisar de nuevo.
He pasado la última semana llevando este flujo de trabajo al límite en tres proyectos. Los resultados me obligaron a replantear por completo cómo abordo el desarrollo front-end. No porque Codex sea perfecto — definitivamente no lo es, y te mostraré exactamente dónde falla. Sino porque el bucle de auto-verificación resuelve el mayor problema del código de interfaz generado por IA: la brecha entre lo que la IA cree que construyó y lo que realmente se renderiza en pantalla.
Déjame mostrarte cómo funciona en la práctica, dónde está la verdadera magia y por qué las demos impresionantes ocultan algunas limitaciones reales que necesitas conocer.
El problema que todas las herramientas de programación con IA tienen (tenían)
Esta es una frustración con la que he convivido desde la primera vez que usé una IA para generar código front-end. Describes un diseño. La IA escribe HTML y CSS. Lo renderizas en el navegador. Y se ve... mal. No mal-roto. Sutilmente mal. El espaciado está desfasado. Los elementos se superponen en ciertos anchos de viewport. Un botón que debería estar centrado está doce píxeles a la izquierda de donde debería estar. Los colores que parecían correctos en el código se ven turbios contra el fondo real.
Entonces describes los problemas. La IA ajusta. Vuelves a renderizar. Sigue sin estar del todo bien. Tres o cuatro rondas de esto y has pasado más tiempo describiendo problemas visuales en texto del que habrías pasado simplemente escribiendo el CSS tú mismo.
El problema de fondo: las herramientas de programación con IA generan código a ciegas. Producen tokens que representan HTML y CSS, pero no tienen un modelo visual de cómo esos tokens se van a renderizar. Es como pedirle a alguien que pinte un retrato con los ojos vendados — conocen la teoría de dónde van los ojos y la nariz, pero no pueden ver el resultado.
Todo desarrollador que ha usado Claude, Cursor, Copilot o cualquier asistente de programación con IA para trabajo front-end ha chocado con esta pared. El código es sintácticamente correcto. La estructura es razonable. Pero la salida renderizada no coincide con lo que tú — o la IA — pretendían. Y el único mecanismo de retroalimentación eres tú, el humano, describiendo problemas visuales con palabras y esperando que la IA interprete esas descripciones correctamente.
El bucle de auto-verificación multimodal de Codex rompe este ciclo por completo. La IA genera código, lo renderiza en un entorno de navegador real, toma una captura de pantalla y usa su modelo de visión para analizar la salida visual real. Si algo se ve mal — elementos superpuestos, diseños rotos, componentes desalineados — ve el problema de la misma forma que tú lo verías y lo corrige antes de que tengas que describirlo.
Eso no es una mejora incremental en la generación de código. Eso es cerrar el bucle de retroalimentación que ha estado abierto desde que aparecieron los asistentes de programación con IA. Y las implicaciones prácticas son más grandes de lo que la mayoría de la gente cree.
Viendo a Codex construir un globo 3D a partir de un boceto en pizarra
La demo que me convenció de tomar esto en serio involucraba una aplicación de viajes llamada Wonderlust. El equipo esbozó ideas en una pizarra física — dibujos toscos, etiquetas escritas a mano, flechas conectando conceptos. Alguien tomó una foto de la pizarra y se la pasó directamente a Codex como prompt.
Lo que sucedió después tomó unos ocho minutos.
Codex analizó el boceto. Identificó los elementos de interfaz pretendidos: un globo 3D para descubrir destinos de viaje, pines clicables en el globo para ubicaciones específicas, un panel de detalles que se desliza al tocar un pin y navegación por teclado para rotar el globo. A partir de una foto de un dibujo en pizarra.
Luego empezó a programar. Three.js para el renderizado del globo. Animaciones CSS para la rotación suave. Manejadores de eventos para las interacciones de clic y entrada por teclado. Un diseño responsivo que adapta el tamaño del globo y la posición del panel de detalles para pantallas móviles.
Pero aquí está la parte que las demos suelen saltarse y la que más importa: después de generar la implementación inicial, Codex abrió un navegador, renderizó la aplicación y tomó una captura de pantalla. El globo estaba ahí. Los pines estaban colocados. Pero el panel de detalles estaba parcialmente oculto detrás del globo en viewports de ancho de tablet. Codex vio esto en la captura, identificó el conflicto de z-index y posicionamiento, ajustó el CSS y volvió a renderizar. La segunda captura mostraba un diseño limpio.
Detectó un bug de diseño responsivo que yo — un desarrollador que construye diseños responsivos regularmente — podría haber pasado por alto en la primera revisión. No porque sea descuidado, sino porque probar cada ancho de viewport manualmente es tedioso y todos tomamos atajos. Codex no toma atajos porque la verificación visual es parte de su bucle automatizado, no un paso manual que pueda saltarse.
La implementación de Three.js en sí era sólida. No optimizada para producción — cargaba la biblioteca completa de Three.js en lugar de hacer tree-shaking para incluir solo los módulos necesarios — pero funcionalmente completa con iluminación adecuada, interpolación suave de rotación y posicionamiento correcto de los pines sobre la superficie del globo. El tipo de código que un desarrollador front-end de nivel medio produciría en un buen día, entregado en minutos a partir de una foto de pizarra.
Quiero ser preciso sobre qué me impresionó y qué no. La velocidad de generación de código es impresionante pero no única — Claude y GPT-4o también pueden generar código de Three.js rápidamente. La entrada multimodal (de boceto en pizarra a código) es impresionante pero ha existido en diversas formas. Lo que es genuinamente nuevo es el bucle cerrado: generar, renderizar, ver, corregir. Ese bucle es lo que convierte una "demo impresionante" en un "flujo de trabajo realmente útil".
La función de registro de viajes: donde la auto-verificación realmente brilla
La segunda parte de la demo construyó una pantalla de Registro de Viajes — un panel de control mostrando estadísticas de viaje con listas de verificación interactivas, gráficos circulares y seguimiento de progreso gamificado. Continentes visitados, fotos tomadas, platos locales probados, ese tipo de cosas.
Este es exactamente el tipo de interfaz que las herramientas de programación con IA suelen arruinar. Los paneles de control tienen diseños complejos con múltiples componentes de visualización de datos, tamaños de tarjetas variados, tipografía mixta y jerarquía de información densa. Hacer bien una tarjeta es fácil. Hacer que doce tarjetas coexistan armoniosamente en una sola pantalla, con espaciado adecuado y ritmo visual en escritorio y móvil, es donde los diseños generados por IA típicamente empiezan a parecer un cajón de sastre.
Codex generó el diseño inicial del panel de control, lo renderizó y tomó una captura. La primera pasada tenía dos problemas visibles: la leyenda de un gráfico circular se truncaba en móvil y el espaciado entre las tarjetas de estadísticas era inconsistente (algunas tenían separaciones de 16px, otras de 24px). Codex identificó ambos problemas a partir de la captura, corrigió el desbordamiento de la leyenda con un diseño de ajuste flexible, estandarizó el espaciado de las tarjetas y volvió a renderizar.
La segunda captura estaba limpia. Espaciado consistente, leyendas legibles, jerarquía adecuada. Dos problemas visuales detectados y corregidos en menos de un minuto, sin intervención humana alguna.
Deliberadamente probé si la auto-verificación era genuina o teatral, dándole a Codex un prompt de panel de control más complejo para uno de mis propios proyectos. Le pedí que construyera un panel de visualización de datos a partir de un boceto tosco que dibujé en mi iPad — intencionalmente desordenado, con anotaciones superpuestas y tamaños de elementos ambiguos.
El primer diseño generado tenía tres problemas que pude detectar: un gráfico de barras era demasiado ancho para su contenedor, un encabezado estaba desalineado con la cuadrícula y una sección desplazable en realidad no se desplazaba. La auto-verificación de Codex detectó dos de los tres. Corrigió el ancho del gráfico y la alineación del encabezado. No detectó el problema de desplazamiento — la captura mostraba la sección en su altura predeterminada, lo que no revelaba el problema de desbordamiento.
Dos de tres no es perfecto. Pero dos de tres detectados automáticamente son dos cosas menos que tuve que describir en texto esperando que la IA entendiera. Eso es un ahorro de tiempo real, y se acumula en cada tarea front-end.
De bocetos en servilletas a mockups de Figma: la flexibilidad de entrada
Una de las capacidades más prácticas de Codex es la variedad de entradas visuales que acepta. Probé cuatro niveles de fidelidad de entrada para ver cómo escalaba la calidad de la salida.
Boceto en pizarra — tosco, dibujado a mano, proporciones ambiguas. Codex interpretó correctamente el diseño general y los tipos de elementos, pero tomó sus propias decisiones sobre espaciado, dimensionado y estilo. La salida fue funcional pero requería un refinamiento significativo para coincidir con una visión de diseño específica. Bueno para prototipado rápido cuando no te importa la precisión al píxel.
Dibujo en iPad con anotaciones — más limpio que la pizarra, con secciones codificadas por colores y etiquetas de texto especificando cosas como "esta sección se desplaza" o "tarjetas en una cuadrícula de 3 columnas". Codex siguió las anotaciones con precisión aproximadamente el 80% de las veces. La codificación por colores le ayudó a distinguir entre diferentes secciones de la interfaz. Salida notablemente mejor que el boceto tosco en pizarra.
Captura de pantalla de la interfaz de un competidor — le pasé a Codex una captura de un panel de control de un producto SaaS y le pedí que "construyera algo con este diseño pero con la paleta de colores de nuestra marca". La reproducción estructural fue excelente — misma cuadrícula, misma jerarquía de componentes, mismos breakpoints responsivos. El estilo fue apropiadamente diferente (no copió los colores exactos ni la tipografía). Este caso de uso — "como esto, pero nuestro" — es probablemente la entrada multimodal más prácticamente útil para proyectos reales.
Exportación de mockup de Figma — un archivo de diseño propiamente dicho exportado como PNG. Esto produjo la salida de mayor fidelidad. Codex reprodujo el diseño, el espaciado y la estructura de componentes de manera cercana. El bucle de auto-verificación detectó desviaciones menores — una tarjeta que era 2px más ancha que el mockup, un peso de fuente que no coincidía — y las auto-corrigió.
El patrón es claro: mejores entradas producen mejores salidas. Suena obvio, pero la implicación práctica es importante. No necesitas un archivo de Figma pulido para obtener una salida útil de Codex. Un boceto rápido en una pizarra o tablet te lleva a un prototipo funcional más rápido de lo que una descripción de texto jamás podría. La entrada visual elimina la capa de traducción entre lo que ves en tu cabeza y lo que puedes articular con palabras.
Para mi flujo de trabajo, el punto ideal es el dibujo anotado en iPad. Suficientemente detallado para que Codex entienda mi intención. Suficientemente tosco para que pase treinta segundos dibujándolo en lugar de treinta minutos en Figma. El bucle de auto-verificación cubre las brechas entre mi boceto tosco y una implementación limpia.
Visualización de datos: donde Codex destaca silenciosamente
La demo que me pareció más sorprendente no fue el llamativo globo 3D — fue la sección de visualización de datos. Codex ingirió un conjunto de datos en bruto de viajes en taxi en la ciudad de Nueva York (millones de filas) y generó un panel de control interactivo con gráficos, filtros y visualizaciones en mapa.
Alimentar datos en bruto y obtener de vuelta un panel analítico funcional no es nuevo. Lo nuevo es que Codex verificó sus propias visualizaciones de forma visual. Cuando un gráfico de barras se renderizó con las etiquetas de los ejes cortadas, la auto-verificación lo detectó. Cuando una superposición de mapa era parcialmente transparente y difícil de leer contra un fondo claro, la auto-verificación ajustó la opacidad.
Repliqué esto con un conjunto de datos de un cliente — datos de ventas anonimizados de múltiples regiones y categorías de productos. Le di a Codex el CSV y pedí un panel de control exploratorio. El primer renderizado tenía un gráfico donde la etiqueta del eje Y colisionaba con el título del gráfico. La auto-verificación lo detectó, añadió padding y volvió a renderizar limpiamente.
El caso de uso de visualización de datos es donde el bucle de auto-verificación proporciona el valor más consistente, porque el renderizado de gráficos tiene muchos modos de fallo visual sutiles: etiquetas superpuestas, leyendas truncadas, colores demasiado similares para distinguirlos, tooltips que desbordan sus contenedores. Estos son problemas difíciles de describir en texto pero instantáneamente obvios visualmente. Una IA con auto-verificación los detecta de la misma forma que un humano — mirando.
Para cualquiera que construya regularmente paneles de control o interfaces con muchos datos, esta capacidad por sí sola hace que valga la pena evaluar Codex.
La integración con Playwright que lo une todo
Bajo el capó, Codex usa Playwright — el framework de automatización de navegadores — para renderizar las interfaces generadas y capturar pantallas. Esto no es solo un detalle de implementación. Significa que Codex puede interactuar con la aplicación generada de la forma en que lo haría un usuario: haciendo clic en botones, rellenando formularios, desplazándose, redimensionando el viewport.
Los desarrolladores front-end que usan Codex junto con Playwright obtienen un pipeline de validación visual continuo. Generar código → renderizar en un navegador real → capturar pantallas en múltiples anchos de viewport → analizar cada captura → corregir problemas → repetir. El ciclo completo está automatizado.
Configuré una versión de este pipeline para uno de mis proyectos. Codex genera un componente, Playwright lo renderiza en tres anchos de viewport (375px móvil, 768px tablet, 1440px escritorio), Codex analiza las tres capturas y corrige problemas responsivos en todos los breakpoints. Las pruebas responsivas que usualmente ocurren como una reflexión tardía manual se convierten en parte del proceso de generación.
El impacto práctico: no he redimensionado manualmente una ventana de navegador para probar la responsividad en ningún componente que Codex generó esta semana. Cada problema responsivo fue detectado por el análisis automatizado de capturas de pantalla. No todos los problemas responsivos — algunos casos extremos con contenido dinámico y container queries se escaparon — pero sí los obvios que consumen la mayor parte del tiempo de prueba manual.
Donde Codex se queda corto (y sí se queda)
Hora de la sección honesta. Porque las demos están diseñadas para impresionar, y la realidad tiene más matices que las demos.
La auto-verificación no es exhaustiva. Codex toma una captura de pantalla en un momento dado, en un ancho de viewport (a menos que configures el pipeline de Playwright para múltiples). No prueba estados hover, animaciones a mitad de transición, retroalimentación de validación de formularios ni estados interactivos que requieren acciones específicas del usuario para activarse. Un botón que se ve perfecto en su estado predeterminado podría tener un estado hover roto que la captura nunca captura.
El análisis visual tiene un límite de resolución. Codex puede detectar una etiqueta de gráfico que está claramente cortada. Le cuesta más con problemas más sutiles: un peso de fuente que es 400 cuando debería ser 500, un color que es #333 cuando la especificación de diseño dice #2D2D2D, una altura de línea que es ligeramente ajustada pero no obviamente incorrecta. La capacidad del modelo de visión para detectar "no del todo bien" es significativamente más débil que el ojo de un diseñador humano.
La calidad del código queda en segundo plano frente a la corrección visual. Codex optimiza para "¿se ve bien en la captura?" Esto a veces significa que genera hacks de CSS — posicionamiento absoluto donde flexbox sería más limpio, valores en píxeles hardcodeados donde unidades relativas serían más mantenibles — porque esos enfoques producen la salida visual correcta más rápido. El código funciona y se ve bien, pero un desarrollador senior refactorizaría la mitad por mantenibilidad.
La gestión de estado complejo sigue siendo débil. Las demos muestran interfaces mayormente estáticas o ligeramente interactivas. Cuando le pedí a Codex que construyera un formulario de múltiples pasos con validación, campos condicionales y estados de error, la auto-verificación solo verificó el estado inicial. No probó el estado de error visualmente, no verificó que los campos condicionales aparecieran correctamente y no detectó un desplazamiento de diseño que ocurría cuando aparecían los mensajes de validación. El bucle cerrado funciona para verificación visual estática. Aún no maneja el espectro completo de pruebas de estado interactivo.
No se considera el rendimiento. Codex generó un globo de Three.js perfectamente funcional. También cargó 500KB de Three.js sin minificar para un componente que usaba quizás el 10% de la biblioteca. La auto-verificación visual confirma que la salida se ve bien. No dice nada sobre el tamaño del bundle, el rendimiento de renderizado ni el uso de memoria. Todavía necesitas a un humano (o una herramienta diferente) para la optimización de rendimiento.
Estas no son quejas menores. Son la diferencia entre una demo y un flujo de trabajo de producción. El bucle multimodal de Codex es genuinamente impresionante para prototipado, implementación inicial y detección de bugs visuales obvios. Aún no es un reemplazo para prácticas exhaustivas de desarrollo front-end.
Lo que esto realmente significa para el desarrollo front-end
Este es el cambio que he hecho en mi propio flujo de trabajo después de una semana con las capacidades multimodales de Codex.
Ya no escribo código front-end de primera pasada a mano para nuevas funcionalidades. Boceto la interfaz (iPad, treinta segundos), se lo paso a Codex con una descripción en texto de la funcionalidad, dejo que genere y auto-verifique la implementación inicial. Después dedico mi tiempo donde realmente importa: refactorizar el CSS generado para mantenibilidad, añadir gestión de estado adecuada, probar flujos interactivos y optimizar el rendimiento.
Mi rol pasó de "escribir el código" a "diseñar la arquitectura del código y refinar la salida". El primer borrador — que es la parte más tediosa del trabajo front-end, luchando con CSS de layout y estructura básica de componentes — ahora está automatizado y verificado visualmente.
El ahorro de tiempo es difícil de cuantificar con precisión porque cada componente es diferente. Pero en términos generales: tareas que tomaban noventa minutos de implementación inicial ahora toman unos veinte minutos de generación más treinta minutos de refinamiento. Aproximadamente la mitad del tiempo total, con un mejor punto de partida.
Esas cuentas no aplican para cada proyecto ni para cada desarrollador. Si tu trabajo front-end es altamente interactivo y orientado a estado, la generación cubre un porcentaje menor del esfuerzo total. Si tu trabajo se centra en diseños con muchas tarjetas, cuadrículas, paneles de control y componentes de visualización de datos — el tipo de trabajo de interfaz que muchas aplicaciones reales necesitan — la cobertura es sustancial.
La pregunta más importante no es si Codex es útil hoy. Claramente lo es, con salvedades. La pregunta es qué sucede cuando el bucle de auto-verificación mejore: análisis visual de mayor resolución, pruebas de estado interactivo, conciencia de rendimiento, verificaciones de accesibilidad. Cada mejora en el lado de verificación hace que el lado de generación sea más confiable.
Estamos viendo cómo el bucle de retroalimentación entre la generación de código con IA y la verificación de código con IA se estrecha en tiempo real. Y el punto final lógico de ese estrechamiento — una IA que genera, verifica e itera hasta calidad de producción sin intervención humana — aún no está aquí. Pero se puede ver desde aquí. Puedes ver la trayectoria.
Los desarrolladores que aprendan a trabajar con este bucle ahora — dirigiéndolo, refinando su salida, cubriendo las brechas que aún no puede cerrar — tendrán una ventaja significativa cuando sea lo suficientemente bueno para cerrar la mayoría de esas brechas por sí solo.
Ese cambio no viene el próximo año. Partes de él ya están aquí. Estoy mirando un globo de Three.js en mi pantalla que era un boceto en pizarra hace veinte minutos, construido por una IA que revisó su propio trabajo y corrigió sus propios errores.
¿Qué vas a construir cuando tu asistente de programación pueda ver?
🤝 Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- 🔗 Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
- 🎨 ColorPark (diseño y branding): colorpark.io
- 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io
