This chapter walks you through the 11 most costly mistakes beginners make with Claude Code, and how to avoid them. Each one comes from a real experience. Reading time: 10 minutes.
Mistake 1, not creating a CLAUDE.md
What happens: every session is inconsistent. Claude uses different conventions, drops files anywhere, picks random colors, forgets the business rules.
What to do instead: create the CLAUDE.md in the first hour of the project (see chapter 3). 30 minutes that save dozens.
Warning sign: if you catch yourself repeating "use the project palette" or
"files go in src/components/", your CLAUDE.md is incomplete.
Mistake 2, asking for everything at once
What happens: "Build me a complete project management app with auth, dashboard, billing, analytics, and an AI assistant" produces a superficial result, full of shortcuts, impossible to maintain.
What to do instead: break it down into features, one at a time, with a plan for each. Every feature gets delivered, tested, and committed before moving to the next.
Rule: if your request contains more than 3 "and"s, it's too big. Break it down.
Mistake 3, jumping in without a plan
What happens: Claude makes technical choices without asking you. After 30 minutes of coding, you find out it picked the wrong approach. Everything has to be redone.
What to do instead: 10 minutes of brainstorm + plan save 2 hours of rework. The ratio is unbeatable. See chapter 5.
Exception: simple bug fixes and cosmetic tweaks don't need a plan.
Mistake 4, blindly accepting the result
What happens: Claude can make subtle mistakes: a flipped condition, an unhandled edge case, a security issue. Without a test, those bugs land in production.
What to do instead: always test visually on localhost. Only you know if the UX matches your vision. Claude can't see your screen.
At a minimum, verify:
- Normal behavior works
- Error cases are handled (bad input, empty data)
- Responsive (mobile) works
- Copy is correct (accents, grammar)
Mistake 5, not iterating
What happens: you settle for a first draft that "works" instead of an excellent result. The perceived quality of your app suffers.
What to do instead: 2-3 iterations give an excellent result. The first draft is the structure, the iterations are the polish.
Typical iteration examples:
- "Increase the spacing, it's too cramped"
- "Add an animation when the data loads"
- "The error message is too technical, rephrase it for a non-developer"
Mistake 6, skipping the checks
What happens: you pile up invisible errors that blow up later. One bad type here, a broken import there, and suddenly your build stops compiling with 47 errors.
What to do instead: run typecheck + lint after every change. Non-negotiable. 5 seconds that save hours of debugging.
Tip: with a well-configured permissions file (chapter 9), Claude runs these checks automatically without asking.
Mistake 7, writing vague prompts
What happens: random output, frustration, 3-4 round-trips to get what you actually wanted.
What to do instead: see chapter 4. Short version: context + what + criteria + constraints. 30 seconds of phrasing saves 10 minutes of corrections.
Mistake 8, not saving memory
What happens: tomorrow, Claude has forgotten everything. It re-suggests approaches you already rejected. It repeats mistakes you already fixed. It wastes time rediscovering the context.
What to do instead: at the end of a productive session, say "Update the project memory." 30 seconds that make the difference. See chapter 10.
Mistake 9, doing everything sequentially
What happens: you lose time waiting for each task to finish when some could run in parallel.
What to do instead: spot independent tasks and say so explicitly.
"Run in parallel: the SQL migration, the UI component, and the unit tests. These 3 tasks are independent."
Claude spins up 3 agents at the same time instead of going one after the other. Gain: 3x faster.
When NOT to parallelize: when one task depends on another's output (e.g., TypeScript types depend on the SQL migration).
Mistake 10, ignoring context management
What happens: your conversation gets long, it passes 70-80% context. Claude forgets your conventions, repeats fixes you already made, makes inconsistent choices. You waste 20 minutes before realizing it's a context problem, not a logic one.
What to do instead: keep an eye on the context (via /context or the status line). /compact at 60%. /clear if you switch topics. /rewind (Esc Esc) if Claude goes off the rails, instead of trying to fix it in an already polluted context.
Warning sign: Claude starts "forgetting" rules it was respecting at the start of the session. That's the signal to compact.
Mistake 11, never running /review
What happens: "It works" doesn't mean "it's solid". Without a review you let security holes through (user data exposed), unhandled edge cases (what happens if the list is empty?), dead code that bloats the app.
What to do instead: run /review before every important commit. Like asking a colleague to re-read your work, a fresh pair of eyes catches what the author no longer sees.
Real example: on Panettone, a review caught sensitive data being logged to the console. Without the review, that data would have been visible in production.
Takeaway: these 11 mistakes are ranked by impact. Fix them in order.
CLAUDE.md is the most critical; context management and review are the most
underrated. Each one is easy to avoid once you know about it.