Most people lose time to Claude not because the model is bad, but because they let it run on bad assumptions.
Here's the hack I showed in the reel, plus four more that compound on it.
Ask Claude to ask qualifying questions before it does anything.
Start every session with:
"Before you start, ask me any clarifying questions that would change your approach. Don't make assumptions. Ask."
This one prompt stops Claude from going 200 lines deep on a misread brief. It takes 30 seconds. It saves 30 minutes.
"Before writing any code, list the files you'll touch, the changes you'll make to each, and any assumptions you're making. Wait for my approval before proceeding."
This forces Claude to show its work upfront. You catch misunderstandings before tokens get burned on the wrong implementation. Review a plan in 60 seconds, or review 300 lines of wrong code for an hour. Your choice.
"Read the relevant files and tell me what you found before making any changes."
Claude Code is eager. Without this, it guesses at your codebase conventions rather than reading them. A reconnaissance pass first means every change is grounded in what's actually there, not what Claude thinks is probably there.
"Make the minimal change needed. Don't refactor unrelated code, don't add comments, don't 'improve' anything I didn't ask about."
Without this, Claude helpfully rewrites surrounding code you didn't touch. Which means your PR review becomes a diff archaeology session, and you introduce unintended changes in code you thought was untouched. Keep the blast radius small.