Most People Use Claude Code Wrong

Claude Code Is Not About Prompting

Most people use Claude Code wrong.

They think the hard part is writing the perfect prompt.

It is not.

The hard part is knowing what context to give it, what constraints to set, what size change to ask for, and how to check if the work is actually correct.

That is the part most tutorials skip.

They tell you to “write clear prompts,” “use CLAUDE.md,” “ask it to plan first,” and “run tests.”

That advice is not wrong.

It is just incomplete.

It is like telling someone to “practice more” before a competition. Like yes, obviously. But that is not useful unless you explain what good practice actually looks like.

Claude Code is not magic.

It is also not just ChatGPT inside a terminal.

Claude Code is an agentic coding tool. It can read your codebase, edit files, run commands, use tools, and keep going until it thinks the task is finished. But that does not mean you should throw a giant feature request at it and hope it figures everything out.

That is how you get bad code.

Good Claude Code usage is not about one perfect prompt.

Good Claude Code usage is about running it like a system.

My framework for that system is simple:

Context. Constraint. Change. Check.

That is how I would think about Claude Code if I were using it to build a real product, not just demo something for a video.

1. What Claude Code Actually Is

Claude Code is an implementation partner.

That sounds simple, but it changes how you use it.

It can explore a repo, trace files, edit code, run tests, summarize changes, use subagents, and connect to external tools. But that does not mean it should decide your whole product, your whole architecture, and your whole feature scope by itself.

That is still your job.

You decide what needs to be built.

Claude helps you move through the code faster.

This is why I do not like when people treat Claude Code like a magic app builder.

That mindset creates bad code.

The better mindset is this:

Claude Code is like a very fast junior developer with weird superpowers.

It can read a ton of files quickly. It can summarize architecture. It can implement faster than you can type. But it still needs direction, constraints, and review.

And honestly, that is not a weakness.

That is how real engineering works.

The best developers do not just randomly code. They understand the system first. They break down the problem. They make small changes. They test the work. They review the final output.

Claude Code does not remove that process.

It makes that process faster.

But only if you actually lead it.

2. What People Get Wrong

The biggest mistake is asking for too much at once.

People say things like:

“Build a full dashboard with auth, payments, analytics, and admin settings.”

Then Claude changes 35 files, invents patterns, breaks something random, and now the user thinks Claude Code is unreliable.

But the real issue is that the task was too large.

You cannot give Claude a massive feature and expect it to magically understand every edge case, every convention, every database rule, every UI pattern, and every security issue in your app.

That is not how good software gets built.

The second mistake is using context like a trash can.

A lot of people keep one giant Claude session open forever. They ask it about bugs, UI changes, database design, random questions, deployment errors, and then keep correcting it inside the same messy thread.

Eventually, that hurts the work.

The conversation gets noisy. Claude starts carrying around too much irrelevant context. You correct it five times, it tries five different approaches, and now the whole session feels polluted.

At that point, restarting with a cleaner prompt is better than trying to rescue the same conversation.

The third mistake is thinking CLAUDE.md is a law.

It is not.

CLAUDE.md is context.

It helps Claude understand the project. But it does not force Claude to do anything.

So if you write, “never edit this file,” that is guidance. If you actually mean never, then you need stronger rules like hooks, permissions, or deny rules.

This is why some of the “just use CLAUDE.md” advice is overrated.

CLAUDE.md is useful.

But it is not a security system.

It is not a project manager.

It is not a substitute for understanding your own architecture.

It is just one part of the operating system.

3. The Real Skill: Context, Constraint, Change, Check

Here is the framework I would actually use.

Context

Context is not “give Claude everything.”

Context is “give Claude the information it cannot safely infer.”

That means things like:

* exact dev commands * test commands * file structure * architecture notes * project-specific rules * examples of existing patterns * common mistakes Claude has made in this repo

A good CLAUDE.md should be short enough to matter.

If it becomes a giant essay, Claude is not going to treat every line equally. That is just not realistic.

The best context is usually boring.

That is the point.

It should tell Claude what commands to run, what folders matter, what patterns to follow, and what mistakes to avoid.

Do not try to make it sound smart.

Try to make it useful.

A bad CLAUDE.md says something vague like:

“Write clean code and follow best practices.”

That means almost nothing.

