La app funciona, pero parece un castillo de naipes. Sabes que si sacas una carta, algo al otro lado de la sala se cae, así que has dejado de sacar cartas. Cada cambio lo haces conteniendo la respiración. El consejo de todos es el mismo: reescríbela bien, hazla como se debe esta vez.
No hace falta, y casi siempre no deberías. Una reescritura apaga la única cosa que tienes que funciona para perseguir estructura que puedes añadir sin apagar nada. La alternativa es más silenciosa y muchísimo más eficaz: poner cimientos bajo la casa mientras está en pie, pieza de carga a pieza de carga, de modo que con cada pieza el conjunto se vuelve más firme en vez de más frágil.
Por qué la app parece de naipes
La fragilidad no es aleatoria y no es porque el código sea “malo”. Le faltan tres cosas concretas, y cada pieza que falta es una fuente del pavor:
- Sin contrato escrito. Nadie escribió qué se supone que hace la app, así que nada puede decirte cuándo un cambio lo violó. “Correcto” vive solo en tu memoria de haber clicado por ahí.
- Sin red de seguridad. Nada atrapa una rotura automáticamente. Te enteras de que las cosas están rotas como se enteran tus usuarios, usando la app.
- Sin límites. Las features se meten directamente en las tripas unas de otras, así que un cambio en un sitio aflora en otro no relacionado. Por eso sacar una carta tira otra.
No puedes arreglar las tres a la vez, y el orden en que las arreglas es todo el juego. Hazlo mal y dejas la casa más temblorosa mientras intentas apuntalarla.
Por qué reescribir es el error caro
Reescribir tienta porque un archivo en blanco parece más seguro que una maraña que no entiendes. Es una trampa por tres razones.
Tiras comportamiento que funciona. El código enredado codifica meses de correcciones pequeñas, casos límite que pisaste y arreglaste, cosas que funcionan por razones que has olvidado. Una reescritura descarta todo eso y redescubres esos casos límite de incidente en producción en incidente en producción.
Reconstruyes los mismos huecos. Si reescribes igual que construiste, por vibes, obtienes un nuevo castillo de naipes. Si reescribes con cuidado, estás haciendo meses de trabajo para llegar a un sitio al que podrías haber llegado en semanas reforzando lo que tienes.
Y la app está apagada todo ese tiempo, o mantienes dos versiones a la vez, que es peor. Mientras tanto, el enfoque de refuerzo no deja la app fuera de servicio ni un segundo.
El orden que de verdad funciona
El refuerzo solo es seguro en una secuencia. Cada paso es lo que hace seguro el siguiente.
1. Escribe la spec que nunca se escribió
Antes de tocar nada, escribe qué hace ya la app, desde fuera, en presente. No cómo funciona el código, cuál es el comportamiento: este rol puede hacer esto, no puede hacer aquello, este total siempre cuadra con la suma de esas partes. Son especificaciones retroactivas, y son lo más barato y de mayor palanca de esta lista, porque definen qué significa “sigue funcionando”. Sin ellas, cada cambio posterior se juzga a ojo.
Hacer esto sobre una app que ya existe, en vez de antes de construir, tiene su propia técnica, y vale la pena hacerlo a propósito: el método completo está en añadir specs a un repo existente sin parar el mundo.
2. Fija el comportamiento actual con tests de caracterización
Ahora captura lo que la app hace ahora mismo en tests. No tests que afirmen lo ideal, tests que congelen lo actual, para que el siguiente cambio hable en el instante en que mueve algo. Son tests de caracterización, y son tu red de seguridad. El punto todavía no es la corrección, es la detección: quieres que la casa te avise en el momento en que una carta se mueve, antes que tus usuarios.
Prueba primero los caminos que dolerían si se rompieran: la aritmética del dinero, la frontera de permisos, el flujo que todos usan. No buscas cobertura, buscas un cable trampa en los muros de carga.
3. Ahora, y solo ahora, refuerza la estructura
Con un contrato y una red en su sitio, cada cambio está comprobado, así que ahora es seguro hacer el trabajo estructural que temías: poner un límite donde dos features se meten una en otra, extraer la lógica copiada y pegada que multiplica cada bug, añadir el contrato que impide que una feature rompa otra en silencio. Hazlo en piezas pequeñas. Después de cada pieza, los tests confirman que no moviste nada que no pretendías, y la casa está, de forma medible, más firme que antes.
Este es el paso por el que todos quieren empezar, y es el que es letal sin los dos primeros. Reforzar la estructura sin red es exactamente cómo “una refactorización pequeña” se lleva por delante cuatro cosas a la vez.
Por qué el orden no es opcional
Sáltate el paso 1 y tus tests fijan comportamiento que no puedes juzgar, congelando bugs en su sitio como si fueran features. Sáltate el paso 2 y el paso 3 es demolición a ciegas. La secuencia, contrato, luego red, luego estructura, no es una preferencia de estilo. Es la diferencia entre que la casa se vuelva más firme con cada cambio o más cerca de caer.
Por eso también “verde” no es la meta en ningún paso. Un build que pasa no es una feature correcta, es un build que compiló. Tu evidencia de que la casa está más firme es el comportamiento verificado contra la spec, no la ausencia de rojo.
Dónde encaja PaellaDoc
Cada paso de aquí es algo que puedes hacer a mano, y en una app pequeña deberías, al menos una vez, para sentir lo que compra. Deja de escalar en cuanto la app es lo bastante grande como para que sostener la spec, la red y la estructura en la cabeza a la vez sea el cuello de botella de verdad, que es justo cuando la app se volvió digna de reforzar.
PaellaDoc está construido para cargar con eso. Lee la app en marcha y la convierte en un modelo que puedes navegar, mantiene las specs retroactivas pegadas al código que describen, y vuelve a ejecutar la app para producir evidencia de que un comportamiento sigue en pie tras un cambio en vez de fiarse de una barra verde. La casa no deja de ser tuya. Deja de ser un castillo de naipes, porque ahora algo distinto de tu memoria sostiene la estructura. Esto es una instancia del cruce mayor que despliego en de vibe coding a producción.
Construiste algo que la gente usa. Te lo puedes quedar, y puedes dejar de contener la respiración cada vez que lo cambias.
Preguntas frecuentes
¿De verdad puedo arreglar una app vibe-coded sin reescribirla? Sí, y normalmente deberías. Una reescritura descarta comportamiento que funciona y reconstruye los mismos huecos. Reforzar en su sitio, spec, luego tests, luego estructura, hace la app más firme con cada cambio y nunca la deja fuera de servicio.
¿Qué son los tests de caracterización? Tests que congelan el comportamiento actual de la app en vez de afirmar el ideal. Su trabajo es la detección: te avisan en el instante en que un cambio mueve algo que funcionaba, para que encuentres las roturas antes que tus usuarios.
¿Por qué no puedo empezar a refactorizar las partes enredadas? Porque sin spec y sin tests, refactorizar es demolición a ciegas. Escribe qué hace la app, fíjalo con tests, y solo entonces reestructura, para que cada cambio esté comprobado sobre la marcha.