Codex + una herramienta secreta es el flujo de diseño que hemos estado usando en nuestra agencia... y el resultado está genuinamente en otro nivel.
Llevo meses diciéndolo. Si tu aplicación parece basura de IA, no es un problema de Codex. Es un problema de flujo de trabajo.
La mayoría de los creadores están atrapados en el mismo bucle. Entregan funciones con IA. El backend funciona. La lógica es sólida. Pero la interfaz se ve como cualquier otra aplicación programada con vibe coding. Los usuarios deciden en dos segundos si se siente real.
La solución de antes era contratar a un diseñador. Esperar semanas por archivos de Figma. Luego ver cómo tu desarrollador interpretaba esos diseños y los reconstruía en código. Para cuando el diseño estaba en vivo, ya habías perdido impulso y quemado dinero que no necesitabas quemar.
Todo ese proceso ahora es opcional.
Para este tutorial creé Haven, un concepto de aplicación móvil de bienes raíces. Sistema de diseño completo en 20 minutos. Todas las pantallas diseñadas en menos de una hora. Código de producción enviado a través de Codex sin reescribir una sola línea de CSS.
Este es el flujo que estoy usando ahora. Y todo creador que envíe productos con IA necesita entender cómo funciona.
Qué es realmente Moonchild
La herramienta secreta es Moonchild.
He probado casi todas las herramientas de diseño con IA que han salido en el último año. La mayoría se ven bien en la primera pantalla, pero se desmoronan en cuanto construyes una segunda página. La consistencia es el problema. Moonchild lo resuelve de una manera que ninguna otra ha logrado.
Es un lienzo de diseño basado en chat que parte de tu sistema de diseño. No de un prompt en blanco. No de una captura de pantalla. De tu sistema real. Puedes traer tu sistema de tres formas:
→ Importando desde Figma, GitHub o una URL en vivo
→ Describiendo tu marca al Constructor de Sistemas de Diseño Agéntico
→ Agregando inspiración de diseño desde Dribbble o cualquier otro lugar
Una vez que el sistema está dentro, no generas diseños como antes. Pegas un PRD. Genera pantallas completas según tu sistema. Desde ahí, diriges el arte.
Y el camino de exportación cierra el círculo. Moonchild envía un conector MCP que entrega tus diseños directamente a Codex como salida estructurada. No una captura para que Codex interprete. Los datos de diseño reales. Componentes, tokens, diseño, todo.
Ese es el flujo. Ahora, cómo usarlo realmente.
El problema de cómo la mayoría de los creadores usan la IA para diseñar
Esto es lo que hace la mayoría.
Le piden a Codex que construya una nueva función. Se entrega. Se ve más o menos. Luego piden la siguiente función. Se ve ligeramente diferente. Para la quinta función, la aplicación parece cinco productos diferentes pegados.
Esto es lo que la gente quiere decir cuando dice que el diseño con IA es malo.
El modelo no es malo. El flujo de trabajo lo es.
Codex no tiene idea de cuál es tu lenguaje de diseño. Cada prompt es un contexto nuevo. Cada pantalla es una suposición. Cada componente se desvía del anterior. Los colores cambian. La tipografía cambia. Todo se acumula.
La solución es simple. Dale a Codex un sistema a seguir. Luego dale el diseño real para construir.
La mayoría de los flujos le dan una cosa o la otra. Moonchild más la conexión MCP le da ambas al mismo tiempo.
Paso 1: Construye tu sistema de diseño primero. Siempre.
Este es el paso que todos se saltan. También es el más importante.
En @ignytlabs construimos un sistema de diseño para cada cliente antes de tocar una pantalla. Esto solía tomarle a un diseñador dos días. Moonchild lo hace en unos 20 minutos.
Para este tutorial creé Haven, un concepto de aplicación móvil de bienes raíces. Hay varias formas de meter un sistema de diseño en Moonchild. Puedes importar desde Figma, GitHub o una URL en vivo. Puedes describir tu marca al Constructor de Sistemas de Diseño Agéntico. Para Haven hice lo que suelo hacer cuando empiezo desde una vibe. Inspiración de diseño desde Dribbble. Subí tres capturas de aplicaciones móviles de bienes raíces que lograban la sensación que buscaba y una descripción corta de qué es Haven y para quién es. La herramienta extrajo el lenguaje de diseño y construyó el sistema desde cero.
Lo que me sorprendió es lo visualizable que es todo. La mayoría de las herramientas de IA, incluyendo el flujo de Google Stitch del que escribí en mi último artículo, te dan un archivo de tokens plano. Colores. Fuentes. Quizás espaciado. Esta hace algo diferente. Construye una biblioteca de componentes completa y una galería. Cada badge, botón, tarjeta y chip renderizado tal como se verá realmente dentro de tu aplicación. Haz clic en cualquier componente y lo ves en vivo, con controles para probar variantes y tamaños. Justo debajo de la vista previa obtienes el JavaScript, CSS, ejemplos y dependencias reales de ese componente. Listo para integrar al código base.
La galería es la parte que realmente cambia la forma de diseñar. En lugar de adivinar cómo debería verse un "badge de marca" o un "badge de calificación" en contexto, los ves todos lado a lado. En Venta. En Renta. Destacado. Toda la familia de una vez. Tomas decisiones de diseño informadas antes de que se genere una sola pantalla.
Es la diferencia entre una hoja de estilos y un sistema real.
Paso 2: De PRD a UI
Una vez que tu sistema de diseño está dentro, no generas diseños como antes.
Pegas un PRD.
Un resumen de funcionalidad de una página. Una especificación de producto. Una declaración de objetivos. Lo que tengas.
Para Haven pegué un PRD estructurado que cubría la introducción del producto, los objetivos, los usuarios y roles objetivo, las funciones clave y el alcance del MVP, los flujos de usuario completos, el stack técnico y la dirección de diseño. Alrededor de una página. Lo suficientemente específico para darle contexto real a la herramienta. Lo suficientemente estructurado para que extraiga los detalles correctos en las pantallas correctas.
Luego hice algo que la mayoría se salta.
Hice una lluvia de ideas con la herramienta antes de generar una sola pantalla.
Esta es la clave que la mayoría de los creadores pierde. El modo chat mantiene el contexto completo del PRD. En lugar de soltar el PRD y darle a generar, primero hablas del producto. Confirmas la lista de pantallas. Defines el patrón de navegación. Predefines la jerarquía de las pantallas clave antes de que exista cualquier píxel.
Para Haven pregunté:
→ "Basado en este PRD, ¿qué pantallas recomiendas construir primero? ¿Hay algo que me esté perdiendo para una aplicación de bienes raíces?"
→ "¿La navegación principal debería ser una barra inferior con Inicio, Búsqueda, Favoritos, Perfil? ¿O algo diferente?"
→ "Antes de generar, explícame el orden de prioridad para la pantalla de Detalle de Propiedad. Primero fotos, luego nombre y precio, luego especificaciones, luego amenities, luego agente. Confirma o mejora."
→ "Ok, ahora procede y genera estas pantallas tanto en modo claro como oscuro, siguiendo el sistema de diseño que tengo adjunto. Asegúrate de completar todo el recorrido de usuario y crear todas las pantallas."
Para cuando le di a generar, la herramienta ya conocía el producto mejor que la mayoría de los diseñadores después de su primera llamada con un cliente.
Ahora un consejo rápido sobre variantes. Lee esto con atención.
Una característica interesante: puedes crear diferentes variantes de tus pantallas. Solo tienes que mencionarlo explícitamente a Moonchild y se encargará de ello. Para Haven quería tres direcciones estéticas diferentes para toda la aplicación antes de decidirme por una. Este es el prompt exacto que usé:
"Quiero que generes 3 conceptos completos de diseño de UI móvil para Haven:
Concepto 1 - Editorial cálido: Fondos crema, espaciado generoso, titulares serif para nombres de propiedades, sombras suaves, tratamiento de imagen tipo revista.
Concepto 2 - Moderno audaz: Modo oscuro, alto contraste, sans-serif en todo, esquinas afiladas, liderado por fotos con imágenes de borde a borde.
Concepto 3 - Minimalista premium: Paleta neutra (blanco roto, carbón, un solo acento), tipografía refinada, mucho espacio para respirar, microinteracciones sutiles.
Usa el sistema de diseño conectado como base, pero deja que cada concepto tire del sistema en una dirección estética diferente. Genera pantallas completas, no solo secciones. ¿Qué harás?"
Nota el "¿Qué harás?" al final. Ese es el pequeño detalle que hace que funcione. En lugar de generar todo a ciegas, la herramienta volvió con un plan.
Dijo que primero construiría 5 pantallas representativas por concepto. Yo revisaría las tres direcciones lado a lado. Una vez que eligiera la que quería, diseñaría toda la aplicación en esa dirección.
Eso cambia completamente la ecuación de costos. No estás pagando por tres construcciones completas. Estás pagando por tres muestras rápidas, luego una sola construcción completa en la dirección que realmente elijas.
Elegí la editorial cálida. El conjunto completo de pantallas llegó después.
Ahora la parte que realmente me sorprendió.
Cada pantalla que genera Moonchild es interactiva en modo de vista previa. No es un mockup estático. Es realmente interactiva.
Puedes hacer clic en campos de entrada. Tocar botones. Moverte entre pantallas como un usuario real probando el prototipo antes de que se escriba cualquier código. Para Haven detecté dos problemas de flujo en la vista previa que de otro modo habrían llegado a Codex. La pantalla de detalle de propiedad no tenía una forma obvia de volver a la exploración. El CTA de contactar al agente estaba demasiado abajo del pliegue. Ambos habrían llegado si hubiera entregado el diseño a Codex sin hacer clic primero.
Esa es la clave. Pruebas el producto antes de que se escriba cualquier código.
El bucle de refinamiento es la última pieza.
Cuando una pantalla necesita trabajo, no vuelves a hacer un prompt desde cero. Seleccionas la pantalla, le dices a la herramienta qué cambiar, y genera una v2 en el mismo lugar. ¿Quieres un héroe más cinematográfico? v2. ¿Quieres cambiar un diseño de tarjeta por una vista de lista? v3. Las variantes se apilan para que puedas comparar y elegir la más sólida.
Para la pantalla de detalle de propiedad de Haven pasé por tres iteraciones. v1 tenía el bloque del agente demasiado arriba. v2 arregló la jerarquía pero la galería de fotos se sentía pequeña. v3 logró ambas. Unos 8 minutos de ida y vuelta.
No estás curando desde un lienzo en blanco. Estás refinando una dirección real. Esta es la parte que más se siente como trabajar con un diseñador senior.
Paso 3: Conecta Moonchild a Codex a través de MCP
Aquí es donde el flujo se vuelve IMPRESIONANTE.
El sistema de diseño le da a Codex las reglas. La conexión MCP le da a Codex algo más poderoso: acceso directo a la salida de diseño real. No capturas de pantalla. No descripciones de texto del diseño. Datos de diseño estructurados que Codex puede leer y reconstruir.
Aquí está la configuración:
→ Ve a Configuración de Moonchild, luego MCP
→ Copia el comando de instalación para tu configuración
→ Abre Codex CLI
→ Pega el comando de instalación
→ Autentica con tu cuenta de Moonchild
→ Listo
Una vez conectado, Codex ve tanto tu sistema de diseño como las pantallas específicas de Haven que has diseñado.
Paso 4: Codex envía el código
Ahora le indicas a Codex así:
Obtén el proyecto de la aplicación móvil de bienes raíces Haven usando el MCP de Moonchild, y dime qué pantallas tenemos dentro.
Este primer prompt hace dos trabajos. Confirma que el MCP está conectado correctamente. Y le da a Codex visibilidad completa de cada pantalla que has diseñado.
Un consejo rápido antes de dejar que Codex haga algo más pesado. Quédate en modo plan. Codex muestra lo que está a punto de hacer antes de ejecutarlo. Lee el plan cada vez. Asegúrate de que entiende qué pantallas quieres, en qué orden y a qué fidelidad. Esta es la diferencia entre que Codex programe lo que realmente necesitas y que programe lo que cree que necesitas.
Una vez que has revisado el plan y lo has dirigido a la pantalla que quieres, Codex extrae los datos de diseño directamente de Moonchild, referencia tu sistema de diseño y escribe el código. Incluso agrega los estados hover, las transiciones y el manejo de casos límite porque está trabajando con datos de diseño reales en lugar de adivinar a partir de un prompt.
El resultado: UI de nivel de producción en tu código base real, coincidiendo exactamente con el diseño, en minutos.
En @ignytlabs solíamos presupuestar dos semanas para el diseño en cada MVP de cliente. Un diseñador construía el archivo de Figma. Un desarrollador lo interpretaba. La interpretación se desviaba. Corregíamos. Ciclo. Con este flujo, todo el ciclo se reduce a una sola tarde de trabajo. Misma calidad. Mayor margen. Mucho menos cambio de contexto.
Cuándo usar este flujo
Este no es el flujo adecuado para todos los equipos. Sé honesto sobre cuándo encaja.
Úsalo cuando:
→ Estás lanzando MVPs como creador solitario o equipo pequeño
→ La consistencia del diseño se rompe constantemente entre pantallas
→ No quieres mantener un pipeline separado de Figma a diseñador a desarrollador
→ Ya tienes un sistema de diseño y quieres que se aplique en todas partes
Saltátelo cuando:
→ Estás a escala con un equipo de diseño interno completo y una biblioteca de Figma madura
→ Necesitas una entrega perfecta de píxeles para un sitio de marketing o trabajo de marca donde cada sombra importa
→ Tu código base tiene patrones de UI altamente personalizados que requieren trabajo de diseño a medida
Para el 80% de los creadores que lanzan MVPs y productos SaaS, este flujo cubre todo lo que necesitas.
Qué tener en cuenta
Algunas banderas honestas antes de que ejecutes esto.
La calidad de tu sistema de diseño determina la calidad de tu resultado. Basura entra, basura sale. Un archivo de Figma a medias con tres tokens de color producirá pantallas mediocres. Invierte tiempo en el sistema desde el principio. Se paga solo en cada pantalla.
La calidad del PRD importa. Un resumen vago te da pantallas genéricas. Un PRD específico con flujos de usuario, casos límite y jerarquía clara te da diseños útiles. Esto no es una limitación de la herramienta. Es una limitación de pensamiento.
Todavía necesitas buen gusto. La herramienta produce. Tú diriges. Elegir la variante correcta y refinarla es donde vive tu criterio. Si te saltas el paso de curación, vuelves a diseñar por vibe.
Algunos componentes necesitan ajustes manuales. Estados animados complejos, patrones de interacción personalizados, cualquier cosa fuera del sistema de diseño necesita un pase manual en Codex. El MCP te lleva al 90%. El último 10% es tu gusto.
Lo que esto realmente significa
Esta es mi opinión honesta.
El cuello de botella al lanzar productos construidos con IA nunca ha sido el código. La IA puede escribir el código. El cuello de botella siempre ha sido la capa de diseño. La consistencia, el gusto, el sistema que lo une todo.
Ese cuello de botella acaba de colapsar.
En nuestra agencia solíamos presupuestar dos semanas para el diseño en cada MVP de cliente. Contratar a un diseñador. Esperar archivos de Figma. Ver al desarrollador interpretarlo. Ciclo. Lo que solía tomar dos semanas ahora toma dos días. Misma calidad. Entrega más rápida. Mayor margen.
Este es el flujo que los equipos con financiación ya tienen con su pipeline de Figma más diseñador más desarrollador. La diferencia es que ahora los creadores solitarios, las agencias independientes y los estudios pequeños obtienen la misma ventaja sin la necesidad de contratar más personal.
2026 va a ser INJUSTO para las agencias y creadores que dominen esto primero.
TLDR
→ Deja de culpar a Codex por la mala UI. Codex no es el problema. Tu flujo de trabajo lo es.
→ Paso 1: Construye tu sistema de diseño dentro de Moonchild. Importa desde Figma, GitHub o una URL en vivo. O describe tu marca. O agrega inspiración de Dribbble como hice yo para Haven.
→ Paso 2: Pega tu PRD. Haz lluvia de ideas en modo chat antes de generar. Define la lista de pantallas y el patrón de navegación primero.
→ Por defecto genera una variante. Pide explícitamente múltiples variantes en las pantallas principales con diferentes vibes especificadas.
→ Usa la vista previa interactiva para probar el flujo antes de escribir cualquier código. Refina las pantallas con iteraciones v2, v3 en el mismo lugar.
→ Paso 3: Conecta Moonchild a Codex a través de MCP. Esto le da a Codex datos de diseño reales, no capturas de pantalla.
→ Paso 4: Indica a Codex que construya cada pantalla usando el MCP. UI de nivel de producción en minutos.
→ La calidad de tu sistema de diseño determina la calidad de tu resultado. Invierte ahí.
→ El ciclo de Figma a entrega a desarrollador ha muerto. Un solo flujo ahora maneja el diseño y el código juntos.
Vamos.
