Describiste una app en lenguaje normal y un agente la construyó. Funcionaba. Se la enseñaste a alguien, empezó a usarla, y en algún punto dejó de ser un experimento. Ahora es de lo que depende la gente, y eres la única persona que puede mantenerla en marcha, salvo que no tienes claro cómo se mantiene en marcha.
Ese es el cruce que nadie explica. Hay contenido infinito sobre cómo empezar a hacer vibe coding y casi nada sobre la parte que de verdad duele: el día en que el prototipo se convirtió en el producto y los cimientos nunca llegaron a ponerse.
Este es el mapa de ese cruce. No un aviso para que vayas más despacio, ni una excusa para reescribirlo todo “como Dios manda”. Un puente por etapas que puedes recorrer con la app en producción.
Dónde estás en realidad
Voy a ser preciso con la situación, porque casi todos los consejos apuntan a otra.
No eres un principiante que tiene que aprender a programar. Publicaste algo real, rápido, y funciona lo bastante bien como para que la gente volviera. Eso es genuinamente difícil y las herramientas que te trajeron aquí son buenas haciéndolo. Si quieres la definición completa de la técnica y el punto donde deja de sostenerte, en qué es el vibe coding y dónde deja de funcionar trazo esa línea sin desprecio.
El problema no es el código que tienes. Es el código que no puedes ver. Un prototipo es un conjunto de comportamientos que funcionaron una vez. Un producto es un conjunto de comportamientos que siguen funcionando mientras los cambias, mientras los usa más gente, mientras duermes. La distancia entre esos dos estados no es talento. Es estructura que un prototipo se salta legítimamente para ir rápido, y que un producto no puede saltarse.
Todo el mundo cruza esta distancia tarde o temprano. La mayoría la cruza por accidente, con pánico, en el peor momento posible. La alternativa es cruzarla a propósito.
Las cuatro cosas que un prototipo se salta
Un prototipo vibe-coded se salta justo lo que no aparece en una demo. No es pereza, es lo que lo hace rápido. Cada una vence más tarde.
Un modelo de lo que hace. El prototipo tiene comportamientos, no una especificación. Nadie escribió qué significa “correcto”, así que nadie sabe cuándo se rompe. El conocimiento vive en tu cabeza, y tu cabeza olvida.
Una memoria del porqué. Cada decisión de diseño que tomó el agente es invisible. Por qué esta forma de datos, por qué este flujo, qué evita hacer a propósito. Tres semanas después ese razonamiento se ha ido, también de ti, un patrón ya documentado.
Una red de seguridad. Nada te avisa cuando un cambio rompe algo que funcionaba. En un prototipo te enteras haciendo clic. En un producto se enteran antes tus usuarios.
Un contrato entre las partes. Cada feature se generó por su cuenta, asumiendo que el mundo a su alrededor se quedaba quieto. Nada obliga a que esa asunción se cumpla, y por eso cada feature nueva empieza a romper una vieja en cuanto tienes más de un puñado.
Ninguna aparece mientras construyes. Las cuatro aparecen mientras mantienes. El cruce es el trabajo de devolverlas sin parar el mundo.
El puente, etapa a etapa
No reescribes. Una reescritura tira el único activo que tienes, comportamiento que funciona, para perseguir estructura que podrías añadir sin apagar nada. Añades la estructura por debajo de lo que ya funciona.
Etapa 1: Ver lo que tienes
No puedes mantener lo que no puedes leer. Antes de cualquier arreglo, el trabajo es convertir un montón opaco de código generado en algo que puedas navegar: cuáles son las partes reales, cómo se hablan, dónde vive el dato, qué pasa de verdad cuando un usuario pulsa el botón principal.
Esto no es “léete cada línea”. Es dibujar un mapa, a la altura de componentes y flujos, no de sintaxis. Cuando puedes señalar las cuatro o cinco piezas reales de tu app y decir para qué sirve cada una, has pasado de pasajero a conductor. El método completo está en qué hacer cuando publicaste código que no sabes leer.
Etapa 2: Escribir la spec que nunca se escribió
Ahora escribe qué se supone que hace la app, en presente, desde fuera. No cómo funciona el código, cuál es el comportamiento: un usuario con este rol puede hacer esto, no puede hacer aquello, este número siempre cuadra con ese otro. Son especificaciones retroactivas, y son lo más barato que harás en todo el puente.
Por qué importan: una especificación es el contrato que dice qué significa “correcto”. Sin ella, “funciona” solo quiere decir “aún no se ha roto de forma visible”. Un build en verde no es una feature correcta, es un build que compiló. La spec es lo que convierte una vaga sensación de que funciona en algo que puedes comprobar.
Etapa 3: Fijar el comportamiento con tests
Una vez escrito lo que hace la app, captúralo en tests de caracterización: tests cuyo trabajo no es definir el comportamiento correcto sino congelar el comportamiento actual, para que el siguiente cambio te avise en el momento en que mueve algo. Esta es la red. Es lo que convierte el miedo a tu propio código en una señal sobre la que puedes actuar.
No lo pruebas todo. Pruebas los caminos que dolerían si se rompieran: la aritmética del dinero, la frontera de permisos, el flujo que la gente usa de verdad. Todo lo de aguas abajo se vuelve más fácil una vez que estos existen, porque ahora puedes cambiar cosas y saberlo.
Etapa 4: Poner cimientos sin reescribir
Con un mapa, specs y una red, por fin puedes reforzar la estructura: poner límites donde las features se meten unas en otras, añadir el contrato que impide que una feature rompa otra en silencio, retirar el código copiado y pegado que multiplica cada bug. Este es el trabajo de carga, y solo es seguro después de las tres primeras etapas, porque ahora cada cambio está comprobado. La secuencia completa está en arreglar una app vibe-coded sin reescribirla.
Por qué el orden es todo
No puedes saltar a la etapa 4. Reforzar la estructura sin red es como “un arreglito” se lleva por delante cuatro cosas a las 2 de la mañana. Tampoco puedes saltar a la etapa 3: unos tests que fijan comportamiento que no entiendes solo congelan tus bugs en su sitio. El orden es mapa, spec, red, cimientos, y no es negociable, porque cada etapa es lo que hace segura la siguiente.
Por eso también “reescríbelo bien y ya” es mal consejo. Una reescritura son las cuatro etapas a la vez, a ciegas, con la versión que funciona apagada. Pierdes el comportamiento que tenías y reconstruyes los mismos huecos en código nuevo. El puente se tarda más en describir y muchísimo menos en vivir, porque la app nunca deja de funcionar mientras cruzas.
He visto la diferencia en abierto. Cuando le pedí a un agente que construyera la misma app sin estructura, no sobrevivió al primer clic. La distancia nunca fue lo bien que se veía el código generado. Fue si había algo debajo que aguantara peso.
Lo que el cruce no es
Ayuda nombrar lo que este puente no es, porque el miedo que lo rodea suele venir de imaginar el trabajo equivocado.
No es aprender ciencias de la computación. No necesitas entender compiladores ni notación big-O para escribir qué hace tu app y comprobar que lo sigue haciendo. Las cuatro etapas son trabajo con forma de producto, no de académico: qué debería ser cierto, ¿sigue siéndolo?, dónde vive.
No es contratar a un ingeniero para que te lo quite de las manos. Puedes traer a uno, y uno bueno te agradecerá haber hecho las etapas uno y dos primero. Pero el cruce está diseñado para que lo camine la persona que construyó el prototipo, porque esa persona tiene lo único que ningún fichaje tiene: la memoria de qué se suponía que hacía, mientras esa memoria aún está fresca.
No es dejar de publicar. Sigues lanzando durante todo el cruce. El puente añade estructura bajo una app en vivo, en piezas pequeñas, cada una verificada. Nada de esto exige una congelación, y una congelación suele ser justo donde las apps vibe-coded van a morir.
Y no es un proyecto de una sola vez que terminas y olvidas. La razón por la que el prototipo perdió su estructura es que la estructura nunca se mantuvo al día. El sentido de cruzar a propósito es dejar tras de ti una spec, una red y un mapa que sigan pegados al código, para que no despiertes en el mismo sitio una segunda vez.
La señal de que estás listo para empezar
No esperas a que la app esté rota para empezar. Empiezas en cuanto notas cualquiera de estas: alguien que no eres tú depende de ella, dudas antes de cambiar algo, o abres un archivo que escribiste y no puedes seguirlo. Cada una es la app diciéndote que cruzó de prototipo a producto mientras estabas ocupado publicando. Cuanto antes respondas, más barato el cruce, porque pagas con memoria que aún tienes en vez de con arqueología que te toca reconstruir.
Dónde encaja PaellaDoc
Cada etapa de este puente es manual ahora mismo. Eres tú quien lee el código para hacer el mapa, quien tiene la spec en la cabeza, quien se acuerda de pasar las comprobaciones, quien caza la feature que rompió otra feature. Eso funciona hasta que la app es lo bastante grande como para que no puedas sostenerla entera, que es más o menos el momento en que se volvió digna de mantener.
PaellaDoc existe para que el puente sea un sistema en vez de un acto heroico. Lee un repo existente y lo convierte en un modelo navegable de lo que hay, mantiene las specs y las decisiones junto al código que gobiernan, y ejecuta la app para producir evidencia de que un comportamiento sigue funcionando en vez de fiarse de un build en verde. La idea no es hacer el cruce por ti. Es que el mapa, el contrato y la prueba vivan en un solo sitio y sigan al día, en vez de degradarse en tu memoria como lo hicieron la primera vez. El argumento amplio de ese sistema es el pilar sobre construir software con agentes de IA.
Ya hiciste la parte difícil y creativa. Construiste algo que la gente usa. El puente es cómo consigues quedártelo.
Preguntas frecuentes
¿Tengo que reescribir mi app vibe-coded para que esté lista para producción? No. Una reescritura descarta el comportamiento que ya funciona para perseguir estructura que puedes añadir por debajo. El enfoque por etapas, mapa, luego spec, luego tests, luego cimientos, añade lo que producción necesita con la app en marcha.
¿Cuándo se convierte un prototipo en producto? El día en que alguien empieza a depender de él, normalmente antes de que decidas que ha pasado. Esa es la señal para empezar el cruce, no el tamaño ni la edad de la app.
¿Qué es lo primero que hago? Hacer el código legible para ti: un mapa de las partes y flujos reales. No puedes especificar, probar ni reforzar lo que no puedes navegar, así que todas las etapas siguientes dependen de esta.