Cuando se habla de los riesgos del Vibe Coding, lo primero que suele aparecer es la mala calidad del código, los fallos de seguridad y la dificultad de mantenimiento. Todo eso existe, pero para una persona que mantiene un proyecto largo en solitario, a menudo hay algo más peligroso: la deriva de requisitos.
La deriva de requisitos no es un bug concreto ni un commit obviamente equivocado. Se parece más a una pérdida gradual del sentido de dirección del proyecto. Las funciones siguen aumentando, el código todavía se ejecuta y la documentación quizá sigue ahí, pero ya no puedes explicar con claridad por qué ciertos módulos se dividieron de esa forma, por qué se mantuvo una restricción o dónde debería encajar el siguiente cambio.
El problema aparece con fuerza cuando intentas añadir una función que parece sencilla. Cambias una parte y se rompe otra; arreglas esa y se deforma una tercera. Después de varias rondas de parches con AI, descubres que lo que falta no es código, sino tu mapa completo del proyecto.
Por Qué Los Proyectos Largos Derivan Tan Fácilmente
El atractivo del Vibe Coding viene de la velocidad. Describes una necesidad vaga y AI genera rápidamente una pantalla de código. Añades una frase más y sigue avanzando. En tareas cortas esto es eficiente, pero en proyectos largos crea dos problemas que se refuerzan entre sí.
Primero, el modelo olvida. Esto no significa necesariamente que ya no pueda ver el contexto. Más bien, la información importante dentro de un contexto largo pierde peso. Los objetivos iniciales del producto, las decisiones de arquitectura, las convenciones de nombres y las condiciones de borde quedan enterrados bajo detalles de depuración, arreglos temporales y estados intermedios. Cuanto más ruidosa se vuelve la ventana de contexto, más fácil es que el modelo tome la prioridad equivocada.
Segundo, las personas también olvidan. AI reduce tanto la fricción de escribir código que salta el proceso que antes te obligaba a pensar con claridad. Antes, si los requisitos no estaban claros, no podías avanzar. Ahora, incluso con requisitos borrosos, AI puede producir una primera versión. La intención vaga se solidifica rápidamente en el código, y explicarla después se vuelve cada vez más difícil.
Por eso los proyectos personales chocan tan fácilmente con este muro. Eres product manager, desarrollador, tester y operador al mismo tiempo. Al programar quieres avanzar rápido; al tomar decisiones de producto necesitas frenar y preguntarte qué quieres realmente. AI acelera lo primero, pero no puede hacer lo segundo por ti.
El Problema Real No Es Que AI Escriba Mal, Sino Que Se Pierde La Intención
El código puede describir qué hace un sistema, pero es malo explicando por qué lo hace de esa manera.
Un proyecto suele descontrolarse no porque una parte del código sea especialmente mala, sino porque la intención detrás de las decisiones queda dispersa entre conversaciones largas, prompts temporales, memoria personal y commits fragmentados. Cuando vuelves a abrir el proyecto, puedes ver el resultado, pero no el razonamiento.
AI no puede resolver esto de forma fiable. Puede leer código, seguir cadenas de llamadas y añadir pruebas, pero no puede reconstruir con seguridad las decisiones originales. Incluso puede racionalizar una dirección equivocada a partir del código local que ve, empujando la deriva todavía más lejos.
Por eso la pregunta clave en Vibe Coding no es cómo hacer que AI nunca olvide. Es cómo evitar que la memoria del proyecto viva solo dentro de una conversación.
Mueve La Memoria Del Proyecto A Archivos
La forma más efectiva de combatir la deriva de requisitos es poner la intención, las restricciones y el estado dentro del repositorio, para que cada nueva sesión pueda leerlos de nuevo.
El paso más ligero es escribir un CLAUDE.md, AGENTS.md o un archivo de reglas similar. No tiene que ser largo, pero debe dejar claro:
- Qué problema resuelve el proyecto.
- Cuál es el objetivo de producto más importante ahora.
- Qué límites de arquitectura no deben cambiarse a la ligera.
- Las reglas habituales de nombres, directorios, pruebas y publicación.
- Qué prácticas están explícitamente prohibidas.
El valor de este archivo no es que sea un prompt más sofisticado. Su valor es fijar las restricciones que más fácilmente derivan al comienzo de cada sesión. Debe ser breve, estable y legible, sin llenarse de detalles temporales.
El siguiente paso es trabajar con especificaciones. No le pidas directamente a AI que “haga una función”. Primero convierte la necesidad en una especificación verificable:
- Cuál es el escenario de usuario.
- Cuáles son las entradas y salidas.
- Qué cuenta como éxito.
- Qué queda explícitamente fuera del alcance.
- Qué módulos existentes se verán afectados.
- Qué pruebas o verificaciones hacen falta.
Una especificación hace que AI trabaje alrededor de una intención clara, no alrededor de un prompt casual. En proyectos personales esto es especialmente importante, porque no hay un product manager que convierta tus ideas vagas en requisitos claros.
Haz Un Traspaso Antes De Cerrar Cada Sesión
No conviene empujar un proyecto largo dentro de una sola conversación interminable. Cuanto más larga es la sesión, más ruido de depuración se acumula y más fácil es que baje la calidad del juicio.
Un hábito más estable es escribir el estado de la sesión en un archivo antes de parar, por ejemplo PROGRESS.md, TODO.md o un registro de tareas:
- Qué se completó en esta sesión.
- Qué archivos importantes cambiaron.
- Qué problemas siguen sin resolverse.
- Desde dónde debería empezar la próxima sesión.
- Qué restricciones no deben romperse.
Luego haces commit del código. La próxima vez que abras una nueva sesión, AI no tendrá que inferir el estado del proyecto a partir de un historial largo de chat. Podrá leer el material de traspaso directamente desde el repositorio.
Parece simple, pero funciona. Mueve la memoria desde una conversación propensa a derivar hacia un sistema de archivos versionado.
Cuándo Detenerse Y Reorganizar
Si ya ves estas señales, conviene pausar la generación de funciones nuevas y ordenar primero el proyecto:
- El mismo problema se arregla una y otra vez y reaparece en otro lugar.
- AI cambia con frecuencia módulos que no tienen relación con la tarea.
- No puedes explicar por qué existe un directorio, una interfaz o un campo de estado.
- Las funciones nuevas dependen cada vez más de parches y menos de diseño claro.
- La documentación, el código y el comportamiento real dejan de coincidir.
- Necesitas mucho tiempo para volver a entender el estado del proyecto.
En ese punto, seguir haciendo Vibe Coding solo apila más confusión. Un mejor orden es reconstruir primero el mapa del proyecto y después escribir código: documentar módulos, añadir especificaciones, eliminar rutas abandonadas, agregar pruebas y registrar decisiones importantes como ADR o notas breves de diseño.
Qué Debe Proteger Realmente Un Proyecto Personal
AI puede ayudarte a escribir código, investigar bugs, añadir pruebas y refactorizar implementaciones locales. No puede sostener por ti la intención del producto a largo plazo.
En un proyecto personal, lo que hay que proteger no es “hacer que AI escriba un poco más cada vez”. Es seguir sabiendo por qué existe el producto, por qué el siguiente paso importa y qué límites no deben moverse. Mientras eso siga claro, AI es un acelerador. Cuando eso deriva, AI solo amplía la desviación más rápido.
Por eso el hábito más importante del Vibe Coding no es buscar el prompt perfecto. Es escribir regularmente requisitos, progreso, restricciones y decisiones de vuelta en el repositorio. Las conversaciones pueden ir rápido. La memoria del proyecto tiene que mantenerse estable.
Enlace original: