Me pidieron arreglar una aplicación creada con vibe coding
El problema del vibe coding no es usar IA. Es eliminar los mecanismos que permiten comprender, comprobar y evolucionar el software. Reparar una aplicación así empieza por recuperar un modelo del sistema, no por generar más código.
Me pidieron arreglar una aplicación creada mediante vibe coding. Había empezado como empiezan muchas: una idea, una conversación con una IA y la satisfacción inmediata de ver una interfaz funcionando. Después llegó el momento en que algo dejó de encajar.
La aplicación funcionaba bien salvo en uno de los navegadores. Con la misma aplicación y la misma factura, una extracción automatizada de datos mediante OCR devolvía resultados incorrectos allí, mientras funcionaba correctamente en el resto.
La tentación ante una aplicación así es continuar exactamente como se creó: describir el error, pedir otro cambio y probar de nuevo. A veces funciona. También puede añadir una capa más sobre un sistema que nadie comprende.
Primero hay que recuperar el mapa
Antes de tocar el código necesito responder preguntas elementales: qué componentes existen, dónde se guarda la información, qué servicios externos participan, cómo se configura cada entorno y qué camino sigue una acción importante.
En software mantenible esas respuestas están repartidas entre arquitectura, código, pruebas, documentación y conocimiento del equipo. En una aplicación construida solo por conversación puede que no exista una fuente fiable. El primer trabajo consiste entonces en reconstruirla.
No es una tarea puramente técnica. También hay que aclarar qué comportamiento importa al usuario y qué datos no se pueden perder. Una aplicación no está arreglada porque haya desaparecido el error que vemos; está arreglada cuando entendemos qué debe preservar y podemos comprobarlo.
Del parche al sistema de calidad
Una recuperación responsable suele necesitar varias capas:
- Crear una forma reproducible de ejecutar el proyecto.
- Inventariar dependencias, credenciales, datos y servicios externos.
- Identificar los recorridos críticos del usuario.
- Añadir pruebas alrededor del comportamiento que no debe romperse.
- Corregir primero los riesgos estructurales que impiden seguir aprendiendo.
- Dejar instrucciones para que la siguiente modificación no vuelva a empezar desde cero.
La IA puede ayudar en cada paso: explorar el repositorio, explicar fragmentos, proponer pruebas o localizar inconsistencias. Pero necesitamos cambiar la relación con ella. Ya no pedimos «haz que funcione». Le damos contexto, criterios y mecanismos para demostrar qué ha hecho.
Vibe coding no es una categoría moral
Crear mediante conversación puede ser una forma excelente de explorar una idea, aprender o producir un prototipo. El problema aparece cuando una pieza exploratoria entra en producción sin cambiar de disciplina.
Un prototipo puede asumir datos ficticios, recorridos felices y decisiones reversibles. Un producto debe convivir con errores, permisos, actualizaciones, personas nuevas y consecuencias reales. La transición entre ambos no ocurre porque cambiemos la etiqueta de «demo» por «versión uno».
La deuda invisible
La deuda técnica no es simplemente código feo. Es la diferencia entre lo que el sistema parece hacer y lo que somos capaces de explicar, verificar y cambiar con confianza. La generación rápida puede ocultar esa diferencia durante un tiempo porque cada nuevo fallo obtiene una respuesta inmediata.
Pero llega un punto en el que nadie sabe si el siguiente arreglo solucionará un problema o moverá el daño a otra parte. Recuperar el producto significa volver a hacer visible esa relación.
Tras el análisis descubrimos que el problema era una particularidad de uno de los navegadores. Debido al motor de renderizado, la imagen enviada para la extracción se comprimía y perdía calidad. Es un detalle difícil de detectar sin experiencia directa en desarrollo web. La aplicación era un MVP y, tras corregirlo, pudo utilizarse. Para seguir avanzando y convertirse en una aplicación preparada para soportar grandes cargas, antes necesitaría una refactorización y comprobar que todos los procesos estuvieran listos para condiciones reales: carga elevada, concurrencia y condiciones de carrera, entre otras.
Fuentes y referencias
- Marco seguro de desarrollo de software de NIST.
- Fuente primaria: experiencia de Victor recuperando la aplicación.