---
title: "Problemas estructurales de un proyecto de vibe coding y sprint de recuperación de 4 horas"
locale: es
category: how_to
category_name: "Cómo hacer"
translation_status: reviewed
license: cc_by
author: "Equipo editorial de Injoys"
source_url: https://injoys.com/es/articles/vibe-coding-project-architecture-and-four-hour-rescue-sprint
published_at: 2026-07-30T13:43:49+09:00
---

# Problemas estructurales de un proyecto de vibe coding y sprint de recuperación de 4 horas

> Las causas de que un proyecto de vibe coding se atasque justo antes del lanzamiento pueden estar, más que en la habilidad para crear prompts, en una estructura poco clara, un código incoherente y los límites entre servicios externos. La recuperación en 4 horas no garantiza un servicio completo, sino que debe entenderse como un sprint condicionado que fija el alcance y reimplementa el flujo principal para crear una base funcional.

## Key Points

- React, Next.js y Supabase no son un problema en sí mismos, pero la complejidad crece rápidamente cuando se combinan sin límites de responsabilidad ni reglas de implementación.
- Como la IA no conserva automáticamente la intención de diseño ni las condiciones operativas de todo el repositorio, una misma función puede implementarse siguiendo patrones diferentes.
- Ruby on Rails reduce las opciones mediante convenciones y componentes integrados, pero no resuelve automáticamente los pagos, la verificación de seguridad ni la preparación operativa.
- La recuperación en 4 horas es una reconstrucción inicial o una tarea de estabilización posible cuando existen requisitos definidos, un alcance principal reducido, cuentas e infraestructura preparadas y un profesional experimentado.
- Para decidir si seguir corrigiendo el código existente o rehacerlo, deben compararse no solo el estado del código, sino también la migración de datos, las integraciones externas, las pruebas, la capacidad del equipo y los riesgos del lanzamiento.

La programación por vibra es una forma de trabajo que utiliza instrucciones en lenguaje natural y herramientas de programación con IA para implementar aplicaciones rápidamente. Al principio, las pantallas y las funciones aumentan con rapidez, pero, a medida que se acerca el lanzamiento, suelen aparecer problemas que atraviesan varias capas, como la autenticación, los datos, los pagos y el despliegue.

Este fenómeno no debe explicarse únicamente por defectos de una pila tecnológica concreta o por la capacidad del usuario para crear prompts. Lo fundamental es **quién controla la coherencia estructural**, **si las responsabilidades de cada componente están claras** y **si existen pruebas que permitan verificar que el trabajo está terminado**.

## Por qué los proyectos de programación por vibra se atascan en las etapas finales

### Completar la interfaz no equivale a completar el servicio

En las primeras fases del desarrollo, se crean rápidamente resultados visibles como botones, formularios de entrada y listas. Sin embargo, un servicio real necesita las siguientes condiciones no visibles.

- Comprobaciones de permisos para que cada usuario solo pueda acceder a sus propios datos
- Procesamiento de datos que tolere solicitudes duplicadas y reintentos de red
- Éxito, fallo, cancelación y reembolso de pagos, además de verificación de webhooks
- Validación de datos de entrada y recuperación ante errores
- Cambios en la base de datos y migración de los datos existentes
- Gestión de claves secretas, registros, monitorización, copias de seguridad y restauración
- Pruebas automatizadas que garanticen que las funciones principales sigan funcionando después del despliegue

El mero hecho de que la interfaz funcione no significa que se cumplan estas condiciones. Los defectos que se descubren en las etapas finales no han surgido de repente; en muchos casos, se han acumulado desde la implementación inicial sin haber sido verificados.

### La IA no siempre conserva la intención de diseño de todo el repositorio

Las herramientas de programación con IA generan propuestas de cambios a partir de los archivos proporcionados, el contexto de la conversación, el código recuperado y las instrucciones. Si las reglas del proyecto no están documentadas, pueden producirse las siguientes incoherencias.

- Implementar de manera diferente una misma consulta de datos en componentes de servidor, rutas de API y código del navegador
- Gestionar de forma duplicada el estado de autenticación mediante cookies, el estado del cliente y un SDK externo
- Escribir de manera distinta las mismas reglas de validación en la interfaz y en el servidor
- Añadir únicamente manejo de excepciones o condicionales sin resolver el error de raíz
- Crear repetidamente funciones y modelos de datos similares al no encontrar las abstracciones existentes

