Agentes de IA que respetan tu sistema de diseño

Los agentes de IA que programan pueden respetar un sistema de diseño cuando se deja de pedirles que «hagan algo acorde con la marca» y se les dan tres cosas concretas: un archivo legible que reúna el criterio de diseño, un conjunto acotado de componentes o estilos para resolver de forma consistente la parte mecánica y evaluaciones fijas que demuestren si las reglas funcionan.

Eso cambia la partida presupuestaria. El objetivo no es generar código más barato, sino dedicar menos horas a corregir las mismas decisiones de tipografía, jerarquía, espaciado y redacción después de cada primer borrador. El flujo público design.md de Vercel es, hasta ahora, el patrón funcional más claro; sus propios resultados también explican por qué la revisión humana debe seguir formando parte del sistema.

Qué necesitan los agentes de IA: un archivo, una capa de restricciones y un ciclo de verificación

Lo valioso del flujo design.md de Vercel no es el nombre del archivo, sino la separación de responsabilidades.

1. La guía concentra el criterio. Un archivo público explica al agente para quién es la página, qué debe decidir el lector, cómo se estructura la evidencia, cómo se expresa la marca y qué vicios habituales del diseño generado conviene evitar.
2. Los elementos base resuelven la mecánica. Una hoja de estilos publicada ofrece al agente un vocabulario acotado de encabezados, tablas, franjas de estadísticas, estilos de gráficos, clases y tokens. El modelo elige un elemento aprobado en vez de improvisar otro sistema de espaciado o tipografía.
3. Las evaluaciones aportan la prueba. Los escenarios fijos, las comprobaciones deterministas y la revisión humana revelan si un cambio mejoró los primeros intentos o solo trasladó el problema a otra parte.

Puede compararse con un restaurante. El archivo de guía representa el criterio del chef sobre el plato; los componentes y estilos son la estación abastecida y los utensilios medidos; las evaluaciones son la degustación final. Ni siquiera una receta detallada produce platos consistentes si falta una estación bien preparada.

Vercel llegó a esta división después de que un prompt sencillo no funcionara. La primera versión pública describía el lenguaje visual, pero los modelos interpretaban de forma distinta las frases subjetivas porque no tenían disponibles los componentes ni los ejemplos publicados dentro de los repositorios de Vercel. Entonces, el equipo reescribió el archivo tomando resultados fijos como referencia, en lugar de considerar terminado el texto solo porque sonaba convincente.

La diferencia es importante. Un sistema de diseño pensado para personas puede apoyarse en el gusto compartido, la memoria institucional y la capacidad de un diseñador para detectar un resultado que casi acierta. Si debe servir a un agente, la decisión tiene que ser recuperable, la implementación permitida debe resultar evidente y el fallo ha de ser observable.

Qué debe contener el archivo de guía

El primer archivo debería ser más breve que el sistema de diseño al que representa. Es un mapa de decisiones, no un museo de todos los componentes.

Conviene dividirlo en seis secciones:

• Alcance: qué superficies deben cargar el archivo y qué trabajos deben ignorarlo.
• Lector y objetivo: quién abre cada artefacto, qué necesita comprender o decidir y qué evidencia permite tomar esa decisión.
• Decisiones observables: reglas como «las tablas de evidencia pueden ocupar todo el ancho del contenido», en vez de adjetivos como «limpio» o «premium».
• Elementos disponibles: los nombres exactos de los componentes, clases o tokens que puede elegir el agente y el contexto apropiado para cada uno.
• Patrones de fallo con nombre: resultados deficientes recurrentes, identificados con nombres fáciles de recordar, un síntoma concreto y la corrección preferida.
• Límites: los datos que el agente debe preservar, los estados que debe cubrir, las afirmaciones sin respaldo que debe omitir y las decisiones que todavía requieren la intervención de una persona.

El archivo debe explicar por qué existe una elección cuando el contexto es relevante, y remitir al código cuando la respuesta ya reside allí. Copiar todas las reglas CSS al contexto del modelo desperdicia atención y crea dos fuentes de verdad. La hoja de estilos pública de Vercel se carga en el navegador, mientras que design.md documenta los nombres que el agente debe utilizar; por eso, el código de la hoja de estilos no ocupa contexto del modelo.

También hay un problema de recuperación. En evaluaciones independientes con Next.js, Vercel comprobó que los agentes no invocaban una skill disponible en el 56% de los casos. Incluye el disparador en las instrucciones persistentes del repositorio, delimita el alcance, pide al agente que indique qué guía cargó y evalúa por separado la carga y el cumplimiento de las reglas. Un archivo perfecto que nunca se abre no deja de ser mera documentación.

