Tutoriales
Vibe coding sin desorden: 6 hábitos que evitan que los proyectos generados con IA se desmoronen
El vibe coding es genial hasta que deja de serlo. Describes lo que quieres, la IA lo escribe, haces clic por ahí, funciona, pides lo siguiente. En la primera hora o dos parece pegamento. Entonces un cambio rompe algo que no tenía nada que ver, le pides a la IA que lo arregle, el arreglo rompe otra cosa, y de pronto estás mirando un proyecto que no escribiste y no logras entender.
Ese fallo no es señal de que necesites aprender a programar primero. Es lo que pasa cuando nada en el proceso te da un camino de vuelta. Un puñado de hábitos pequeños resuelve la mayor parte, y ninguno exige entender cada línea que produce la IA.
Aquí van seis que vale la pena adoptar antes de tu próximo proyecto.
1. Escribe una especificación de una página antes del primer prompt
La forma más común de que un proyecto hecho con vibe coding salga mal es un primer prompt tipo “hazme una app de hábitos.” La IA tiene que inventar cada decisión que no tomaste: el stack, el modelo de datos, qué significa “terminado”. Cada suposición es razonable por sí sola, y juntas suman una app que no es del todo la tuya.
Dedica diez minutos a escribir lo que realmente quieres antes de abrir el chat. No hace falta que sea formal. Tiene que responder cuatro preguntas: qué hace, quién lo usa, qué herramientas debería usar y qué no forma parte explícitamente de esta versión.
Después pega esa especificación al inicio de la conversación y déjala ahí:
Esta es la especificación de lo que estamos construyendo. Síguela y pregúntame antes de añadir cualquier cosa que no esté en ella.Qué hace: [una o dos frases] Quién lo usa: [quién, y en qué dispositivo] Stack: [p. ej. HTML/CSS/JS puro, o React + Vite] Fuera del alcance de esta versión: [cosas que no quieres todavía]
No escribas código todavía. Primero, cuéntame en lenguaje claro cómo piensas construirlo, en pasos pequeños.
Esa última línea importa. Pedir primero el plan te da la oportunidad de detectar una suposición equivocada mientras todavía es una frase, y no una carpeta llena de archivos.
2. Una funcionalidad por prompt
Los prompts del tipo “construye la app entera” producen mucho código que nunca viste funcionar. Si algo está mal, no puedes saber cuál de las quince partes es la culpable.
Pide la porción más pequeña que funcione de punta a punta, ejecútala y solo después pide la siguiente. Añade el formulario. Haz que guarde. Muestra los elementos guardados. Añade el borrado. Cada paso es lo bastante pequeño como para que, si se rompe, sepas exactamente qué prompt lo rompió.
Esto también mantiene honesta a la IA. Los pedidos más pequeños dejan menos espacio para que reestructure en silencio cosas que no le pediste que tocara.
3. Haz commit después de cada paso que funcione
Este es el hábito que más rinde por el menor esfuerzo. El control de versiones con Git es un guardado de videojuego: cada vez que algo funciona, guardas, y si el siguiente prompt destruye el proyecto, vuelves al último guardado en lugar de intentar deshacer el desastre.
Después de cada paso que funcione, ejecuta:
git add -A
git commit -m "Add the save button"Cuando un prompt sale mal y todavía no hiciste commit del resultado, esto descarta los cambios sin commit en los archivos que Git ya rastrea y te devuelve a tu último guardado:
git restore .Cuidado: esto realmente descarta esos cambios, así que es para “este intento salió mal”, no para nada que quieras conservar. Si nunca usaste Git, pídele a la IA que lo configure y te explique cada comando. Lleva cinco minutos y es la mayor red de seguridad que puedes tener.
4. Mantén los secretos fuera de los prompts y fuera del repositorio
Tarde o temprano tu proyecto va a necesitar una clave de API, una contraseña de base de datos o un token. El error que hay que evitar es pegarlo en el chat o dejarlo fijo en el código, porque la IA lo escribirá directamente en tu código fuente con mucho gusto, y el código fuente termina en GitHub.
Pon los secretos en un archivo .env, y asegúrate de que .env esté listado en el .gitignore antes de tu primer commit, no después. Dile a la IA que esa es la regla:
Lee todas las claves de API y contraseñas desde variables de entorno
cargadas de un archivo .env. Nunca pongas una clave real en el código.
Asegúrate de que .env esté en .gitignore y añade un .env.example con
los nombres de las variables pero sin valores.Si una clave llega a hacerse commit o a pegarse en algún lugar público, no basta con borrarla del archivo. Trátala como comprometida: revócala en el panel del proveedor y crea una nueva, porque el historial de Git y los repositorios públicos guardan el valor antiguo.
5. Haz que la IA revise su propio trabajo
El código generado por IA suele escribirse para parecer correcto, y puede estar equivocado de formas que solo aparecen con una entrada fuera de lo común. No necesitas encontrar esos casos tú solo. Puedes pedirlos.
Después de cada funcionalidad, antes de seguir adelante, haz que la IA revise lo que acaba de escribir:
Antes de seguir: lista qué podría romperse con este cambio, incluyendo
entradas vacías, entradas muy largas y cualquier cosa que dependa de
las otras funcionalidades. Luego escribe pruebas para los dos casos
más riesgosos y ejecútalas. Explica en lenguaje claro cualquier parte
del código que hayas cambiado.Dos cosas para tener en cuenta. Primero, esto es una segunda mirada, no una garantía, así que sigue abriendo la app y tratando de romperla tú mismo. Segundo, la parte de “explica en lenguaje claro” es como vas, poco a poco, entendiendo tu propio proyecto, lo que compensa el día en que necesites depurarlo.
6. Reinicia el chat cuando empiece a dar vueltas en círculo
Hay un patrón familiar: la IA intenta un arreglo, no funciona, pegas el nuevo error, ella prueba otro arreglo, y tres rondas después el código está peor que donde empezaste. Las conversaciones largas acumulan ideas a medio abandonar, y la IA sigue construyendo sobre ellas.
Cuando un bug sobrevive a dos o tres intentos, detente. Vuelve atrás con git restore . si los intentos lo desordenaron todo, abre una conversación nueva y dale solo lo que necesita: la especificación, el archivo con el problema y el error exacto.
Empezamos de cero. Aquí está la especificación, el archivo que falla y el error exacto. Antes de cambiar nada, explica qué crees que lo causa y cómo podemos confirmarlo. Luego haz la corrección más pequeña posible.
[pega la especificación] [pega el archivo] [pega el error]
Un contexto limpio más “explica primero la causa” le gana a un cuarto intento a ciegas casi siempre.
La versión resumida
Si te llevas solo una cosa de aquí, que sea la red de seguridad. Los hábitos, en orden de esfuerzo frente a retorno:
- Haz commit después de cada paso que funcione, para tener siempre un camino de vuelta.
- Escribe una especificación corta, para que la IA no adivine lo que quieres.
- Pide una funcionalidad a la vez, para que una rotura sea fácil de rastrear.
- Mantén los secretos en el
.env, para que una clave nunca termine en un repositorio público. - Haz que la IA revise su propio trabajo, para que los problemas aparezcan antes de publicar.
- Reinicia el chat cuando entre en bucle, para que una mala conversación no hunda el proyecto.
Nada de esto hace el vibe coding mucho más lento. Solo significa que, cuando algo se rompa, y algo se va a romper, tienes un guardado al que volver y una idea clara de dónde falló.