Guide
How to Vibe Code with Claude: A Method That Survives Week Two
Every Claude Code session starts with an empty context. Whatever is not written down in the repository, the agent decides again from scratch, and it decides a little differently each time.
Most posts on how to vibe code with claude describe the first afternoon: open Claude Code in a folder, describe the app, approve what it proposes, click around, ask for changes. That part works. The trouble shows up around the third day, when the app has a login, a few screens and a database, and each new request breaks something an earlier one built.
This page is the method for the days after that. It is specific to Claude Code, because it is mostly about how that tool remembers, plans, asks permission and runs out of room.
One caveat first. If you want a single-screen prototype tonight and have no wish to keep the code, a prompt-to-app builder such as Lovable or Bolt gets you a link faster, with hosting included. Claude Code is the better choice when the code should live in your own folder and the app is meant to last.
Why day three is where it goes wrong
Claude Code works in a context window: your messages, every file it reads and every command output it sees all go into one space. Anthropic's own guidance says the window fills up fast and quality drops as it fills, with earlier instructions getting lost first. A new session starts clean, which fixes the clutter and also wipes whatever you agreed on yesterday.
In an empty folder, that means the agent has nothing to copy. On Monday it puts data access in one place. On Wednesday, in a fresh session, it reads three files, infers a slightly different layout, and builds the next feature that way. Both versions run, and the next session now has two patterns to choose from.
Failure modes to watch for
A test gets fixed by being deleted
You say the tests fail. The agent makes them pass by removing the assertion, skipping the test, or loosening the expected value. The summary says all tests pass, and it is true. Ask what changed in the test files every time a red run turns green.
A second auth system appears
You ask for an invite link or a password reset. The session did not read the existing login code, so it writes its own token check next to it. Now two pieces of code decide who is signed in, and only one of them gets your later fixes.
A secret lands in client code
An API key is pasted into a frontend file to make a call work. It works. It also ships to every visitor's browser. Anything secret belongs in a server-side environment file that is not committed.
None of these look like bugs in the moment. Each one makes the thing you asked for work.
The method, as Claude Code actually works
One feature, start to finish
Write down what is already decided
CLAUDE.md is the file Claude Code reads at the start of every session, and the /init command drafts one from the folder. Keep it short: how to run the app and the tests, what must not be touched. Longer conventions go in .claude/rules, where a paths field makes a rule load only when the agent touches matching files.
Plan before any file changes
In plan mode Claude reads the code and proposes what it will do without editing anything. Read the plan even if you cannot read code. Look for surprises: a new library, a new folder, a second way of doing something you already have.
One feature per session
Approve the plan, let it build that one thing, then start a fresh conversation with /clear before the next. If you have corrected the same mistake twice, clear and restate the request. A thread of failed attempts makes the next one worse.
Make it prove the work
Tell it to run the typecheck and the tests and show the output, not report on it. Claude stops when the work looks done, so give it a check that can fail.
Commit when it works
Claude Code keeps checkpoints you can rewind to, but they only cover edits made through its own file tools, not what a shell command changed. Git is the real undo. Ask it to commit after every working step.
Permission prompts are a review step, until they are not. Depending on the permission mode, Claude Code asks before it edits files or runs shell commands, while reading files needs no approval. After the tenth prompt most people approve without reading. Allow the boring commands once (the test runner, the linter) so the prompts that remain are the ones worth a look: deleting files, installing packages, anything touching a database.
Instructions are advice, not enforcement. Anthropic's docs say Claude treats memory files as context and not as
enforced configuration. A line in CLAUDE.md saying "do not delete tests" lowers the odds. A typecheck and a test suite
that the agent has to run are what catch the miss.
Skills and MCP servers extend the same idea. A skill is a folder with a SKILL.md that Claude loads only when the task
matches, so a long procedure costs no context until it is needed. An MCP server gives the agent a tool for something it
would otherwise guess at.
Checking work you cannot read
You can review an agent without reading code well. These checks produce yes or no answers.
Before you accept a change
- Typecheck and tests ran, and you saw the outputAsk for the command and its result pasted in, with the count of passing tests. A count that went down is a deleted test.
- You asked for a diff summary by fileWhich files changed, which were created, which were deleted, one line each. A file you did not expect is the question to ask about.
- You clicked through it signed out and as a second userMost missing permission checks show up the moment a different account opens the same URL.
- You searched the frontend for anything that looks like a keyAsk the agent to list every place a secret is read and confirm each one runs on the server.
These only work if the project has a typecheck and tests to run. An empty folder has neither until someone writes them.
What to start from instead of an empty folder
Claude copies what it finds. If the repository has one way to write a route, one place for data access and one auth system, the plan it proposes follows them, and a wrong turn fails a check instead of quietly becoming the second way.
This is the part we make. Hype Stack is a full-stack TypeScript codebase (React on the front, Hono and Prisma on Postgres behind it) that you scaffold with a CLI and own as source. For this method, three things in it matter.
The conventions are already written for Claude Code. Pick Claude Code as your editor during create and the project
gets its rules as .claude/rules/*.md, with the scoped ones carrying paths frontmatter so a backend rule loads only
on backend files. They cover error handling, route validation, folder layout, data fetching and testing.
Skills come installed. create pulls ten skills into .agents/skills and links .claude/skills to the same
folder. One of them, grill-with-docs, checks a plan against the docs before building. Another, teach, explains the
change it made, which is useful when you cannot read the diff yourself.
The MCP server replaces the riskiest prompts. "Add login" and "add payments" are the requests where an agent writing
from memory does the most damage. With our MCP server connected, Claude calls the real installer: add_packs copies a
pack's code into the project, and setup_project starts Docker and runs the migration, after asking you first. Install
it with npx @hype-stack/cli@latest mcp install, pick Claude Code, and approve the sign-in in the browser. It installs
globally, which is what lets the agent create a project from an empty folder, and you restart Claude Code once so it
reads the new config.
For most app ideas the template to start from is better-studio: sign-up, teams and Stripe subscriptions already exist,
so your first prompt can be about your product.
What is not in it: the agent and the product. We do not ship Claude Code or a prompt box, and you pay Anthropic for the model separately. Hosting is yours to arrange. The rules describe how this codebase is built, not what your app does, so the features that make it yours are still plans you read and checks you run. Types and tests narrow what can go wrong. They do not remove the review.
The sections below show the templates and the command that scaffolds one.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.