Consejo rápido — Esto es todo lo que necesitas saber para empezar
La app se rompió. El login que funcionaba ayer hoy no funciona. Los pagos se cobran dos veces. Cada cambio en el código rompe otra cosa. Decirle a la IA que “lo arregle” solo lo empeora.
No la reescribas. Si la reescribes, en tres meses se romperá en el mismo lugar. Primero bloquea el estado actual.
Tres herramientas estructurales:
- codistill — Diagnostica. Extrae automáticamente endpoints de API, esquemas de DB y flujos de autenticación del código existente.
- huma — Bloquea. Añade pruebas de regresión a todos los endpoints para proteger el comportamiento actual.
- yongol — Migra. Genera un nuevo backend desde SSOT y demuestra comportamiento idéntico usando las pruebas existentes.
Avanza de izquierda a derecha. Diagnostica con codistill, bloquea con huma y migra con yongol cuando estés listo.
Dile al agente: “Ejecuta codist scan para extraer los endpoints, el esquema de DB y los flujos de autenticación de este proyecto.”
Obtienes el estado actual. Puedes ver cuántos de los 25 endpoints están vivos y cuántos están muertos.
Dile al agente: “Ejecuta huma verify para revisar el estado de todos los endpoints, y escribe una prueba Hurl para cada uno que esté activo.”
Este es tu conjunto de pruebas de regresión. Bloquea lo que está funcionando ahora. Mientras estas pruebas pasen, el agente puede modificar el código sin romper el comportamiento existente.
Dile al agente: “Ahora arregla el bug de login. Pero todas las pruebas Hurl deben pasar.”
Arregla el bug sin romper nada más. Estás haciendo reparaciones con el ratchet puesto.
Pruébalo tú mismo
No necesitas una app rota para experimentarlo. Vive el ciclo “construir → romper → rescatar” en menos de tres minutos.
Paso 1 — Construye la app
En Claude Code:
“Crea una API simple de lista de tareas. Cinco endpoints: listar tareas, agregar tarea, actualizar tarea, eliminar tarea, marcar tarea como completada. Levanta el servidor.”
Paso 2 — Diagnostica con codist
“Ejecuta codist scan para extraer la lista de endpoints de este proyecto.”
codist extrae automáticamente la ruta, el método y los parámetros de los 5 endpoints. Este es tu mapa actual.
Paso 3 — Bloquea con huma
“Ejecuta huma verify y escribe una prueba Hurl para cada endpoint.”
Se genera un archivo Hurl para cada uno de los 5 endpoints. El comportamiento actual queda bloqueado.
Paso 4 — Rómpelo a propósito
“Cambia el formato de respuesta del endpoint de actualizar tarea. Renombra el campo title a name.”
Después del cambio:
“Ejecuta las pruebas Hurl.”
Una prueba falla. “Se esperaba title pero llegó name.” El drift fue capturado. El ratchet está funcionando.
Paso 5 — Repara con el ratchet puesto
“Arréglalo para que todas las pruebas Hurl pasen. Pero la nueva funcionalidad que usa el campo name también debe mantenerse.”
El agente mantiene la compatibilidad hacia atrás mientras aplica la corrección. Cuando Hurl pasa, el comportamiento existente queda preservado.
Esta es una versión en miniatura de codistill → huma → reparar. Con una app realmente rota, el proceso escala a 25, 50 o 200 endpoints — el principio es el mismo.
Por qué este es el enfoque correcto
Introducción: La verdadera razón por la que se rompió tu app
En 2025, las bases de datos de 170 apps construidas con Lovable quedaron completamente expuestas en internet — correos electrónicos, claves de API, información de pagos. La causa no fue un bug de código. La IA construyó las apps sin políticas de seguridad, y nadie lo verificó.
En enero de 2026, 1.5 millones de tokens de API se filtraron desde la red social de IA Moltbook. La misma causa. La IA lo construyó, los humanos no lo revisaron.
Esto no es la historia de otro. Si construiste una app con vibe coding, estás sentado sobre la misma estructura.
“Haz un login” — 30 segundos. “Agrega pagos” — 2 minutos. “Añade un panel de administración” — 5 minutos. Tres meses después, la IA “limpia” la lógica de pagos y cambia el cálculo de descuentos, agregar una nueva función rompe la autenticación, y una página que funcionaba ayer devuelve un error 500 hoy.
Tienes dos opciones:
- Reescribir
- Rescatar
Reescribir era una opción hace tres meses. El problema es que reescribir repite el mismo patrón. El drift no es un problema de código — es un problema estructural.
Necesitas aprender a rescatar.
Autorrescate para el náufrago — 5 pasos
Rescatar una app rota es como responder a una emergencia de montaña. No corras. Identifica tu posición, asegura la seguridad y muévete un paso a la vez.
Paso 1. Diagnosticar — Qué sigue vivo
Lo primero que debes hacer no es arreglar el código. Es entender el estado actual.
Dile al agente: "Escanea todos los endpoints de API de este proyecto.
Envía una petición real a cada endpoint y
registra el código de estado de respuesta.
Resume los resultados en una tabla: ruta, método, código de estado, tiempo de respuesta."
Si 18 de 25 endpoints devuelven 200, 4 devuelven 401 y 3 devuelven 500 — ese es tu mapa actual. Empezar reparaciones sin mapa hace que lo que arreglas rompa otras cosas.
El codist scan de codistill automatiza este trabajo. Extrae endpoints, modelos de datos y flujos de autenticación del código existente.
Paso 2. Bloquear — Proteger primero lo que está vivo
Una vez diagnosticado, bloquea los endpoints activos.
Dile al agente: "Escribe una prueba Hurl para cada uno de los 18 endpoints que devuelven 200.
Usa la respuesta actual como valor esperado.
Para los endpoints que requieren autenticación, ejecuta primero la secuencia de login para
obtener un token y úsalo."
Estos 18 archivos Hurl son tu red de seguridad. Sin importar qué cambios vengan después, si estas pruebas pasan, el comportamiento existente queda preservado.
El huma verify de huma sistematiza este proceso. Hace seguimiento del estado por endpoint y califica cada uno como PASS/IMPROVE/FAIL.
Importante: El bloqueo parcial no funciona. Si solo bloqueas 10 de los 18 endpoints, no sabrás si los otros 8 se rompen durante las reparaciones. La cobertura total es la regla.
Paso 3. Reparar — Corregir con el ratchet puesto
Con la red de seguridad en su lugar, ahora puedes arreglar bugs.
Dile al agente: "Encuentra y arregla la causa del fallo de login.
Todas las pruebas Hurl deben pasar.
Si alguna prueba falla, revierte el cambio."
Esta es la aplicación en el mundo real del Ratchet Pattern de la Clase 6. Arregla sin romper. Ejecuta Hurl después de cada reparación. Pasa — al siguiente bug. Falla — revierte.
Arregla los 3 endpoints que devuelven errores 500 de la misma manera. Una vez reparados, añade nuevas pruebas Hurl. El ratchet hace clic un diente más.
Paso 4. Extraer — Sacar la lógica de la caja negra
Este es el paso crítico. La causa raíz de una app rota generalmente está aquí.
Si estás usando Supabase:
- Las políticas RLS solo existen en el panel de control, no en el código
- La lógica de negocio está escondida dentro de Edge Functions
- La lógica de autenticación está atada a Supabase Auth
Si estás usando Firebase:
- Las Security Rules solo existen en la consola
- La lógica está dispersa entre Cloud Functions
La misma estructura sin importar qué BaaS uses. La lógica de negocio vive fuera del codebase.
Dile al agente: "Extrae todas las políticas RLS del panel de control de Supabase.
Guarda las políticas SELECT, INSERT, UPDATE, DELETE de cada tabla
como archivos SQL. Haz commit en git."
Dile al agente: "Analiza la lógica de negocio en las Edge Functions.
Documenta qué funciones implementan qué reglas de negocio."
Esto es sacar la lógica de la caja negra hacia el codebase. Una vez fuera, el agente puede leerla, probarla y bloquearla con el ratchet.
El codist ddl de codistill extrae DDL de bases de datos existentes. codist scan extrae SSOT del código. Son herramientas para moverse de la caja negra a la capa declarativa.
Paso 5. Migrar — Solo cuando estés listo
Después de los pasos 1–4, la app está en este estado:
- Cada endpoint tiene una prueba de regresión Hurl
- Los bugs están arreglados
- La lógica de la caja negra está documentada en el codebase
- El ratchet está puesto, evitando que nuevos cambios rompan el comportamiento existente
Desde este estado, decide sobre la migración. De Supabase a backend propio, de Deno a Go, lo que sea.
La red de seguridad de la migración son las pruebas Hurl escritas en el paso 2. Ejecuta el mismo Hurl contra el nuevo servidor — si todo pasa, se prueba el comportamiento idéntico al legacy.
Dile al agente: "Genera un backend Go+Gin con yongol generate.
Haz que todas las pruebas Hurl existentes pasen."
La migración es el paso 5, no el paso 1. Intentar migrar en el paso 1 fallará. Esta es una lección confirmada en revisiones post-incidente.
Cómo escapar de Supabase
El escenario más frecuente de la Clase 11 es Supabase. Empiezas con vibe coding, te vas all-in en Supabase, y tres meses después se rompe.
La secuencia de salida:
1. Mantén la DB, solo añade el ratchet
Mantén el PostgreSQL de Supabase como está. Cambiar la DB es lo último.
codist ddl → extraer DDL de las tablas existentes
huma verify → evaluar el estado de los endpoints
hurl → bloquear todas las APIs activas en su totalidad
2. Mueve la lógica al código
Políticas RLS → archivos Rego. Edge Functions → anotaciones SSaC. Del panel de control al codebase.
3. Desacopla la autenticación
Supabase Auth es lo último que se elimina. Como no se pueden extraer los hashes de contraseñas de auth.users, si no hay usuarios aún, migra de inmediato; si ya hay usuarios, ejecuta un período de autenticación dual.
4. Levanta el nuevo servidor y valida con Hurl
yongol generate → generar backend Go+Gin
ejecutar todas las pruebas hurl → probar comportamiento idéntico al legacy
Cuando Hurl pase completamente, cambia el tráfico.
Por qué no debes reescribir
“¿No puedo simplemente reescribirlo desde cero?”
No. Tres razones:
1. El mismo patrón se repite
El drift es un problema estructural, no de código. Reescribir sin un ratchet te lleva de vuelta al mismo punto de quiebre en tres meses.
2. El conocimiento está enterrado en el legacy
Tres meses de vibe coding acumularon reglas de negocio en el código. Reescribir significa reconstruir esas reglas desde la memoria. La memoria se equivoca.
3. Es posible que ya tengas usuarios
Hay un momento en que un prototipo se convierte en producción. Si hay aunque sea un usuario, “reescribir” significa migración de datos, transición de autenticación y tiempo de inactividad.
Aprender a rescatar es más valioso que aprender a reescribir. Porque el legacy siempre existe, y el código nuevo se convierte en legacy en seis meses.
Cómo la Clase 11 se relaciona con las Clases 1–10
| Clase | Construir bien desde el principio | Clase 11: Rescatar lo que se rompió |
|---|---|---|
| Clase 3 Hurl | Declarar el contrato de API | Bloquear el comportamiento existente como pruebas de regresión |
| Clase 4 yongol | Generar desde SSOT | Extraer SSOT del código existente |
| Clase 6 Ratchet | Bloquear cuando las pruebas pasan | Arreglar sin romper |
| Clase 8 filefunc | Estructurar el código | Limpiar el código legacy |
| Clase 10 DDL | Declarar el esquema | Extraer DDL de la DB existente |
Las mismas herramientas, dirección opuesta. Las Clases 1–10 iban “de arriba hacia abajo” (declarar → generar). La Clase 11 va “de abajo hacia arriba” (código existente → extraer → declarar).
codistill es la herramienta que automatiza esta extracción “de abajo hacia arriba”. Destila SSOT del código existente.
Del náufrago al rescatador
Después de completar este proceso, tienes dos capacidades:
- Cómo construir desde cero (Clases 1–10) — declarar, verificar, bloquear, persistir
- Cómo rescatar lo que se rompió (Clase 11) — diagnosticar, bloquear, reparar, extraer, migrar
La mayor parte del código en el mundo es legacy. Los proyectos que se construyen desde cero son raros. La capacidad de rescatar se usa con más frecuencia.
El vibe coding no ha terminado. Has aprendido a sostener las riendas.
Artículos relacionados
- Supabase es una trampa del vibe coding — El fondo teórico de la Clase 11. Por qué el BaaS se rompe.
- Hurl detiene el drift en el vibe coding — Detalles del bloqueo en el paso 2.
- codistill — Destilando SSOT del código existente — Herramienta para el diagnóstico del paso 1 y la extracción del paso 4.
- huma — El ratchet que no se pierde ningún endpoint — Herramienta para el bloqueo del paso 2.
- yongol — La quilla del SaaS de codificación con IA — Herramienta para la migración del paso 5. Generación full-stack desde SSOT.
- Un codebase operable por agentes — El principio detrás de convertir una caja negra en una fábrica.
- tsma — La defensa de regresión para código legacy — Cómo hacer reparaciones con el ratchet puesto.
- Construyendo sistemas operables por agentes — Cómo hacer que el legacy bloqueado sea alcanzable por agentes.
Reins Engineering — Todas las clases
| Clase | Título |
|---|---|
| Clase 1 | Cómo delegar a la IA |
| Clase 2 | Cómo desconfiar de la IA |
| Clase 3 | Apps que no se rompen |
| Clase 4 | Decisiones fuera del código |
| Clase 5 | IA con riendas |
| Clase 6 | Bloquear cuando las pruebas pasan |
| Clase 7 | Invertir la adulación |
| Clase 8 | La fábrica del agente |
| Clase 9 | Automatización más allá del código |
| Clase 10 | La ley de los datos |
| Clase 11 | Cómo rescatar una app de vibe coding que se rompió |
Fuentes
- Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — La obra original sobre characterization testing. La técnica de envolver el código legacy en pruebas para bloquear el comportamiento actual. Base teórica del paso 2 de la Clase 11.
- CVE-2025-48757 (2025). Más de 170 apps generadas por Lovable con RLS faltante exponiendo sus DBs de Supabase. ameeba.com
- OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” Exposición de 1.5M tokens de API. blog.ogwilliam.com
- Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Aumento permanente del 41.6% en la complejidad del código tras adoptar Cursor. Evidencia cuantitativa de por qué el vibe coding se rompe.
- Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — Análisis de 6,299 repositorios y 302,600 commits de IA. La deuda técnica sin resolver se disparó de cientos a principios de 2025 a más de 110,000 en febrero de 2026.
- Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — Teoriza la causa raíz del drift como “deuda cognitiva” (erosión del entendimiento compartido) y “deuda de intención” (justificación no externalizada).
- Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — El primer artículo académico que documenta el intercambio flow-debt en el vibe coding.
- Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — El 45% del código generado por IA contiene vulnerabilidades del OWASP Top 10. La tasa de exposición de secretos en commits de IA es 2 veces mayor.
- GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — Análisis de 211M líneas. La duplicación de código aumentó 4 veces, el ratio de refactorización bajó del 25% al 10%.
- Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — Salir de un BaaS no es portarlo — es reescribir el backend.