Al elegir el agente o la interfaz para este sistema, las diferencias prácticas entre Claude Design y v0 para generar interfaces importan menos que garantizar que ambos reciban las mismas restricciones y evaluaciones.

Envía cada corrección al responsable más específico

La regla operativa más sólida es sencilla: no intentes resolver todos los fallos de diseño con más texto.

Aquí es donde muchos equipos terminan inflando demasiado el archivo. Siguen añadiendo frases como «usa el espaciado correcto» cuando un token de espaciado acotado resolvería siempre la decisión. O convierten una elección de política de producto en un linter, aunque el código no pueda juzgar sus excepciones. Más instrucciones no significan necesariamente más control.

Cómo evaluar agentes de IA para diseño web antes del despliegue

Una evaluación solo sirve si la comparación es justa. Elige un artefacto recurrente con un lector real, datos reales y una rúbrica breve. Genera una línea base y repite después el mismo prompt, los mismos datos, el mismo modelo y el mismo viewport con la guía cargada. Conserva los primeros intentos. Mezcla los resultados antes de revisarlos para que quien los evalúe no sepa qué versión utilizó las reglas nuevas.

Vercel creó siete escenarios basados en trabajos recurrentes, entre ellos una propuesta de renovación, un informe de benchmarks, una página de planificación, un informe de seguridad y una presentación. Las rondas completas ejecutaron los siete con Claude Opus 4.8 y Codex con GPT-5.5. Cada ejecución almacenada conservó el prompt, los datos de entrada, la configuración del modelo, la versión de la guía, las capturas de pantalla y los comentarios del revisor.

El resultado que conviene recordar es específico, no universal. En tres escenarios de escritorio y seis páginas generadas al primer intento, Vercel contabilizó 39 fallos conocidos con design.md y 91 sin él: un 57% menos en esa prueba. La muestra fue pequeña, las comprobaciones solo podían detectar fallos ya codificados y todas las páginas todavía presentaban al menos un problema lo bastante grave como para impedir su publicación. No traslades ese 57% a una previsión comercial. Replica el método y mide la carga de revisión de tu propio equipo.

Empieza por estas cuentas de negocio:

• Cuenta los minutos que un diseñador o un ingeniero sénior dedica a corregir cada primer borrador.
• Multiplica esa cifra por la cantidad de artefactos recurrentes publicados cada mes.
• Suma el tiempo invertido en explicar la misma corrección en el chat, los pull requests y las revisiones de diseño.
• Tras incorporar el sistema, ejecuta el mismo conjunto de artefactos y mide la diferencia.

Por ejemplo, cuatro páginas recurrentes que necesitan dos horas de correcciones cada una consumen ocho horas de revisión. Si el sistema acotado elimina una hora de arreglos repetidos por página, el ahorro es de cuatro horas. Eso sí es un ahorro medido; «el resultado parece más acorde con la marca» no lo es.

El mercado actual aporta otra referencia útil. Los creadores de sitios web con IA cuestan aproximadamente entre $0 y $160 al mes según los precios publicados, mientras que una guía de 2026 sobre sitios a medida sitúa esos proyectos entre $1,500 y $5,000. Una capa de control de marca debe justificar su coste frente a ambas opciones. Su valor no reside en añadir otro botón para generar, sino en reducir las revisiones, las aprobaciones y el riesgo de marca en trabajos recurrentes.

Siete casos de uso, ordenados por quién obtiene más valor

1. Agencias multimarca que producen sitios de campaña de forma recurrente

Una agencia con diez clientes activos puede mantener un archivo de guía y un conjunto acotado de elementos base para cada uno, y ejecutar después la misma evaluación de páginas de lanzamiento cada vez que cambie un agente, una biblioteca de componentes o un modelo. La recompensa es dedicar menos horas de diseño sénior a recuperar la tipografía y la jerarquía cuando la página ya funciona. Este grupo es el más beneficiado porque cada corrección aceptada puede mejorar todos los artefactos posteriores de ese cliente.

2. Equipos de producto con varios agentes trabajando sobre la misma interfaz

Un equipo de plataforma puede dirigir todo el trabajo de interfaz mediante una sola instrucción del repositorio, cargar la guía únicamente para los cambios visibles para el usuario y aplicar las reglas mecánicas con linting. El agente concreto puede cambiar, pero las decisiones aprobadas permanecen junto al código. El beneficio es mantener la consistencia entre colaboradores sin pedir a cada modelo que deduzca la intención únicamente a partir de los componentes publicados.

3. Equipos comerciales que generan propuestas, benchmarks e informes

Un equipo de operaciones de ventas puede fijar un escenario de propuesta de renovación con datos ficticios del cliente, una rúbrica para lectura ejecutiva y otra para una auditoría detallada. Cada nueva versión de la guía debe mantener visible la recomendación, preservar las cifras proporcionadas y dar suficiente espacio a la evidencia. El resultado son primeros borradores más rápidos sin permitir que un dashboard genérico oculte la decisión comercial.