En esta situación, al corregir un error nuevo, un cambio en una capa puede romper las suposiciones de otra. El usuario siente que la IA da vueltas sobre el mismo punto, pero en realidad puede ocurrir que no exista una única estructura ni criterios de verificación que la IA deba seguir.

## Comprender correctamente la combinación de React, Next.js y Supabase

No es exacto definir React, Next.js y Supabase simplemente como una mala pila compuesta. Cada tecnología tiene funciones independientes y ventajas ampliamente utilizadas.

| Tecnología | Función básica | Aspectos que deben decidirse en el proyecto |
|---|---|---|
| React | Biblioteca para crear interfaces de usuario | Gestión del estado, solicitudes de datos, límites de los componentes |
| Next.js | Framework web full stack basado en React | Método de renderizado, límites entre servidor y cliente, configuración de caché y API |
| Supabase | Plataforma backend que ofrece PostgreSQL, autenticación, almacenamiento, etc. | Políticas de acceso, modelo de datos, gestión de sesiones, permisos del servicio |
| Ruby on Rails | Framework integrado para aplicaciones web centradas en el servidor | Modelos, controladores, tareas, correo y configuración del despliegue dentro de las convenciones de Rails |

Next.js no es una herramienta que se ocupe únicamente de la interfaz, sino que también ofrece funciones de servidor. Supabase tampoco es solo una base de datos, ya que puede incluir autenticación, almacenamiento y otras funciones. El problema surge cuando se utilizan varias funciones sin determinar **dónde reside la responsabilidad final sobre los permisos y las reglas de negocio**.

Por ejemplo, si las reglas para crear pedidos están repartidas entre el código del navegador, las rutas de servidor de Next.js y las políticas de la base de datos de Supabase, resulta difícil rastrear los errores. Por el contrario, si se establece una regla según la cual las operaciones de escritura pasan por la capa de servicios del servidor y las políticas de la base de datos se utilizan como última línea de defensa, la misma pila puede operarse de forma estable.

## Por qué Ruby on Rails puede ser una alternativa

### Reduce las opciones mediante la convención sobre configuración

La convención sobre configuración, uno de los principios representativos de Ruby on Rails, unifica mediante las reglas predeterminadas del framework las decisiones estructurales que deben tomarse repetidamente. La ubicación y la forma de conexión de los modelos, controladores, cambios de la base de datos, tareas, correo y pruebas son relativamente predecibles.

Esta previsibilidad resulta especialmente útil en la programación con IA. Seguir convenciones claras reduce la posibilidad de que la IA añada nuevas funciones con patrones completamente distintos y también facilita que una persona revise los cambios.

### Gestiona las funciones comunes de los servicios web dentro de un solo sistema

Rails ofrece componentes y rutas oficiales para el acceso a la base de datos, el enrutamiento, el renderizado en el servidor, las tareas asíncronas, el correo, la comunicación en tiempo real, las pruebas y el despliegue. Esto permite reducir los puntos de conexión entre herramientas independientes.

Sin embargo, también presenta limitaciones claras.

- Para procesar pagos, sigue siendo necesario un proveedor de pagos externo como Stripe.
- Una página de administración no se completa automáticamente de forma que satisfaga todos los requisitos.
- Aunque se generen funciones de autenticación o se configuren mediante una biblioteca, el diseño de permisos y la revisión de seguridad son tareas independientes.
- Las interfaces complejas en tiempo real o las API móviles independientes requieren un diseño adicional.
- Si el equipo no tiene experiencia con Rails, habrá costes de aprendizaje y contratación.

Por tanto, Rails no es una herramienta que permita que la IA resuelva todos los problemas, sino **una opción que delimita la ruta básica que deben seguir tanto la IA como las personas**.

## Qué se puede resolver en 4 horas

No existe una base universal para afirmar que cualquier servicio que incluya inicio de sesión, pagos, funciones administrativas, migración de datos, revisión de seguridad y despliegue operativo pueda completarse en 4 horas. Los objetivos realistas para 4 horas son los siguientes.

- Comprender la estructura actual y los puntos de fallo.
- Elegir entre el mantenimiento y la reimplementación.
- Poner en funcionamiento un flujo de usuario prioritario.
- Crear una nueva base de referencia comprobable.
- Desplegarla, si es posible, en un entorno de staging.
- Dejar una lista de los riesgos restantes y las tareas posteriores.

### Condiciones que permiten una reimplementación en 4 horas

Cuantas más de las siguientes condiciones se cumplan, más viable será una reimplementación rápida.

