Most people use Claude at about 20% of its capability โ typing questions the same way they'd Google something, reading the answer, closing the tab. After months of daily professional use as a data engineer, building this site with Claude's help, and setting up full local AI workflows with Claude Code and Ollama, I've assembled the tips that actually changed how much work I can do in a day.
These are organized by who they're for โ some are for everyone on Claude.ai, others are specifically for developers who use the API, Claude Code, or local models.
๐ฏ Claude.ai Tips โ For Every User
Tip 1: Create a "Work" Project and never start fresh again
The single biggest productivity unlock is Projects. Create one for each ongoing context: "Data Engineering Work", "Interview Prep", "This Side Project". Write a system prompt that tells Claude your stack, your conventions, and your communication preferences. Upload your schema or architecture doc to Project Knowledge.
Now every conversation in that project starts with Claude already knowing everything about you โ no more "I'm a data engineer working in Python on PostgreSQL..." preamble every time.
I am a [role] at [company type]. Stack: [your tech stack] Conventions: [naming, patterns, preferences] Communication: [concise/detailed, code-first/explanation-first] Currently working on: [current project/goal]
Tip 2: Use Shift+Enter for multi-line prompts โ don't compress everything into one line
A prompt with structure gets a structured answer. Use Shift+Enter for new lines. Write your context on one set of lines, your task on another, your format requirements on another. Claude's output quality is directly proportional to your input quality.
Tip 3: Put your most important instruction last
Claude pays more attention to instructions at the end of a prompt than in the middle. If you have a critical constraint โ "never use external libraries", "output must be under 200 words", "always include error handling" โ state it last, not first.
Tip 4: Use XML tags for complex, multi-part prompts
For any prompt with distinct sections (context, task, format, constraints), use XML tags. Claude is specifically trained to respect them as semantic boundaries:
<context>Our orders table has 50M rows on PostgreSQL 15</context> <task>Rewrite this query for performance</task> <constraints>No CTEs โ DBA says they're slow on our version. Use subqueries.</constraints> <format>SQL first, then explain each optimization</format>
Tip 5: Ask Claude to critique its own output
After getting an answer, ask: "What are the weaknesses in that solution? What edge cases did you not handle? What would a senior engineer flag in a code review?" Claude is better at critiquing than it is at self-censoring during generation โ this two-pass approach catches significantly more issues.
Tip 6: "Think step by step" actually works โ use it for hard problems
Adding "Think through this step by step before giving your final answer" to any complex reasoning task measurably improves accuracy. This triggers chain-of-thought reasoning. For SQL query design, architecture decisions, or debugging โ add it. For simple factual questions โ skip it.
Tip 7: Use the model selector strategically โ don't default to Sonnet for everything
| Task | Best model | Why |
|---|---|---|
| Quick questions, simple code, formatting | Haiku | Fastest, cheapest, more than enough |
| Daily coding, writing, analysis | Sonnet (default) | Best balance |
| Architecture decisions, long doc analysis, hard reasoning | Opus | Worth the extra cost for complex tasks |
A common mistake: using Opus for everything because "it's the best." Haiku handles 60% of typical tasks perfectly well at a fraction of the cost.
Tip 8: Upload your error messages, not descriptions of your errors
Don't type: "I'm getting a connection refused error when I try to connect to Postgres." Copy-paste the full stack trace and include the relevant code. Claude can read error messages, understand which library threw them, and give you the exact fix โ it can't do that from a paraphrase.
Tip 9: Use Claude for rubber-duck debugging โ talk through the problem first
Before pasting code, describe what you expect to happen vs what actually happens. Force yourself to articulate the discrepancy. Often, writing it out reveals the bug before Claude even responds. When it doesn't, Claude has all the context it needs to diagnose precisely.
Tip 10: Set Claude's "persona" for consistent long-term projects
In your Project instructions, define a persona: "You are a senior data engineer at our company. You are direct, prefer simple solutions over clever ones, always flag potential data quality issues, and use British English spelling." Claude maintains this across every conversation in the project, producing more consistent output than re-explaining every session.
Tip 11: Use Claude as a second opinion, not just a generator
One of the most underused patterns: share your own solution and ask Claude to improve it. "Here's the approach I'm planning. What am I missing? What would you do differently?" Claude as critic is often more valuable than Claude as author.
Tip 12: The "continue" trick for long outputs
If Claude stops mid-output (due to max tokens), just say "continue" or "keep going". It resumes exactly where it left off. For very long documents, you can also ask "output section 2 of 3" to get chunked output you can assemble.
๐ป Developer Tips โ API, Claude Code & Advanced
Tip 13: Put your system prompt in environment variables, not hardcoded in scripts
import os, anthropic
system = os.getenv("CLAUDE_SYSTEM_PROMPT", "You are a data engineering assistant.")
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=system,
messages=[{"role": "user", "content": user_input}]
)
This lets you swap system prompts per environment, run A/B tests on prompts, and keep sensitive context out of your codebase.
Tip 14: Use /compact aggressively in Claude Code sessions
Context window costs money. In long Claude Code sessions, run /compact every 30โ45 minutes. It summarizes the conversation history, preserving key decisions while shedding the token-heavy back-and-forth. A compact session can cost 50โ70% less than an uncompacted one of equivalent length.
Tip 15: CLAUDE.md is more powerful than a system prompt for codebases
Unlike a system prompt (which you set once and forget), CLAUDE.md files are version-controlled, team-shared, and hierarchical. Put a root CLAUDE.md for global project context, then src/api/CLAUDE.md for API-specific conventions, tests/CLAUDE.md for test patterns. Claude reads the relevant ones automatically when working in each directory.
Tip 16: Use streaming for better UX in API applications
with client.messages.stream(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": user_input}],
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True) # display word by word
Streaming makes your Claude-powered app feel responsive โ users see output appear immediately rather than waiting for the full response.
Tip 17: Batch API for high-volume, non-urgent tasks
If you have 10,000 documents to classify and don't need results immediately, use the Batch API. It's 50% cheaper per token than the standard API and processes requests asynchronously. Perfect for nightly data pipelines, bulk labeling jobs, and document processing workflows.
batch = client.messages.batches.create(
requests=[
{"custom_id": f"row_{i}",
"params": {"model": "claude-haiku-4-5-20251001",
"max_tokens": 64,
"messages": [{"role": "user", "content": row}]}}
for i, row in enumerate(rows)
]
)
Tip 18: Use Claude Code's --resume flag to continue interrupted sessions
If your Claude Code session gets interrupted (network drop, Ctrl+C mid-task), you can resume it:
claude --resume # resumes the most recent session claude --resume <session-id> # resume a specific session
Claude restores full context and continues from where it left off, including any files it was in the middle of editing.
Tip 19: Route tasks between Claude API and Ollama by complexity
Build a two-tier AI layer in your applications: local Ollama for high-volume, low-stakes, or privacy-sensitive tasks โ Claude API for anything that requires quality:
COMPLEX_THRESHOLD = 500 # characters
def smart_complete(prompt: str) -> str:
if len(prompt) < COMPLEX_THRESHOLD and not requires_reasoning(prompt):
return ollama_complete(prompt, model="llama3.2")
return claude_complete(prompt, model="claude-sonnet-4-5")
Tip 20: Pin specific Claude model versions in production
Never use "claude-sonnet-latest" in production code. Anthropic occasionally updates what "latest" points to, which can break your prompts. Always pin to a specific version string: "claude-sonnet-4-5", "claude-haiku-4-5-20251001". Update deliberately after testing.
๐ Safety, Cost & Quality Tips
Tip 21: Monitor your token usage โ set hard budget alerts
In the Anthropic Console, set spending alerts at 50% and 90% of your monthly budget. A runaway script or agentic loop can burn through credits fast. The Console dashboard shows per-API-key usage โ create separate keys for dev, staging, and prod so you can attribute costs precisely.
Tip 22: Validate Claude's output for factual claims โ always
Claude is excellent at reasoning and structure; it's less reliable for specific facts (dates, names, statistics, version numbers). Always verify: version numbers against official docs, statistics against primary sources, any claim that's specific enough to be wrong. Use Claude for understanding and structure; use authoritative sources for facts.
Tip 23: Use Claude for documentation โ this is its stealth superpower
Claude writes better technical documentation than most engineers do. Give it a function and ask for: docstring, parameter descriptions, return type, example usage, edge cases, and a note on complexity. It produces RST, Google-style, or NumPy-style docstrings equally well. For a team project, have Claude document every function once โ the future code reviewers will thank you.
Tip 24: The "opposite perspective" technique for reviewing architecture
After designing something with Claude's help, ask: "Now argue against this design. What are its weaknesses? If this system had 10ร the load in 2 years, where would it break? What would a skeptical architect say in a design review?" This surfaces problems that Claude politely glosses over when it's helping you build something.
Tip 25: Build a personal prompt library
Keep a prompts.md file (or a Notion page) with your best prompts for recurring tasks. Not vague templates โ actual complete prompts that worked well. Over time you'll accumulate 20โ30 high-value prompts that consistently produce great output for your specific work context. This is a compound-interest asset โ it gets more valuable every week.
- "Review this Python function for correctness, performance, and readability. List issues as: [Critical] [Minor] [Style]"
- "Write pytest tests for this function: [paste function]. Cover: happy path, edge cases, error cases."
- "Explain this error to a junior developer and give 3 possible causes in order of likelihood: [paste error]"
- "Translate this SQL query into plain English, then identify any performance concerns: [paste query]"
- "Write a git commit message for these changes following Conventional Commits format: [paste diff]"
Summary: the 5 highest-leverage habits
If you only implement five of these tips, make them these:
- Create a Work Project with a detailed system prompt โ once set up, this saves 5+ minutes every session
- Structure your prompts with context, task, and format sections
- Ask Claude to critique its own output โ two-pass quality is dramatically better
- Build a CLAUDE.md for every code project you work on
- Never blindly ship Claude's output โ read it, understand it, own it
Claude used well isn't a replacement for expertise โ it's a force multiplier for it. The engineers who get the most out of it are the ones who already know what good looks like, and use Claude to get there faster.