Choque con la realidad de producción
El vibe era perfecto. La aplicación está rota.
El prototipo se convirtió en sistema antes de tener pruebas y un proceso de release. Otro prompt no siempre es el mejor comienzo.
01
¿Qué ha pasado?
El vibe coding prima velocidad; producción exige repetibilidad. Un prompt amplio mezcla arreglo, refactor, dependencias y migraciones.
02
Por qué ocurre
- No hay un diff pequeño entre la versión buena y la mala.
- Mocks o datos de preview ocultaron una dependencia real.
- Cada intento cambia otra zona sin relación.
03
Qué puedes comprobar
- Detén ediciones y guarda commit, logs y evidencia.
- Compara solo lo posterior al último commit estable.
- Convierte el fallo original en una prueba de regresión.
NO TÉCNICO
¿No escribiste tú el código? Aun así puedes ayudar a arreglarlo.
Lo más útil que puedes hacer ahora no es un mejor prompt, sino dejar de generar más cambios.
- Congela el proyecto: nada de prompts de "prueba esto" hasta que alguien revise qué se rompió.
- Anota más o menos cuándo funcionó por última vez y qué le pediste construir o cambiar a la IA desde entonces.
- Guarda (o pide a tu herramienta de IA) la exportación actual del proyecto o acceso al repositorio.
- Enumera todo lo que toque usuarios reales, dinero o datos personales: eso cambia el cuidado que necesita el arreglo.
Shipvise o un revisor sénior puede usar ese historial para averiguar qué cambio rompió la aplicación, sin que tengas que entender commits ni diffs.
04
Cómo probar el arreglo con seguridad
Aplica el arreglo en una rama separada, valídalo en un staging parecido a producción y publica exactamente la versión aprobada. Conserva el último artefacto estable y un rollback probado.
05
Cuándo necesitas a un desarrollador
Llama a un revisor sénior cuando nadie pueda explicar la arquitectura generada, puedan perderse datos o cada arreglo rompa otra parte distinta. Shipvise añade staging versionado, controles, revisión y una decisión de release explícita sin obligarte a abandonar tu herramienta de IA. No necesitas un equipo de DevOps propio solo por una aplicación.
FAQ
Preguntas que la gente realmente hace
¿El vibe coding siempre es inseguro?
No. El riesgo está en comportamiento sin revisar y releases sin control, no en la etiqueta.
¿Hay que reescribir?
No automáticamente. Delimita el fallo y compara una reparación controlada con el riesgo de reescribir.
¿Qué le doy a un desarrollador para que pueda arreglar la aplicación?
Acceso al repositorio, la URL donde falla, los pasos para reproducirlo, los logs, el último commit que funcionaba, la configuración de despliegue y una descripción de lo que cambió la IA.
¿Cómo arreglo una aplicación vibe-coded que se rompió de repente?
Primero deja de pedirle más cambios a la IA: cada intento nuevo puede tapar lo que realmente se rompió. Busca el último punto en el que funcionaba, compáralo con el estado actual y arregla esa regresión concreta en vez de dejar que la IA reconstruya la función entera.
¿Por qué el vibe coding rompe una y otra vez funciones que antes funcionaban?
Los prompts amplios y rápidos suelen tocar más aplicación de la que pedía la tarea, así que arreglar una cosa puede romper otra en silencio. Sin cambios pequeños y revisables, ni tests, nadie detecta ese daño colateral hasta que lo encuentra un usuario.
¿Sigo pidiéndole a la IA que lo arregle, o eso lo empeora?
Otro prompt de «arréglalo» puede ayudar. También puede romper otras tres cosas. Conserva primero la versión rota actual, averigua qué cambió de verdad, y dale a la IA una tarea más concreta y acotada en vez de repetir la misma petición vaga.
No uso Git: ¿cómo vuelvo a una versión que funcionaba?
Revisa si tu herramienta de IA tiene historial de versiones o checkpoints, una exportación anterior o un despliegue previo que puedas restaurar. Si no existe nada de eso, este es el momento de empezar a guardarlo: hasta una copia manual del proyecto antes de cada cambio grande te ayuda la próxima vez.
¿Puede un desarrollador arreglar una aplicación hecha con Lovable, Bolt, Replit o Cursor aunque no la haya construido él?
Sí. Un desarrollador no necesita conocer la misma herramienta: necesita acceso al código, ver el fallo y saber qué cambió últimamente. La aplicación resultante sigue siendo solo código y servicios; qué herramienta de IA la generó no cambia eso.