1. Las pantallas y los flujos de usuario necesarios ya están definidos.
2. Los campos de datos principales y sus relaciones están organizados.
3. Es posible tomar como referencia las pantallas existentes sin volver a discutir el diseño.
4. Se puede acceder inmediatamente al repositorio, el dominio, el entorno de despliegue y las cuentas de los servicios externos.
5. Se puede omitir la migración de los datos existentes o trasladar únicamente una muestra pequeña.
6. Los pagos se limitan a un alcance reducido, como el flujo básico de éxito en el entorno de pruebas.
7. Una persona que conozca Rails y el entorno de despliegue revisa los resultados de la IA.

Aquí también reside la razón por la que resulta útil contar con un proyecto existente en el que se ha trabajado durante varios meses. Si durante ese periodo se concretaron los flujos de usuario, los campos obligatorios, los casos de fallo y las prioridades, se reduce el tiempo de exploración. Sin embargo, esto no significa que la planificación se haya vuelto perfecta automáticamente, y solo deben reutilizarse los requisitos validados en el proyecto existente.

## Sprint práctico de recuperación de 4 horas

| Tiempo | Trabajo | Entregable mínimo |
|---|---|---|
| 0:00~0:30 | Conservación del repositorio y del estado operativo, investigación de la pila tecnológica | Copia de seguridad, lista de componentes, comprobación de exposición de información secreta |
| 0:30~1:00 | Definición del flujo principal y del modelo de datos, decisión entre reparación y reimplementación | Alcance en una frase, condiciones de finalización, lista de riesgos |
| 1:00~2:00 | Base de referencia en Rails o modificación estructural del proyecto existente | Aplicación ejecutable, modelo de datos, estructura básica de autenticación |
| 2:00~3:15 | Implementación vertical del flujo de usuario principal | Un flujo conectado desde la interfaz hasta el almacenamiento de datos y sus pruebas |
| 3:15~3:45 | Configuración mínima de integraciones externas y despliegue en staging | Integración con el entorno de pruebas, URL de despliegue, configuración de variables de entorno |
| 3:45~4:00 | Pruebas de humo y traspaso | Resultados de éxito y fallo, elementos pendientes, orden de las siguientes tareas |

### Paso 1: Conservar el original

Antes de modificar nada, se crea una rama separada o una copia del repositorio y se realiza una copia de seguridad de la base de datos. No se deben pegar claves de API, contraseñas de bases de datos ni información de identificación personal en las conversaciones con la IA. Si ya se han expuesto, lo más seguro es revocar esos secretos y emitir otros nuevos.

### Paso 2: Investigar la pila tecnológica basándose en pruebas

En lugar de pedir a la IA que simplemente adivine la pila tecnológica, hay que exigirle que compruebe los siguientes recursos.

- Manifiestos y archivos de bloqueo que registran los paquetes y sus versiones
- Esquema de la base de datos y migraciones
- Archivos que gestionan la autenticación y las sesiones
- Rutas de API y funciones del servidor
- Configuración de despliegue, nombres de variables de entorno y SDK de servicios externos
- Pruebas automatizadas y configuración de integración continua

Un ejemplo de solicitud que puede utilizarse es el siguiente.

> Lee el repositorio y organiza en una tabla las herramientas del frontend, el servidor, la base de datos, la autenticación, el almacenamiento, los pagos, el despliegue y las pruebas. Incluye las rutas de los archivos que justifican cada conclusión y señala dónde están duplicadas las reglas de negocio y dónde podría haber infracciones de los límites entre servidor y cliente. No modifiques todavía el código ni muestres valores secretos.

### Paso 3: Elegir un solo flujo vertical principal

Un flujo vertical es una ruta completa que conecta la interfaz con la lógica del servidor y el almacenamiento de datos. Algunos ejemplos son los siguientes.

- Registro → inicio de sesión → consulta del perfil
- Selección de producto → creación del pedido → aprobación del pago en el entorno de pruebas
- Inicio de sesión del administrador → creación de una publicación → visualización en la página pública

En lugar de crear varias pantallas a la vez, validar un solo flujo principal en condiciones de éxito, falta de permisos y entrada incorrecta permite revelar más rápidamente los riesgos estructurales.

### Paso 4: Fijar las condiciones de finalización mediante pruebas

Si solo se pide a la IA que implemente una función, puede generar código adaptado al caso de éxito visible en la interfaz. Como mínimo, se deben fijar las siguientes condiciones mediante pruebas automatizadas o una lista de comprobación repetible.

