Contenido6 secciones
Vibe Coding Cleanup: qué se rompe después de la demo
Una app hecha en Lovable o Claude Code funciona el día de la demo. Lo que falla después es todo lo que rodea al código, y una limpieza es la unidad equivocada.
La demo funcionó
Alguien construyó un CRM en Lovable en dos fines de semana. Otra persona enlazó catorce workflows de n8n a lo largo de un año, uno por semana. Un director de ventas abrió Claude Code un domingo por la noche y el lunes había una app que todo el equipo usa para reservar entregas. Cada una funcionó el día que se enseñó, y cada una es ahora algo de lo que depende el negocio.
El código que escriben las herramientas es en su mayoría correcto, y donde no lo es, lo es como lo es el código de un desarrollador junior: hace lo que le pidieron y no sabe qué pasa alrededor. Los fallos que llegan seis semanas después casi nunca están en la función que se demostró. Están en lo que nadie pidió escribir.
Qué se rompe de verdad
Seis cosas, en el orden en que una lectura las encuentra.
Los secretos están en el código. La clave de servicio de Supabase está en el bundle del cliente porque ahí la puso el prompt. La clave de OpenAI está en un archivo que entró en el repositorio el primer día y no se ha tocado desde entonces. Cualquiera que abra las herramientas de desarrollador del navegador tiene la base de datos; cualquiera que lea el repositorio tiene la factura.
El despliegue solo se reproduce en un portátil. Funciona donde se construyó, con las variables de entorno que se definieron ahí una vez y nunca se anotaron. La primera vez que otra persona tiene que desplegarlo, normalmente la semana en que el autor está de vacaciones, no hay manera.
La base de datos no tiene camino de vuelta. Las copias o no existen o nunca se han restaurado, y no hay migraciones, así que el esquema es lo que dejó la última edición en el panel. La primera restauración ocurre el día que importa, que es el peor día para descubrir que no funciona.
Nadie está mirando. Los logs o no existen o van a una consola que nadie abre, y la autenticación que falla, la cola que se acumula o el webhook que devuelve un formato nuevo no alertan a nadie. El sistema falla como una integración cambia por debajo: en silencio, con datos erróneos, durante semanas.
El suelo se mueve. Cada clave de API, cada formato de webhook y cada versión de modelo de la que depende el sistema cambiará sin avisar. El modelo para el que se ajustó recibe fecha de retirada, un proveedor añade una capa al formato de la respuesta, y la herramienta que usaba el autor la compra alguien junto con su plan gratuito. Cada una de estas cosas es un cambio que algún proveedor publicó sin avisarte, porque nunca estuviste en su lista, y ninguna aparecerá nunca como una caída.
El runbook es una persona. La única documentación es la memoria de quien lo construyó, y lo construyó un fin de semana, lo que significa que tampoco se acuerda. Pregúntale cómo se despliega y la respuesta honesta es que probaría cosas hasta que funcionara.
Por qué "cleanup" es la unidad equivocada
El mercado ya ha puesto nombre a este trabajo. Busca vibe coding cleanup y la primera página son empresas de outsourcing que ofrecen exactamente eso, una refactorización del repositorio que les mandes, con presupuesto adjunto. Un hilo de Hacker News lo llamó cleanup as a service. Las empresas aciertan el trabajo y fallan la compra.
Una limpieza es un proyecto. Tiene un inicio, un alcance y una factura, y después termina, y el sistema vuelve a ser tuyo. El viernes siguiente por la noche se rompe, quien lo limpió está en otro contrato, y estás exactamente donde estabas, con un repositorio más ordenado. El negocio necesitaba a alguien cuyo trabajo fuera el sistema, y un repositorio más ordenado no es eso.
Eso cambia la compra de "cuánto cuesta arreglar esto" a "qué haría falta para que alguien fuera responsable de esto", que es una pregunta sobre la infraestructura de alrededor y no sobre el código. Es la misma pregunta que una empresa respondía con un administrador de sistemas, cuando las cosas de las que dependía eran servidores y un paquete de contabilidad. Las cosas de las que depende ahora son un CRM en Lovable, una docena de workflows y un agente, y la pregunta no ha cambiado.
La lectura va antes que la reparación
Un vendedor de limpiezas empuja a empezar a arreglar. El orden que funciona es leer primero, y leer con una lista fija.
- ¿Dónde están los secretos?
- ¿El despliegue se reproduce en algún sitio que no sea el portátil?
- ¿Hay copia, y alguien ha restaurado desde ella?
- ¿Algo genera logs, y alguien recibe alertas?
- ¿De qué APIs y versiones de modelo depende, y cuándo cambian?
- ¿Hay un camino de vuelta que no pase por quien lo construyó?
Esa lectura lleva alrededor de una semana para un parque típico, y termina en una de tres frases. El sistema se puede operar tal cual, y alguien lo asume. El sistema se puede operar tras una reparación definida, con el alcance escrito y presupuestado, y nada fuera de ese alcance. O las reparaciones reconstruirían la arquitectura en lugar de completar lo que falta a su alrededor, sustituir es más barato que reparar, y el informe lo dice antes de que alguien haya gastado un mes en averiguarlo.
La tercera respuesta es la que una limpieza nunca da, porque a una limpieza se le paga por limpiar. Un agente que decide solo sobre reembolsos, sin un límite claro a partir del cual decide una persona, necesita un diseño distinto, no un repositorio más ordenado, por las razones por las que falló el último chatbot, y saberlo en la primera semana es lo más barato de esta página.
Cuánto cuesta convertirlo en el trabajo de alguien
Son tres cosas, en secuencia, y solo la primera es segura.
La primera es una semana de lectura, con precio desde un mínimo porque una sola app en Vercel lleva un día y un CRM con ocho workflows y dos bases de datos lleva la semana entera. La segunda es la reparación, y solo donde la lectura pidió una: despliegue, migraciones, copias, secretos, logs, los agujeros evidentes, lo que tiene que aguantar antes de que alguien esté de guardia. Ese sprint no añade funciones, porque una reparación a la que se le van añadiendo funciones deja de ser una reparación. La tercera es un mes que sigue siendo un mes: monitorización, verificación de copias, una ventana de respuesta, actualizaciones cuando el suelo se mueve y un informe que se puede leer. La funcionalidad nueva se define y se presupuesta aparte, para que el mes siga siendo predecible.
La comparación que merece la pena es con el coste de ese viernes por la noche, multiplicado por cuántos viernes tiene un negocio antes de que quien lo construyó se vaya, y no con el presupuesto de la limpieza; la misma aritmética ya está incluida en la línea de mantenimiento de cualquier presupuesto de automatización. En la comparación de proveedores de este sitio esa fila está en la columna "enteramente tuyo, incluido el mantenimiento que nadie programó", escrita sobre Zapier y Make antes de que nadie hubiera hecho un CRM con vibe coding. Sigue siendo verdad.
El parque va a crecer
Hace un año la expresión no registraba volumen de búsqueda. En septiembre de 2026 son ciento diez mil búsquedas al mes en Estados Unidos y treinta y tres mil en Brasil, y una empresa que tenía tres sistemas de TI va camino de tener un CRM, ocho herramientas internas, catorce workflows, tres agentes, dos bases de datos y un proyecto en Vercel que el director de ventas escribió un domingo por la noche. No hay forma de discutirlo: es software más barato, construido por la gente que conoce el proceso, y va a seguir llegando.
Lo que necesita es una forma de que lo que construyen se convierta en el trabajo de alguien, y para eso sirve asumir un sistema: la lectura, la reparación donde se pide una, y después el mes en el que alguien entiende cómo está construido, ve cuándo se rompe y sabe levantarlo de nuevo.
01¿Puede una app hecha con vibe coding funcionar en producción?+
A menudo, sí. El código que escribe una herramienta de IA rara vez es lo que falla; lo que falta es todo lo de alrededor. Los hallazgos habituales son secretos en el repositorio, una base de datos sin copia de seguridad, un esquema sin migraciones, fallos que no llegan a nadie y un despliegue que solo recuerda el autor, y cada uno es una reparación con un alcance conocido, no un motivo para tirar la app. Si una app en concreto puede, lo decide una semana de lectura, y la lectura también puede concluir que sustituirla es más barato que repararla.
02¿Qué diferencia hay entre un vibe coding cleanup y el mantenimiento gestionado?+
Una limpieza es un proyecto. Alguien refactoriza el código, arregla lo que encontró, lo devuelve, y el siguiente incidente vuelve a ser tuyo, un viernes por la noche, con quien hizo la limpieza en otro contrato. El mantenimiento gestionado es responsabilidad: la limpieza ocurre donde una lectura dice que hace falta, y después alguien se queda con el sistema, vigilándolo, actualizando las dependencias y el modelo, verificando las copias y restaurándolo cuando se rompe, todo el tiempo que quieras.
03¿Qué debe comprobar primero la aceptación de un sistema hecho en casa?+
En este orden: dónde están los secretos, si el despliegue se reproduce en algún sitio que no sea un portátil, si la base de datos tiene rutina de copias y una restauración ensayada, si algo genera logs y alguien recibe alertas, de qué APIs y versiones de modelo depende el sistema y cuándo cambian, y si existe algún camino de vuelta documentado que no pase por quien lo construyó. El orden importa porque los tres primeros deciden si el sistema se puede entregar a alguien.
04¿Cómo saber cuándo es más barato sustituir que reparar?+
Cuando las reparaciones reconstruirían la arquitectura en lugar de rodearla. Una app cuyos únicos problemas son secretos, copias y despliegue es un sprint de estabilización. Un agente que decide solo sobre reembolsos y reclamaciones sin una línea clara hasta una persona, o un workflow cuyo modelo de datos no aguanta lo que el negocio ahora le hace pasar, es una reconstrucción, y una lectura que lo dice pronto es más barata que una reparación que lo descubre en la tercera semana.
