Your App Will Fail, If You Do This

Key Concepts

Vibe Coding: Building applications using natural human language prompts with AI.
Bulky/Bloat App: An application suffering from excessive code, often due to dead code or files that are too large, leading to poor performance and maintainability.
Dead Code: Sections of source code that are executed but whose results are never used in any other computation.
Refactoring: The process of restructuring existing computer code without changing its external behavior, done to improve non-functional attributes of the software (e.g., readability, maintainability, complexity).
Component: A self-contained, reusable piece of code that performs a specific function within an application (e.g., a chat box).
Tech Stack: The set of technologies an organization uses to build and run an application (e.g., React and TypeScript).
Ask, Plan, Execute (APE) Framework: A methodology for using AI in development, involving asking the AI for suggestions, having it plan the changes, and then executing those changes.
Composer 1: An AI model specifically highlighted for its speed and code quality in the execution phase, particularly when guided by a detailed plan.
4.5 (AI Model): An AI model recommended for its strong reasoning capabilities, making it suitable for the planning phase of refactoring.
Sonnet (AI Model): An AI model mentioned for its intelligent pre-planning questions.
GitHub Branching: Using separate versions of a codebase (e.g., a "YOLO branch") to experiment with changes without affecting the main development line.
Debugging: The process of identifying and removing errors from computer hardware or software.

The Critical Need for Code Refactoring in AI-Driven Development

The video emphasizes a crucial aspect for developing robust applications, especially when leveraging AI for coding: preventing apps from becoming "bulky, bloat, undesirable" and prone to breaking. While "vibe coding" allows building apps with human language, the output from AI models can often lead to poor coding practices, specifically generating excessively large files. The presenter, Corbin, highlights that failing to address this issue is "shooting yourself in the foot" if you intend to launch a real, money-making application.

Specific Details & Consequences:

An example cited is the "studio editor app" page, which initially grew to over 4,000 lines of code in a single file due to AI generation. This was later reduced to 859 lines and then further to 459 lines through refactoring.
Such large files create significant challenges for debugging. If a small component (e.g., a chat box) breaks, a developer would have to "scour through 4,000 lines of code" to find the bug. Refactoring can reduce the relevant code to "maybe 500 lines," making debugging much more efficient.

Identifying Overly Large Code Files

To proactively address the issue of bulky files, the video outlines a method for identifying them using an AI model.

Step-by-Step Process:

Select a High-Level AI Model: The presenter recommends using Composer 1 or 4.5 for this initial search.
Use "Ask Mode": Ensure the AI is in a mode where it can analyze the codebase.
Formulate the Prompt: "look at my entire repo and find the top five files with the most lines of code."
Analyze Results: The AI will scan the repository and list the largest files. The presenter's own studio editor app page, at 860 lines, was identified as the largest after initial cleaning, down from its original 4,000 lines.

Contextualizing File Size Guidelines:

For React and TypeScript projects, the presenter suggests an upper limit of 1,200-1,500 lines of code per file, with an ideal recommendation based on his "10 years of developing" experience being under 1,000 lines.
When asked, AI models typically suggest 300-400, maybe 500 lines for React and TypeScript. The presenter notes his personal preference for up to 1,000 lines is based on experience pushing limits.
General Advice: If you don't know the appropriate file size for your specific tech stack, ask the AI model directly: "hey based off my tech stack XYZ what is a good amount of lines for me?" If you don't even know your tech stack, ask the AI: "what is my tech stack?" followed by the file size question.

The Refactoring Methodology: Ask, Plan, Execute (APE)

Once an overly large file is identified, the video details a three-phase methodology for refactoring it using AI.

1. Ask Phase

Action: Copy the entire content of the large file into the AI chat.
Prompt: Ask the AI, "Can we refactor it more? What would you suggest?"
Model Choice: Use a strong reasoning model like 4.5 for this phase.

2. Plan Phase

