📌 TL;DR
If you’re only using Claude as a “thing you ask questions to,” you’re getting less than half of what it can do.
The tips that make the biggest difference for developers are surprisingly underdiscussed.
Here are 5 patterns I’ve actually used and seen pay off.
💡 Tip 1. Stop wasting the context window — throw the whole thing in at once
Claude Sonnet 4.6 and Opus 4.6 support a 1M token context window. That’s not just “you can paste long text now.”
Switch from asking file-by-file to handing Claude the entire codebase in one shot, and accuracy jumps because it’s reasoning over the whole picture instead of fragments.
📝 Example prompt
[After pasting the full project codebase]
“Find every piece of auth-related logic in this codebase and list anything that looks like a potential security vulnerability.”
Best for understanding legacy code or reviewing large PRs.
💡 Tip 2. Put “bad example / good example” directly in the prompt
Showing examples beats describing what you want. Concrete examples are way faster than adjectives. Saying “be more specific” rarely works. Showing what “specific” looks like always does.
❌ Bad example
“This code has a problem.”
✅ Good example
“L34 — accessing user.profile.email without a null check, which throws a runtime error when user is undefined. Use optional chaining, or add a guard clause higher up the call stack.”
📝 Prompt template
Write code review comments in the style below.
[Paste bad example / good example]
Now review this code in that same style:
💡 Tip 3. Use the system prompt aggressively — for API and Claude Code users
If you're hitting the Claude API or running Claude Code, don't leave the system prompt empty. Lock down the role and constraints, and you stop re-explaining the same context every single request.
📝 System prompt example (Kotlin + Spring Boot project)
You are an assistant for a Kotlin + Spring Boot backend developer.
- Always write code examples in Kotlin
- Keep explanations concise; minimize comments
- Prioritize readability over performance, but always flag obvious N+1 queries
- Recommend libraries that fit our stack (Spring Boot 3.x, JPA, Redis)
Set this once and you're done repeating "in Kotlin please" or "keep it short." Different system prompts per project also let you switch contexts almost instantly.
💡 Tip 4. Force step-by-step reasoning — especially for debugging and design
Most of Claude's wrong answers come from jumping to a conclusion too fast. Force the steps and it stops skipping the middle of the reasoning chain.
📝 Example prompt
Don't fix this bug yet. First, list at least 3 possible root causes.
For each one, also write down how to verify it.
Then pick the most likely candidate and propose a fix.
Hugely effective for tricky troubleshooting and architecture reviews.
💡 Tip 5. Specify the output format in painful detail
"Summarize this" or "clean this up" gets you mush. Show the exact format you want and Claude fills it in. The output comes out clean enough to paste straight into a team wiki.
📝 Example prompt (API doc cleanup)
Reformat this API doc into the structure below:
## [Endpoint name]
- Method: GET/POST/...
- URL: /api/v1/...
- Parameters: (write "none" if empty)
- Response example: (JSON code block)
- Notes: (omit if none)
---
🎁 Bonus — HN favorite: store project conventions in CLAUDE.md
A trick that got a lot of love on a recent Hacker News thread, "How I'm Productive with Claude Code":
💡 When using Claude Code, drop a CLAUDE.md in the project root listing your conventions, frequently-used commands, and files that should never be touched. Then you stop re-explaining all of that on every session.
I tried it myself, and the consistency of the resulting code style — without me nagging — was way more noticeable than I expected. If you're on Claude Code, just do it.
💬 Editor's note
Getting good at Claude is really just getting good at asking good questions. The good news: that skill ramps up faster than you'd think. Use these 5 patterns deliberately for two weeks and you'll feel a clear difference.
Tip 2 (bad example / good example) hit the hardest for me. I thought it was a hassle at first, but the moment I actually did it, the output quality jumped in a way that surprised me.
This post is based on official channels and community sources. Information is current as of the time of writing and may change.
This post is part of an English mirror of a Korean dev experiments blog. Cross-posted for the global developer audience.