- Un usuario válido puede completar la tarea.
- Un usuario que no haya iniciado sesión no puede acceder a datos protegidos.
- Aunque se introduzca el identificador de otro usuario, no es posible acceder a sus datos.
- Los datos incorrectos no se guardan y devuelven un error comprensible.
- Aunque se repita una misma solicitud de pago o escritura, no se procesa por duplicado.

### Paso 5: Desplegar solo hasta staging

Por lo general, es más seguro considerar el despliegue del sprint de 4 horas como una validación en staging y no como la confirmación definitiva para producción. Antes de aceptar usuarios y pagos reales, se deben comprobar por separado la seguridad, la migración de datos, la restauración de copias de seguridad, la monitorización y la respuesta ante incidentes.

## Criterios para decidir si reparar el proyecto existente o rehacerlo

| Situación | Mantener y reparar la estructura existente | Considerar una reimplementación con Rails u otra opción |
|---|---|---|
| Funciones principales y pruebas | La mayoría funciona y existen pruebas | Incluso los flujos principales se rompen repetidamente |
| Datos | Hay muchos datos operativos y el riesgo de migración es alto | No hay datos o el alcance de la migración es pequeño |
| Estructura | Los límites de responsabilidad y los patrones son mayoritariamente coherentes | Una misma función está duplicada en varias capas |
| Requisitos del frontend | Son importantes las interacciones complejas y los recursos existentes de React | El trabajo se centra en CRUD del lado del servidor y flujos operativos |
| Capacidades del equipo | Hay personal capaz de operar la pila actual | Las convenciones de Rails se adaptan mejor a la forma de trabajar del equipo |
| Integraciones externas | Ya están operativas numerosas integraciones estables | Las integraciones están en una fase inicial o pueden sustituirse |

No se debe realizar una reescritura completa únicamente porque haya muchos archivos o existan errores. Una reescritura puede hacer que se pierdan casos excepcionales ya resueltos y crear nuevos defectos. Es preferible implementar primero un pequeño flujo vertical de las dos maneras y comparar la velocidad de desarrollo, la capacidad de prueba, la comprensión del código y los riesgos del despliegue.

## Aspectos que deben comprobarse por separado antes del lanzamiento

Aunque se cree una base de referencia en 4 horas, pueden quedar pendientes los siguientes aspectos.

- Revisión del modelo de permisos y de la configuración de seguridad de Rails
- Firma de webhooks de pago, prevención de duplicados y gestión de cancelaciones y reembolsos
- Migración de datos operativos y verificación del número de registros y los totales
- Copias de seguridad de la base de datos y prueba real de restauración
- Seguimiento de errores, conservación de registros y monitorización de disponibilidad
- Pruebas de carga y estimación de costes
- Gestión de datos personales, términos de uso y revisión legal relacionada
- Comprobación de accesibilidad, navegadores y entornos móviles
- Procedimiento de reversión en caso de incidentes y designación de responsables

## Conclusión

El estancamiento de los proyectos de programación por vibra en sus etapas finales no puede explicarse únicamente por la capacidad de programación de la IA. Si en una configuración con un alto grado de libertad no se definen reglas, límites de responsabilidad, pruebas y criterios operativos, las soluciones locales creadas por la IA tienden a entrar en conflicto entre sí.

Ruby on Rails puede ser una alternativa práctica que reduce ese grado de libertad mediante convenciones y una estructura integrada. Sin embargo, rehacer todos los proyectos con Rails no es la respuesta correcta. Primero se debe investigar la pila actual basándose en pruebas, definir el flujo principal y utilizar las 4 horas **no como tiempo para crear un producto terminado, sino como tiempo para verificar la estructura y establecer una base de referencia recuperable**.

## FAQ

### ¿Por qué un proyecto de vibe coding avanza rápido al principio y se ralentiza en la fase final?
Al principio hay muchas tareas destinadas a crear flujos funcionales visibles, pero en la fase final se concentran los problemas que conectan múltiples capas, como los permisos, la consistencia de los datos, la recuperación ante fallos, los pagos, el despliegue y la seguridad. Si no hay reglas estructurales ni pruebas, las modificaciones locales añadidas por la IA pueden entrar en conflicto con el código existente y reducir aún más la velocidad.

