The core loop

1. Describe — say what you want in plain English, focused on behavior, not implementation
2. Plan — ask for a plan before any code gets written, and actually read it
3. Execute — approve the plan, let it build
4. Verify — click through it yourself like a real user, don't take "done" on faith
5. Refine — if it's not right, describe more precisely and repeat

Every level in the 100% vibe coding path is a different angle on this same five-step loop. There's no separate "then you learn to code" phase — the loop itself is the method.

Weak descriptions vs. strong ones

The single highest-leverage skill in vibe coding is writing the request, not reading the result.

Weak:   "Make a login thing."
Strong: "Add an email/password login form
         above the fold. Show an error if
         the password is wrong. Redirect
         to /dashboard on success."

Weak:   "Fix the button."
Strong: "The delete button works once, but
         clicking it a second time does
         nothing. Find out why."

What it's genuinely good for

• Prototypes and proof-of-concepts you want to see fast
• Personal tools and internal scripts nobody else depends on
• A first draft of almost anything, including code you'll later read and learn from
• Small, well-scoped client projects where you're honest about the method

What it's not good for yet

• Anything handling real payment or personal data at scale, without someone who can read the security-relevant code
• Production systems you're the only one responsible for fixing under time pressure
• Long-lived codebases meant to survive years and multiple contributors
• The moment Claude Code is wrong and you can't independently tell — this is the actual limit, not a hypothetical one

What "open source" actually means

• The source code is public — anyone can read exactly how it works, not just use a black box
• A license explicitly grants you the legal right to use, modify, and (usually) redistribute it
• Development often happens in the open too — you can watch decisions get made, not just receive finished releases
• "Free" refers to freedom to use and modify, not always to price — though almost everything in this roadmap is also free of charge

Why it's genuinely powerful

• You're standing on millions of hours of other people's work for free — a solo learner can ship things that used to need a whole team
• Code that thousands of projects depend on gets far more scrutiny than anything you'd write alone — bugs and security holes get found faster
• You can read the actual source when documentation falls short, instead of guessing
• It compounds: this roadmap itself only exists because Next.js, Vercel's tooling, and dozens of other open projects exist to build on

Licenses — the part beginners skip, and shouldn't

Not all open source licenses let you do the same things. Two categories cover almost everything you'll encounter:

Permissive (MIT, Apache-2.0, BSD)
→ Use it in a commercial, closed-source
  product with almost no restrictions.
  Most JS/npm packages use this.

Copyleft (GPL, AGPL)
→ If you distribute software built on
  GPL code, you may have to open-source
  YOUR code too. AGPL extends this to
  software only used over a network.

Check a package's license before depending on it for anything commercial — it's usually one line in its README or a LICENSE file.

How to evaluate a package before depending on it

• Check the license first (see above) — this can be a genuine legal blocker, not just a preference
• Look at recent commit/release activity — an unmaintained package is a future liability
• Check weekly downloads and open issues on npmjs.com as a rough health signal, not gospel
• Read the README before installing — if it can't explain itself clearly, that's a signal too
• Remember: every dependency you add is something you're now trusting to keep working, stay secure, and not disappear

How to actually use one, day to day

npm install package-name
# then read its README for the import syntax

import { thing } from "package-name";

• Claude Code can usually tell you what a package does and how to use it — ask it before digging through docs yourself
• Pin versions in production (avoid blindly auto-updating major versions) — a breaking change in a dependency shouldn't break your app without warning
• If something's broken or confusing, check the project's GitHub Issues — someone has almost always hit it before you

Giving back, even as a complete beginner

• Star a repo you actually use — it's a real, if small, signal that helps maintainers gauge usage
• File a clear bug report when you find one — a good bug report is a genuine contribution, no code required
• Read a project's CONTRIBUTING.md before your first pull request — most projects have specific expectations
• Sponsor a maintainer of a tool you rely on, if you're able to — most open source maintainers are unpaid volunteers