A better CLAUDE.md says:

“Use npm run test for tests. Use npm run lint before commits. API routes are in /app/api. Database queries must go through /lib/db. Do not add new dependencies without asking. Follow the existing error response format in /lib/api/errors.ts.”

That is actually useful.

Claude does not need motivational advice.

It needs project reality.

Constraint

Constraint is telling Claude what not to do.

This is where a lot of people fail.

They ask Claude to fix a bug, but they do not say:

Do not change public API behavior.

Do not edit unrelated files.

Do not rewrite the whole module.

Do not add a new dependency unless you justify it first.

Show me the files you plan to touch before editing.

That kind of constraint matters because Claude is very willing to be helpful.

Sometimes too helpful.

If you give it a bug, it may redesign the whole area.

If you give it a UI issue, it may refactor your styling system.

If you give it a failing test, it may “fix” the test instead of the implementation.

That is dangerous.

Not because Claude is bad, but because it is trying to solve the problem with too much freedom.

So the move is not to trust Claude less.

The move is to give it less room to be clever in the wrong direction.

A good constraint sounds like this:

“Fix the root cause of this bug. Do not change the API response shape. Do not edit unrelated files. Before making changes, tell me which files you plan to touch and why.”

That is way better than:

“Fix this.”

Change

Change is the unit of work.

This might be the most underrated part of using Claude Code.

Claude is better at six small changes than one giant change.

For example, instead of asking:

“Build the entire onboarding flow.”

Ask:

“First, inspect the current auth and user model. Do not edit anything.”

Then:

“Plan the smallest backend change needed for onboarding status.”

Then:

“Implement only the database field and API response change.”

Then:

“Add tests for the new behavior.”

That feels slower.

But it is usually faster because you do not spend two hours cleaning up one giant diff that went in the wrong direction.

Speed is not the goal.

Reliable progress is the goal.

That is something a lot of people miss with AI coding tools.

They see how fast Claude can generate code, so they think the win is speed.

But the real win is controlled speed.

Fast code that breaks your project is not useful.

Fast code that moves the product forward safely is useful.

That is the difference.

Check

Check means Claude needs a real finish line.

Not vibes.

Not “looks good.”

Not “the code seems correct.”

A real check.

That could be:

* a failing test that turns green * a build that passes * a lint check * a type check * a security review * a screenshot comparison * a fresh subagent reviewing the diff against the original plan

This matters because Claude can think something is done when it only looks done.

Without verification, you are the test harness.

With verification, Claude can actually work against evidence.

For important changes, I like the idea of using a fresh subagent to review the final diff.

Basically, do not let the same agent that wrote the code be the only judge of the code.

That is like letting a student grade their own test and then being shocked when they say they did great.

4. Set Up Claude Code Before Asking It To Build

Before I ask Claude Code to build anything serious, I want the repo ready.

First, I want a clean CLAUDE.md.

Not long.

Useful.

Mine would include:

* how to install dependencies * how to run dev * how to run tests * how to lint and typecheck * main architecture * important folders * database rules * API conventions * styling conventions * things Claude should not touch without asking

Second, I would split repeatable workflows into skills.

If I have a repeatable process like “review security,” “prepare PR,” “generate release notes,” or “audit tests,” that probably should not live as a huge block inside CLAUDE.md.

Skills are better for procedures because they load when needed instead of filling the main context all the time.

Third, I would enforce hard rules with hooks or permissions.

This is where beginner setups usually break.

If formatting should always run after edits, use a hook.

If a file should never be edited, block it.

If a dangerous command should require approval, set permissions.

CLAUDE.md is advice.

Hooks are rules.

That distinction matters a lot.

Fourth, for bigger repos, I would care about context management from the start.

The bigger the codebase, the more Claude needs a map.

If your repo has a frontend, backend, database layer, shared types, design system, and deployment scripts, Claude should not have to rediscover everything every single time.

You need structure.

You need documentation.

You need clean boundaries.

Because if your repo is messy, Claude will not magically make it clean.

It will probably amplify the mess.

5. The Workflow That Actually Works

The best workflow is:

Explore. Plan. Execute. Verify.

This is not just a cute framework.

It works because it separates thinking from editing.

Most bad Claude Code sessions happen because editing starts before the problem is understood.

