Vibe Coding: cómo recuperar un proyecto cuando el código se desordena

Vibe Coding: cómo recuperar un proyecto cuando el código se desordena

El primer prototipo construido con IA puede avanzar muy rápido: una pantalla nueva aquí, una integración allá y varias instrucciones enviadas al asistente para corregir errores o agregar funciones. El problema aparece después, cuando una modificación rompe otra, existen archivos que hacen casi lo mismo o el proyecto parece comportarse de manera diferente según el cambio realizado.

Esta situación no significa necesariamente que el proyecto deba descartarse. En muchos casos, todavía es posible recuperarlo, pero conviene dejar de agregar funcionalidades temporalmente y recuperar el control sobre el comportamiento, la estructura y el contexto del proyecto. En este artículo verás un método práctico para estabilizar un MVP antes de continuar desarrollándolo con IA.

Por qué un proyecto con IA puede desordenarse

Una herramienta de IA genera respuestas a partir del contexto que recibe. Si ese contexto es incompleto, contradictorio o demasiado amplio, puede proponer cambios que parezcan razonables de forma aislada, pero que no encajen con el resto del sistema.

El desorden suele aparecer por una combinación de estos factores:

• Requisitos que cambiaron sin quedar documentados: una función debía comportarse de una manera, pero después se pidió una excepción distinta.
• Instrucciones contradictorias: una conversación indica que ciertos datos son obligatorios y otra solicita permitirlos vacíos.
• Archivos duplicados: existen dos componentes, servicios o configuraciones que parecen resolver el mismo problema.
• Cambios demasiado grandes: se solicitan varias funcionalidades y correcciones en una sola instrucción.
• Falta de validación: se acepta una modificación porque parece correcta, sin probar los flujos que ya funcionaban.
• Dependencias o configuraciones inconsistentes: una parte del proyecto espera una biblioteca, una variable o una estructura de datos diferente.

La IA no mantiene automáticamente una visión completa y confiable del proyecto. Por eso, dirigir el cambio es parte del desarrollo, incluso cuando gran parte del código la genera una herramienta.

Primero define qué debería hacer el proyecto

Antes de revisar archivos o pedir otra corrección a la IA, vuelve a describir el comportamiento esperado. Esta es la referencia que permitirá distinguir entre un error real y una decisión que simplemente cambió.

Describe los flujos principales

Elige las acciones más importantes para el usuario y escríbelas con un formato simple:

• El usuario crea una cuenta.
• El usuario inicia sesión.
• El usuario crea un registro.
• El usuario consulta sus registros.
• El usuario modifica o elimina un registro.

Para cada flujo, define qué debe ocurrir, qué datos son necesarios y qué debería ver el usuario cuando algo sale mal. No es necesario utilizar lenguaje técnico. Una descripción como “si el correo ya está registrado, se debe mostrar un mensaje y no crear otra cuenta” puede ser más útil que una instrucción general como “corrige el registro”.

Convierte las expectativas en criterios de aceptación

Un criterio de aceptación es una condición concreta que permite comprobar si una función está terminada. Por ejemplo:

• Si el usuario envía el formulario sin nombre, el sistema no debe guardar el registro.
• Después de guardar un registro válido, debe aparecer en la lista sin recargar manualmente la aplicación.
• Un usuario no debe poder consultar registros pertenecientes a otra cuenta.

Estos criterios ayudan a evitar que la IA “corrija” un problema introduciendo otro. También permiten probar el proyecto sin depender de si el código se ve ordenado o moderno.

Haz un inventario de la estructura y las dependencias

Cuando un proyecto se desordena, no conviene comenzar cambiando nombres de archivos o reorganizando carpetas al azar. Primero necesitas saber qué existe y qué parte del sistema participa en cada flujo.

Identifica las piezas principales

En un MVP normalmente encontrarás algunas de estas áreas:

• Interfaz: pantallas, formularios, botones y mensajes que utiliza la persona.
• Lógica de negocio: reglas que determinan qué se puede hacer y bajo qué condiciones.
• API o backend: servicios que reciben solicitudes y devuelven datos.
• Base de datos: información persistente del producto.
• Configuración: variables de entorno, credenciales, direcciones de servicios y opciones de ejecución.
• Pruebas y herramientas: mecanismos para verificar que los flujos continúan funcionando.

La ubicación exacta puede variar según la tecnología utilizada. Lo importante es comprender el papel de cada parte, no memorizar una estructura específica de carpetas.

Busca duplicados y fuentes de verdad

