{"content_id":"sjuxeehxgw","slug":"vibe-coding-project-architecture-and-four-hour-rescue-sprint","locale":"en","schema_type":"TechArticle","category":"how_to","category_name":"How-to","title":"Structural Problems in Vibe Coding Projects and a 4-Hour Recovery Sprint","summary":"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.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["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."],"content_markdown":"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.\n\nThis 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**.\n\n## Why Vibe Coding Projects Stall in the Later Stages\n\n### A finished interface is not the same as a finished service\n\nDuring 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.\n\n- Authorization checks that ensure users can access only their own data\n- Data handling that can withstand duplicate requests and network retries\n- Payment success, failure, cancellation, refunds, and webhook verification\n- Input validation and error recovery\n- Database changes and migration of existing data\n- Secret key management, logging, monitoring, backup, and recovery\n- Automated tests that ensure core functionality continues to work after deployment\n\nThe 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.\n\n### AI cannot always preserve the design intent of the entire repository\n\nAI 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.\n\n- Implementing the same data query differently in server components, API routes, and browser code\n- Managing authentication state redundantly through cookies, client state, and external SDKs\n- Writing different versions of the same validation rule in the interface and on the server\n- Adding only exception handling or conditional statements without addressing the root cause of an error\n- Repeatedly creating similar functions and data models because an existing abstraction was not found\n\nWhen 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.\n\n## Understanding the React·Next.js·Supabase Combination Accurately\n\nIt 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.\n\n| Technology | Primary role | Decisions required in a project |\n|---|---|---|\n| React | Library for building user interfaces | State management, data requests, component boundaries |\n| Next.js | React-based full-stack web framework | Rendering approach, server·client boundaries, caching and API structure |\n| Supabase | Backend platform providing PostgreSQL, authentication, storage, and more | Access policies, data model, session handling, service privileges |\n| Ruby on Rails | Server-centered, integrated web application framework | Models, controllers, jobs, mail, and deployment configuration within Rails conventions |\n\nNext.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**.\n\nFor 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.\n\n## Why Ruby on Rails Can Be an Alternative\n\n### It reduces choices through convention over configuration\n\nConvention 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.\n\nThis 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.\n\n### It handles common web service functionality within one system\n\nRails 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.\n\nHowever, it also has clear limitations.\n\n- Payment processing still requires an external payment provider such as Stripe.\n- An admin page is not automatically completed to fit every requirement.\n- Even if authentication features are generated or configured with a library, authorization design and security review remain separate tasks.\n- Complex real-time interfaces or independent mobile APIs require additional design.\n- Teams without Rails experience will incur training and hiring costs.\n\nTherefore, 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**.\n\n## What Can Be Solved in 4 Hours\n\nThere 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.\n\n- Identify the current structure and points of failure.\n- Choose between maintenance and reimplementation.\n- Make one critical user flow work.\n- Create a new, testable baseline.\n- Deploy to a staging environment if possible.\n- Document remaining risks and follow-up tasks.\n\n### Conditions That Make Reimplementation in 4 Hours Possible\n\nThe more of the following conditions are met, the more feasible a short reimplementation becomes.\n\n1. The required screens and user flows have already been finalized.\n2. The core data fields and relationships have been defined.\n3. Existing screens can be referenced without reopening design discussions.\n4. The repository, domain, deployment environment, and external service accounts are immediately accessible.\n5. Migration of existing data can be omitted, or only a small sample needs to be moved.\n6. Payments are limited to a narrow scope, such as the default successful flow in a sandbox.\n7. Someone who understands Rails and the deployment environment reviews the AI’s output.\n\nThis 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.\n\n## A Practical 4-Hour Recovery Sprint\n\n| Time | Task | Minimum deliverable |\n|---|---|---|\n| 0:00~0:30 | Preserve the repository and production state, investigate the technology stack | Backup, component inventory, check for exposed secrets |\n| 0:30~1:00 | Finalize the core flow and data model, decide whether to repair or reimplement | One-sentence scope, completion criteria, risk list |\n| 1:00~2:00 | Establish a Rails baseline or make structural changes to the existing project | Runnable app, data model, authentication skeleton |\n| 2:00~3:15 | Implement the core user flow vertically | One flow connected from interface to data storage, with tests |\n| 3:15~3:45 | Configure minimum external integrations and deploy to staging | Sandbox integration, deployment URL, environment variable configuration |\n| 3:45~4:00 | Perform smoke tests and handoff | Success·failure results, incomplete items, order of next tasks |\n\n### Step 1: Preserve the original\n\nBefore 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.\n\n### Step 2: Investigate the technology stack with evidence\n\nDo not simply ask AI to guess the technology stack. Require it to inspect the following materials.\n\n- Manifest and lock files recording packages and versions\n- Database schemas and migrations\n- Files that handle authentication and sessions\n- API routes and server functions\n- Deployment settings, environment variable names, and external service SDKs\n- Automated tests and continuous integration settings\n\nAn example request is as follows.\n\n\u003e 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.\n\n### Step 3: Choose only one core vertical flow\n\nA vertical flow is one complete path connecting the interface to server logic and data storage. Examples include the following.\n\n- Sign up → log in → view profile\n- Select product → create order → approve payment in sandbox\n- Admin login → create post → display on public page\n\nRather than building multiple screens at once, validating one core flow under success, unauthorized, and invalid-input conditions reveals structural risks more quickly.\n\n### Step 4: Fix the completion criteria in tests\n\nIf 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.\n\n- A valid user can complete the task.\n- A user who is not logged in cannot access protected data.\n- Entering another user’s identifier does not grant access to that user’s data.\n- Invalid input is not saved and returns an understandable error.\n- Repeating the same payment or write request does not result in duplicate processing.\n\n### Step 5: Deploy only to staging\n\nIt 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.\n\n## Criteria for Deciding Whether to Fix or Rebuild an Existing Project\n\n| Situation | Keep·repair the existing structure | Consider reimplementation with Rails or another option |\n|---|---|---|\n| Core features and tests | Most features work and tests exist | Even core flows repeatedly break |\n| Data | There is substantial production data, and migration risk is high | There is no data, or the migration scope is small |\n| Structure | Responsibility boundaries and patterns are generally consistent | The same functionality is duplicated across multiple layers |\n| Frontend requirements | Complex interactions and existing React assets are important | Server-centered CRUD and business workflows are central |\n| Team capabilities | Personnel are available to operate the current stack | Rails conventions better fit the team’s way of working |\n| External integrations | Many stable integrations are already in production | Integrations are in an early stage or can be replaced |\n\nA 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.\n\n## Items to Check Separately Before Launch\n\nEven after a 4-hour baseline has been created, the following items may remain.\n\n- Review of the authorization model and Rails security settings\n- Payment webhook signatures, duplicate prevention, cancellation, and refund handling\n- Production data migration and verification of record counts·totals\n- Database backups and actual restoration testing\n- Error tracking, log retention, and availability monitoring\n- Load testing and cost estimation\n- Privacy processing, terms of service, and related legal review\n- Accessibility, browser, and mobile environment checks\n- Rollback procedures and designation of responsible personnel for incidents\n\n## Conclusion\n\nLate-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.\n\nRuby 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**.","content_html":"\u003cp\u003eVibe 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.\u003c/p\u003e\n\u003cp\u003eThis 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 \u003cstrong\u003ewho controls structural consistency\u003c/strong\u003e, \u003cstrong\u003ewhether each component’s responsibilities are clear\u003c/strong\u003e, and \u003cstrong\u003ewhether tests exist to verify completion\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-vibe-coding-projects-stall-in-the-later-stages\" class=\"anchor\" id=\"why-vibe-coding-projects-stall-in-the-later-stages\"\u003e\u003c/a\u003eWhy Vibe Coding Projects Stall in the Later Stages\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#a-finished-interface-is-not-the-same-as-a-finished-service\" class=\"anchor\" id=\"a-finished-interface-is-not-the-same-as-a-finished-service\"\u003e\u003c/a\u003eA finished interface is not the same as a finished service\u003c/h3\u003e\n\u003cp\u003eDuring 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.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAuthorization checks that ensure users can access only their own data\u003c/li\u003e\n\u003cli\u003eData handling that can withstand duplicate requests and network retries\u003c/li\u003e\n\u003cli\u003ePayment success, failure, cancellation, refunds, and webhook verification\u003c/li\u003e\n\u003cli\u003eInput validation and error recovery\u003c/li\u003e\n\u003cli\u003eDatabase changes and migration of existing data\u003c/li\u003e\n\u003cli\u003eSecret key management, logging, monitoring, backup, and recovery\u003c/li\u003e\n\u003cli\u003eAutomated tests that ensure core functionality continues to work after deployment\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ai-cannot-always-preserve-the-design-intent-of-the-entire-repository\" class=\"anchor\" id=\"ai-cannot-always-preserve-the-design-intent-of-the-entire-repository\"\u003e\u003c/a\u003eAI cannot always preserve the design intent of the entire repository\u003c/h3\u003e\n\u003cp\u003eAI 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.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eImplementing the same data query differently in server components, API routes, and browser code\u003c/li\u003e\n\u003cli\u003eManaging authentication state redundantly through cookies, client state, and external SDKs\u003c/li\u003e\n\u003cli\u003eWriting different versions of the same validation rule in the interface and on the server\u003c/li\u003e\n\u003cli\u003eAdding only exception handling or conditional statements without addressing the root cause of an error\u003c/li\u003e\n\u003cli\u003eRepeatedly creating similar functions and data models because an existing abstraction was not found\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWhen 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#understanding-the-reactnextjssupabase-combination-accurately\" class=\"anchor\" id=\"understanding-the-reactnextjssupabase-combination-accurately\"\u003e\u003c/a\u003eUnderstanding the React·Next.js·Supabase Combination Accurately\u003c/h2\u003e\n\u003cp\u003eIt 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTechnology\u003c/th\u003e\n\u003cth\u003ePrimary role\u003c/th\u003e\n\u003cth\u003eDecisions required in a project\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Technology\"\u003eReact\u003c/td\u003e\n\u003ctd data-label=\"Primary role\"\u003eLibrary for building user interfaces\u003c/td\u003e\n\u003ctd data-label=\"Decisions required in a project\"\u003eState management, data requests, component boundaries\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Technology\"\u003eNext.js\u003c/td\u003e\n\u003ctd data-label=\"Primary role\"\u003eReact-based full-stack web framework\u003c/td\u003e\n\u003ctd data-label=\"Decisions required in a project\"\u003eRendering approach, server·client boundaries, caching and API structure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Technology\"\u003eSupabase\u003c/td\u003e\n\u003ctd data-label=\"Primary role\"\u003eBackend platform providing PostgreSQL, authentication, storage, and more\u003c/td\u003e\n\u003ctd data-label=\"Decisions required in a project\"\u003eAccess policies, data model, session handling, service privileges\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Technology\"\u003eRuby on Rails\u003c/td\u003e\n\u003ctd data-label=\"Primary role\"\u003eServer-centered, integrated web application framework\u003c/td\u003e\n\u003ctd data-label=\"Decisions required in a project\"\u003eModels, controllers, jobs, mail, and deployment configuration within Rails conventions\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eNext.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 \u003cstrong\u003ewhere final responsibility for permissions and business rules lies\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eFor 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-ruby-on-rails-can-be-an-alternative\" class=\"anchor\" id=\"why-ruby-on-rails-can-be-an-alternative\"\u003e\u003c/a\u003eWhy Ruby on Rails Can Be an Alternative\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#it-reduces-choices-through-convention-over-configuration\" class=\"anchor\" id=\"it-reduces-choices-through-convention-over-configuration\"\u003e\u003c/a\u003eIt reduces choices through convention over configuration\u003c/h3\u003e\n\u003cp\u003eConvention 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.\u003c/p\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#it-handles-common-web-service-functionality-within-one-system\" class=\"anchor\" id=\"it-handles-common-web-service-functionality-within-one-system\"\u003e\u003c/a\u003eIt handles common web service functionality within one system\u003c/h3\u003e\n\u003cp\u003eRails 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.\u003c/p\u003e\n\u003cp\u003eHowever, it also has clear limitations.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePayment processing still requires an external payment provider such as Stripe.\u003c/li\u003e\n\u003cli\u003eAn admin page is not automatically completed to fit every requirement.\u003c/li\u003e\n\u003cli\u003eEven if authentication features are generated or configured with a library, authorization design and security review remain separate tasks.\u003c/li\u003e\n\u003cli\u003eComplex real-time interfaces or independent mobile APIs require additional design.\u003c/li\u003e\n\u003cli\u003eTeams without Rails experience will incur training and hiring costs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTherefore, Rails is not a tool that makes AI solve every problem; it is \u003cstrong\u003ean option that narrows the default paths AI and people must follow\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#what-can-be-solved-in-4-hours\" class=\"anchor\" id=\"what-can-be-solved-in-4-hours\"\u003e\u003c/a\u003eWhat Can Be Solved in 4 Hours\u003c/h2\u003e\n\u003cp\u003eThere 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.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIdentify the current structure and points of failure.\u003c/li\u003e\n\u003cli\u003eChoose between maintenance and reimplementation.\u003c/li\u003e\n\u003cli\u003eMake one critical user flow work.\u003c/li\u003e\n\u003cli\u003eCreate a new, testable baseline.\u003c/li\u003e\n\u003cli\u003eDeploy to a staging environment if possible.\u003c/li\u003e\n\u003cli\u003eDocument remaining risks and follow-up tasks.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#conditions-that-make-reimplementation-in-4-hours-possible\" class=\"anchor\" id=\"conditions-that-make-reimplementation-in-4-hours-possible\"\u003e\u003c/a\u003eConditions That Make Reimplementation in 4 Hours Possible\u003c/h3\u003e\n\u003cp\u003eThe more of the following conditions are met, the more feasible a short reimplementation becomes.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eThe required screens and user flows have already been finalized.\u003c/li\u003e\n\u003cli\u003eThe core data fields and relationships have been defined.\u003c/li\u003e\n\u003cli\u003eExisting screens can be referenced without reopening design discussions.\u003c/li\u003e\n\u003cli\u003eThe repository, domain, deployment environment, and external service accounts are immediately accessible.\u003c/li\u003e\n\u003cli\u003eMigration of existing data can be omitted, or only a small sample needs to be moved.\u003c/li\u003e\n\u003cli\u003ePayments are limited to a narrow scope, such as the default successful flow in a sandbox.\u003c/li\u003e\n\u003cli\u003eSomeone who understands Rails and the deployment environment reviews the AI’s output.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#a-practical-4-hour-recovery-sprint\" class=\"anchor\" id=\"a-practical-4-hour-recovery-sprint\"\u003e\u003c/a\u003eA Practical 4-Hour Recovery Sprint\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTime\u003c/th\u003e\n\u003cth\u003eTask\u003c/th\u003e\n\u003cth\u003eMinimum deliverable\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e0:00~0:30\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003ePreserve the repository and production state, investigate the technology stack\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eBackup, component inventory, check for exposed secrets\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e0:30~1:00\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003eFinalize the core flow and data model, decide whether to repair or reimplement\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eOne-sentence scope, completion criteria, risk list\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e1:00~2:00\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003eEstablish a Rails baseline or make structural changes to the existing project\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eRunnable app, data model, authentication skeleton\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e2:00~3:15\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003eImplement the core user flow vertically\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eOne flow connected from interface to data storage, with tests\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e3:15~3:45\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003eConfigure minimum external integrations and deploy to staging\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eSandbox integration, deployment URL, environment variable configuration\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Time\"\u003e3:45~4:00\u003c/td\u003e\n\u003ctd data-label=\"Task\"\u003ePerform smoke tests and handoff\u003c/td\u003e\n\u003ctd data-label=\"Minimum deliverable\"\u003eSuccess·failure results, incomplete items, order of next tasks\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-1-preserve-the-original\" class=\"anchor\" id=\"step-1-preserve-the-original\"\u003e\u003c/a\u003eStep 1: Preserve the original\u003c/h3\u003e\n\u003cp\u003eBefore 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-2-investigate-the-technology-stack-with-evidence\" class=\"anchor\" id=\"step-2-investigate-the-technology-stack-with-evidence\"\u003e\u003c/a\u003eStep 2: Investigate the technology stack with evidence\u003c/h3\u003e\n\u003cp\u003eDo not simply ask AI to guess the technology stack. Require it to inspect the following materials.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eManifest and lock files recording packages and versions\u003c/li\u003e\n\u003cli\u003eDatabase schemas and migrations\u003c/li\u003e\n\u003cli\u003eFiles that handle authentication and sessions\u003c/li\u003e\n\u003cli\u003eAPI routes and server functions\u003c/li\u003e\n\u003cli\u003eDeployment settings, environment variable names, and external service SDKs\u003c/li\u003e\n\u003cli\u003eAutomated tests and continuous integration settings\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAn example request is as follows.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eRead 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.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-3-choose-only-one-core-vertical-flow\" class=\"anchor\" id=\"step-3-choose-only-one-core-vertical-flow\"\u003e\u003c/a\u003eStep 3: Choose only one core vertical flow\u003c/h3\u003e\n\u003cp\u003eA vertical flow is one complete path connecting the interface to server logic and data storage. Examples include the following.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSign up → log in → view profile\u003c/li\u003e\n\u003cli\u003eSelect product → create order → approve payment in sandbox\u003c/li\u003e\n\u003cli\u003eAdmin login → create post → display on public page\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRather than building multiple screens at once, validating one core flow under success, unauthorized, and invalid-input conditions reveals structural risks more quickly.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-4-fix-the-completion-criteria-in-tests\" class=\"anchor\" id=\"step-4-fix-the-completion-criteria-in-tests\"\u003e\u003c/a\u003eStep 4: Fix the completion criteria in tests\u003c/h3\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA valid user can complete the task.\u003c/li\u003e\n\u003cli\u003eA user who is not logged in cannot access protected data.\u003c/li\u003e\n\u003cli\u003eEntering another user’s identifier does not grant access to that user’s data.\u003c/li\u003e\n\u003cli\u003eInvalid input is not saved and returns an understandable error.\u003c/li\u003e\n\u003cli\u003eRepeating the same payment or write request does not result in duplicate processing.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-5-deploy-only-to-staging\" class=\"anchor\" id=\"step-5-deploy-only-to-staging\"\u003e\u003c/a\u003eStep 5: Deploy only to staging\u003c/h3\u003e\n\u003cp\u003eIt 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#criteria-for-deciding-whether-to-fix-or-rebuild-an-existing-project\" class=\"anchor\" id=\"criteria-for-deciding-whether-to-fix-or-rebuild-an-existing-project\"\u003e\u003c/a\u003eCriteria for Deciding Whether to Fix or Rebuild an Existing Project\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituation\u003c/th\u003e\n\u003cth\u003eKeep·repair the existing structure\u003c/th\u003e\n\u003cth\u003eConsider reimplementation with Rails or another option\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eCore features and tests\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003eMost features work and tests exist\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eEven core flows repeatedly break\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eData\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003eThere is substantial production data, and migration risk is high\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eThere is no data, or the migration scope is small\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eStructure\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003eResponsibility boundaries and patterns are generally consistent\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eThe same functionality is duplicated across multiple layers\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eFrontend requirements\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003eComplex interactions and existing React assets are important\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eServer-centered CRUD and business workflows are central\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eTeam capabilities\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003ePersonnel are available to operate the current stack\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eRails conventions better fit the team’s way of working\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eExternal integrations\u003c/td\u003e\n\u003ctd data-label=\"Keep·repair the existing structure\"\u003eMany stable integrations are already in production\u003c/td\u003e\n\u003ctd data-label=\"Consider reimplementation with Rails or another option\"\u003eIntegrations are in an early stage or can be replaced\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#items-to-check-separately-before-launch\" class=\"anchor\" id=\"items-to-check-separately-before-launch\"\u003e\u003c/a\u003eItems to Check Separately Before Launch\u003c/h2\u003e\n\u003cp\u003eEven after a 4-hour baseline has been created, the following items may remain.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eReview of the authorization model and Rails security settings\u003c/li\u003e\n\u003cli\u003ePayment webhook signatures, duplicate prevention, cancellation, and refund handling\u003c/li\u003e\n\u003cli\u003eProduction data migration and verification of record counts·totals\u003c/li\u003e\n\u003cli\u003eDatabase backups and actual restoration testing\u003c/li\u003e\n\u003cli\u003eError tracking, log retention, and availability monitoring\u003c/li\u003e\n\u003cli\u003eLoad testing and cost estimation\u003c/li\u003e\n\u003cli\u003ePrivacy processing, terms of service, and related legal review\u003c/li\u003e\n\u003cli\u003eAccessibility, browser, and mobile environment checks\u003c/li\u003e\n\u003cli\u003eRollback procedures and designation of responsible personnel for incidents\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eLate-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.\u003c/p\u003e\n\u003cp\u003eRuby 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 \u003cstrong\u003enot as time to build a finished product, but as time to validate the structure and create a recoverable baseline\u003c/strong\u003e.\u003c/p\u003e\n","tags":["AI Coding","Vibe Coding","Ruby on Rails","Web Development","Project Recovery"],"faqs":[{"question":"Why do vibe coding projects start out fast but slow down in the later stages?","answer":"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."},{"question":"Does using React, Next.js, and Supabase inevitably result in spaghetti code?","answer":"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."},{"question":"Does switching to Ruby on Rails eliminate the need for all external services?","answer":"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."},{"question":"Can an entire app really be rebuilt in 4 hours?","answer":"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."},{"question":"What are the signs that existing code should be discarded and rewritten?","answer":"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."},{"question":"How should I have AI investigate the current project's technology stack?","answer":"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."},{"question":"What should be implemented first in a 4-hour recovery effort?","answer":"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."},{"question":"Does using Rails automatically resolve security issues?","answer":"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":[{"url":"https://react.dev/learn","title":"React Learn","type":"source"},{"url":"https://nextjs.org/docs","title":"Next.js Documentation","type":"source"},{"url":"https://supabase.com/docs","title":"Supabase Documentation","type":"source"},{"url":"https://rubyonrails.org/doctrine","title":"The Rails Doctrine","type":"source"},{"url":"https://guides.rubyonrails.org/","title":"Ruby on Rails Guides","type":"source"},{"url":"https://guides.rubyonrails.org/active_job_basics.html","title":"Active Job Basics","type":"source"},{"url":"https://guides.rubyonrails.org/action_mailer_basics.html","title":"Action Mailer Basics","type":"source"},{"url":"https://guides.rubyonrails.org/action_cable_overview.html","title":"Action Cable Overview","type":"source"},{"url":"https://guides.rubyonrails.org/security.html","title":"Ruby on Rails Security Guide","type":"source"},{"url":"https://guides.rubyonrails.org/testing.html","title":"A Guide to Testing Rails Applications","type":"source"}],"images":[{"id":359,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI0OSwicHVyIjoiYmxvYl9pZCJ9fQ==--671c6671ab2b4dd55a12c8db4a32cd95021e1402/ai-ff797ac5.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"얽힌 시스템 연결망과 정돈된 계층 구조 사이에 서 있는 개발자","caption":"복잡하게 얽힌 프로젝트를 명확한 계층 구조로 재정비하는 과정을 보여준다.","description":null},"en":{"alt":"Developer standing between tangled system connections and an orderly layered architecture","caption":"The illustration shows a tangled project being reorganized into a clear layered structure.","description":null},"ja":{"alt":"絡み合うシステム接続と整然とした階層構造の間に立つ開発者","caption":"複雑に絡んだプロジェクトを明確な階層構造へ整理する過程を表している。","description":null},"es":{"alt":"Desarrollador entre conexiones de sistema enredadas y una arquitectura ordenada por capas","caption":"La ilustración muestra un proyecto enredado que se reorganiza en una estructura clara por capas.","description":null},"id":{"alt":"Pengembang berdiri di antara koneksi sistem kusut dan arsitektur berlapis yang rapi","caption":"Ilustrasi ini menunjukkan proyek yang kusut sedang ditata ulang menjadi struktur berlapis yang jelas.","description":null},"pt":{"alt":"Desenvolvedor entre conexões de sistema emaranhadas e uma arquitetura organizada em camadas","caption":"A ilustração mostra um projeto emaranhado sendo reorganizado em uma estrutura clara de camadas.","description":null},"zh-hant":{"alt":"開發者站在糾結的系統連線與井然有序的分層架構之間","caption":"插圖呈現將混亂糾結的專案重新整理為清晰分層架構的過程。","description":null},"de":{"alt":"Entwickler zwischen verworrenen Systemverbindungen und einer geordneten Schichtenarchitektur","caption":"Die Illustration zeigt, wie ein verworrenes Projekt in eine klare Schichtenstruktur überführt wird.","description":null}}},{"id":360,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--dd1b9b18b3b924f01625710e0b4bafd8fbbd0002/ai-74d32191.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"무너진 절벽과 견고한 플랫폼 사이의 다리를 수리하는 개발자들과 보안·배포 아이콘","caption":"개발자들이 불안정한 프로젝트 구조를 보강해 안정적인 시스템으로 복구하는 과정을 보여준다.","description":null},"en":{"alt":"Developers repairing a bridge between a crumbling cliff and a stable platform, with security and deployment icons","caption":"Developers reinforce a fragile project structure to restore it as a stable system.","description":null},"ja":{"alt":"崩れた崖と安定した基盤を結ぶ橋を修復する開発者と、セキュリティやデプロイのアイコン","caption":"開発者が不安定なプロジェクト構造を補強し、安定したシステムへ復旧する過程を表している。","description":null},"es":{"alt":"Desarrolladores reparan un puente entre un terreno agrietado y una plataforma estable con iconos tecnológicos","caption":"Los desarrolladores refuerzan una estructura frágil para recuperar un sistema estable.","description":null},"id":{"alt":"Pengembang memperbaiki jembatan antara tebing retak dan platform kokoh dengan ikon keamanan dan deployment","caption":"Para pengembang memperkuat struktur proyek yang rapuh untuk memulihkan sistem yang stabil.","description":null},"pt":{"alt":"Desenvolvedores consertam ponte entre penhasco rachado e plataforma estável, cercados por ícones de tecnologia","caption":"Desenvolvedores reforçam uma estrutura frágil para recuperar um sistema estável.","description":null},"zh-hant":{"alt":"開發人員修復連接崩裂懸崖與穩固平台的橋梁，周圍有安全與部署圖示","caption":"開發人員加固脆弱的專案結構，使其恢復為穩定的系統。","description":null},"de":{"alt":"Entwickler reparieren eine Brücke zwischen brüchiger Klippe und stabiler Plattform, umgeben von Technik-Symbolen","caption":"Entwickler verstärken eine fragile Projektstruktur und stellen ein stabiles System wieder her.","description":null}}}],"published_at":"2026-07-30T13:43:49+09:00","updated_at":"2026-07-30T13:43:49+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/vibe-coding-project-architecture-and-four-hour-rescue-sprint"}