### ¿Usar la combinación de React, Next.js y Supabase conduce necesariamente a código espagueti?
No. Las tres tecnologías son herramientas con funciones claramente definidas, y un equipo experimentado puede crear servicios estables con ellas. El problema surge cuando se implementa la misma funcionalidad de forma redundante en varias capas sin definir las responsabilidades del acceso a los datos, la autenticación, las reglas de negocio y la gestión de errores.

### ¿Cambiar a Ruby on Rails elimina la necesidad de todos los servicios externos?
No. Rails permite gestionar el acceso a los datos, el procesamiento de tareas, el correo, la comunicación en tiempo real, las pruebas y el despliegue dentro de un sistema coherente, pero aún pueden ser necesarios servicios externos como proveedores de pagos, infraestructura de envío de correo, alojamiento en la nube y monitorización.

### ¿Es realmente posible rehacer toda la aplicación en solo 4 horas?
No se puede garantizar de forma general. Si los requisitos y el modelo de datos están definidos, el flujo principal tiene un alcance muy limitado, las cuentas externas y el entorno de despliegue están preparados, y una persona experimentada revisa los resultados de la IA, se puede crear una base funcional o un pequeño MVP. La seguridad de nivel operativo, la gestión de excepciones en los pagos, la migración de datos y la respuesta ante incidentes suelen requerir tiempo adicional.

### ¿Qué señales indican que se debe descartar el código existente y reescribirlo?
Se puede considerar una reimplementación si las reglas de negocio fundamentales están duplicadas en varios lugares, las modificaciones pequeñas siguen rompiendo funciones no relacionadas, no hay pruebas automatizadas y todavía hay pocos datos, por lo que el coste de migración es bajo. Si hay muchos datos operativos e integraciones externas estables, o si la estructura actual cuenta con pruebas, una reparación gradual puede ser más segura.

### ¿Cómo se le debe pedir a la IA que investigue la pila tecnológica del proyecto actual?
Se le debe pedir que lea los archivos de paquetes, los archivos de bloqueo, el esquema de la base de datos, el código de autenticación, las rutas de la API, la configuración de despliegue y los archivos de pruebas, y que cree una tabla con la función de cada tecnología y los archivos que la justifican. Es recomendable indicarle que no modifique el código de inmediato, que no muestre valores secretos y que también señale las reglas de negocio duplicadas y las posibles infracciones de los límites entre componentes.

### ¿Qué funcionalidad debe implementarse primero en un trabajo de recuperación de 4 horas?
Se debe elegir un único flujo principal de usuario que represente el valor del servicio. No basta con crear las pantallas: hay que conectarlo con la autenticación, la validación del servidor, el almacenamiento de datos y la gestión de fallos, y probar las condiciones tanto para usuarios legítimos como para usuarios no autorizados, a fin de evaluar rápidamente la validez de la estructura.

### ¿Usar Rails resuelve automáticamente los problemas de seguridad?
No. Rails proporciona diversos valores predeterminados y mecanismos de protección de seguridad, pero no evita automáticamente la falta de controles de permisos, la exposición de información secreta, las integraciones externas vulnerables ni las configuraciones de despliegue incorrectas. Es necesario seguir la guía de seguridad del framework y revisar por separado los permisos y los flujos de datos específicos de cada aplicación.

## Sources

- [Aprende React](https://react.dev/learn)
- [Documentación de Next.js](https://nextjs.org/docs)
- [Documentación de Supabase](https://supabase.com/docs)
- [La doctrina de Rails](https://rubyonrails.org/doctrine)
- [Guías de Ruby on Rails](https://guides.rubyonrails.org/)
- [Conceptos básicos de Active Job](https://guides.rubyonrails.org/active_job_basics.html)
- [Conceptos básicos de Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html)
- [Descripción general de Action Cable](https://guides.rubyonrails.org/action_cable_overview.html)
- [Guía de seguridad de Ruby on Rails](https://guides.rubyonrails.org/security.html)
- [Guía para probar aplicaciones Rails](https://guides.rubyonrails.org/testing.html)

## Images

![Desarrollador entre conexiones de sistema enredadas y una arquitectura ordenada por capas](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI0OSwicHVyIjoiYmxvYl9pZCJ9fQ==--671c6671ab2b4dd55a12c8db4a32cd95021e1402/ai-ff797ac5.webp)
![Desarrolladores reparan un puente entre un terreno agrietado y una plataforma estable con iconos tecnológicos](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--dd1b9b18b3b924f01625710e0b4bafd8fbbd0002/ai-74d32191.webp)