4. Equipos de sistemas de diseño que se preparan para adoptar agentes

Un equipo responsable del sistema de diseño puede documentar los tokens y componentes exactos que los agentes tienen permitido utilizar, asignar nombres a los patrones de fallo habituales y añadir comprobaciones deterministas cuando la regla sea mecánica. Así, una biblioteca de componentes se convierte en un sistema operativo para tomar decisiones, no en un simple catálogo que los agentes imitan de forma inconsistente.

5. Startups sin una cola de revisión de diseño a tiempo completo

Un equipo pequeño puede empezar con un solo artefacto, como su página semanal de métricas, y las últimas diez correcciones recurrentes. No necesita toda la aplicación de evaluación de Vercel. Basta con una línea base, una ejecución comparable y una ficha de evaluación humana para revelar los principales fallos. La ventaja consiste en concentrar el escaso criterio de diseño en un lugar reutilizable y conservar la aprobación final en manos de una persona fundadora o diseñadora.

6. Equipos de herramientas internas al servicio de distintos departamentos

Un equipo de plataforma interna puede compartir mecanismos aprobados de accesibilidad, estados y maquetación, y mantener a la vez una pequeña capa de guía para cada tarea, como la conciliación financiera o las operaciones de soporte. El beneficio es compartir la calidad de implementación sin obligar a flujos de trabajo sustancialmente distintos a encajar en una única plantilla visual.

7. Equipos regulados que necesitan un registro de auditoría

Un equipo de salud, finanzas o seguridad podría conservar el prompt, los datos de entrada, la versión del modelo, la versión de la guía, el render, las comprobaciones y la decisión del revisor en cada ejecución. El beneficio es la trazabilidad: quien revisa puede ver qué regla influyó en un resultado y qué persona aprobó la excepción. Este patrón no vuelve conforme el resultado por sí solo, pero facilita la reconstrucción de las evidencias de revisión.

Si tu organización todavía está decidiendo si el flujo de agentes debe convertirse en un producto o seguir siendo una capacidad interna, el siguiente paso útil es este marco para decidir entre crear o comprar agentes de programación.

Tres productos que vale la pena crear

1. Compilador de sistemas de diseño para agentes: la mejor oportunidad

Crea un espacio de trabajo que transforme los tokens, la documentación de componentes y las correcciones recurrentes de una empresa en un archivo de guía versionado, un mapa de implementación acotado y un paquete inicial de evaluaciones. Los equipos de operaciones de diseño y plataforma estarían dispuestos a pagar porque el producto se sitúa justo entre su sistema actual y todos los agentes de programación que adopten.

La demanda es más específica que la generación genérica de sitios web, pero está mucho más cerca del comprador. Alrededor de 260 búsquedas mensuales en EE. UU. apuntan a design system software, con intención comercial, dificultad de palabra clave 14 y un CPC de $12.33. Ese CPC es relevante porque indica que los proveedores ya valoran esa atención, aunque el volumen de búsquedas sea modesto.

La versión vendible más pequeña necesita una única vía de entrada, como un repositorio más un formulario estructurado para registrar correcciones, y una única vía de salida: design.md, un mapa de elementos base aprobados, tres escenarios fijos y un informe que muestre qué reglas superó cada ejecución. Empieza con un framework y una clase de artefacto.

El obstáculo está en la incorporación. El criterio de diseño más valioso de una empresa rara vez está lo bastante ordenado como para importarlo automáticamente. Al principio, el producto funcionará en parte como software y en parte como servicio; su ventaja competitiva surgirá de convertir un historial desordenado de revisiones en decisiones fiables y verificables.

2. Fábrica de micrositios sujetos a una marca

Crea un generador para agencias y equipos comerciales que produzca una clase concreta de página acorde con la marca, como propuestas o micrositios de campaña, a partir de datos aprobados y un paquete de restricciones específico del cliente. El comprador paga por iteraciones controladas y pruebas de aprobación, no por generar páginas sin más.

La demanda general es grande: ai website builder recibe unas 40,500 búsquedas mensuales en EE. UU., con un aumento del 49% en la tendencia anual, intención comercial y un CPC de $31.41. Las ofertas existentes abarcan desde planes gratuitos hasta aproximadamente $160 al mes, así que un nuevo participante no puede competir con la promesa «escribe un prompt y obtén un sitio». Necesita una propuesta más precisa: las mismas reglas de marca, los mismos elementos base aprobados y las mismas evidencias de revisión en cada ejecución.