Explore

Claude should inspect before editing.

I want it to find the relevant files, explain the architecture, and identify the current patterns.

Prompt:

“Read the repo and explain how this feature currently works. Identify the exact files involved. Do not edit anything yet. If the repo is large, use a subagent for exploration and return only the summary.”

That prompt matters because it forces Claude to understand before touching anything.

Plan

Now Claude should propose the smallest safe change.

Prompt:

“Create a plan for adding [feature]. List the files that need to change. Explain why each file needs to change. List what should not change. List the verification steps. Do not write code yet.”

This is where you catch bad ideas before they become bad code.

If the plan is wrong, correcting the plan is easy.

Correcting 35 files is not.

Execute

Now it can code.

But still in a controlled way.

Prompt:

“Implement the plan in the smallest useful diff. Do not rewrite unrelated code. Follow the existing patterns. If you discover the plan is wrong, stop and explain before changing direction.”

That last sentence is important.

Claude should not silently change direction.

If the plan is wrong, it should stop and tell you.

Verify

This is where a lot of people quit too early.

Prompt:

“Run the relevant checks. Explain what passed, what failed, and what you changed. Then review the final diff against the original plan and flag anything out of scope.”

That loop works because Claude knows what stage it is in.

Explore means understand.

Plan means think.

Execute means code.

Verify means prove it.

When you mix all of those into one giant prompt, things get messy.

6. Advanced Features That Actually Matter

A lot of advanced Claude Code features sound cool, but not all of them matter for every project.

Here is how I think about them.

Hooks

Hooks are for rules that should happen every time.

Use them for formatting, blocking risky edits, logging actions, or requiring checks before certain operations.

They are probably overkill for tiny projects.

But once Claude starts making repeated mistakes, hooks become very useful.

Skills

Skills are for repeatable workflows.

Security review.

PR preparation.

Release notes.

Design-system checks.

Migration review.

Documentation cleanup.

Do not put every thought into a skill.

Use them when a process repeats.

Subagents

Subagents are underrated.

Their biggest value is not “having an AI team.”

Their biggest value is context isolation.

That is huge.

If Claude needs to explore a big auth system, search logs, or review a diff, send that to a subagent so your main session does not become a pile of raw file reads.

The main session should stay focused.

The subagent can do the messy exploration and return the useful summary.

MCP

MCP is useful when Claude needs real external tools.

Things like GitHub, Figma, Notion, databases, or internal systems.

But MCP is also overused.

If your local project context is a mess, adding more tools will not fix it.

More tools do not automatically mean better results.

Sometimes they just create more ways for the agent to get distracted.

Use MCP when it removes a real bottleneck.

Do not use it just because it sounds advanced.

Worktrees

Worktrees are useful when you want Claude working on multiple branches or experiments without destroying your main working state.

For solo builders, this is especially useful when testing bigger refactors.

You can let Claude try something risky without putting your main branch in danger.

That is actually useful.

GitHub Integration

Claude Code in GitHub workflows can help with PR reviews, issue work, and automation.

But I would still treat it like a contributor, not the final reviewer.

AI can help review code.

It should not be the only thing protecting production.

Cost And Token Management

This is not glamorous, but it matters.

Context costs tokens.

Long messy sessions cost more and usually perform worse.

If your sessions are expensive and bad, the issue might be the same thing:

Too much irrelevant context.

Better context is not more context.

Better context is cleaner context.

7. Failure Modes And How To Avoid Them

Claude Code fails in predictable ways.

That is actually good news because predictable failures can be designed around.

It hallucinates files, APIs, or identifiers

Fix: make it read before editing.

Ask for file references.

Force it to show where an API or type is defined.

It over-edits

Fix: limit file scope.

Ask for the smallest diff.

Tell it to stop if it needs to change more files than expected.

It breaks project conventions

Fix: give it examples of the correct pattern.

Do not describe style in abstract terms.

Point to real files.

It adds unnecessary complexity

Fix: require justification for new abstractions, dependencies, and services.

Sometimes Claude will try to build a whole system when you only needed one function.

Stop that early.

It passes tests but solves the wrong problem

Fix: add behavior-level checks.

Use manual reproduction steps, screenshots, or regression tests tied to the actual bug.

A passing test does not matter if the product still behaves wrong.

