How to vibe code an app in 2026 with Claude Code

To vibe code an app with Claude Code, write a one-page spec, let the agent propose a stack that you score, and put your rules in AGENTS.md. Then build in small, plan-first steps, each saved in git and reviewed in a pull request, with data in Supabase behind tested Row Level Security and the app deployed on Vercel. Before launch, run a security checklist, make a passing smoke test the definition of "done", and keep the agent away from production.

That's the path of Vibe Coding 101, which builds DayBoard, a task list with live weather from Open-Meteo. (New to the term? Read what vibe coding is.) This guide uses Claude Code on your laptop. The same steps work with Codex, or with Grok Bot driving either CLI on its cloud computer, because your rules live in an AGENTS.md file that travels with the repo (how the agents differ).

The path on one page

Step 1: Install Claude Code and open three free accounts

Create a GitHub account with two-factor authentication on, then sign up for Vercel Hobby and Supabase Free with it. Install Node.js LTS, git and Claude Code (curl -fsSL https://claude.ai/install.sh | bash on macOS, Linux or WSL). Claude Code needs Claude Pro, Max, Team, Enterprise or Console, not the free plan (Anthropic). Pro is $20/month, or $17/month billed annually (checked 2026-10-20, Claude pricing).

Claude Code starts in auto mode, which "reduces permission prompts but does not guarantee safety" (Anthropic), so press Shift+Tab once for Manual while you learn. Then, from the lab-setup lesson (adapted):

Run `node --version` and `git --version`, and report your own name and version.
Create HELLO.md in this folder with those three versions. Do not create or
change any other file. Show me HELLO.md when you're done.

Check: three real version numbers, one file.

Step 2: Write a one-page spec with a "not doing" list

Anthropic recommends you "have Claude interview you first" and then "write a complete spec to SPEC.md" (best practices). The interview prompt from the spec lesson (adapted):

Before anyone writes code, interview me so we can write a one-page spec together.
- Do not write or change any code. The only file you may create is SPEC.md.
- Ask at most 3 questions at a time, then wait for my answers.
- Challenge my assumptions. If I add something that doesn't serve a job,
  ask whether it belongs under "Not doing".
- If I don't know an answer, put it under "Open questions". Don't guess.

Check: one page, every screen serves a job, personal data marked, at least three "not doing" items.

Step 3: Let the agent propose the stack, then score it

You set constraints, not frameworks. In plan mode, paste this from the stack lesson (adapted):

Read SPEC.md. This is a planning question: don't create, edit or install anything.
Propose 2–3 stack options. Each must deploy on Vercel, use Supabase for the
database and email sign-in, and have a server side for the weather call.
For each, give the current major version and two honest downsides.

Check: score each option on six points. The must-haves: it deploys on Vercel, Supabase has an official guide including server-side sign-in, and it has a server side. The course's examples use Next.js, but any option that scores well is fine. Record the pick in SPEC.md.

Step 4: Put your rules in AGENTS.md

Write five sections: stack, commands, conventions, never do, and definition of done. Then create a CLAUDE.md containing only @AGENTS.md, the pattern Anthropic documents for one file every tool shares (memory docs). Three of the seven never-do rules from the rules lesson:

1. Never commit secrets or .env* files. Never print a secret's value.
2. Never put a secret key in code that runs in the browser.
6. Never force-push, rewrite git history, or push unless I ask.

Check: in a fresh session, ask it to list the never-do rules "without opening any files". Remember that Claude treats these files "as context, not enforced configuration" (memory docs); later steps add the locks.

Step 5: Plan first, scaffold, then read the diff

Press Shift+Tab until you see ⏸ plan mode on, and build one small step at a time (prompting lesson). Anthropic's test: "If you could describe the diff in one sentence, skip the plan" (best practices). create-next-app refuses a folder that already holds your files, so the agent scaffolds into a temporary folder. From the scaffold lesson (adapted):

Scaffold DayBoard with Next.js. Follow AGENTS.md. Don't run git init.
1. Inside this folder, run:
   npx create-next-app@latest scaffold-tmp --yes --skip-install --disable-git
2. Delete scaffold-tmp/AGENTS.md, then move everything else into this
   folder. Never overwrite an existing file. If a name clashes, stop.

On 2026-10-23 that installed Next.js 16.4.3. Check: "Done" is a claim; the diff, terminal and browser console are the evidence. Review every change for scope, secrets, new libraries, it runs, it behaves.

Step 6: Call the outside API from your server, with a cache and a failure state

The weather card's constraints, from the live-weather lesson (adapted):

- The browser never calls Open-Meteo. It calls our own server route, and
  the server calls Open-Meteo.
- Round lat/lon to 2 decimals BEFORE the cache lookup. Refresh after
  15 minutes, expire after 30.
- 5-second timeout. On any non-200 answer (including 429), throw so
  nothing is cached, and have the route answer 502.

Check: point the API base URL at a wrong path. The card says "Weather unavailable right now" and tasks keep working. The free API is non-commercial only, with "Less than 10'000 API calls per day, 5'000 per hour and 600 per minute" (Open-Meteo terms).

Step 7: Save points, a secret-free push, one branch per task

Commit before and after every agent task, so git restore . undoes a bad one (save points lesson). Claude Code's checkpoints are no substitute: "This isn't a replacement for git" (Anthropic). Before the first push to a private repo, confirm .env.local is ignored and untracked (push lesson). Then add to AGENTS.md (adapted):

## Git workflow
- One branch per task. Never commit to main and never push to main.
- Never merge a pull request unless I ask. I review Files changed and I merge.

Check: you review each PR's Files changed tab, then squash and merge.

Step 8: Add Supabase with migrations, email sign-in and tested RLS

Supabase's own rule: "The golden rule: never change the remote database directly" (Supabase migrations). So the agent writes SQL files in supabase/migrations/, and you approve a dry run before each push to dayboard-dev (migrations lesson). Email sign-in on Next.js 16 uses proxy.ts: "The middleware file convention is deprecated and has been renamed to proxy" (Next.js). The server trusts getClaims(), never getSession() (sign-in lesson), and the built-in email sends 2 messages per hour, to your team only (Supabase).

Ship the RLS policies as a migration, wire tasks and the home city to the tables, then test. From the RLS lesson (adapted):

Give me two curl commands I can run myself, with placeholders for our
dayboard-dev project URL and publishable key, requesting all rows from
tasks and then profiles, sending only the publishable key. Don't run them.

Check: user B, in a private window, sees none of user A's tasks or city, and curl returns a permission error or []. Rows mean fail. More in Supabase RLS for vibe coders.

Step 9: Deploy on Vercel with variables per environment

You create dayboard-prod and push the migrations to it yourself. Import the repo into Vercel and set each variable twice: prod values for Production, dev values for Preview and Development (first-deploy lesson). Vercel's rule: "Scope each variable deliberately so preview builds and production don't read each other's values" (Vercel KB). NEXT_PUBLIC_ values are public and baked in at build time, so redeploy after every change (Next.js).

Every pushed branch gets a preview wired to dayboard-dev, and merging to main ships (previews lesson). Hobby allows 100 deployments per day (Vercel).

Check: sign in on the live URL, add a task, and confirm it landed in prod. If it breaks, see deploy errors agents get wrong.

Step 10: Harden it before launch

• Audit. The agent runs a report-only audit; you check the production rows yourself, such as custom SMTP and the RLS re-test on prod (checklist lesson; full list in Is vibe coding safe?).
• Smoke test. One Playwright test signs in, adds a task and checks the weather card (smoke test lesson).
• Away from prod. "Permission rules are enforced by Claude Code, not by the model" (permissions), so commit deny rules to .claude/settings.json. Supabase Free has no automatic backups (pricing), so you back up prod before each prod migration (production lesson).
• The bill. About $20 a month on setup A while learning, and about $105 a month in the course's estimate once you charge money (costs lesson; line by line in what it costs).

The rule that closes the loop, added to AGENTS.md:

- Run `npx playwright test` and paste its final lines word for word. A task
  is done only when every test passes, with nothing skipped.
- If a test fails, fix the app, not the test.

Check: the run's own output, not the agent's summary.

Step 11: Ship v1

The capstone asks for evidence on eight rubric rows, including sign-in for an address not on your Supabase team, the second-user test on production, a passing smoke test, and one feature of your own shipped through branch, PR, preview and merge. Then tag the release (adapted):

Switch to main and pull. Create an annotated tag v1.0.0 with the message
"DayBoard v1", push only that tag, then create a GitHub release from it.

Check: every rubric row has proof, and the URL works for a friend.

What Vibe Coding 101 has you do

• Set up Claude Code, Codex or Grok Bot, then write DayBoard's spec, stack decision and AGENTS.md.
• Build and review each feature in plan-first steps, merged through pull requests.
• Write migrations, add email sign-in, and attack your own RLS as a second user.
• Deploy with separate dev and prod databases, and roll back a bad merge.
• Audit security, write the smoke test, lock the agent out of production, price the app, and ship v1.

LearnOS keeps your notes and progress next to each lesson, and its Q&A answers with citations back to the course.

Start Vibe Coding 101 on LearnOS