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 esté empeorando. Es que nada en el proyecto definió nunca cómo debía verse la cosa, por lo que cada turno vuelve a decidir: un espaciado ligeramente distinto aquí, un gris nuevo allá, un nuevo color de acento cuando el anterior "parecía un poco plano".

Los profesionales que lanzan productos de forma constante describen el mismo hábito: esquematizar el scaffolding primero (tema, rejilla, tipografía, color) y solo entonces empezar a pedir funcionalidades. Ese orden lo cambia todo, y es la parte que se suele saltar porque hacer prompting es más divertido.

1. 1

   Incluye un conjunto de tokens en el proyecto

   Roles de color con nombre para modo claro y oscuro, una escala tipográfica, espaciado, radios. No una paleta: roles, para que la respuesta a "qué color tiene un botón desactivado" exista antes de que nada lo necesite. Un comando instala un conjunto completo si prefieres no armarlo tú mismo: npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Escribe un archivo de reglas que prohíba cosas

   Independientemente de la herramienta que uses: .cursor/rules/design.mdc, .devin/rules/design.md, una línea en CLAUDE.md. Manténlo como una política, no como un gusto: usa solo los tokens semánticos, nunca un hex raw, no añadas un segundo color de acento en una pantalla, nunca lances un cambio de modo claro sin su contraparte en modo oscuro, y pregunta en lugar de inventar cuando el sistema guarde silencio.

3. 3

   Ten una vista previa en ejecución antes de construir nada

   Eres diseñador; revisas visualmente. Si no puedes ver cómo se aplica el cambio, estás revisando código, que es lo único para lo que no estás preparado.

4. 4

   Haz el primer commit

   Antes de la primera funcionalidad. Esta es tu línea base, y desde 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. "Usa nuestro verde" permite que cualquier valor predeterminado genérico siga siendo válido. "Nunca introduzcas un color que no sea un token" no lo hace. Analizamos 299 documentos de diseño públicos escritos precisamente para este propósito y el 76% solo enumeraba preferencias, lo que explica con precisión por qué dejan de funcionar hacia la quinta pantalla.

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 se produjo sin revisión y te la encontrarás más tarde como un "¿por qué esta página se ve diferente?".

• Una pantalla o un componente por turno. Míralo, haz commit y sigue adelante.
• Haz commit antes de cada prompt, no después. Así, el estado bueno anterior siempre estará a un comando de distancia y nunca tendrás que decidir si el último cambio valía la pena mientras intentas arreglarlo.
• Indique qué no debe tocar. "Cambia solo este componente" evita que el agente realice una refactorización "útil" de tres archivos que usted ya había aprobado.
• Cuando algo salga mal, revierta en lugar de negociar. Tres rondas de "no, no así" producen un resultado parcheado que satisface la conversación, pero no el diseño. Vuelva al último commit correcto y vuelva a preguntar con un prompt mejor.

Esta es la habilidad que merece la pena aprender; es una capacidad de revisión de diseño disfrazada de git. No se trata de comprobar si el código es bueno. Se trata de verificar cuatro cosas, y las cuatro son visibles sin entender una sola línea de lógica.

Esas cuatro comprobaciones llevan aproximadamente un minuto por diff y detectan la mayor parte de lo que causa la deriva del diseño. Todo lo demás (si la gestión del estado es sensata, si la consulta es eficiente) no es realmente su trabajo en esta etapa; fingir lo contrario es lo que hace que los diseñadores eviten la revisión por completo.

• Aceptación complaciente. Si pregunta "¿está esto siguiendo el sistema de diseño?", normalmente le dirán que sí. Pregunte 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 referencia hace que la pantalla se vea correcta, pero que el sistema esté mal. Esto sale a la luz la primera vez que cambia un token y un componente no se mueve.
• Parchear el resultado en lugar de corregir la causa. Un margen añadido para compensar un diseño que estaba mal dos componentes más arriba. Cada parche es pequeño; el décimo es la razón por la que ya nada puede cambiarse de forma segura.
• Mejorar el sistema a mitad de la tarea. Un color nuevo 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.
• Superar la prueba equivocada. Se renderiza, así que funciona. Compruebe el modo oscuro, un estado vacío y una cadena de texto larga en una columna estrecha antes de darlo por válido.

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

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

Lo que no necesita es escribir React, entender las herramientas de build o gestionar dependencias. Para eso es exactamente 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 usted.

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

Una regla útil: si el peor resultado de equivocarse es que se vea mal, láncelo e itere. Si el peor resultado es que se vean afectados los datos o el dinero de otra persona, eso es un handoff, no un prompt.