The AI will analyze the code and propose a refactoring strategy. This typically involves breaking down the main component into smaller, logical units and placing them in dedicated folders such as utils, hooks, domain, features, or custom folders like tools (e.g., for prop eraser or remove background functionalities).
The AI will also estimate the reduction in lines of code (e.g., reducing the main component from 860 lines to 100 lines).

Crucial Advice: Incremental Refactoring:

Avoid Aggressive Refactoring: Do not attempt to refactor an extremely large file (e.g., 8,000 lines) down to a very small size (e.g., 100 lines) in a single step.
Step-by-Step Approach: Break down the refactoring into manageable chunks. For an 8,000-line file, first aim for 6,000 lines, then 3,000 lines, and so on.
Benefits: This allows for easier testing, ensures nothing is broken at each stage, and provides the ability to "roll back" if a step introduces issues.

Sonnet's Planning Questions: The presenter praises Sonnet for its intelligent pre-planning questions, which help define the scope and expectations of the refactoring:

"Which refactoring should I implement?" (Typically, choose "All seven" for comprehensive refactoring).
"Should I preserve all existing functionality as is?" (Always answer "Yes" to prevent breaking the app).
"Should we verify the refactoring works?" (The presenter prefers "manual testing").

3. Execute Phase

Model Choice: The presenter highly recommends Composer 1 for execution due to its "amazing at speed and code quality." However, Composer 1 "needs a plan" from a higher-level reasoning model (like 4.5). If Composer 1 is unavailable (e.g., only in Cursor), 4.5 is a good alternative for execution.
Process: The execution model follows the detailed plan generated in the previous phase, acting like a "robot" that reads and implements each step.
Development Environment: The presenter advises working in a separate "YOLO branch" on GitHub for experimental refactoring, allowing for breakage without impacting the main codebase.

Handling Errors During and After Execution

A significant part of the video addresses the inevitable occurrence of errors during the refactoring process, especially when using AI.

Errors During Execution:

It's common for errors to "randomly pop up and then go away" as the AI moves through and modifies files.
Key Takeaway: "Don't freak out." Let the AI complete its entire flow. The appearance of errors during this phase does not necessarily mean the process has failed.

Errors After Execution (App is Broken):

If the app is not working after the AI completes its refactoring, the solution is straightforward.
Action: Copy the error message from the console or developer tools.
Prompt: Paste the error into the AI agent and instruct it to fix the app (e.g., "Hey, composer, you did a great job, but you broke my app.").
Mindset: The presenter advocates for an "emotionless" reaction to errors in the age of AI. "Your reaction should be emotionless. I don't care. And the reason you don't care is because we have this AI model that can literally solve anything now. You just have to know how to use it."
Learning Opportunity: Even if you don't fully understand the error, "just read it." Errors typically reference the specific file and even the line number where they occurred. This practice, over time, compounds knowledge and allows developers to "do things within software development that you thought you would have never been able to do."

Refactoring Outcome and Best Practices

The video demonstrates a successful refactoring where the studio editor app file was reduced from 860 lines to 459 lines. While this wasn't the initial target of 100 lines, it represents a substantial improvement.

Best Practices:

Don't Overkill It: While further refactoring is possible, the presenter cautions against excessive optimization if the current state is already significantly improved and manageable.
Branching for Safety: Always use separate development branches (like a "YOLO branch") when performing significant refactoring to isolate changes and prevent disruption to the main project.

Conclusion: The Importance of Structured Code in AI-Driven Development

The core message is that while "vibe coding" empowers developers to build complex applications using natural language, it's imperative to integrate traditional software engineering best practices, particularly code refactoring. AI is a powerful tool that can generate code and even fix its own errors, but developers must guide it and understand the principles of good code structure. By actively managing file sizes, breaking down components, and adopting a systematic approach to refactoring, developers can ensure their AI-generated applications are not only functional but also maintainable, scalable, and robust, leading to long-term success. The continuous process of reading and understanding errors, even with AI assistance, is highlighted as a key pathway to compounding technical knowledge and becoming a more capable developer.