5 Claude Tips Every Developer Should Know

Recently I ran a test. I wanted to know how fast I could hit the Claude Pro usage limit if I just used Claude the way most developers use it — opening sessions, asking questions, pasting code, fixing bugs, with no real strategy behind any of it.

It took me 2.5 hours.

That was a wake-up call. Not because the limit is too low, but because I clearly wasn’t getting the most out of the tool. And I see this same problem with developers everywhere. They use Claude like a fancy version of Stack Overflow — type a question, get an answer, paste it in, repeat. It works, but it leaves most of the value on the table.

The developers who actually get 2–3x more done with Claude aren’t writing better prompts. They’re not paying for a more expensive model. They’re architecting the session.

These are the 5 habits that make the difference. None of them are complicated. But nobody tells you about them, and you only figure them out after burning through your usage limit a few times.

Real gains don’t come from better models — they come from architecting the session.

1. Plan Before You Code. Always.

The single biggest lever in AI coding isn’t a better prompt or a smarter model. It’s planning before you write a line of code.

The most expensive failure mode is Claude confidently writing 400 lines in the wrong direction.

Five minutes of planning prevents an hour of cleanup — and a lot of wasted tokens.

Plan inside Claude Code for small to medium tasks For anything non-trivial inside your coding session, press Shift+Tab to enter plan mode. Claude explores the codebase, proposes an approach, you review and approve it, and then implementation starts.

Use the opusplan model for this workflow. Opus reasons through the plan, Sonnet writes the code.

You get the expensive thinking only where it actually pays back.

Plan in the Claude app first for bigger work

This is the step most developers skip — and it’s a game-changer.

For new projects, major features, or significant refactors, don’t start in VS Code.

Open the Claude app in your browser and start a fresh chat.

Talk through what you’re building. Push back on Claude’s first answer. Change your mind. Throw out an entire approach and start over. In a chat, iteration is cheap. In a coding session, every pivot costs you context and tokens.

When the plan feels right, ask Claude to turn it into a project brief:

goals, constraints, file structure, key decisions, tech choices, and definition of done.

Bring the plan into your coding session Now you have two options:

• Paste the brief as the opening prompt in your Claude Code session

• Drop it into your CLAUDE.md file if it’s project-wide context that should persist across sessions

The principle underneath this: plan in the medium where iteration is cheap. Two-step planning gives Claude the why behind your code, not just the what. That’s what stops it from making bad decisions on your behalf later.

2. Write Specific Prompts With Verification Targets

“Improve this code” is the worst prompt you can write. It’s vague, it triggers broad scanning across files, and it almost guarantees Claude does something you didn’t actually want.

Compare these two prompts:

“Improve the auth module”

vs.

“Add input validation to the login function in auth.ts. Reject empty email, validate format with the existing isEmail util, return 400 with {error: ‘invalid_email’}. Test case: login(’‘) → 400.”

The second one takes 30 seconds longer to write and saves you 20 minutes of fix-up rounds.

Rule 1: Name the file, name the function

Don’t make Claude guess where the work happens. If you can point to the exact location, do it.

Every time you save Claude from having to search the codebase, you save tokens and time.

Rule 2: Give a verification target

Paste the failing test, the expected output, or a screenshot of the broken UI.

When Claude can verify its own work before handing it back to you, it catches issues before you have to ask for fixes.

Why this compounds

Every prompt either saves you a turn or costs you one. Across a session, that’s the difference between shipping a feature and still debugging it at 6pm. The 30 seconds you spend writing a clear prompt pay back ten times over by the end of the day.

3. Manage Context Like It’s a Budget — Because It Is

Your context window isn’t infinite. Every file you load, every command you run, every piece of tool output Claude sees — it all stacks up. When the window fills, performance degrades and Claude starts losing the thread of your work.

Three habits handle 90% of context problems.

Use /clear between unrelated tasks

Stale context taxes every subsequent message. If you spent the morning debugging auth and now you’re writing tests for the payments module, hit /clear. Before you do, run /rename so you can find the session later, then /resume to come back to it if you need to.

Use /compact at natural breakpoints

/compact summarizes your conversation history and replaces it with a compressed version.

Use it proactively — at the end of a subtask, before switching focus — not when you’re already at 95% full.

Tell it what to keep:

/compact keep the auth refactor decisions and the schema changes

That single line preserves what matters and lets the rest go.

Run /context to see what’s actually loaded

