Del Diseño al Código con IA: Claude Code lo Cambia Todo
Algo cambió en un taller reciente. He participado en suficientes revisiones de diseño, planificaciones de sprint y sesiones de entrega entre diseñadores y desarrolladores como para saber cuándo un cambio en el flujo de trabajo es cosmético — y cuándo es estructural. Este fue estructural.
Diane, CEO y cofundadora de The Design Project, tenía Cursor abierto a la izquierda, Figma a la derecha y Claude Code ejecutándose entre ambos. Escribió un prompt — "rediseña esta UI como lo haría un diseñador de producto de clase mundial" — y observó cómo la IA leía todo el código base, esbozaba su plan, hacía una pregunta de aclaración y luego comenzaba a modificar archivos.
Sin documento de entrega. Sin mockup anotado. Sin ticket de Jira esperando dos semanas en el backlog de un desarrollador. Solo una diseñadora generando código front-end real a través de una IA que entendía el contexto del proyecto.
Me quedé procesando esa imagen un buen rato. Porque lo que estaba presenciando no era un truco de productividad — era el flujo de trabajo de diseño a desarrollo empezando a disolverse. Y creo que la mayoría de los equipos de producto aún no lo han sentido, pero lo sentirán.
Esto es lo que me llevé de esa sesión, filtrado por mi propia experiencia construyendo con Claude Code. Seré honesto sobre dónde este flujo de trabajo realmente cambia las cosas y dónde las limitaciones actuales te van a morder si no tienes cuidado.
Hay un momento específico en la sección de implementación que transformó cómo pienso sobre el modo de planificación de la IA. Tenlo en cuenta mientras lees.
El Flujo de Trabajo Anterior Ya Se Estaba Rompiendo Antes de que Llegara la IA
Déjame describir la entrega de diseño a desarrollo que la mayoría de los equipos conoce. Un diseñador termina los mockups en Figma. Anota espaciados, tamaños de fuente, estados de interacción, hover states. Agenda una reunión de entrega. El desarrollador hace preguntas que las anotaciones no cubrieron. Hay un ida y vuelta. Comienza un sprint. El desarrollador construye algo que se acerca — pero no del todo. Hay un ciclo de revisión. Más ida y vuelta. Finalmente se lanza algo que es el 80% de lo que se diseñó originalmente.
¿Te suena familiar?
El problema no son las personas. Los diseñadores son buenos en su trabajo. Los desarrolladores son buenos en el suyo. El problema es la capa de traducción entre ambos — la brecha donde la intención se pierde, se hacen suposiciones y el contexto se evapora durante la entrega. Incluso con Zeplin, InVision o el modo de desarrollador de Figma, sigues trasladando una representación estática de un diseño a un medio que necesita código dinámico, responsive y con estado.
Lo que hace Claude Code — y lo que Diane demostró claramente — es colapsar esa capa de traducción.
Cuando le das a Claude Code un prompt de diseño y lo dejas operar sobre un código base real, no está adivinando la implementación a partir de una captura de pantalla. Lee la estructura de código existente, entiende la jerarquía de componentes, sabe qué ya existe y genera cambios que encajan en la arquitectura existente. Eso es algo cualitativamente diferente a la generación de código genérica.
La distinción importa. Los generadores de código genéricos producen código que puede verse bien pero no encaja en tu proyecto. Claude Code — trabajando en contexto — produce código que encaja con lo que ya has construido.
Pero antes de entrar en cómo funciona esto exactamente en la práctica, necesitas entender el stack de herramientas específico que usó Diane y por qué cada elección importa.
El Stack de Tres Herramientas que Realmente Funciona en Conjunto
El taller se centró en tres herramientas trabajando en concierto. He usado las tres de forma independiente. Verlas combinadas en un flujo de trabajo deliberado me aclaró por qué esta combinación específica es más que la suma de sus partes.
Cursor como entorno inicial. Cursor es un editor de código basado en VS Code, con capacidades de IA integradas a nivel de IDE en lugar de añadidas como extensión. Para diseñadores que entran en un entorno de programación por primera vez, esto importa enormemente. La interfaz es lo suficientemente familiar para navegar, la terminal es accesible sin ser intimidante y clonar un repositorio es sencillo a través de la interfaz gráfica.
Para el taller, Diane clonó LLM Council de Andrej Karpathy — un proyecto open-source que te permite consultar múltiples modelos de IA simultáneamente, donde esos modelos califican las respuestas de los demás. La elección del proyecto fue inteligente. Es un código base real, de calidad de producción, con una estructura no trivial, no una app tutorial de juguete. Trabajar con algo real es la única forma de probar si un flujo de trabajo realmente funciona.
Claude Code como capa de inteligencia. Esta es la parte que más me interesa — y la parte donde tengo más experiencia directa para comparar.
Claude Code no solo genera código a partir de una descripción. Lee. Empieza escaneando el README, entendiendo la estructura del proyecto, identificando dependencias, verificando qué ya está instalado. En un repositorio recién clonado, maneja la instalación de dependencias, la configuración del entorno y pone el proyecto en marcha antes de tocar un solo elemento de diseño.
Esa comprensión contextual es lo que los generadores de código genéricos no logran. Cuando Diane le pidió a Claude Code rediseñar la UI de LLM Council, no generó un componente nuevo desde cero esperando que ella lo integrara. Modificó los componentes existentes, en la estructura de archivos existente, usando los patrones de estilo existentes — mientras aplicaba la dirección de diseño que ella especificó.
Figma MCP para sincronización bidireccional. El Figma MCP (Multi-Component Plugin) es el puente entre diseño y código que hace este flujo de trabajo bidireccional. Después de que Claude Code genera cambios de UI en código, esos cambios pueden sincronizarse de vuelta a Figma — dándole a los diseñadores una forma de seguir refinando en la capa de diseño sin redibujar manualmente lo que se generó. Las ediciones hechas en Figma pueden luego volver al código base.
La advertencia honesta aquí: esta sincronización bidireccional es genuinamente impresionante en concepto e imperfecta en ejecución por el momento. El mapeo de tokens, las convenciones de nomenclatura de componentes y el comportamiento responsive no se traducen perfectamente en ninguna dirección. El taller de Diane expuso exactamente esto — resolución de problemas en vivo, limitaciones visibles, una demostración en tiempo real de que esto no es un problema resuelto aún. Volveré a esto en la sección de limitaciones reales.
Modo de Planificación — La Parte que la Mayoría Ignora
Este es el momento que mencioné al principio y que transformó cómo uso Claude Code.
Cuando Diane le pidió a Claude Code rediseñar la UI, no simplemente lanzó el prompt y esperó el código. Lo dejó ejecutarse primero en modo de planificación.
El modo de planificación es la fase de Claude Code donde esboza lo que pretende hacer antes de hacer cualquier cosa. Lee los archivos relevantes, identifica qué necesita cambiar, traza la secuencia de modificaciones y — de manera crítica — hace preguntas de aclaración si el prompt deja margen para interpretación.
Esto no es algo menor. La mayoría de los desarrolladores que he visto usar herramientas de programación con IA saltan directamente a la ejecución. Lanzan un prompt, obtienen código, lo ejecutan, ven que falla, lanzan otro prompt para arreglarlo y terminan en un ciclo de corrección ida y vuelta que consume más tiempo que escribir el código ellos mismos.
El modo de planificación rompe ese patrón. Cuando la IA esboza su enfoque primero, detectas malentendidos a nivel del plan — antes de que se cambie cualquier código. "Planeo modificar el componente Header y agregar un nuevo esquema de colores al Tailwind config" es algo que puedes evaluar y redirigir en treinta segundos. Descubrir que la IA modificó el componente equivocado después del hecho te cuesta diez minutos de depuración y rollback.
Desde la línea temporal del taller, esta secuencia de planificación-y-ejecución ocurrió entre los minutos 15 y 20 — el segmento donde los participantes tuvieron más momentos de revelación. Ver a la IA hacer una pregunta de aclaración sobre la paleta de colores antes de tocar CSS hizo visible la deliberación de una manera que una simple demostración de antes/después no logra.
Mi propia experiencia coincide con esto. En un proyecto reciente, usé el modo de planificación de Claude Code para rediseñar un componente de tabla de datos. El plan reveló que mi prompt era ambiguo respecto a la paginación — ¿debería el nuevo diseño mantener la paginación del lado del servidor o cambiar a paginación del lado del cliente? Cinco segundos para aclarar. El código resultante fue correcto al primer intento. Sin el modo de planificación, habría obtenido código que asumía un enfoque, habría descubierto el problema al probarlo y habría invertido tiempo arreglándolo.
Trata el modo de planificación como obligatorio, no opcional. Los noventa segundos extra que añade al inicio ahorran múltiplos de ese tiempo en cada paso posterior.
Recorrido del Flujo de Trabajo del Taller — Paso a Paso
Permíteme reconstruir el flujo de trabajo que Diane demostró, con el nivel de detalle de implementación que es útil si quieres replicarlo.
Paso 1: Clonar el repositorio en Cursor.
# In Cursor's integrated terminal
git clone https://github.com/karpathy/llm-council.git
cd llm-council
Para diseñadores que nunca han usado una terminal, la interfaz gráfica de Cursor hace que esto se sienta menos hostil. También puedes usar la paleta de comandos de Cursor para clonar — sin necesidad de terminal.
Paso 2: Dejar que Claude Code lea y configure el proyecto.
Abre Claude Code y dale contexto antes de pedir cualquier cosa relacionada con diseño:
Read the README.md file thoroughly. Understand the project structure,
what this application does, and what dependencies it needs. Then install
the dependencies and tell me what I need to set up to run this locally.
Claude Code escaneará el README, identificará el stack (en el caso de LLM Council, un backend en Python con un frontend en JavaScript), instalará las dependencias a través del gestor de paquetes especificado y señalará cualquier configuración faltante — como variables de entorno.
Paso 3: Crear el archivo .env.
LLM Council, como la mayoría de los proyectos reales, necesita API keys para funcionar. Claude Code te dirá exactamente qué variables se necesitan. Crea el archivo .env en la raíz del proyecto:
# .env — never commit this file
ANTHROPIC_API_KEY=your_key_here
OPENAI_API_KEY=your_key_here
Claude Code se encarga de señalar lo que se necesita. Tú proporcionas las claves reales. Esta es la división de trabajo correcta — la IA gestiona la forma de la configuración, tú gestionas los secretos.
Paso 4: Ejecutar el proyecto y verificar que funciona.
# Start the backend
python app.py
# In a separate terminal, start the frontend
npm run dev
Claude Code te dará los comandos exactos basándose en lo que leyó de los scripts del proyecto. Una vez que la app está corriendo localmente y puedes ver la UI original, estás listo para solicitar cambios de diseño.
Paso 5: Solicitar cambios de diseño usando el modo de planificación.
Este es el paso crítico. Estructura tu prompt de diseño para invocar el modo de planificación explícitamente:
Before making any changes, enter planning mode. I want to redesign
this application's UI as a world-class product designer would. The
current UI is functional but visually sparse. I want:
- A dark, modern color scheme
- Improved typography hierarchy
- Better spacing and visual rhythm
- Clear visual separation between model responses
Plan your approach first. List every file you intend to modify and
why. Ask me any clarifying questions before you start.
La respuesta de la IA será un esquema — algo como: "Planeo modificar App.css para el esquema de colores global, actualizar ModelResponse.jsx para el diseño de las tarjetas de respuesta, ajustar el Tailwind config para valores de espaciado personalizados. Pregunta: ¿debería preservar la estructura de componentes existente o proponer una reorganización?"
Respondes la pregunta. Luego apruebas el plan. Luego comienza la ejecución.
Paso 6: Sincronizar con Figma usando MCP.
Una vez que los cambios en el código están activos y estás conforme con la dirección, el plugin Figma MCP te permite trasladar esos cambios de código a un archivo de Figma. En la práctica, esto genera frames de Figma que aproximan lo que el código renderiza — útil para compartir con stakeholders o continuar la iteración de diseño en Figma.
Paso 7: Hacer ediciones en Figma y enviarlas de vuelta al código.
Los ajustes pixel-perfect suelen ser más fáciles en Figma que en CSS. Haz esas ediciones en Figma, luego usa el MCP para exportar los cambios como modificaciones de código. Claude Code puede entonces incorporarlos al código base existente.
Paso 8: Hacer commit y push de tus cambios.
# Stage your changes
git add -A
# Commit with a meaningful message
git commit -m "redesign: apply modern dark theme to LLM Council UI"
# Push to your fork
git push origin main
Si hiciste fork del proyecto para hacer cambios independientes — que es lo que Diane recomendó — este push va a tu fork personal en GitHub. Desde ahí tienes la opción de abrir un pull request al proyecto original si los cambios valen la pena contribuirlos.
Si has seguido mentalmente ese flujo de trabajo, ya entiendes algo que a la mayoría le toma tres intentos comprender: la IA no está diseñando por ti. Está implementando una dirección que tú especificas. La calidad de lo que obtienes depende casi enteramente de la calidad de cómo formulas tu prompt. Y es exactamente por eso que existe la fase de planificación.
Ahora, la parte honesta.
Lo que el Taller Acertó Sobre las Limitaciones
Diane no presentó esto como un flujo de trabajo resuelto. Esa fue la parte que más aprecié de la sesión.
La integración con Figma MCP reveló limitaciones reales en pantalla en vivo. Las inconsistencias en la nomenclatura de componentes entre el código base y Figma significan que lo que se importa a Figma no siempre se mapea limpiamente a los componentes de tu sistema de diseño existente. La gestión de tokens — design tokens para color, espaciado y tipografía — no se sincroniza de forma confiable en ninguna dirección todavía. Puedes obtener una aproximación razonable de código a Figma, pero "sincronización bidireccional pixel-perfect" es lenguaje de marketing aspiracional, no una descripción precisa de dónde están las herramientas hoy.
El problema de los tokens es el que encuentro más frustrante en la práctica. Si tu código base usa un Tailwind config personalizado con tokens de color nombrados, y tu archivo de Figma tiene un sistema de diseño que coincide, esperarías que la sincronización preserve esos nombres. A menudo no lo hace. Terminas con valores hexadecimales en lugar de nombres de tokens, y overrides de componentes en lugar de instancias de componentes. Arreglar eso manualmente anula gran parte del ahorro de tiempo.
Mi opinión honesta: trata la sincronización de Figma a código y de código a Figma como un paso de "lo suficientemente cerca para continuar", no como un paso "precisamente exacto". Úsalo para comunicar dirección y llegar al terreno aproximado del diseño correcto. No esperes que reemplace la disciplina meticulosa del sistema de diseño.
La otra limitación que vale la pena mencionar: la ventana de contexto de Claude Code. En códigos base grandes — decenas de miles de líneas distribuidas en docenas de archivos — Claude Code puede perder el hilo del contexto del proyecto a mitad de una sesión. La fase de planificación mitiga esto en cierta medida, porque el plan actúa como ancla. Pero en proyectos muy grandes, notarás que la IA hace sugerencias que contradicen decisiones anteriores en la misma sesión. Cuando eso ocurra, reestablecer el contexto con un prompt de resumen suele ponerlo de vuelta en camino.
Ninguna de estas limitaciones hace que el flujo de trabajo sea menos valioso. Lo convierten en un flujo de trabajo que requiere una mano experimentada para detectar las brechas — que es exactamente lo que la sesión de Diane demostró. Se encontró con el problema del MCP en vivo y lo manejó explicando qué estaba pasando y por qué. Ese es el modelo correcto: entender los límites de la herramienta, trabajar dentro de ellos y no dejar que los casos extremos te distraigan de lo que el flujo de trabajo hace bien.
Lo que Esto Realmente Cambia para los Equipos de Producto
El taller dedicó su Q&A final a una pregunta que considero la más interesante: ¿qué pasa con los roles cuando esto se generalice?
El marco de Diane: los límites entre Product Managers, diseñadores e ingenieros se están difuminando. Los PMs están prototipando directamente. Los diseñadores están escribiendo — o al menos generando — código. Los ingenieros siguen enfocados en la ingeniería, pero participan más en decisiones de diseño y PRDs más temprano en el proceso.
He visto que esto empieza a suceder en equipos con los que he trabajado, y añadiría algunos matices.
La difuminación es real. Pero no es uniforme. Lo que herramientas de IA como Claude Code permiten es que los especialistas puedan adentrarse más en territorios adyacentes sin convertirse en generalistas. Una diseñadora sin experiencia en programación ahora puede generar un prototipo funcional, evaluarlo en el navegador, iterarlo y compartir algo más cercano a lo final que cualquier mockup. Eso no la convierte en ingeniera. La convierte en alguien cuyas decisiones de diseño ahora están informadas por cómo se siente realmente el código en ejecución.
El efecto downstream: las revisiones de diseño cambian. En lugar de revisar un mockup estático en Figma e imaginar cómo se sentirá en el navegador, estás revisando algo con lo que realmente puedes interactuar. El feedback se vuelve más específico, más fundamentado y más accionable. "Este botón se siente pequeño en móvil" reemplaza a "No estoy seguro de este botón" — porque puedes probar en móvil antes de la revisión.
Para los ingenieros, el cambio es más sutil pero igual de real. Cuando los diseñadores llegan a la entrega con código funcional en lugar de mockups, la conversación de ingeniería pasa de "¿podemos construir esto?" a "¿cómo lo hacemos listo para producción?" Esa es una mejor conversación. Se salta la capa de traducción por completo.
La habilidad multifuncional que se vuelve esencial — y animaría a cualquiera en equipos de producto a desarrollarla — es saber cómo formular prompts. No cómo programar. No cómo diseñar. Cómo articular la intención con suficiente claridad para que una IA pueda ejecutarla con precisión. Eso es una disciplina. Requiere práctica. Las personas que la desarrollen temprano tendrán una ventaja significativa sobre quienes traten las herramientas de IA como cajas mágicas.
Mis Resultados Después de Aplicar Este Flujo de Trabajo
El fin de semana después de ver este taller, apliqué el flujo de trabajo de diseño a código en un proyecto de un cliente — una aplicación de dashboard que había estado en limbo de diseño durante tres semanas porque el diseñador y el desarrollador no lograban alinearse en la estructura de componentes.
Cloné el código base existente en Cursor, le di a Claude Code contexto sobre el proyecto y luego le pedí que generara el diseño del dashboard que la diseñadora había creado en Figma. El modo de planificación reveló una pregunta inmediata: ¿debería el nuevo diseño usar la estructura existente de CSS modules o cambiar a Tailwind? Una aclaración. El plan se actualizó. La ejecución comenzó.
Cuarenta y cinco minutos después, el desarrollador tenía un prototipo funcional en el navegador que coincidía en un 85% con el mockup de Figma. No pixel-perfect. Pero lo suficientemente cerca como para que la conversación de revisión restante fuera sobre ajustes específicos en lugar de preguntas de alineación fundamental. Lanzamos la primera versión dos días después.
Comparado con el sprint donde esto había estado estancado: tres semanas vs. dos días.
La versión honesta: el 15% de diferencia aún necesitó edición manual. La sincronización de Figma MCP añadió unos treinta minutos de limpieza para actualizar el archivo de Figma y que reflejara lo que realmente estaba en el código. Y el primer intento de Claude Code en los componentes de visualización de datos necesitó un segundo prompt para lograr el comportamiento responsive correcto en pantallas más pequeñas. Nada de eso fue sorprendente. Todo fue más rápido que la alternativa.
Qué medir si pruebas esto: tiempo desde la aprobación del diseño hasta el prototipo funcional (objetivo: menos de 4 horas para una sola funcionalidad), número de ciclos de revisión de diseño antes de la entrega al desarrollador (objetivo: 1, no 3), y con qué frecuencia la intención de diseño sobrevive intacta a la entrega (registra las discrepancias entre la especificación de diseño y la funcionalidad enviada — deberían disminuir).
Una Cosa que Hacer Antes de Tu Próxima Entrega de Diseño
Elige una funcionalidad. Una — no todo tu sistema de diseño, no un rediseño completo de página. Un solo componente o sección que esté esperando en Figma para ser desarrollado.
Clona tu código base en Cursor. Abre Claude Code. Dale contexto sobre el proyecto, luego pídele que implemente el diseño a partir de tu descripción en Figma. Usa el modo de planificación. Deja que la IA haga sus preguntas. Aprueba el plan. Observa qué pasa.
Obtendrás un resultado imperfecto. Está bien. El objetivo de este ejercicio no es lanzar desde el primer prompt. El objetivo es ver qué tan grande es realmente tu brecha actual entre diseño y desarrollo, y sentir cómo es iterar en código en lugar de en mockups.
Los equipos que van a construir los mejores productos en los próximos tres años no son los que tienen más diseñadores o más desarrolladores. Son los que descubrieron cómo convertir diseño y desarrollo en una sola conversación continua, acelerada por IA — con Claude Code ejecutándose en algún lugar en el medio.
El documento de entrega tradicional tuvo una buena racha. Su reemplazo ya está aquí.
🤝 Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- 🔗 Fiverr (builds e integraciones personalizadas): 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
