Hay un vídeo que se repite cada semana. Alguien abre un Figma, arrastra una pantalla a un chat y, treinta segundos después, aparece una página maquetada que se parece bastante al diseño. El comentario final suele ser el mismo: «esto antes eran dos días de trabajo».
Y es cierto. Esa pantalla, ella sola, antes eran dos días.
El problema empieza en la pantalla doce.
Porque para entonces ya tienes cuatro formas distintas de escribir un botón, tres escalas de espaciado conviviendo en el mismo CSS y una lista de clases que nadie podría mantener dentro de seis meses. Nada está roto. Todo se ve bien. Y aun así tienes un proyecto peor que si lo hubieras hecho a mano.
La IA no maqueta mal. Maqueta sin saber en qué proyecto está.
Llevo meses usando los MCP de Figma y Zeplin dentro de VSCode para maquetar pantallas de cliente. Funciona. Pero no funciona como se cuenta por ahí, y la diferencia entre que salga bien o salga mal no está en el prompt. Está en lo que hay preparado antes de escribirlo.
Contenidos
Maquetar rápido no es maquetar bien
Las demos funcionan porque la pantalla está sola.
Una pantalla aislada no tiene que convivir con nada. No hereda estilos, no comparte componentes, no tiene que encajar con lo que maquetó otra persona el mes pasado. Es un ejercicio cerrado y la IA lo resuelve bien.
Un proyecto real es lo contrario. Una web de cliente son treinta o cuarenta plantillas que comparten componentes, un tema de WordPress con sus convenciones, un CSS que ya tiene decisiones tomadas y, casi siempre, un histórico que no puedes tirar a la basura.
En ese contexto, la pregunta deja de ser si la IA puede generar el HTML de una pantalla. Puede. La pregunta es si ese HTML se parece al resto del proyecto.
La primera vez que lo probamos en serio, el resultado visual fue bueno desde la segunda iteración. El problema apareció al revisar el diff: tres componentes nuevos que ya existían con otro nombre, valores de espaciado en píxeles donde el proyecto usaba variables, y una estructura de clases que no seguía ninguna de las convenciones del tema.
Nada de eso se ve en el navegador. Todo eso se paga después.
La IA no conoce tu sistema hasta que se lo das
Esto suena obvio y sin embargo es el error que más veces he cometido.
Cuando llevas semanas dentro de un proyecto, tienes en la cabeza cosas que no están escritas en ninguna parte: que los espaciados van en múltiplos de 4, que los componentes se prefijan con c-, que las utilidades viven en un archivo aparte, que los breakpoints son tres y no cinco, que el h1 de las plantillas internas lo pinta un componente de cabecera y no la plantilla.
La IA no tiene nada de eso. Y como no lo tiene, lo inventa. Con criterio, además, lo cual lo empeora: genera una solución razonable que un desarrollador sin contexto aprobaría.
Por sistema me refiero a cosas muy concretas:
Variables de color y su nomenclatura. Escala tipográfica y cómo se aplica. Sistema de espaciado. Breakpoints. Convención de nombres de clases. Qué es un componente y qué es una variante. Dónde vive cada archivo. Qué está prohibido tocar.
Cuando eso está escrito en un archivo que la IA lee antes de cada tarea, el resultado cambia de forma notable. No porque el modelo sea más listo, sino porque deja de tener huecos que rellenar.
Cada hueco que no rellenas tú lo rellena la herramienta, y lo rellena con la media de internet.
Este es el trabajo que no sale en los vídeos. Sentarte a escribir qué es tu proyecto no es glamuroso y es exactamente lo que separa una maqueta aprovechable de una que solo lo parece.
Del diseño al código: qué parte se automatiza de verdad
Con los MCP conectados, la IA lee el archivo de diseño directamente. No le describes la pantalla: la tiene delante.
Eso resuelve bien una parte del trabajo, y conviene decir cuál:
Extraer valores es donde más gana. Colores, tamaños, espaciados, tipografías, medidas exactas de un componente. Ese trabajo de ir a mirar cada capa y copiar el valor desaparece casi por completo, y es un trabajo que además hacíamos mal: todos hemos puesto un padding: 23px porque lo leímos mal en el inspector.
Montar la estructura también funciona. Una rejilla, una sección con su cabecera y sus tarjetas, un formulario con sus campos. Si el sistema está definido, sale con las clases correctas y a la primera.
Los estados y variantes salen a medias. Si el diseñador los ha dejado documentados en el archivo, bien. Si no están, la IA no te avisa de que faltan: te entrega el componente con su estado por defecto y ya está. El hover, el focus, el disabled, el estado de error y el estado vacío siguen siendo una conversación con diseño, no una tarea de maquetación.
Y hay una parte que no se automatiza en absoluto: decidir si lo que estás viendo debería existir. Un diseño puede traer una tarjeta que es casi igual a otra que ya tienes con dos diferencias cosméticas. La IA maquetará las dos. Tu trabajo es preguntar si no deberían ser la misma con una variante.
El coste que nadie cuenta: cada pantalla se vuelve a leer
Este es el detalle más práctico que me he encontrado y casi nunca se menciona.
Leer una pantalla de diseño consume muchos tokens. Miles. Y cada vez que haces una pregunta nueva sobre esa misma pantalla, se vuelve a leer. Preguntas por el margen inferior de una tarjeta y vuelves a pagar el coste de procesar el archivo entero.
En una pantalla suelta da igual. En una sesión de trabajo de cuatro horas sobre un módulo con varios estados, se nota mucho: en tiempo de espera, en coste y en que la conversación se degrada antes de lo que debería.
Lo que nos ha funcionado es dejar de tratar el archivo de diseño como algo que se consulta en vivo. Primero hacemos una lectura, extraemos los valores y la estructura a un documento propio, y a partir de ahí trabajamos contra ese documento. Es menos espectacular que enseñar la conexión directa, pero es lo que hace que el flujo sea sostenible más allá de la demo.
Sigue siendo un problema abierto. Estoy probando maneras de guardar esa lectura entre consultas, y hoy por hoy la solución es manual.
El código generado suele ser correcto y estructuralmente pobre
Hay una diferencia entre código que funciona y código que está bien hecho, y la IA se queda del primer lado con mucha facilidad.
Lo que más me he encontrado:
Elementos que deberían ser semánticos y no lo son. Un div con un manejador de clic donde tocaba un button. Una lista de enlaces que no es una lista. Un acordeón sin ningún atributo que indique si está abierto.
Jerarquías de encabezados que saltan niveles porque el diseño tiene un texto grande y otro pequeño, y el modelo traduce tamaño visual a nivel de encabezado. Lo cual tiene una lógica, solo que no es la lógica correcta.
Estados de foco que desaparecen. El diseño no los dibuja, así que el código no los tiene. Y cuando el proyecto es de un cliente con obligaciones de accesibilidad, eso no es un detalle.
Ninguna de estas cosas rompe nada. Se ven perfectas. Pasan una revisión visual sin problema y salen a producción si nadie mira el HTML.
Revisar una maqueta generada no es mirar si se parece al diseño. Es mirar lo que el navegador no enseña.
Cuando entra el CMS, la maqueta deja de ser una maqueta
Aquí es donde el trabajo con IA pasa de ir muy rápido a ir normal.
Una maqueta estática es contenido controlado. Los títulos miden lo que tú decides, todas las tarjetas tienen imagen y el listado siempre trae seis elementos. Un WordPress con ACF Pro y WPML detrás no se parece nada a eso.
Lo que aparece en cuanto conectas el contenido real:
Un título de producto de noventa caracteres en una tarjeta diseñada para cuarenta. Un repeater vacío porque el cliente aún no ha rellenado esa sección. Una imagen destacada que no existe y una plantilla que no tiene fallback. Textos escritos directamente en la plantilla, sin pasar por las funciones de traducción, que en un proyecto multiidioma es un error que se descubre tarde y se arregla despacio.
La IA puede generar el código de la plantilla. Lo que no puede es anticipar cómo se comporta ese diseño cuando lo llena una persona que no estaba en la reunión de diseño.
Por eso el primer contenido real entra pronto en nuestro proceso. No al final, cuando la maqueta está «terminada». En cuanto hay tres componentes en pie, metemos datos feos a propósito: el título más largo, el campo vacío, el listado con un solo elemento.
Lo que no delegamos
Hay decisiones que no tienen que ver con escribir código y que condicionan todo lo demás.
Nombrar. Cómo se llama un componente determina si alguien lo encuentra dentro de un año o crea uno nuevo. La IA propone nombres correctos y genéricos. Nosotros necesitamos los nuestros.
Decidir si algo es un componente nuevo o una variante. Es la decisión que más deuda genera a medio plazo y la que la IA resuelve siempre por el camino fácil: componente nuevo.
Discutir el diseño cuando el diseño está mal. Un archivo de Figma no es una especificación cerrada. A veces la mejor respuesta a una pantalla es una llamada al diseñador, no una maqueta. La IA nunca te va a decir que eso no debería hacerse así.
Accesibilidad y rendimiento. Ambas se pueden revisar con ayuda, ninguna se puede delegar. Son criterios que alguien tiene que sostener.
Cuándo es más rápido hacerlo a mano
No uso la IA para todo, y no por principios. Por tiempo.
Si el cambio son tres líneas de CSS, escribirlas es más rápido que explicar dónde están. Si el componente es pequeño y lo tengo claro en la cabeza, escribirlo es más rápido que revisar lo que me devuelvan. Si estoy depurando algo raro, describir el problema con la precisión necesaria para que la ayuda sirva ya me ha hecho entender el problema, y para entonces suele estar resuelto.
Hay un cálculo bastante honesto que se puede hacer antes de empezar: si preparar el contexto cuesta más que la tarea, la tarea es más rápida a mano.
Esto cambia según el proyecto. En un proyecto donde el sistema ya está documentado, el contexto es casi gratis y la balanza se inclina rápido. En un proyecto que acabas de heredar, con un CSS de cinco años y sin convenciones claras, preparar el contexto es la mitad del trabajo.
Lo que ha cambiado de verdad en nuestro proceso
No es que maquetemos más rápido. Es que el orden se ha invertido.
Antes, el sistema de diseño se consolidaba mientras maquetabas. Empezabas por la home, ibas resolviendo, y hacia la pantalla quince tenías claras las reglas. Funcionaba porque el coste de improvisar lo pagaba una sola persona sobre la marcha.
Ahora el sistema tiene que estar antes. Si no está, la IA multiplica la improvisación por cuarenta pantallas en dos tardes, y eso no se arregla refactorizando: se arregla volviendo a empezar.
Dicho de otra forma: la IA ha hecho que preparar bien el sistema sea rentable. Antes era una buena práctica que a veces te podías saltar. Ahora es la condición para que lo demás funcione.
El tiempo no se ha ido de la maquetación. Se ha movido a la preparación y a la revisión.
Una maqueta mal hecha no se ve, se paga
Una maqueta mal hecha no se detecta el día de la entrega. Se detecta seis meses después, cuando hay que añadir una sección y nadie sabe qué componente reutilizar, o cuando un cambio de espaciado obliga a tocar quince archivos.
Eso es lo que hace que este trabajo sea difícil de juzgar desde fuera. El día que se publica, todo se ve bien.
Lo difícil de maquetar nunca fue escribir el HTML. Fue organizar un proyecto para que se pueda mantener, ver que dos componentes son en realidad el mismo, saber que ese div tenía que ser un button y detectar que un título de noventa caracteres va a romper la tarjeta en móvil. Todo eso sigue haciendo falta exactamente igual que antes.
Lo que cambia es el volumen. Con experiencia, la IA te quita de encima la parte mecánica y te deja más tiempo para las decisiones que importan. Sin experiencia, te entrega mucho código que parece bueno y no tienes con qué evaluarlo, así que lo aceptas.
La IA no baja el nivel de conocimiento que hace falta para maquetar bien. Lo sube.
Si estás empezando a incorporarla a tu flujo, lo que yo haría no tiene nada de espectacular: dedicar el primer día a escribir cómo funciona tu proyecto, y todo el tiempo que venga después a revisar lo que te devuelve. Ahí se decide si el proyecto se va a poder mantener o si alguien lo va a pagar más adelante.
Preguntas frecuentes sobre maquetar con IA
¿Se puede maquetar una web entera con IA?
Se puede generar el código de todas las pantallas, pero eso no equivale a tener la web maquetada. Sin un sistema de diseño definido y una revisión estructural, el resultado son decenas de soluciones parecidas que no comparten criterio y que son difíciles de mantener. La IA acelera la producción, no sustituye la arquitectura del proyecto.
¿Qué necesita la IA para maquetar siguiendo mi sistema de diseño?
Necesita que el sistema esté escrito: variables de color, escala tipográfica, sistema de espaciado, breakpoints, convención de nombres de clases, qué componentes existen ya y dónde vive cada archivo. Si esa información no está documentada en un lugar que la herramienta pueda leer, generará una solución razonable pero ajena al proyecto.
¿Sirve el MCP de Figma para maquetar?
Sirve, sobre todo para extraer valores exactos y montar la estructura de una pantalla sin tener que ir capa por capa. Su límite está en el coste: cada lectura del archivo consume muchos tokens y se repite en cada consulta posterior, así que en sesiones largas conviene extraer la información una vez y trabajar después contra ese documento.
¿El código que genera la IA es accesible?
No por defecto. Los fallos más habituales son elementos no semánticos con comportamiento interactivo, saltos en la jerarquía de encabezados y ausencia de estados de foco, porque el diseño no suele dibujarlos. Son errores invisibles en el navegador que hay que revisar en el HTML, no en la pantalla.
¿Cuánto tiempo se ahorra realmente maquetando con IA?
El ahorro es claro en la parte mecánica: extraer valores, montar estructuras repetitivas y generar variantes. A cambio aparece tiempo nuevo en preparar el contexto del proyecto y en revisar el código generado. El balance suele ser positivo en proyectos con el sistema bien definido y bastante peor en proyectos heredados sin convenciones.
¿Hace falta saber maquetar para usar IA en desarrollo front?
Hace más falta que antes. La herramienta entrega código que parece correcto y solo alguien con criterio puede distinguir el que está bien hecho del que simplemente funciona. Sin ese criterio no hay forma de evaluar el resultado, y los problemas aparecen en el mantenimiento, no en la entrega.
¿Qué falla cuando la maqueta se integra en un CMS?
El contenido real. Títulos más largos de lo previsto, campos vacíos, imágenes que no existen, listados con un único elemento y textos escritos en la plantilla sin pasar por las funciones de traducción en proyectos multiidioma. Conviene meter contenido real, e incómodo, en cuanto haya dos o tres componentes en pie.