El MVP debería admitir un tipo de página, un formato de importación, un conjunto fijo de componentes, tres escenarios de evaluación y una pantalla de aprobación lado a lado. El inconveniente es una categoría saturada con competidores consolidados. La gobernanza y la repetibilidad deben ser el producto; de lo contrario, esto se convierte en otra interfaz superficial sobre un modelo.

3. Servicio de control de calidad de diseño para agentes

Crea un servicio para pull requests que renderice las páginas hechas por agentes en viewports fijos, ejecute comprobaciones mecánicas de diseño, almacene las versiones del modelo y de la guía y envíe las diferencias subjetivas a una cola de revisión humana a ciegas. Los equipos que ya usan agentes de programación pagarían por detectar fallos recurrentes antes de que lleguen a un revisor sénior.

Alrededor de 320 búsquedas mensuales en EE. UU. apuntan a visual regression testing, con dificultad de palabra clave 8 y un CPC de $20.56. No es un volumen de mercado masivo, pero demuestra de manera directa que hay equipos buscando verificación visual automatizada. La baja dificultad abre espacio para un enfoque específico para agentes, basado en el cumplimiento de reglas y no solo en la diferencia entre píxeles.

El MVP puede empezar con una comprobación de GitHub, dos viewports, una docena de reglas deterministas, almacenamiento de capturas de pantalla y el veredicto de un revisor. El inconveniente es que una diferencia visual no equivale a calidad de diseño. Una comparación de píxeles puede detectar desviaciones y un modelo evaluador puede redactar una crítica, pero la jerarquía, el significado del producto y las políticas nuevas siguen necesitando personas.

Lo que este patrón no resuelve

Un solo archivo no convierte un sistema de diseño débil en uno sólido. No puede aportar decisiones que el equipo nunca tomó, reparar componentes inaccesibles, demostrar la exactitud de los datos ni decidir una política de producto nueva. Tampoco hará que todos los modelos se comporten de la misma forma.

Las restricciones pueden reducir variaciones repetibles, pero también inmovilizar un elemento base deficiente. Las evaluaciones pueden impedir fallos conocidos, pero también premiar una rúbrica estrecha y pasar por alto un problema nuevo. La revisión humana puede detectar errores de criterio, pero solo si los revisores registran las correcciones en un formato reutilizable por el sistema.

El resultado de Vercel es una señal útil precisamente porque la empresa expone sus límites. Seis páginas no constituyen un estudio de fiabilidad. Las comprobaciones de fallos conocidos no miden la calidad global del diseño. Todas las páginas evaluadas todavía tenían un obstáculo para su publicación. El objetivo honesto del primer despliegue es reducir las correcciones repetidas, no aprobar diseños de manera autónoma.

La acción concreta para el lunes es esta: elige una página recurrente, guarda el primer borrador sin asistencia, reúne las últimas diez correcciones que hizo el equipo en ese tipo de página, envía cada una a la guía, los elementos base, el código o una decisión humana y realiza una comparación a ciegas. Amplía el sistema solo cuando ese ciclo reduzca el tiempo de revisión medido.

¿De verdad puede la IA crear un sitio web por mí?

Sí. Los agentes de programación y los creadores de sitios web con IA pueden producir páginas funcionales a partir de un prompt. La cuestión más difícil es si el primer borrador respeta la marca, conserva los datos proporcionados, contempla los estados correctos y supera la revisión. Una guía, elementos base acotados y evaluaciones comparables sirven para cerrar esas brechas.

¿Es bueno un creador de páginas web con IA?

Resulta útil para trabajar rápido, sobre todo cuando la tarea está bien delimitada y las opciones de implementación están acotadas. Es menos fiable cuando «bueno» depende de un criterio de producto no expresado, un lenguaje de diseño propio o decisiones de política nuevas. Evalúalo por el tiempo necesario para corregir el primer intento, no por la demostración más atractiva después de regenerar varias veces.

¿Cuánto cuestan los creadores de sitios web con IA?

Los precios publicados para los creadores de sitios web con IA van aproximadamente de $0 a $160 al mes. Ese precio no incluye los costes de revisión, corrección, aprobación y riesgo de marca del equipo. Mide esas horas por separado antes de decidir si compensa adoptar un sistema interno más controlado.

¿Conviene más crear un sitio propio o usar un creador de sitios web?

Usa un creador cuando la página sea estándar, el riesgo sea bajo y sus restricciones encajen con la marca. Crea un flujo de agentes controlado cuando repitas el mismo artefacto, necesites componentes y evidencias aprobados o dediques una cantidad relevante de tiempo sénior a corregir resultados. La cifra decisiva es el coste recurrente de revisión.

Si quieres implantar en tu empresa un flujo de agentes de programación que tenga en cuenta el diseño, consulta el servicio de desarrollo de agentes de IA.