Los prototipos generados con IA fallan por inconsistencias pequeñas en el sistema de diseño. Aquí está la estructura de tres capas que reduce ese problema.
Llevamos meses viendo cómo equipos de producto adoptan agentes IA para generar prototipos, documentación y código de interfaz. El resultado, en muchos casos, es decepcionante. No porque la tecnología falle, sino porque el material que le damos para trabajar está lleno de decisiones no documentadas, valores escritos a mano que nadie limpió y componentes desconectados del sistema.
Hardik Pandya, del equipo de Atlassian, publicó en Smashing Magazine una guía práctica para reducir ese problema. Lo que sigue es nuestra lectura de ese enfoque, contextualizada para equipos que ya tienen un sistema de diseño en marcha y quieren que los modelos de lenguaje lo aprovechen de verdad.
El problema real: decisiones invisibles
Cuando un agente IA genera un prototipo a partir de una maqueta, intenta inferir el criterio de diseño. Adivina qué componente usar, qué espaciado aplicar, qué jerarquía respetar. Si esa información no está explícita en ningún sitio, el resultado varía en cada iteración.
La raíz del problema no es técnica: es que tratamos las decisiones de diseño como algo que "todo el mundo sabe". El modelo de lenguaje no lo sabe. Necesita que se lo contemos.
El enfoque que describe Pandya parte de una idea sencilla pero potente: las decisiones de diseño son infraestructura. No solo las decisiones visuales, también las de priorización y proceso. Si tomamos una decisión y no la escribimos en algún lugar que la IA pueda leer, esa decisión no existe para el sistema.
Tres capas para un sistema preparado
1. Archivos de especificación en Markdown
La primera capa son los llamados spec files: archivos de texto estructurado en Markdown que recogen reglas de espaciado, paleta de color, guías de uso de componentes, criterios de accesibilidad y prioridades del equipo.
Cada vez que el agente IA genera un prototipo, lee ese archivo primero. Al ser texto plano, el coste de procesamiento es menor y la precisión es mayor que cuando el modelo intenta interpretar una maqueta visual por su cuenta.
Esto tiene una implicación práctica importante: extender código existente suele dar mejores resultados que generarlo desde cero a partir de capturas. El modelo trabaja sobre reglas explícitas, no sobre suposiciones visuales.
2. Capa de tokens
Los tokens de diseño —variables de color, tipografía, espaciado— son el puente entre las decisiones documentadas y el código. Si los tokens están bien nombrados, son coherentes y están vinculados correctamente en los componentes, el agente IA puede usarlos sin ambigüedad.
El problema habitual es que los tokens existen en teoría pero en la práctica hay valores escritos a mano dispersos por el sistema. Esos valores "duros" rompen la cadena y generan inconsistencias en el output generado.
3. Auditoría continua
La tercera capa es el proceso de revisión. Pandya menciona FigmaLint, un complemento gratuito para Figma que permite auditar tokens, detectar instancias desvinculadas, identificar valores escritos a mano, revisar estados interactivos faltantes y comprobar accesibilidad.
Es especialmente útil cuando trabajamos con proveedores o terceros que entregan sus propias bibliotecas de componentes. Antes de conectar ese material a un flujo con IA, una auditoría con FigmaLint permite detectar los puntos débiles que van a causar problemas más adelante.
Lo que cambia en la práctica
Aplicar este enfoque no es un proyecto de semanas: es un cambio de hábito. Cada vez que el equipo toma una decisión —de diseño, de proceso, de criterio— alguien tiene que escribirla en el archivo de especificación correspondiente.
Al principio cuesta. Con el tiempo, ese archivo se convierte en la memoria del sistema: útil para incorporar personas nuevas, útil para revisiones, y útil para cualquier agente IA que trabaje con el sistema.
Hemos visto equipos que mejoran notablemente la calidad del código generado simplemente añadiendo un archivo de especificación bien escrito. No hace falta un sistema perfecto para empezar: hace falta un sistema documentado.
Por dónde empezar
- Escribe un primer archivo de especificación con las reglas más usadas: espaciado, color, tipografía y los tres o cuatro componentes principales.
- Pasa FigmaLint sobre tu biblioteca actual y anota los valores escritos a mano que aparezcan.
- Establece la norma de que toda decisión nueva se documenta antes de implementarse.
No es glamuroso. Pero es lo que separa un sistema de diseño que funciona con IA de uno que produce resultados aleatorios.
Fuente original
Sigue leyendo
Artículos relacionados.
Un año de ciberamenazas con IA: qué hemos aprendido analizando los patrones reales
Anthropic publicó un análisis exhaustivo de amenazas cibernéticas habilitadas por IA. Estas son las conclusiones más relevantes para entender el riesgo real.
Proteus, Stark y Vulcan: así renueva Amazon su flota de robots logísticos
Amazon presentó en Londres su nueva generación de robots autónomos con IA integrada. Te contamos qué cambia y qué significa para el sector logístico.
De la co-inteligencia a la co-existencia: trabajar con IA que a veces te supera
El investigador Ethan Mollick anuncia un nuevo libro sobre cómo prosperar junto a una IA que ya supera a los humanos en tareas concretas, sin ser aún perfecta.
Publicado el 6 de junio de 2026