Most developers are shocked the first time they run this. Their CLAUDE.md, MCP servers, and skills are eating 20% of the window before they’ve typed a single character.

If that’s you, fix the base load first:

• Trim CLAUDE.md to under 200 lines

• Disable MCP servers you don’t actively use (/mcp to list them)

• Move detailed workflow instructions out of CLAUDE.md and into skills, which only load when invoked

Watch out for files that are too big for the context window

Here’s a real problem I ran into. I was developing a notebook that grew so large Claude couldn’t load it directly into context anymore. To read or edit it, Claude had to use a Python function — which meant every read and edit dumped huge output into context. On top of that, I lost visibility into what Claude was actually changing.

The fix: split big files into smaller, single-purpose ones before you start AI work. The same principle applies to huge log files, data dumps, and generated code. Preprocess or chunk them before Claude ever touches them. If a file is too big to load cleanly, it’s already costing you.

4. Match the Model and the Effort to the Task

Two independent dials. Most developers only know about one.

Model choice — how smart the engine is

• Sonnet is your default. It handles 80% of coding work at a fraction of Opus cost.

• Opus is for genuine architectural decisions and multi-file reasoning. Don’t sit on it for everything.

• Haiku is for cheap, fast, mechanical work.

Switch mid-session with /model. The right answer is almost never “use this one model for everything” — it’s “switch based on what you’re doing right now.”

Effort — how long Claude thinks before answering

This is the dial most developers don’t even know exists. Set it with /effort.

Extended thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request. That adds up fast.

The levels, roughly:

• Low — renames, typo fixes, obvious feature work

• Medium — default for most coding

• High — gnarly debugging, architectural decisions, multi-file refactors

You can also set MAX_THINKING_TOKENS=8000 for an entire session focused on simpler work, then crank it back up when you hit something hard.

The key insight

Sonnet on high effort often beats Opus on low effort, at lower cost.

The thinking budget is doing the heavy lifting, not the model tier.

The common mistake

Cranking everything to max for the entire session. You’ll burn through tokens on trivial requests where Claude is “thinking” about whether to use let or const. Dial it down for the boring 80% of work, and dial it up for the 20% that actually needs reasoning.

5. Debugging: Paste Errors Properly and Let Claude Diagnose Before It Fixes

Debugging is the most common AI coding task — and most developers do it wrong.

They paraphrase errors, skip context, and let Claude jump straight to fixing without diagnosing.

Paste the full error verbatim

Stack trace, line numbers, error code, everything. Don’t paraphrase, don’t summarize.

Claude needs the raw signal — the exact error message often contains the clue that solves the bug.

Include what you already tried

A quick note like “I checked X, ruled out Y, the issue persists when Z” stops Claude from suggesting things you’ve already eliminated. Saves a full back-and-forth round.

Point to the file and function

Same rule as Tip 2 — name the location. Don’t make Claude guess where the bug lives.

For non-obvious bugs, use plan mode

Force Claude to diagnose before touching the code. This is especially important for intermittent bugs, race conditions, and issues that span multiple files. The worst thing Claude can do is “fix” the symptom without understanding the cause.

Match effort to bug complexity

• Missing import, typo, null check → low effort, Sonnet

• Distributed system failing under load, weird state issue, intermittent failure → high effort, possibly Opus

Cut losses early with /rewind

If Claude starts heading the wrong direction, double-tap Escape or use /rewind to restore your conversation and code to a previous checkpoint. Cutting losses early saves more tokens than any optimization technique. Don’t let a bad path eat your session.

The Bigger Picture

The thread running through all 5 habits is the same:

your job isn’t to type prompts. Your job is to architect the session.

• Plan first

• Scope tight

• Model-match

• Keep context lean

• Debug methodically

The gap between developers who do this and developers who don’t widens with every project.

On a small task it’s 10% faster. On a real codebase, it’s the difference between shipping and not shipping.

Remember the 2.5 hours I burned through Pro at the start of this article? That was me with zero of these habits.

Imagine what’s possible with all five.

***

Ready to become a Data Engineer? Then join my Learn Data Engineering Academy today!

If you want to build real platforms, master the full stack, and close your skill gaps, check out my Data Engineer Coaching program.

If you are interested, but still have a few burning questions on your mind: feel free to contact me via hello@learndataengineering.com.

For more information and content on Data Engineering, also check out my other blog posts, videos and more on Medium, YouTube and LinkedIn!