¿Cómo hago vibe coding?

Qué te exige realmente el vibe coding

El vibe coding suena como la ausencia de método, y precisamente por eso les sale mal a tantas personas. Dejar que un modelo escriba el código elimina el problema de la sintaxis, pero no elimina los dos trabajos que siempre fueron la parte difícil: decir con precisión qué debe ocurrir, y comprobar que ocurrió. Tu esfuerzo se traslada en lugar de desaparecer —de escribir código a especificarlo y revisarlo. Para saber de dónde viene el término, consulta vibe coding.

Por eso dos fundadores que usan la misma herramienta obtienen resultados radicalmente distintos. El que empieza con "constrúyeme un marketplace" obtiene una demo que se derrumba en la segunda función. El que empieza con un párrafo que nombra al usuario, los datos y la única cosa que la versión uno debe hacer obtiene algo sobre lo que merece la pena construir. La elección de la herramienta importa menos de lo que sugieren la mayoría de las comparativas —las mejores herramientas de vibe coding cubre en qué se diferencian las familias— porque el bucle de abajo es el mismo elijas la que elijas.

El bucle, paso a paso

1. Escribe la especificación antes del prompt — un párrafo: quién usa esto, qué debe hacer, qué datos almacena, y qué no hará explícitamente en la versión uno. Diez minutos aquí evitan la reconstrucción que ocurre cuando el modelo adivina todo lo que dejaste sin decir.
2. Construye una porción cada vez — pide lo más pequeño que funcione de principio a fin, confirma que realmente funciona, y luego amplíalo. Un único prompt enorme produce una superficie tan grande que no tienes forma realista de revisarla.
3. Haz commit cada vez que algo funcione — el control de versiones es el botón de deshacer del trabajo generativo. Cuando el siguiente cambio rompe tres cosas a la vez, un commit que sabes que funciona es la única forma fiable de volver atrás, y cuesta un solo comando.
4. Lee tú mismo las líneas de riesgo — inicios de sesión, pagos, cualquier cosa que toque datos de clientes, y cualquier cosa que borre. Un modelo escribe código plausible y no te va a decir qué comprobación se saltó, así que esas rutas se leen línea por línea aunque el resto no.
5. Pruébalo como un desconocido — recórrelo como un usuario primerizo: entradas incorrectas, estados vacíos, el botón de atrás, una segunda cuenta. Las apps generadas suelen ser correctas en la ruta que describió el prompt y débiles en todo lo demás.
6. Lleva un registro de cambios — pide al modelo que resuma qué cambió y por qué después de cada porción, y guarda ese texto junto al proyecto. Es la defensa más barata contra un código que ya no puedes explicarle a nadie, ni siquiera a ti mismo.

Dónde se rompe

Los modos de fallo son constantes entre herramientas, y ninguno tiene realmente que ver con que el modelo sea malo programando:

• Suposiciones silenciosas — el modelo construye lo que pediste, no lo que querías decir. Todo lo que dejaste sin especificar se rellena con algo plausible, y descubres la brecha cuando un usuario real la encuentra.
• Cosas que funcionaban y dejan de funcionar en silencio — las ediciones generadas alcanzan más lejos de lo que parece. Si no puedes ejecutar todo el conjunto después de cada cambio, no notarás qué rompió el último cambio hasta mucho después.
• Seguridad que nunca elegiste — reglas de acceso por defecto, políticas de base de datos demasiado permisivas y claves confirmadas donde no deberían estar son habituales en las apps generadas, y nada te avisa. Compruébalas antes de lanzar, no después.
• El último veinte por ciento — el primer ochenta llega en una tarde; el resto es donde el modelo necesita que entiendas de verdad el sistema. O presupuestas ese tramo, o delimitas la versión uno para que no lo tenga.

Qué pasa después de que funcione

Terminar el bucle te da software que funciona pero que nadie sabe que existe, que es ahora la situación estándar de un fundador: construir se abarató drásticamente y la distribución no. Antes de construir más, decide para qué sirve realmente la versión uno —ese es todo el sentido de un producto mínimo viable— y cuando funcione, la siguiente pregunta es cómo dar a conocer una app hecha con vibe coding.

Nota en primera persona por construir AgentCeres —el Director de Crecimiento con IA en agentceres.com: la mayoría de nuestro código y de nuestras páginas de marketing las redacta la IA y las revisa un humano, y la clase de error más cara nunca fue el código malo. Fue el trabajo que desaparecía en silencio. Dos cambios generados en paralelo, cada uno correcto y superando todas las comprobaciones frente al punto de partida contra el que se escribió, y roto en el momento en que se combinaron —porque nadie volvió a ejecutar las comprobaciones sobre el resultado combinado. Si te llevas un solo hábito de esta página, que sea ese: porciones pequeñas, y verificar lo que realmente enviaste en lugar de la pieza que acabas de generar.