Your First Project in Claude Code.
Zero to shipping in one session.
It is not a chat box with a code plugin. It is an agent that operates directly in your codebase, reading files, running commands, editing code, and reasoning about architecture. The first session is either disorienting or transformative. This guide makes it the second.
Ricardo Ramirez
Founder, Sprintt · Product Builder
TL;DR · 4 takeaways
- 01
Context first, tasks second. CLAUDE.md is your most important file.
- 02
Work conversationally. Review diffs. Push back when wrong.
- 03
Use ! to run shell commands inline. Use the review loop.
- 04
By hour two, you should have shipped something real.
What you actually need.
- 01
An Anthropic account
Install the CLI. The CLI is more powerful than the web UI for real work. Web UI is fine for exploration.
- 02
Node.js installed
Run node --version to confirm. If empty, grab it from nodejs.org. Nothing about this step is subtle.
- 03
A real project directory
Even if empty. Claude Code thinks in terms of a project, not a chat thread. Give it somewhere to live.
- 04
One sentence of intent
Not a spec. A sentence. "I want a Next.js portfolio with a contact form." That is enough to start. The rest emerges.
Context first. Tasks second.
The most important thing to understand: Claude Code reads your project context automatically. It knows what files exist, what stack you are on, what conventions you have already set. You do not need to paste code in.
Start with context, not requests. Tell it what you are trying to do and the constraints that matter. A CLAUDE.md file in your project root is the single highest-leverage move you can make. It is read at the start of every session, forever.
# Project
Portfolio site for Jane Doe.
## Stack
- Next.js 15 (App Router), TypeScript, Tailwind v4
- Framer Motion for entrance animations only
- Resend for contact form
## Conventions
- Named exports, PascalCase components
- No inline styles. Tailwind only.
- Keep files under 200 lines.
- Never use em-dashes in copy.
## Commands
- npm run dev (localhost:3000)
- npm run build
- npm run lintHow to work with it, not just use it.
The most common mistake new users make is treating Claude Code like a code generator. You paste a request, it produces code, you copy the output somewhere. That workflow misses the point entirely.
Claude Code is a collaborator. It maintains context across the whole session. Ask it to build something, review what it built, push back on what you do not like, ask it to explain decisions you do not understand. The back-and-forth is where the value is.
- 01
Read before edit
Claude does this automatically. You can still ask it to confirm its understanding first. One sentence of reflection often prevents five minutes of undo.
- 02
Ask for reasoning before accepting architecture
"Before you implement, tell me why this shape over two alternatives." Forces explicit tradeoffs. You catch bad defaults early.
- 03
Describe what is wrong specifically
Not "this does not work." Rather: "the form submits twice on double-click. The handler is not debounced and does not disable the button on submit."
- 04
Run commands inline
Use shell execution to test as you go. npm run dev. npm test. Fast feedback loops beat careful code review for small changes.
- 05
Review diffs
Always. Speed is intoxicating. Do not let speed become a reason to approve changes you did not read.
What to expect.
First sessions are often disorienting. The tool moves fast and makes decisions without always asking for approval. That is by design. It is trying to be useful, not cautious. You will develop a feel for when to let it run and when to pause and ask for an explanation.
Expect to course-correct. The agent will occasionally make assumptions you disagree with. This is normal. Correct it clearly and specifically. It will adjust.
By the end of a focused two-hour session, most people have shipped something real. That pace is the point.
If you are moving slower than that, the bottleneck is usually prompt clarity or scope management, not the tool.
Common pitfalls, and the fix.
- 01
Vague first message
"Build me a site" gets you a generic site. Specify stack, intent, and constraints. Write CLAUDE.md before the first task.
- 02
Accepting all file edits blind
The speed is a trap. Read the diff. You are the PM, engineer, and QA in one. Review is not optional.
- 03
Letting scope creep in real time
Claude will happily implement everything you mention. If you say "also, while you're there…" three times, you have a bloated commit. Save those for new sessions.
- 04
Never using memory
Persistent memory exists for a reason. Teach it preferences once, not every session. That is the compounding return.
The first-week milestone.
You are doing this right if, one week in, all of the following are true:
- 01
You have shipped something real
Not a demo. A deployed thing. Even small. Even ugly. Real.
- 02
Your CLAUDE.md is longer than when you started
You have encoded preferences. The next session begins better than the last one ended.
- 03
You have pushed back at least five times
Argued a decision. Rejected a default. That muscle is the one that matters.
- 04
You have a rhythm
You know when to let it run, when to pause, when to review, when to commit. The tool feels like yours.
If this was useful, pass it on.
Ricardo Ramirez
Product Builder and Founder of Sprintt. Advising product teams on AI strategy and operating models.