Cuándo deja de compensar el vibe coding: una regla práctica para parar
Arreglas el inicio de sesión y los pagos se rompen. Restauras los pagos y el error de inicio de sesión vuelve a aparecer. Un prompt más largo no necesariamente romperá ese ciclo. Antes de solicitar otro cambio, verifica si el fallo se repite y si el comportamiento relacionado está cubierto por una prueba.
No existe un punto fijo en el que el vibe coding deje de funcionar. La respuesta depende del producto, su riesgo y el estado del código. Las señales que indican un método de trabajo diferente son mucho más fáciles de identificar.
Juzga según el costo de un fallo, no por la cantidad de características
Mockups, prototipos desechables y herramientas internas utilizadas por un equipo pequeño pueden absorber el ensayo y error. Las herramientas de inteligencia artificial también pueden asumir gran parte de una aplicación CRUD simple cuando sus requisitos son claros y su comportamiento es verificable.
Eso no significa que la aplicación pueda construirse sin supervisión. Significa que un error sigue siendo reversible. La misma aplicación CRUD se convierte en una propuesta diferente cuando almacena datos personales o sirve a clientes que pagan.
El riesgo puede ser mayor de lo que muestra el producto
Una pantalla funcional no es suficiente una vez que el producto incluye:
- Pagos: El servidor debe calcular montos, verificar firmas de webhooks y evitar el procesamiento duplicado de eventos.
- Datos personales: La autenticación es solo el comienzo. La autorización por usuario, retención, eliminación y respuesta a incidentes también son importantes.
- Usuarios concurrentes: Dos personas modificando los mismos datos pueden crear conflictos y estados inconsistentes.
- Dependencias operativas: El despliegue, la monitorización, las copias de seguridad y la recuperación son disciplinas diferentes de la implementación de características.
Los servicios gestionados reducen la cantidad de código que debes escribir. No asumen toda la responsabilidad sobre tus datos, controles de acceso o configuración de la aplicación; Supabase lo describe explícitamente en su modelo de responsabilidad compartida.
El último tramo no es un porcentaje fijo
El trabajo inicial es altamente visible: las pantallas aparecen y el flujo principal empieza a funcionar. El trabajo posterior expone las conexiones entre características, rutas de error, datos legados, pruebas, reglas de seguridad y restricciones de despliegue. La cantidad de características visibles puede cambiar muy poco mientras que la cantidad de límites que debes verificar crece rápidamente.
El volumen de conversación y código incluido en el contexto de un modelo de inteligencia artificial también importa. Anthropic usa el término “degradación del contexto” para describir la forma en que la capacidad del modelo para recuperar información con precisión puede disminuir a medida que entran más tokens en el contexto. No hay un umbral universal de archivos. El riesgo práctico aumenta cuando archivos no relacionados y conversaciones largas llenan el contexto, o cuando el cambio intencional está mal delimitado y las decisiones anteriores son más fáciles de pasar por alto.
Lo que parece una pared repentina cerca del final suele ser algo más: la cantidad de conexiones que requieren verificación comienza a crecer más rápido que la cantidad de características que quedan por implementar.
Tres señales que indican que es hora de detenerse y buscar ayuda
Las correcciones vuelven a causar el mismo problema
Cambiar A rompe B, luego arreglar B rompe A nuevamente. Congela los pasos de reproducción y las pruebas antes de solicitar otro parche. La señal importante no es que el error haya existido durante un cierto número de días; es que cada intento de solución falla las mismas pruebas de regresión.
No puedes determinar si el resultado es correcto
La autenticación, la autorización, los pagos y la recuperación de datos no pueden evaluarse solo desde la interfaz de usuario. Si no hay pruebas o si existen registros pero nadie puede usarlos para evaluar la seguridad, la brecha de verificación es mayor que la brecha de implementación. Una revisión de código o seguridad enfocada puede ayudar aquí.
Un fallo afectaría a alguien más
El producto ya maneja dinero real o datos de clientes, o un corte de servicio afectaría a los ingresos. “Lanzar ahora, arreglar después” ahora tiene un costo diferente. La revisión previa al lanzamiento, las copias de seguridad, un plan de reversión y la monitorización pasan a formar parte del alcance.
Puedes delegar una revisión específica en lugar de toda la aplicación
Detén temporalmente el desarrollo de funciones y conserva la versión actual que funciona. Coloca los pasos de reproducción, el resultado esperado, el resultado real y los registros relevantes en un solo documento. Así, tanto una herramienta de inteligencia artificial como un desarrollador parten de la misma información.
Luego haz la solicitud pequeña:
- revisa solo la autenticación y la autorización por usuario
- revisa solo las solicitudes de pago y el procesamiento de webhooks
- revisa solo la configuración de despliegue, las claves API y las variables de entorno
- escribe pruebas para la función que vuelve a fallar
“Termina mi aplicación” es difícil de valorar y difícil de verificar. Una solicitud con un área bien delimitada y criterios de aceptación facilita comparar propuestas y resultados. Incluye la repetición de las mismas pruebas después del arreglo en el encargo.
Registra cuatro cosas antes del siguiente prompt
Incluso si no estás transfiriendo el proyecto aún, escribe:
- la ruta exacta de clic y el estado de la cuenta que reproduce el error
- el último commit conocido que funciona
- los archivos que la IA cambió y por qué
- las pruebas que deben pasar después del siguiente cambio
Este registro evita que el equipo tenga que redescubrir el problema una y otra vez y muestra si un arreglo revirtió otra función sin que nadie lo advirtiera. El límite del Vibe Coding no es una línea que te indique abandonar la herramienta. Es el punto donde la verificación y las operaciones son más importantes que producir otro parche.