El mensaje suele empezar de la misma manera: « He creado una app con Lovable, funciona casi. » Ese « casi » esconde todo lo demás. Una página que se bloquea cuando dos personas la usan al mismo tiempo. Un pago que solo funciona una vez cada tres intentos. Una pantalla que la IA corrige diez veces, y que rompe algo más en otro lugar en cada corrección.
No estoy en contra de estas herramientas, al contrario. Lovable, Bolt o Cursor permiten que un gestor vea tomar forma su idea en un fin de semana, sin esperar una cotización. Es una verdadera revolución para probar un proyecto. El problema llega después, el día en que clientes, empleados o dinero pasan por la aplicación.
Así es como procedo para retomar una aplicación hecha con vibe coding, y cómo saber si la suya puede ser salvada.
¿Qué es exactamente el vibe coding?
Se habla de vibe coding cuando se construye una aplicación describiendo a una IA lo que se quiere, sin escribir el código uno mismo. Se pide « añade una página de reserva », la herramienta la genera, se prueba, se vuelve a pedir. Las herramientas más conocidas suelen producir una aplicación en React, con una base de datos Supabase detrás.
El resultado parece terminado. La pantalla está limpia, los botones responden. Pero nadie ha revisado realmente lo que hay debajo, y ahí es donde se esconden las sorpresas.
Señales de que una aplicación generada por IA llega al límite
Después de unas semanas, los mismos síntomas reaparecen:
- cada corrección rompe otra. La IA solo ve un fragmento del código a la vez, así que repara una pantalla y desajusta otra;
- el mismo código existe en cuatro versiones, un poco diferentes, y nadie sabe cuál se está usando;
- funciona para usted, pero no para diez usuarios. Las páginas se ralentizan, los datos se mezclan cuando varias personas trabajan al mismo tiempo;
- ya no se atreve a modificar nada antes de una reunión con un cliente, por miedo a que todo se desmorone;
- la factura de la herramienta sube a medida que vuelves a solicitar correcciones.
Si te identificas con dos o tres de estos puntos, no es un fracaso. Es el momento en que un prototipo debe convertirse en una verdadera aplicación.
Lo primero que reviso: la seguridad y los datos
Antes de tocar nada, evalúo lo que puede salir caro.
¿Quién puede leer qué? En Supabase, las reglas que impiden a un usuario ver los datos de otro no se configuran solas. A veces, una aplicación generada deja la base abierta a cualquiera que conozca la dirección. Es lo primero que verifico, porque datos de clientes expuestos no es un error, es un problema legal.
Las claves expuestas. Una clave de pago o de envío de correos escrita en claro dentro del código del navegador puede ser recuperada por cualquiera.
Las copias de seguridad. Reviso si existe una copia de seguridad de la base de datos y si se sabe restaurar. A menudo, la respuesta es no.
El pago. Un pago exitoso es fácil. Un reembolso, un anticipo o un pago abandonado a medio camino es donde las aplicaciones generadas fallan más. En Izidoor, la plataforma de reservas en la que trabajé durante dos años y medio, desarrollé el pago en línea con anticipos y reembolsos: estos son los casos que requieren más atención.
¿Reanudar, reescribir o empezar de cero?
Es la verdadera pregunta, y la respuesta no siempre es la que uno espera.
Reanudar y consolidar cuando la estructura aguanta: se asegura, se eliminan redundancias, se añaden pruebas en las partes sensibles, y se continúa desde tu código. Es el caso más frecuente cuando la aplicación es reciente y no demasiado grande.
Reescribir una parte cuando un fragmento específico es el problema, por ejemplo, todo el módulo de reserva o de pago. Se conserva el resto.
Reiniciar desde cero cuando cada pantalla ha sido montada por separado y los datos están desorganizados. Duele escucharlo, pero a veces es menos costoso que parchear durante meses. Tu versión generada conserva entonces todo su valor: es un documento de especificaciones vivo. Sabemos exactamente lo que quieres, pantalla por pantalla, y eso acorta mucho el proyecto.
Hago mi trabajo con Nuxt, Vue, TypeScript y Python, y también he trabajado con React en Kodeva y en Izidoor. Una aplicación React generada por Lovable o Bolt no me asusta, y no es necesario cambiar de tecnología para retomarla.
Un ejemplo concreto
Imaginemos a Claire, que gestiona tres salas de deporte. En un mes, con Lovable, construyó una aplicación para que sus socios reservaran sus clases. Al principio, todo funcionaba perfectamente. Luego llegó el inicio del curso escolar: doscientos socios a la vez el lunes por la mañana, clases reservadas dos veces, una sala que mostraba plazas libres cuando estaba llena.
Empezaríamos con una media jornada de auditoría: lectura del código, de la base de datos y de las reglas de acceso, lista de riesgos clasificados del más urgente al menos urgente. Luego corregiríamos primero lo relacionado con las reservas duplicadas y los datos de los socios, antes de añadir cualquier funcionalidad. La aplicación de Claire sigue en línea durante este tiempo: trabajamos en una copia y cambiamos cuando esté listo.
¿Cuánto cuesta retomar una aplicación?
Todo depende de lo que revele la auditoría, y por eso siempre empiezo por ella. Consolidar una pequeña aplicación puede requerir solo unos días de trabajo. Reiniciar desde cero se asemeja más a un proyecto clásico: la mayoría de las herramientas para PYMES que realizo oscilan entre 5.000 y 15.000 € en precio fijo, más 100 a 300 € al mes de mantenimiento. Todo está detallado en mi página aplicación empresarial a medida.
Y si tu necesidad es estándar, también te lo diré: a veces, un software existente hace mejor el trabajo que una aplicación personalizada, generada o no. Explico cómo decidir en este comparativo entre software del mercado y a medida.
Preguntas frecuentes
¿Tengo que dejar de usar Lovable o Bolt?
No necesariamente. Para probar una idea o maquetar una nueva pantalla, es muy bueno. Lo que cambia es que, una vez que la aplicación esté en producción, cada modificación pasa por alguien que revisa el código.
¿El código me pertenece?
Sí, y es un buen hábito recuperarlo ahora mismo en un repositorio GitHub a tu nombre. También es lo que permite que un desarrollador lo retome.
¿Cuánto tiempo toma la auditoría?
Normalmente media jornada a una jornada para una pequeña aplicación. Recibirás una lista escrita de los riesgos y las correcciones previstas, en orden.
¿Se puede mantener la aplicación en línea durante la reactivación?
Sí. Trabajamos en una copia, y sus usuarios solo ven la nueva versión cuando esté lista.
¿Revisamos la suya?
Si tiene una aplicación creada con IA que empieza a preocuparle, envíeme la dirección y unas palabras sobre qué falla. Hablamos por teléfono o videollamada, reviso el código y se va con un plan de acción escrito: lo que hay que corregir de inmediato, lo que puede esperar, y un presupuesto estimado. Si su aplicación funciona bien y solo necesita algunos ajustes, también se lo diré.
