I’ll admit something. The first time I opened Claude Code, I typed a fuzzy request, watched it change the wrong file, and briefly wondered what all the hype was about. So when I came across this post from an AI professional who went through the exact same phase, I was nodding the whole way through.
The author opens with one line that sums up the whole post: “Claude Code is only as good as the person driving it.” Then they lay out the failure pattern most of us know too well:
- You fire off a vague request.
- It edits the wrong file.
- The context fills up with noise.
- It calls the job finished when nothing actually runs.
And then people decide the tool is overhyped. The creator says they did exactly the same thing. Before, they barely had time to build. Now they finally do. But the first few weeks went to fighting Claude Code instead of shipping with it: endless sessions, five tasks crammed into one prompt, zero plan.
Their conclusion is refreshingly honest. The tool was never the problem. The process was.
🧠 Treat Claude Like a Sharp New Hire
In their current role, the original poster sees the same pattern on every team. The people who plan first get clean code. The people who skip planning get a mess and a long cleanup afterward.
What fixed it for them was a simple mindset shift. They started treating Claude like a sharp new hire. You don’t hand a new hire the keys on day one. You give them:
- Context
- A plan
- Guardrails
- A way to check their own work
I love this framing because it takes the mystery out of AI coding. You wouldn’t blame a talented junior dev for guessing wrong when you gave them a one-line brief. Same rules apply here.
From there, the expert breaks it all down into 50 tips across 10 areas. Here’s how they’d use each one, with a bit of extra context from me on why each habit pays off.
⚡ The 10 Areas That Separate Clean Code From Chaos
- Set up right: Run /init in every project and keep CLAUDE.md short. The /init command scans your codebase and writes a starter CLAUDE.md, which is the file Claude reads for project context. Short matters, because a bloated file eats context before you’ve even started.
- Prompt better: Describe what “done” looks like, then point to files with @. Instead of “fix the login,” try something like “login should redirect to /dashboard after success, see @src/auth.ts.” A clear finish line plus exact files means far less guessing.
- Plan first: Hit Shift+Tab for plan mode before a single file changes. In plan mode, Claude proposes an approach without touching your code. You review it, push back, and only then let it build.
- Control the session: Press Esc to stop, use /clear between tasks, and run /compact when things start dragging. Esc saves you when Claude heads the wrong way. /clear wipes old context so one task doesn’t pollute the next, and /compact condenses a long conversation so it stays focused.
- Pick the right power: Raise /effort for nasty bugs and lower it for quick edits. You don’t need deep reasoning to rename a variable, but you probably do for a race condition that only shows up on Tuesdays.
- Manage permissions: Allow the safe commands and keep Claude away from .env and secrets. Pre-approving harmless commands cuts down on constant confirmation prompts, while blocking sensitive files protects your API keys and credentials.
- Work in parallel: Use subagents for research and git worktrees for separate sessions. Subagents dig through files in their own context, so your main session stays clean. Worktrees give each session its own copy of the repo, so parallel tasks don’t trip over each other.
- Automate: Set up hooks that run tests after every edit and skills for prompts you repeat. Hooks fire automatically on events, so tests run without you remembering to ask. Skills package your go-to instructions so you stop retyping them.
- Extend it: Connect your tools with /mcp and build specialists with /agents. MCP lets Claude talk to outside services like databases or project trackers, and custom agents act like focused team members for jobs such as reviewing or testing.
- Ship safely: Commit before big changes and run /code-review before every PR. A fresh commit is your undo button if a big refactor goes sideways, and a review pass catches issues before a teammate has to.
🔁 Two Underrated Tricks Most People Skip
The post’s author also calls out two features they think most people overlook, and I agree they deserve more love:
- claude -p inside your scripts and CI: This runs Claude in non-interactive mode. You pass a prompt, get a result, and the process exits. That means you can drop Claude into build pipelines, cron jobs, or shell scripts.
- /loop to re-check something on an interval: Point it at a deploy, a test suite, or a status check, and it keeps checking while you get on with other work.
🎯 If You Only Steal Three
Fifty tips is a lot to absorb at once. So the creator narrows it down to the three habits they’d never drop:
- Plan mode before anything big, every single time.
- /clear between unrelated tasks.
- Read every diff yourself before you merge.
That last one matters most, according to the author. Claude writes the code. You still own what ships.
This is the part I’d tape to my monitor. AI can produce a lot of code very fast, and that speed makes it tempting to skim. But if a bug hits production, “the AI wrote it” isn’t going to fly with your team or your users.
💡 Why This Works
Notice that none of these tips need a better model or a fancier setup. They’re habits. The expert closes with a line that stuck with me: the builders getting real output from AI right now aren’t smarter. They just have better habits.
If you’re just getting started, here’s how I’d apply it this week:
- Day one: Run /init in your main project and trim CLAUDE.md down to the essentials.
- Every task: Write down what “done” looks like before you hit enter.
- Anything bigger than a small fix: Shift+Tab into plan mode first.
- Between tasks: /clear, every time.
- Before merging: Read the full diff, line by line.
Got a dev friend still wrestling their terminal? This one’s worth passing along. And the original poster asks a fun question I’d love your take on too: which of these 50 would you never give up?
Check out the full LinkedIn post to see the complete breakdown and join the conversation in the comments.