Un problema frecuente es que una misma decisión esté implementada en varios lugares. Por ejemplo, una validación puede existir en la interfaz y también en el backend, pero con reglas distintas. También puede haber dos archivos que representan el mismo tipo de usuario o dos funciones que calculan el mismo valor de forma diferente.

Para cada concepto importante, intenta responder:

• ¿Dónde se define?
• ¿Dónde se modifica?
• ¿Quién lo consume?
• ¿Cuál de las versiones debe considerarse válida?

Si no puedes responder estas preguntas, todavía no es buen momento para pedir una refactorización amplia. Primero necesitas aclarar la fuente de verdad.

Revisa las dependencias sin actualizarlas por impulso

Una dependencia es una biblioteca o componente externo que el proyecto utiliza. Si existen errores después de instalar, quitar o actualizar una dependencia, registra qué cambió antes de probar nuevas versiones.

Actualizar todo puede parecer una forma rápida de resolver problemas, pero también puede introducir cambios incompatibles. En una etapa de recuperación, la prioridad es reducir la cantidad de variables, no modificar muchas piezas a la vez.

Aísla el fallo antes de pedir una solución

Un mensaje como “la aplicación no funciona” es demasiado amplio para una persona y también para una IA. El siguiente paso consiste en convertir el problema en un caso reproducible.

Documenta una reproducción mínima

Escribe la secuencia exacta que provoca el error:

• Qué pantalla o función abriste.
• Qué datos introdujiste.
• Qué acción realizaste.
• Qué esperabas que ocurriera.
• Qué ocurrió realmente.
• Si el problema sucede siempre o solo en ciertas condiciones.

Por ejemplo, “al guardar una tarea vacía aparece un error” es menos útil que “desde la pantalla de nuevas tareas, al dejar vacío el título y pulsar Guardar, la interfaz muestra un error genérico; esperaba un mensaje indicando que el título es obligatorio”.

Separa los tipos de problema

No todos los errores se solucionan de la misma forma. Intenta clasificar el fallo como uno de estos casos:

• Interfaz: el botón no aparece, el formulario no muestra el mensaje correcto o una pantalla no se actualiza.
• Regla de negocio: se permite una acción que debería estar bloqueada o se rechaza una acción válida.
• Comunicación: la interfaz y el backend intercambian datos con nombres o formatos diferentes.
• Persistencia: la información parece guardarse, pero desaparece o se recupera de forma incorrecta.
• Configuración: el proyecto no puede conectarse a un servicio o funciona de manera diferente entre entornos.

Esta clasificación evita pedir una solución genérica para un problema que puede encontrarse en otra capa del sistema.

Estabiliza una versión antes de continuar

Una versión estable no tiene que ser perfecta ni estar lista para miles de usuarios. Es una versión en la que los flujos esenciales funcionan de forma repetible y los problemas conocidos están identificados.

Congela temporalmente el alcance

Define qué funciones son necesarias para que el MVP cumpla su objetivo y cuáles pueden esperar. Mientras recuperas el proyecto, evita agregar características que no sean imprescindibles para solucionar el problema actual.

Esta decisión puede sentirse como un retroceso, pero reduce la superficie de cambio. Si al mismo tiempo intentas agregar pagos, rediseñar la navegación y corregir el registro de usuarios, será difícil saber qué modificación provocó un nuevo fallo.

Guarda un punto de recuperación

Antes de realizar cambios importantes, conserva una copia o un punto versionado del estado actual. El mecanismo concreto dependerá de las herramientas utilizadas, pero el objetivo es el mismo: poder comparar, deshacer o recuperar el proyecto si una modificación empeora la situación.

También conviene registrar brevemente:

• Qué funciona actualmente.
• Qué errores conocidos existen.
• Qué archivos o áreas se modificarán.
• Cómo se comprobará el resultado.

Prueba los flujos críticos después de cada cambio

Después de una modificación pequeña, repite los criterios de aceptación principales. No esperes hasta terminar una gran reorganización para comprobar si el proyecto sigue funcionando.

Si algo se rompe, tendrás un rango de cambios pequeño para revisar. En cambio, si aplicas diez instrucciones diferentes y pruebas al final, tendrás que investigar muchas posibles causas.

Cómo trabajar con la IA sin perder el control

La calidad de la respuesta depende en gran parte del contexto que proporcionas. Una solicitud útil no necesita ser extensa, pero sí debe delimitar el problema y las restricciones.

Entrega contexto específico

Una instrucción de recuperación puede incluir:

