No Installment Delivery Accepted
Why AI loves to deliver "the simple version first," and why you must break this pattern
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “No Installment Delivery Accepted”?
Why AI loves to deliver "the simple version first," and why you must break this pattern
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
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.
Turn the feeling in “Motivation Analysis” into a judgment
“In practice, when AI says "let's do a simple version first," it's rarely about complexity.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “Click Play to watch how the "simple version first" login module becomes permanent technical debt over 90 days.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “"Optimize it later" — later never comes.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Motivation Analysis” to “Interactive Demo 1 · Technical Debt Timeline Player”
“Motivation Analysis” grounds the problem in “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," "…”. “Interactive Demo 1 · Technical Debt Timeline Player” then moves it toward “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”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Motivation Analysis”: 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," "…
- “Interactive Demo 1 · Technical Debt Timeline Player”: 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
- “The closing point”: "Follow the rules: give me the complete solution and an effort estimate. If it's genuinely too complex, list the prerequisite decisions I need to make first."
The final “The closing point” brings the discussion to “"Follow the rules: give me the complete solution and an effort estimate. If it's genuinely too complex, list the prerequisite decisions I need to make first."”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.