Structural Problems in Vibe Coding Projects and a 4-Hour Recovery Sprint

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.

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.

1. The required screens and user flows have already been finalized.
2. The core data fields and relationships have been defined.
3. Existing screens can be referenced without reopening design discussions.
4. The repository, domain, deployment environment, and external service accounts are immediately accessible.
5. Migration of existing data can be omitted, or only a small sample needs to be moved.
6. Payments are limited to a narrow scope, such as the default successful flow in a sandbox.
7. 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

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

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.