Vibe coding: qué hacer cuando tu app de IA se queda atascada antes de lanzar

El patrón que se repite

Cada semana hablo con alguien atascado en el mismo sitio. La historia tiene matices, pero la curva es siempre parecida:

1. Empezaste a construir con Cursor, Lovable, Bolt, Replit o un mix de IA y código pegado a mano
2. En las primeras 48 horas tenías algo que parecía un producto
3. Cada nuevo prompt rompía algo que antes funcionaba
4. El deploy a producción reveló problemas que en local nunca se vieron
5. Llevas tres semanas dando vueltas en círculos y no sabes si patchear, refactorizar o tirar todo

Si te sientes identificado, no estás solo. Esto se llama vibe coding: construir rápido por intuición y prompts, sin un mapa técnico claro. Funciona muy bien hasta que toca pasar el último 20%.

---

Los cuatro bloqueos típicos

1. El bucle de prompts

Pides un cambio pequeño, el asistente reescribe partes que no le pediste tocar. Arreglas eso, aparece otro bug en otro sitio. La sensación es de avanzar y retroceder al mismo tiempo.

Por qué pasa: Los modelos no tienen una visión global de tu código. Cuando "ayudan", a veces sustituyen lógica que ya funcionaba por una versión genérica que rompe casos de uso reales.

Cómo salir:

• Usa control de versiones obsesivamente (git commit cada vez que algo funciona)
• Reduce el alcance de cada prompt: "cambia solo este archivo, no toques el resto"
• Cuando el asistente reescribe sin pedirlo, vuelve atrás con git reset antes de aceptar

2. Las piezas críticas casi funcionan

Login, pagos, emails, integraciones de terceros, permisos de base de datos. En la demo se ven listos. En producción, con un usuario real, fallan.

Por qué pasa: Estos sistemas tienen detalles que la IA no maneja bien por defecto:

• Auth: chequeo de state, expiración de tokens, cookies con httpOnly y secure, manejo de redirects
• Stripe: verificación de firma del webhook, manejo de modos test/live, gestión de eventos duplicados
• Email: SPF/DKIM/DMARC, distinción transaccional vs marketing, manejo de bounces
• DB: row-level security, índices, migraciones reversibles

Cómo salir: Estas piezas no se "vibe-codean". Necesitan revisión humana con ojos expertos. Son el último 20% que duele más.

3. El deploy que en local funciona pero en producción se cae

Variables de entorno mal configuradas, build pipelines que no replican el entorno local, dependencias que se comportan distinto en serverless, tiempos de cold-start.

Por qué pasa: Los entornos de Vercel, Render, Railway, Supabase y Firebase tienen comportamientos sutiles distintos al desarrollo local. El asistente de IA no los ve.

Cómo salir:

• Revisa los logs reales del proveedor, no asumas
• Compara variables de entorno línea por línea entre local y producción
• Si usas Next.js: separa bien lo que es server-side de client-side
• Despliega temprano y a menudo, no acumules cambios sin validar en producción

4. La sensación de "esto ya no es mantenible"

El código creció rápido, hay archivos enormes, lógica duplicada, nombres inconsistentes, y ya no entiendes qué hace cada parte. Cada cambio te da miedo.

Por qué pasa: La IA optimiza para "que funcione ya", no para "que sea legible dentro de 3 meses". Si no pones tú el orden, el orden no aparece.

Cómo salir:

• No reescribas todo, refactoriza por capas: primero nombres y estructura de archivos, luego lógica
• Añade tests para los flujos críticos (auth, pagos) antes de tocar nada más
• Si está demasiado roto, decide honestamente qué partes vale la pena salvar y cuáles reemplazar

---

Decisiones honestas: parchear, refactorizar o rehacer

No hay una respuesta universal, pero estos son los criterios que uso:

Parchea cuando:

• El bug es local y aislado
• El resto del código está razonablemente sano
• El producto está ya en producción con usuarios

Refactoriza cuando:

• Hay 2 o 3 partes problemáticas pero la idea principal funciona
• Tienes tiempo y aún no estás en producción con muchos usuarios
• Identificas un patrón claro que repetir bien resuelve la mayoría

Rehaz desde cero solo cuando:

• El stack de base es incompatible con lo que necesitas (ej. construir un SaaS multi-tenant sobre Firebase sin pensar la auth desde el inicio)
• El código ya es ininteligible incluso para ti
• Vas a invertir más tiempo arreglando que reconstruyendo limpio

La mayoría de proyectos atascados que veo no necesitan rehacer. Necesitan un par de semanas de manos expertas desbloqueando piezas concretas.

---

Lo que SÍ funciona del vibe coding

No quiero que esto suene como un alegato anti-IA. La realidad es que construir con Cursor, Lovable o Bolt te da un superpoder: velocidad inicial brutal.

Lo que funciona:

• Validar una idea de producto en días, no semanas
• Construir prototipos para conseguir feedback temprano
• Levantar landing pages, dashboards internos y herramientas no críticas
• Mantenerse en flow sin pelear con boilerplate

Lo que NO funciona del todo:

• Lanzar a producción con pagos, datos sensibles o muchos usuarios sin revisión humana
• Mantener el código a largo plazo sin alguien que entienda lo que hay debajo
• Resolver bugs de integración, deploy o seguridad solo a base de prompts

La clave es saber dónde la IA acelera y dónde la IA esconde deuda técnica.

---

Si estás en este punto ahora mismo

Si llevas semanas atascado, pidiendo cambios y viendo cómo cada uno trae uno nuevo, considera estas tres opciones:

Opción 1: dale otro intento solo Aplica los consejos de arriba, comprométete con git, reduce el alcance de los prompts, y dale 1-2 semanas más. A veces solo hace falta cambiar la metodología.

Opción 2: pide una revisión rápida Que alguien con experiencia mire tu código durante una hora y te diga objetivamente dónde estás, qué se puede salvar y qué se debe reemplazar. Una revisión bien hecha te ahorra meses.

Opción 3: trabaja codo a codo con un dev senior Especialmente útil si tu app está cerca de lanzarse pero las piezas críticas (auth, pagos, deploy) no terminan de cerrar. No es delegar el proyecto: es tener a alguien al lado mientras tú sigues al volante.

Para esa tercera opción tengo un sitio dedicado: rescuevibe.dev. Está pensado específicamente para builders que construyeron con IA y necesitan ayuda de un dev senior para llegar a producción. Diagnóstico honesto primero, sprint enfocado después si vale la pena seguir.

---

Conclusión

Atascarse con una app construida con IA no es señal de que estés haciendo algo mal. Es señal de que llegaste al punto donde el vibe coding se queda corto y necesitas un nivel distinto de rigor técnico.

La buena noticia: ese último 20% que tanto duele tiene caminos claros. Solo hay que reconocer dónde estás, qué bloqueo concreto te tiene parado, y qué tipo de ayuda necesitas (si la necesitas).

Tu app puede llegar a producción. La pregunta no es si es posible, sino cuál es la ruta más corta y honesta para que ocurra.