Vibe coding para diseñadores: la parte que decide si funciona

La experiencia común es que las dos primeras pantallas son asombrosas y la décima es un desastre. No es que el modelo empeore. Es que nada en el proyecto fijó cómo debía verse el resultado, por lo que cada turno vuelve a decidir: un espaciado ligeramente diferente aquí, un gris nuevo allá, un nuevo color de acento porque el anterior "se veía un poco plano".

Los profesionales que lanzan proyectos de forma constante describen el mismo hábito: esbozar primero el andamiaje —tema, rejilla, tipografía, color— y solo entonces empezar a pedir funcionalidades. Ese orden marca toda la diferencia, y es la parte que se suele omitir porque hacer prompts es más divertido.

1. 1

   Incluya un set de tokens en el proyecto

   Roles de color nombrados para modo claro y oscuro, una escala tipográfica, espaciados, radios. No una paleta, sino roles, para que la respuesta a "qué color tiene un botón desactivado" exista antes de que alguien la necesite. Un comando instala un set completo si prefiere no montarlo manualmente: npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Escriba un archivo de reglas que prohíba cosas

   Sea lo que sea que lea su herramienta —.cursor/rules/design.mdc, .devin/rules/design.md, una línea en CLAUDE.md. Manténgalo como una política, no como una cuestión de gusto: use solo los tokens semánticos, nunca un hex raw, no use un segundo color de acento en una pantalla, nunca implemente un cambio en modo claro sin su contraparte en modo oscuro, y pregunte en lugar de inventar cuando el sistema no especifique nada.

3. 3

   Tenga una vista previa activa antes de construir cualquier cosa

   Usted es diseñador; revisa mirando. Si no puede ver cómo se aplica el cambio, está revisando código, que es precisamente lo que no sabe hacer.

4. 4

   Haga el primer commit

   Antes de la primera funcionalidad. Este es su punto de referencia y, a partir de aquí, cada prompt es reversible. git es el botón de deshacer; el del chat no lo es.

El archivo de reglas importa más de lo que parece, y específicamente las prohibiciones. Una preferencia añade una opción; una prohibición elimina todas las demás. "Use nuestro verde" deja que cualquier valor predeterminado genérico siga siendo válido. "Nunca introduzca un color que no sea un token" no lo permite. Analizamos 299 documentos de diseño públicos escritos exactamente para este propósito y el 76% solo enumeraba preferencias, lo cual describe con precisión por qué dejan de funcionar alrededor de la pantalla cinco.

El problema autoinfligido más común es pedir demasiado a la vez. Un prompt que produce un diff de cuarenta archivos es un diff que nadie lee, lo que significa que la desviación entró sin revisión y se encontrará con ella más tarde preguntándose "por qué esta página se ve diferente".

• Una pantalla o un componente por turno. Revíselo, haga commit y continúe.
• Haga commit antes de cada prompt, no después. Así, el estado anterior correcto estará siempre a un comando de distancia y nunca tendrá que decidir si el último cambio valía la pena mientras intenta corregirlo.
• Indica qué no se debe tocar. "Cambia solo este componente" evita que se produzca una refactorización útil de tres archivos que ya habías aprobado.
• Cuando las cosas se tuercen, revierte en lugar de negociar. Tres rondas de "no, así no" producen un resultado parcheado que satisface la conversación, pero no el diseño. Vuelve al último commit correcto y vuelve a preguntar con un mejor prompt.

Esta es la habilidad que merece la pena aprender, y es una habilidad de revisión de diseño con un enfoque de git. No estás comprobando si el código es bueno. Estás comprobando cuatro cosas, y las cuatro son visibles sin necesidad de entender una sola línea de lógica.

Esos cuatro controles tardan aproximadamente un minuto por diff y detectan la mayor parte de lo que causa la deriva. Todo lo demás —ya sea si la gestión de estado es sensata o si la consulta es eficiente— no es realmente tu trabajo en esta etapa, y fingir lo contrario es lo que hace que los diseñadores eviten la revisión por completo.

• Aceptación complaciente. Pregunta "¿sigue esto el sistema de diseño?" y normalmente te dirán que sí. Pregunta en su lugar "enumera cada valor de color en este archivo que no sea un token", una pregunta con una respuesta verificable.
• Hardcoding para que funcione. Un valor pegado en lugar de una búsqueda hace que la pantalla sea correcta pero el sistema sea erróneo. Esto sale a la luz la primera vez que cambias un token y un componente no se mueve.
• Parchear la salida en lugar de corregir la causa. Un margen añadido para compensar un diseño que estaba mal dos componentes arriba. Cada parche es pequeño; el décimo es la razón por la que nada se puede cambiar de forma segura.
• Mejorar el sistema a mitad de la tarea. Un nuevo color introducido "para dar contraste". Esto es deriva con una justificación adjunta, y es el tipo más difícil de detectar porque el razonamiento es sólido.
• Pasar la prueba equivocada. Se renderiza, así que funciona. Comprueba el modo oscuro, un estado vacío y una cadena larga en una columna estrecha antes de darlo por válido.

Menos de lo que sugieren los cursos y más que cero. De forma útil, la cantidad requerida es específica en lugar de general.

• Leer un diff. Verde añadido, rojo eliminado y los cuatro controles anteriores. Una tarde.
• Git básico. Commit, ver un log, revertir a un commit. Media hora, y es la media hora con mayor retorno disponible.
• Dónde residen las cosas. Qué archivo es el tema, cuál es un componente y cuál es una página. Pide al agente que explique la estructura una vez; es muy bueno en esto.
• Leer un error. No solucionarlo. Ser capaz de pegar la parte relevante en lugar de una captura de pantalla de toda la terminal.

Lo que no necesitas es escribir React, entender las herramientas de compilación o gestionar dependencias. Eso es precisamente para lo que sirve el agente, y el tiempo dedicado a aprenderlas es tiempo que no se dedica a la habilidad de revisión, que es algo que nada más puede hacer por ti.

El vibe coding es excepcional para prototipos, herramientas internas, sitios de marketing y para demostrar que una interacción merece la pena ser construida. Es realmente arriesgado en los límites donde un error no es visual: autenticación, pagos, cualquier cosa que toque datos de clientes o cualquier cosa que implique una migración. Esos fallos no aparecen en la vista previa, que es el único canal de revisión que tienes.

Una línea útil: si el peor resultado de equivocarse es que se vea mal, lánzalo e itera. Si el peor resultado es que se vea afectado el dinero o los datos de otra persona, eso es una transferencia de responsabilidad, no un prompt.