Vibe Coding para diseñar: algunos aprendizajes

Mi primer post: por qué pasé de diseñar a mano a hacer vibe coding.

Vale, sí. Este es mi primer post. Llevaba tiempo dándole vueltas a escribir algo y al final he decidido empezar por lo que de verdad me ha tenido ocupado los últimos meses: dejar de diseñar a mano para empezar a hacer vibe coding. Así que bienvenido seas, y perdona si me enrollo, que es la primera vez y todavía le estoy cogiendo el punto a esto.

Te lo cuento tal cual me pasó, sin postureo. No soy ningún gurú del diseño ni del desarrollo: soy alguien que quería sacar cosas y se fue topando con sus propios límites por el camino.

Qué entiendo yo por "diseñar a mano"

Cuando digo "diseñar a mano" no me refiero a lápiz y papel. Me refiero a sentarme a construir cada pantalla pieza a pieza: colocar cada componente, ajustar cada margen, mimar cada interacción. Yo lo viví primero con Figma, y luego con Framer cuando quise darle algo más de movimiento. Herramientas que adoro, ojo. Pero las dos comparten una cosa: el resultado depende de cuánto tiempo y mimo le metas tú a mano.

Y ahí estaba mi problema.

El cariño (y el atasco) de hacerlo todo a mano

A Figma le tengo cariño de verdad. Abres y dices "qué a gusto se trabaja aquí". Tenía diseños preciosos, pantallas que daban gusto verlas... y luego nada. Bonito, sí. Pero quieto. No se movía, no respondía, no era real.

Entonces salté a Framer buscando ese punto más dinámico. Y al principio, genial. Pero aquí viene la parte honesta: yo no me dedico a esto al 100%. Lo hago a ratos, entre otras mil cosas. Y en cuanto quería algo un poco más complicado, la cosa se atascaba. Intentos, errores, vuelta a empezar. Me pasaba más tiempo peleándome con el cómo que avanzando con el qué.

No es culpa de las herramientas. Es que yo le pedía a un proceso a mano cosas que requerían un tiempo que sencillamente no tenía.

El salto al vibe coding

Y aquí está el giro. Llegó un momento en el que pensé: "necesito salir con algo, ya". No el diseño perfecto, no la animación de revista. Algo que funcione y que pueda enseñar.

Ahí me ganó el vibe coding. Le cuentas lo que quieres, casi como se lo explicarías a un colega, y vas viendo resultados. Iteras hablando, no peleándote con menús ni propiedades que no sé dónde están. Y eso que a mano se me atravesaba, lo tenía medio resuelto en un rato.

No te voy a vender que es magia ni que todo sale a la primera (spoiler: no). Pero la sensación de avanzar en lugar de atascarme fue justo lo que necesitaba.

Lo bueno (y lo no tan bueno)

Lo curioso es lo distinto que se siente cuando las cosas se complican. Diseñando a mano, cuanto más ambicioso era el proyecto, más rápido subía mi frustración. Con vibe coding también sube, claro, pero mucho más despacio: la cuesta no se hace tan empinada.

Eso sí, te lo digo también: con el vibe coding pierdes algo de control fino. Esa precisión de píxel, ese mimo en cada animación... no es lo mismo. Hay un intercambio ahí, y sería deshonesto no reconocerlo.

Entonces, ¿cuál es mejor?

Ninguno. O los dos, según para qué. Me he dado cuenta de que no es una guerra: diseñar a mano gana en mimo visual y en control, y el vibe coding gana en velocidad para salir con algo. Y cuando no le dedicas el 100% de tu tiempo, esa velocidad no es un lujo: es lo que marca la diferencia entre publicar o quedarte el proyecto en un cajón.

Lo que me llevo de todo esto

Si tuviera que quedarme con una idea, sería esta: no pasa nada por usar el atajo cuando el atajo te deja terminar. Durante mucho tiempo sentí que "lo correcto" era hacerlo todo a mano, con mimo, hasta el último píxel. Y resulta que lo correcto, al menos para mí, era acabar las cosas.

El vibe coding no me ha convertido en mejor diseñador. Me ha convertido en alguien que publica. Y para un primer post, en un blog que acabo de estrenar, me parece una buena moraleja con la que empezar.

Gracias por leer hasta aquí. Nos vemos en el siguiente.