The Vibe-Coder Mindset — Iteration Over Perfection

End-of-lesson check

15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-vibecoder-ship-ship-ship

1. In AI-assisted building, what does the lesson identify as the scarcest resource?

   1. Perfect component libraries
   2. Code itself
   3. GPU compute time
   4. A real user

2. Why does the lesson recommend shipping something 'embarrassing' within 48 hours?

   1. Because AI cannot help with polished code
   2. Because embarrassing code runs faster on AI tools
   3. Because you learn more from real usage than from planning
   4. Because users prefer ugly interfaces

3. How many users does the lesson say can teach you approximately 80% of what you need to know?

   1. Five honest strangers
   2. Three developers
   3. Fifty polite friends
   4. One hundred random users

4. Which activity does the lesson specifically warn against doing before anyone has used your app?

   1. Writing any code at all
   2. Adding a login system
   3. Testing on your own phone
   4. Spending a week on the logo

5. What does the lesson say about arguing with your AI for an hour about component libraries?

   1. It wastes time better spent shipping
   2. It helps you learn the framework
   3. It produces cleaner code
   4. It impresses potential users

6. Based on the lesson, what is the 'vibe-coder' approach to launching a product?

   1. One big launch with many features
   2. Launch once and never update it
   3. Launch only when the code is perfect
   4. Many tiny launches over time

7. What does the lesson identify as the primary 'safety net' that enables fearless building?

   1. Detailed documentation
   2. Cloud backups
   3. Git history
   4. Comprehensive test suites

8. If you ship version 10 of your app and nobody cares, what does the lesson say the problem likely is?

   1. The execution quality is poor
   2. The idea itself is flawed
   3. The UI design needs work
   4. You didn't refactor enough

9. What does the lesson recommend doing on Friday of each week?

   1. Send the current build to three humans and watch them try it
   2. Write documentation
   3. Start building a new feature
   4. Refactor the code

10. How does the lesson describe the fundamental shift from the 'old way' to the 'vibe-coder way'?

    1. Code first, ask questions later
    2. Ship only on Fridays
    3. Prompt, ship, then listen, instead of design, spec, then build
    4. Plan more, build less

11. Why does the lesson say five honest strangers provide better feedback than fifty polite friends?

    1. Strangers use better devices
    2. Friends will steal your idea
    3. Strangers are more technically skilled
    4. Friends are too nice and won't give honest criticism

12. What does the lesson explicitly say NOT to do before you have users?

    1. Add a feature because it might be useful later
    2. Write tests
    3. Refactor your code
    4. Build anything at all

13. Which statement best captures the lesson's 'only playbook that compounds'?

    1. Build once, launch big
    2. Ship, learn, ship again
    3. Test everything twice
    4. Plan extensively, then execute perfectly

14. What does the lesson suggest about debating component libraries in AI-assisted building?

    1. It produces better user experience
    2. It's essential for long-term success
    3. It should be avoided because shipping matters more
    4. It saves time in the long run

15. Why can a vibe-coder afford to 'fear' breaking things less than traditional developers?

    1. Git history lets you undo any change
    2. AI-written code never breaks
    3. They don't care about bugs
    4. They have better hardware