No Partial Deliveries
You ask for a complete authentication system, and AI says "let's start with a simple username/password login first and add OAuth later." Later never comes. This lesson uses two demos to see the full lifecycle of "ship a simple version first" and practice the right way to respond.
In practice, when AI says "let's do a simple version first," it's rarely about complexity. It wants to give you something that runs quickly in exchange for positive feedback. "Use a temporary solution first," "mock it for now," "just handle it simply" — these all follow the same pattern. Once you break this pattern, AI actually works harder to analyze the complete solution.
Click Play to watch how the "simple version first" login module becomes permanent technical debt over 90 days. The two numbers above will change in sync with the timeline.
Simple Version Launched
Username/password login is working. AI promises "we'll add OAuth later," and you think it sounds reasonable.
"Later" Never Came
New requirements keep coming; nobody goes back to add OAuth. Session, permissions, payments, and notifications — 4 modules now depend directly on the simple interface.
Becomes Permanent Technical Debt
When you finally try to complete it, the dependencies have calcified. 9 modules are coupled to the simple version; refactoring costs more than a rewrite. The simple version has become the permanent version.
AI proposes a phased plan. Your response determines the outcome 90 days later. Try both branches.
Prohibited Practices
No implementation simplification is permitted for any reason: "use a temporary solution first," "optimize later," "mock it for now," "handle it simply" — none of these are acceptable. AI is also prohibited from proactively planning phased delivery, MVP approaches, or "phase 1/2/3" structures. Every implementation must be complete, correct, and free of code debt.
Preferred Practices
Evaluating a feature requires answering just two things: what it takes to do it completely, and how complex it is. When it's genuinely too complex, explicitly list "what prerequisite decisions you need to make first," and return the choice to the human. If a known-flawed approach exists, give the correct version directly — don't build a makeshift solution first.
In large projects this rule may seem aggressive: when a feature genuinely requires 2000 lines of code, completing it in one shot isn't realistic. But the correct action still holds — let AI provide the complete solution and honest effort estimate, and let the human decide whether and how to split it. Splitting is a human decision; downgrading is AI taking matters into its own hands. That distinction is the core of this rule.
"Optimize it later" — later never comes. Take back the choice: AI is responsible for providing the complete solution and the honest cost; whether and how to split it is the human's call.