• El objetivo del flujo.
• El comportamiento esperado.
• El comportamiento actual.
• Los archivos o componentes relacionados.
• Las restricciones: qué no debe cambiarse.
• El criterio que utilizarás para validar la solución.

Por ejemplo, en lugar de pedir “arregla el formulario”, puedes indicar que el formulario debe impedir el envío cuando falta un campo, que el backend también debe validar la regla y que no se debe modificar el flujo de autenticación.

Pide primero un diagnóstico

Cuando el problema es confuso, solicita que se identifiquen las posibles causas y los archivos involucrados antes de generar cambios. Esto te permite revisar si la propuesta coincide con lo que observas y evita aplicar una solución basada en una suposición incorrecta.

Solicita cambios acotados

Una instrucción como “reescribe toda la lógica para hacerla más limpia” deja demasiado espacio para cambios inesperados. Es preferible trabajar con objetivos concretos:

• Corregir la validación del campo de correo.
• Eliminar una implementación duplicada después de confirmar cuál se utiliza.
• Adaptar el nombre de un dato entre la interfaz y la API.
• Agregar una comprobación para un caso específico.

Después de cada cambio, revisa el resultado y actualiza tu descripción del estado del proyecto. La IA puede ayudarte a escribir y analizar, pero la decisión de aceptar el cambio debe seguir siendo tuya.

Errores frecuentes durante la recuperación

Seguir agregando funciones para “compensar” el desorden

Una nueva pantalla no corrige una regla contradictoria ni una dependencia mal configurada. Si el comportamiento básico no es confiable, cada función adicional aumenta la dificultad de diagnóstico.

Conservar todas las versiones por miedo a borrar

Guardar archivos antiguos puede parecer prudente, pero tener varias implementaciones activas o ambiguas aumenta la confusión. Después de crear un punto de recuperación, elimina o aparta las versiones que ya no participan en el flujo, siempre que tengas claro qué se está utilizando.

Cambiar muchas capas al mismo tiempo

Modificar la interfaz, el backend y la base de datos en una única instrucción puede ser necesario en algunos casos, pero dificulta descubrir dónde se originó el problema. Para un MVP en recuperación, suele ser más manejable avanzar por etapas y comprobar cada límite entre componentes.

Confiar solo en que la pantalla “se ve bien”

Una interfaz correcta no garantiza que los datos se guarden, que los permisos se respeten o que la API maneje errores. Prueba también casos vacíos, datos inválidos, usuarios distintos y situaciones en las que una dependencia externa no responde.

Un método sencillo para retomar el desarrollo

Cuando la versión estable esté funcionando, puedes volver a avanzar con un ciclo más controlado:

1. Define una sola función o cambio.
2. Describe el comportamiento esperado y sus criterios de aceptación.
3. Identifica las áreas del proyecto que deberían modificarse.
4. Pide a la IA un diagnóstico o un cambio acotado.
5. Revisa la propuesta antes de aplicarla.
6. Prueba el flujo principal y algunos casos de error.
7. Guarda el cambio cuando el resultado sea aceptable.

Este proceso puede parecer más lento que pedir muchas funciones en una sola conversación, pero proporciona algo esencial: capacidad de saber qué cambió y por qué. Esa trazabilidad es especialmente importante cuando no tienes experiencia revisando código línea por línea.

Si el proyecto continúa creciendo, también puede ser útil mantener un documento breve con las decisiones actuales: qué representa cada entidad, qué reglas son obligatorias, qué servicios participan y qué restricciones no deben romperse. No necesita convertirse en una documentación extensa; debe servir como contexto confiable para futuras sesiones con la IA.

Conclusión: recupera el control antes de seguir construyendo

Cuando un proyecto creado con IA acumula cambios incompatibles, archivos duplicados y errores que reaparecen, el problema principal no suele resolverse con otra instrucción genérica. La recuperación comienza por definir el comportamiento esperado, entender la estructura existente, aislar el fallo, estabilizar una versión y aplicar cambios pequeños con criterios de aceptación claros.

El aprendizaje central es que el Vibe Coding no consiste únicamente en pedir código. También implica administrar el contexto, decidir qué cambio aceptar y comprobar que el producto sigue cumpliendo su propósito.

Si tu proyecto con IA se volvió difícil de cambiar sin romper algo, vuelve a estabilizarlo antes de seguir agregando funciones. Ese proceso puede ser un buen momento para fortalecer tus prácticas con formación y acompañamiento especializado en Vibe Coding.