Hay un patrón que aparece tan a menudo que casi es un calendario. Alguien hace vibe coding de una app, funciona, la publica, y durante semanas parece magia. Las features nuevas caen en minutos. Y entonces, hacia el tercer mes, la misma app que parecía sin esfuerzo se convierte en un sitio donde cada cambio rompe algo y nadie, incluida la persona que la construyó, sabe decir por qué.
Este es el ajuste de cuentas del día 90. No es mala suerte y no es tu culpa como constructor. Es la factura de la estructura que se saltó para ir rápido, y llega con un reloj predecible. Saber por qué cae en el mes 3 en concreto es lo que te deja salirle al paso antes de que él te salga a ti.
Qué aspecto tiene el ajuste de cuentas
Lo reconocerás por los síntomas antes de entender la causa:
- Un cambio que debería llevar cinco minutos lleva un día, y ni así estás seguro de que sea seguro.
- Arreglas una cosa y se rompen otras dos, a menudo en partes que no tocaste.
- Empiezas teniendo miedo a desplegar un viernes, y luego miedo a desplegar y punto.
- Abres un archivo que escribiste tú mismo hace dos meses y no puedes seguirlo.
- Las features nuevas se ralentizan hasta arrastrarse, justo lo contrario de cómo empezó.
La señal es la inversión. El vibe coding empieza rápido y, pasado el ajuste de cuentas, se vuelve más lento que hacer la cosa con cuidado desde el principio. La curva no se aplana. Se dobla hacia abajo.
Por qué el mes 3, y no el mes 1
El momento no es místico. Tres fuerzas se cruzan más o menos en el mismo punto.
Tu memoria del código se degrada con calendario. Cuando haces vibe coding, la comprensión de cómo funciona vive en tu cabeza, no en el código, porque nunca leíste la mayor parte. La memoria humana de ese tipo de contexto no escrito se desvanece en semanas. En la segunda semana aún recuerdas por qué el agente hizo las cosas. Para el tercer mes esa memoria se ha ido, y no hay nada escrito que la sustituya. Ahora mantienes el código de un desconocido, y el desconocido eras tú.
La complejidad compone, no suma. Cada feature se generó asumiendo que el resto de la app se queda quieta. Las interacciones entre N features crecen mucho más rápido que N. Para el primer puñado los choques son raros. Pasado un umbral, cada añadido toca algo que no estaba diseñado para conocer, y las features nuevas rompen las viejas de forma rutinaria. Ese umbral suele caer hacia el tercer mes de añadidos constantes.
El prototipo se convirtió en el producto sin avisar. En las primeras semanas nadie depende de él, así que una rotura no cuesta nada. Para el tercer mes hay gente real que confía en él, y la misma rotura que antes era invisible ahora es una caída, un número mal, un registro perdido. Nada del código cambió. Lo que cambió fue lo que hay en juego, y la red que falta pasa a soportar peso.
Junta todo: tu memoria se ha ido, las interacciones han compuesto más allá de lo que puedes sostener, y el coste de cada error ha dado un salto. Esa intersección es el ajuste de cuentas.
La versión pública de la misma lección
La versión suave es una app lenta y un fundador nervioso. La versión severa sale en las noticias. Hubo un incidente muy comentado en 2025 en el que un agente de código, operando sobre un proyecto en vivo, borró la base de datos de producción de una empresa durante lo que se suponía era una congelación. No voy a adornar los detalles más allá de lo que fue público, porque el punto no necesita adorno: cuando un agente opera sobre un sistema que nadie ha mapeado del todo, sin límites obligados y sin red, el modo de fallo no es un bug pequeño. Es todo, de golpe.
La mayoría de los ajustes de cuentas son más silenciosos que ese. Pero tienen la misma forma, a menor escala: un agente, o tú, cambiando un sistema que ya no tiene una estructura conocible, y descubriendo por las malas qué estaba conectado con qué.
El ajuste de cuentas es una deuda, y la deuda tiene condiciones
La forma útil de pensar esto no es “la app es mala”. Es que pediste un préstamo. El vibe coding te presta velocidad por adelantado, y el préstamo es real y a menudo vale la pena pedirlo. Pero tiene condiciones, y el ajuste de cuentas es el vencimiento. Qué debes exactamente, y cuándo vencen las distintas partes, vale la pena calcularlo a propósito en vez de descubrirlo por sorpresa; ese es todo el tema de la deuda técnica del vibe coding.
La trampa es tratar el préstamo como gratis porque los primeros pagos son invisibles. El interés se acumula desde el día uno. Solo que no lo sientes hasta que la memoria se desvanece y las interacciones componen, que es, otra vez, hacia el tercer mes.
Cómo salirle al paso pronto
No evitas el ajuste de cuentas haciendo menos vibe coding. Lo evitas amortizando la deuda antes de que venza, mientras aún recuerdas cómo funciona el código.
La jugada es dejar de tratar “funciona” como la meta en cuanto alguien empieza a depender de la app. Antes de que se desvanezca la memoria, haz las tres cosas baratas que convierten la deuda en estructura: escribe qué se supone que hace la app de verdad, captura el comportamiento actual en una red para que los cambios anuncien su daño, y haz el código legible para tu yo futuro. Ese es el cruce, y la ruta completa por etapas está en de vibe coding a producción. Cuanto antes lo empieces, menos cuesta, porque pagas con memoria que aún tienes en vez de con arqueología que te toca rehacer.
Dónde encaja PaellaDoc
La razón por la que cae el ajuste de cuentas es que el conocimiento de cómo funciona la app no tiene casa fuera de tu cabeza, y tu cabeza se vacía con calendario. El trabajo de PaellaDoc es darle a ese conocimiento una casa: lee el repo y lo convierte en un modelo que puedes navegar, mantiene las specs y las decisiones pegadas al código, y vuelve a ejecutar la app para probar que los comportamientos siguen en pie. No hace desaparecer la deuda. Hace que la deuda deje de ser invisible, para que el tercer mes sea un pago programado en vez de una emboscada.
Puedes salirle al paso al ajuste de cuentas pronto y barato, o tarde y caro. La fecha está más o menos fijada. Lo que pagas, no.
Preguntas frecuentes
¿Por qué las apps vibe-coded se rompen hacia el mes 3 en concreto? Tres cosas se cruzan en ese punto: tu memoria de cómo funciona el código se ha desvanecido, las interacciones entre features han compuesto más allá de lo que te cabe en la cabeza, y ahora hay gente real que depende de la app, así que los fallos por fin cuestan algo.
¿Se puede evitar el ajuste de cuentas? La fecha está más o menos fijada, pero el coste no. Amortizar la deuda pronto, mientras aún recuerdas el código, convierte una crisis en una tarea programada. Hacer menos vibe coding no es el arreglo; añadir estructura antes del vencimiento sí.
¿Qué hago en cuanto noto los síntomas? Deja de añadir features y empieza el cruce: escribe qué debería hacer la app, pon una red alrededor del comportamiento actual y vuelve a hacer el código legible. Añadir más sobre una base sin mapear solo sube el interés.