Structural Problems in Vibe Coding Projects and a 4-Hour Recovery Sprint
Vibe coding projects may stall just before launch not because of prompting skills, but because of unclear architecture, inconsistent code, and boundaries between external services. A 4-hour recovery should be understood not as a guarantee of a fully completed service, but as a conditional sprint that fixes the scope and reimplements the core flow to create a working baseline.
- React, Next.js, and Supabase are not inherently the problem; complexity grows rapidly when they are combined without clear boundaries of responsibility and implementation rules.
- Because AI does not automatically preserve the design intent and operational requirements of an entire repository, the same feature may be implemented using different patterns.
- Ruby on Rails reduces the number of choices through conventions and integrated components, but it does not automatically handle payments, security validation, or production readiness.
- A 4-hour recovery is an initial rebuild or stabilization effort that is possible when requirements are finalized, the core scope is narrow, accounts and infrastructure are ready, and a skilled practitioner is available.
- Whether to keep fixing the existing code or rebuild should be decided by comparing not only the state of the code, but also data migration, external integrations, testing, team capabilities, and launch risks.
Vibe coding refers to a way of working that uses natural-language instructions and AI coding tools to build applications quickly. Screens and features increase rapidly at first, but as launch approaches, problems that cut across multiple layers—such as authentication, data, payments, and deployment—often emerge.
This phenomenon should not be explained solely as a flaw in a particular technology stack or a matter of the user’s prompting ability. The key questions are who controls structural consistency, whether each component’s responsibilities are clear, and whether tests exist to verify completion.
Why Vibe Coding Projects Stall in the Later Stages
A finished interface is not the same as a finished service
During early development, visible results such as buttons, input forms, and lists are created quickly. However, a real service requires invisible safeguards such as the following.
- Authorization checks that ensure users can access only their own data
- Data handling that can withstand duplicate requests and network retries
- Payment success, failure, cancellation, refunds, and webhook verification
- Input validation and error recovery
- Database changes and migration of existing data
- Secret key management, logging, monitoring, backup, and recovery
- Automated tests that ensure core functionality continues to work after deployment
The fact that the interface works does not mean these conditions have been met. Defects discovered later usually did not appear suddenly; in many cases, they accumulated because they were never verified during the initial implementation.
AI cannot always preserve the design intent of the entire repository
AI coding tools generate changes based on the files provided, conversational context, retrieved code, and instructions. If project rules are not documented, inconsistencies such as the following may arise.
- Implementing the same data query differently in server components, API routes, and browser code
- Managing authentication state redundantly through cookies, client state, and external SDKs
- Writing different versions of the same validation rule in the interface and on the server
- Adding only exception handling or conditional statements without addressing the root cause of an error
- Repeatedly creating similar functions and data models because an existing abstraction was not found
When new errors are fixed in this state, a change in one layer may break the assumptions of another. The user may feel that the AI is going in circles, but the actual problem may be that there is no single structure or verification standard for the AI to follow.
Understanding the React·Next.js·Supabase Combination Accurately
It is inaccurate to characterize React, Next.js, and Supabase simply as a bad, pieced-together stack. Each technology has its own widely used role and advantages.
| Technology | Primary role | Decisions required in a project |
|---|---|---|
| React | Library for building user interfaces | State management, data requests, component boundaries |
| Next.js | React-based full-stack web framework | Rendering approach, server·client boundaries, caching and API structure |
| Supabase | Backend platform providing PostgreSQL, authentication, storage, and more | Access policies, data model, session handling, service privileges |
| Ruby on Rails | Server-centered, integrated web application framework | Models, controllers, jobs, mail, and deployment configuration within Rails conventions |
Next.js is not merely a tool for building interfaces; it also provides server functionality. Supabase is likewise not simply a database and can include authentication, storage, and more. Problems arise when using multiple features without deciding where final responsibility for permissions and business rules lies.
For example, if order creation rules are distributed across browser code, Next.js server routes, and Supabase database policies, errors become difficult to trace. Conversely, if a rule is established that write operations must pass through a server service layer and database policies serve as the final line of defense, the same stack can be operated reliably.
Why Ruby on Rails Can Be an Alternative
It reduces choices through convention over configuration
Convention over configuration, a defining principle of Ruby on Rails, standardizes repeatedly required structural decisions through the framework’s default rules. The locations of models, controllers, database changes, jobs, mail, and tests—and how they connect—are relatively predictable.
This predictability is particularly useful in AI coding. Following clear conventions reduces the likelihood that AI will add new features using entirely different patterns and also makes it easier for people to review changes.
It handles common web service functionality within one system
Rails provides official components and established paths for database access, routing, server rendering, asynchronous jobs, mail, real-time communication, testing, and deployment. This can reduce the number of integration points between separate tools.
However, it also has clear limitations.
- Payment processing still requires an external payment provider such as Stripe.
- An admin page is not automatically completed to fit every requirement.
- Even if authentication features are generated or configured with a library, authorization design and security review remain separate tasks.
- Complex real-time interfaces or independent mobile APIs require additional design.
- Teams without Rails experience will incur training and hiring costs.
Therefore, Rails is not a tool that makes AI solve every problem; it is an option that narrows the default paths AI and people must follow.
What Can Be Solved in 4 Hours
There is no universal basis for claiming that any service—including login, payments, admin features, data migration, security review, and production deployment—can be completed within 4 hours. Realistic goals for 4 hours are as follows.
- Identify the current structure and points of failure.
- Choose between maintenance and reimplementation.
- Make one critical user flow work.
- Create a new, testable baseline.
- Deploy to a staging environment if possible.
- Document remaining risks and follow-up tasks.
Conditions That Make Reimplementation in 4 Hours Possible
The more of the following conditions are met, the more feasible a short reimplementation becomes.
- The required screens and user flows have already been finalized.
- The core data fields and relationships have been defined.
- Existing screens can be referenced without reopening design discussions.
- The repository, domain, deployment environment, and external service accounts are immediately accessible.
- Migration of existing data can be omitted, or only a small sample needs to be moved.
- Payments are limited to a narrow scope, such as the default successful flow in a sandbox.
- Someone who understands Rails and the deployment environment reviews the AI’s output.
This is also why an existing project developed over several months can be helpful. If user flows, required fields, failure cases, and priorities were clarified during that period, less time is needed for exploration. However, this does not mean the plan has automatically become perfect; only requirements validated in the existing project should be reused.
A Practical 4-Hour Recovery Sprint
| Time | Task | Minimum deliverable |
|---|---|---|
| 0:00~0:30 | Preserve the repository and production state, investigate the technology stack | Backup, component inventory, check for exposed secrets |
| 0:30~1:00 | Finalize the core flow and data model, decide whether to repair or reimplement | One-sentence scope, completion criteria, risk list |
| 1:00~2:00 | Establish a Rails baseline or make structural changes to the existing project | Runnable app, data model, authentication skeleton |
| 2:00~3:15 | Implement the core user flow vertically | One flow connected from interface to data storage, with tests |
| 3:15~3:45 | Configure minimum external integrations and deploy to staging | Sandbox integration, deployment URL, environment variable configuration |
| 3:45~4:00 | Perform smoke tests and handoff | Success·failure results, incomplete items, order of next tasks |
Step 1: Preserve the original
Before making changes, create a separate branch or copy of the repository and back up the database. Do not paste API keys, database passwords, or personally identifiable information into AI conversations. If they have already been exposed, it is safer to revoke those secrets and issue new ones.
Step 2: Investigate the technology stack with evidence
Do not simply ask AI to guess the technology stack. Require it to inspect the following materials.
- Manifest and lock files recording packages and versions
- Database schemas and migrations
- Files that handle authentication and sessions
- API routes and server functions
- Deployment settings, environment variable names, and external service SDKs
- Automated tests and continuous integration settings
An example request is as follows.
Read the repository and organize the frontend, server, database, authentication, storage, payment, deployment, and testing tools into a table. Include the file paths supporting each conclusion, and identify locations where business rules are duplicated and where server·client boundaries may be violated. Do not modify the code yet, and do not output secret values.
Step 3: Choose only one core vertical flow
A vertical flow is one complete path connecting the interface to server logic and data storage. Examples include the following.
- Sign up → log in → view profile
- Select product → create order → approve payment in sandbox
- Admin login → create post → display on public page
Rather than building multiple screens at once, validating one core flow under success, unauthorized, and invalid-input conditions reveals structural risks more quickly.
Step 4: Fix the completion criteria in tests
If AI is asked only to implement a feature, it may produce code tailored to successful cases visible in the interface. At minimum, establish the following conditions as automated tests or a repeatable checklist.
- A valid user can complete the task.
- A user who is not logged in cannot access protected data.
- Entering another user’s identifier does not grant access to that user’s data.
- Invalid input is not saved and returns an understandable error.
- Repeating the same payment or write request does not result in duplicate processing.
Step 5: Deploy only to staging
It is generally safer to treat deployment during a 4-hour sprint as staging validation rather than a finalized production release. Before accepting real users and payments, security, data migration, backup restoration, monitoring, and incident response must be checked separately.
Criteria for Deciding Whether to Fix or Rebuild an Existing Project
| Situation | Keep·repair the existing structure | Consider reimplementation with Rails or another option |
|---|---|---|
| Core features and tests | Most features work and tests exist | Even core flows repeatedly break |
| Data | There is substantial production data, and migration risk is high | There is no data, or the migration scope is small |
| Structure | Responsibility boundaries and patterns are generally consistent | The same functionality is duplicated across multiple layers |
| Frontend requirements | Complex interactions and existing React assets are important | Server-centered CRUD and business workflows are central |
| Team capabilities | Personnel are available to operate the current stack | Rails conventions better fit the team’s way of working |
| External integrations | Many stable integrations are already in production | Integrations are in an early stage or can be replaced |
A full rewrite should not be undertaken merely because there are many files or errors. Rewriting can discard previously resolved edge cases and introduce new defects. It is better to first implement a small vertical flow using both approaches and compare development speed, testability, code comprehensibility, and deployment risk.
Items to Check Separately Before Launch
Even after a 4-hour baseline has been created, the following items may remain.
- Review of the authorization model and Rails security settings
- Payment webhook signatures, duplicate prevention, cancellation, and refund handling
- Production data migration and verification of record counts·totals
- Database backups and actual restoration testing
- Error tracking, log retention, and availability monitoring
- Load testing and cost estimation
- Privacy processing, terms of service, and related legal review
- Accessibility, browser, and mobile environment checks
- Rollback procedures and designation of responsible personnel for incidents
Conclusion
Late-stage stagnation in vibe coding projects cannot be explained solely by AI’s coding ability. In a highly flexible configuration, if rules, responsibility boundaries, testing, and operational standards are not established, locally generated AI solutions are likely to conflict with one another.
Ruby on Rails can be a practical alternative that reduces this flexibility through conventions and an integrated structure. However, rebuilding every project in Rails is not always the right answer. First investigate the current stack based on evidence, define the core flow, and then use the 4 hours not as time to build a finished product, but as time to validate the structure and create a recoverable baseline.
FAQ
Why do vibe coding projects start out fast but slow down in the later stages?
Early on, much of the work involves building visible happy paths, but later stages are dominated by problems that connect multiple layers, such as authorization, data consistency, failure recovery, payments, deployment, and security. Without architectural rules and tests, localized changes added by AI may conflict with existing code and slow progress even further.
Does using React, Next.js, and Supabase inevitably result in spaghetti code?
No. Each of the three technologies is a tool with a clear role, and an experienced team can build a stable service with them. Problems arise when the same functionality is implemented redundantly across multiple layers without defining responsibility for data access, authentication, business rules, and error handling.
Does switching to Ruby on Rails eliminate the need for all external services?
No. Rails can handle data access, job processing, email, real-time communication, testing, and deployment within a consistent framework, but external services such as payment providers, email delivery infrastructure, cloud hosting, and monitoring may still be necessary.
Can an entire app really be rebuilt in 4 hours?
This cannot be guaranteed in general. If the requirements and data model are finalized, the core flow is very narrow, external accounts and the deployment environment are ready, and an experienced person reviews the AI's output, it may be possible to build a working baseline or a small MVP. Production-grade security, payment exception handling, data migration, and incident response usually require additional time.
What are the signs that existing code should be discarded and rewritten?
A rewrite may be worth considering if core business rules are duplicated in multiple places, small changes repeatedly break unrelated features, there are no automated tests, and there is still little data, making migration costs low. If there is a large amount of production data and many stable external integrations, or if the current architecture has tests, incremental repairs may be safer.
How should I have AI investigate the current project's technology stack?
You should ask it to read the package files, lockfiles, database schema, authentication code, API routes, deployment configuration, and test files, then create a table showing each technology's role and the supporting files. It is best to have it avoid modifying the code immediately or exposing secrets, while also flagging duplicated business rules and potential boundary violations.
What should be implemented first in a 4-hour recovery effort?
You should choose one core user flow that represents the service's value. Rather than building only the screens, connect authentication, server-side validation, data storage, and failure handling, and test both authorized and unauthorized user scenarios so you can quickly assess whether the architecture is sound.
Does using Rails automatically resolve security issues?
No. Rails provides many secure defaults and protective features, but it does not automatically prevent missing authorization checks, exposure of secrets, vulnerable external integrations, or incorrect deployment configurations. You must follow the framework's security guides and separately review application-specific permissions and data flows.
Sources
Images