It gets stuck in loops

Fix: stop the session.

Do not keep yelling corrections into a polluted context.

Restart with a cleaner summary and a narrower task.

It fixes symptoms instead of root causes

Fix: make it reproduce the bug first, explain the root cause, and only then edit.

This is the difference between:

“Claude, fix it.”

And actually leading the work.

8. Prompts I Would Actually Use

These are the kinds of prompts I would use in a real repo.

Understand a new codebase

Read this repo and explain:

1. the main architecture, 2. the key entry points, 3. the files involved in auth, data flow, and state management, 4. the commands needed to run and test the project, 5. the conventions I need to follow.

Do not edit anything.

If the repo is large, use a subagent for exploration and return only the summary.

Create a safe implementation plan

I want to add [feature].

Stay in plan mode.

First identify the exact files that should change.

Then propose the smallest implementation plan that fits the current architecture.

For each step, include:

* why this file needs to change * what should not change * risks * how we will verify it

Do not write code yet.

Fix a bug without over-editing

Reproduce this bug first: [steps / command / stack trace].

Limit yourself to the smallest fix that addresses the root cause.

Do not change unrelated files.

Before editing, tell me which files you expect to touch and why.

After the fix, run the narrowest relevant checks and explain why this is root-cause, not symptom masking.

Add a backend feature

Add [endpoint / job / backend feature].

Follow the existing patterns in [example files].

Preserve current auth, error format, logging style, and response shape.

If you need a new abstraction or dependency, justify it before adding it.

Write tests for:

* success path * auth failure * one edge case

Refactor safely

Refactor [file/module] for readability, but preserve behavior exactly.

Do this in small steps.

Before each edit, state the behavior that must stay the same.

Afterwards, run relevant tests and summarize what behavior was checked.

Review security

Use a fresh subagent to review the current diff for:

* auth mistakes * injection risks * secret handling * unsafe shell or network usage * trust boundary issues

Report only real correctness or security issues.

Include file references and concrete fixes.

Improve CLAUDE.md

Audit this repo and draft a lean CLAUDE.md.

Include only:

* commands Claude cannot safely infer * architecture notes that matter * project-specific conventions * recurring mistakes Claude should avoid

Move long procedures into skills instead.

Explain what you left out and why.

Before a commit

Summarize the current diff.

Check whether the changes match the original plan.

Flag anything out of scope.

Suggest a commit message.

Then use a fresh subagent to review the diff for correctness gaps.

Recover after Claude makes a bad change

Stop.

Assume the last approach was wrong.

Explain:

1. what changed, 2. why it was wrong, 3. what should be restored, 4. the narrower next attempt.

If the context is too messy, tell me whether we should rewind or clear and restart.

9. My Advice To Student Builders And Founders

If you are a student, solo builder, or founder, Claude Code can be insanely useful.

But only if you stay in charge.

The mistake is thinking Claude Code replaces engineering judgment.

It does not.

It amplifies your judgment.

If you understand the user, the product, the workflow, and the business problem, Claude can help you move much faster.

That is why Claude Code is so good for MVPs, dashboards, websites, internal tools, startup prototypes, and messy projects that need cleanup.

You can use it to:

* turn a rough idea into a technical plan * understand a codebase you barely remember * add backend features * refactor messy AI-generated code * write tests after moving fast * debug production issues * document the project so future Claude sessions get better

That is how builders should use it.

Not as a toy.

Not as a replacement for thinking.

As leverage.

The honest truth is this:

Claude Code makes weak thinking more obvious.

If your product idea is vague, Claude will build vague code.

If your architecture is messy, Claude will amplify the mess.

If your verification is weak, Claude will give you something that looks done.

But if you know what you want, give it the right context, constrain the task, and check the output, it becomes a serious building tool.

10. Final Takeaway

Claude Code is not about prompting.

It is about operating the loop.

Context. Constraint. Change. Check.

That is the whole game.

Give Claude the right information.

Limit the blast radius.

Ask for the right size change.

Force evidence before you trust the result.

That is the difference between vibe coding and reliable progress.

And honestly, that is why Claude Code is more interesting than most tutorials make it seem.

The hard part is not talking to the AI.

The hard part is thinking like someone who can lead engineering work.

Claude just makes that obvious really fast.