Claude Code for Clinicians Chapter 20

Chapter 20: Ten Rookie Mistakes to Avoid

Almost every mistake in this chapter has been made by a competent person — including the author — doing the dumb thing first. The chapter exists so that you can skip the dumb thing.

If you flipped here first instead of reading from the beginning, you’ll see a few terms defined again. That is on purpose. A reference chapter has to stand alone.

1. Running --dangerously-skip-permissions on Day One

What it is. A flag you can attach to the claude command (a flag is just a modifier you write after the command, like claude --dangerously-skip-permissions). It tells Claude Code to stop asking for approval before every action and just do everything. People sometimes set up an alias called cc so they can run this with two keystrokes.

The mistake. Doing this on day one because you saw it on Twitter and felt left behind. Boris Cherny, the original author of Claude Code, has said he doesn’t use this flag. You don’t need to either, at least not for the first week, while you’re learning what Claude actually wants to do when left alone.

What to do instead. Use the /permissions command to pre-approve specific safe operations (read-only tools, your test command, git status, git diff). The speed gain is 95% as good as the dangerous flag, and the blast radius is 5% as bad.

⚠️ Warning. “Dangerously skip permissions” is a real phrase written by adults who picked the name on purpose. Treat it that way.

2. Letting One Conversation Run All Day

The mistake. You started at 9 AM on the AKI cohort SQL. You drifted to the pathology prompt. You wandered into a Power BI question. It’s 4 PM and Claude is suggesting code for the wrong year. This is context rot — the gradual degradation of a long conversation as too many unrelated topics pile up.

What to do instead. Use /clear between unrelated tasks. After two failed corrections, /clear and start a fresh conversation that includes what you just learned. A clean 30-minute session beats a tangled four-hour one every time.

Clinical example. A research fellow at the AI Office spent a whole afternoon trying to debug why Claude kept inserting tidyverse syntax into a data.table script. The conversation had started with a tidyverse analysis at 10 AM. By 3 PM, Claude was working on data.table code but still “remembered” he preferred tidyverse. One /clear fixed it instantly.

3. Pasting an Entire CLAUDE.md from Twitter

What CLAUDE.md is. A file at the root of your project that gives Claude background instructions: your stack, your test command, your rules. We covered it in Chapter 10. Claude reads it every session.

The mistake. Somebody on social media posted a 600-line CLAUDE.md for their startup and you copied the whole file into your project. Now Claude is following rules for a stack you don’t use, in a language you don’t write, with style preferences that don’t match your team’s.

What to do instead. Run /init (which writes a starter CLAUDE.md by reading your code) and then cut the result in half. The litmus test for every line: “Would Claude make a real mistake without this line?” If no, delete it. You have a budget of roughly 150–200 useful lines before Claude starts ignoring them. Don’t burn it on inherited dogma.

4. Describing Bugs Instead of Pasting Them

The mistake. “There’s some kind of error with the date column, I think it’s not parsing right, the second row looks weird, maybe it’s a timezone thing.”

What to do instead. Stop. Paste the actual error. Paste the actual row. Use the ! prefix (Chapter 5) to run a command and put its output straight into Claude’s context:

!python scripts/load_vitals.py 2>&1 | head -50

Claude doesn’t need your interpretation of what went wrong. It needs the data. Your interpretation is often what’s hiding the real symptom.

5. Approving Every Single npm install Forever

What npm install is. A command that downloads JavaScript libraries — small bundles of pre-written code — from the public internet. JavaScript projects use npm (Node Package Manager) to fetch them. Python has the equivalent with pip install. They are how third-party code gets into your project.

What “the allowlist” and “deny list” are. Two lists inside .claude/settings.json. The allowlist names commands Claude can run without asking. The deny list names paths Claude is forbidden to read or write. Together they replace the constant “Approve? Y/N” prompts with one decision made once.

The mistake. Six months in, you’re still hitting the Approve button for npm test and pytest. Each interruption costs three seconds of attention and ten seconds of flow.

What to do instead. Add the safe commands to your allowlist: pytest, npm test, pre-commit run, the gh CLI, git status, git diff. Keep gates up for anything that pushes to remote, installs new code, or touches the internet. The middle ground is the sweet spot.

6. Skipping Plan Mode for Multi-File Changes

What Plan Mode is. A mode you enter by pressing Shift+Tab (we covered it in Chapter 9). Claude writes out a plan first; you read the plan; then it executes. If the plan is wrong, say so — Claude revises it before touching a single file.

The mistake. You typed “refactor the AKI staging logic to use the updated KDIGO thresholds” and hit enter. Claude immediately began editing three notebooks at once. Forty minutes later, the changes don’t pass the eval suite and you can’t tell which file caused the regression.

What to do instead. Use Plan Mode for anything structural. Read the plan. Edit it. Then let Claude execute. The 90 seconds you spend reviewing the plan saves you 90 minutes of un-doing the wrong change.

🧠 Remember. “It went and spent 20 minutes confidently solving the wrong problem” is the most common Claude Code failure mode. Plan Mode is the antidote.

7. Not Reading the Diff Before You Commit

What a diff is. The set of changes between the file as it was and the file as it is now. git diff shows them line by line, with red strikethroughs for what was removed and green for what was added. It is the last chance to see what Claude actually did before the change becomes permanent.

The mistake. Claude is fast. The default rhythm becomes “describe → wait → accept → next task.” Somewhere along the way, you stopped reading the actual code changes.

What to do instead. Always read the diff. Run git diff --stat first to see which files changed, then git diff on the suspicious ones. Claude is good. Claude is not infallible. Boris Cherny has said every single line of his last 30 days of work was Claude-written — but he is also the person who built the checkpoint and review systems into the tool. He is checking.

8. Forgetting the Deny List

What .env files are. Plain-text files in the project root that store secrets — API keys, database passwords, encryption keys. They are named .env (with the leading dot) by convention. They should never be committed to git, never logged, never read by anything but the program that needs them.

The mistake. You’ll add an allowlist on day one. You’ll get to the deny list never. Then one day Claude reads your .env while answering an innocent question about configuration, the file contents land in the conversation context, and you spend the afternoon rotating credentials.

What to do instead. Inside .claude/settings.json, add deny rules for .env, *.key, *.pem, secrets/, and any folder containing patient data (e.g., data/patients/). Claude won’t even discover those files exist. For clinical work this is non-negotiable.

9. Treating Subagents Like Magic

What a subagent is. A separate, focused Claude instance the main session can spawn for a self-contained task. It has its own context window (so it doesn’t pollute yours), its own allowed tools, and its own model choice. Chapter 13 covered them.

The mistake. You read Chapter 13 and decided every task should be a subagent. Now you have five subagents running, you can’t remember what each one was for, and the main conversation is more confused than it was before you delegated anything.

What to do instead. Subagents are for self-contained tasks: “Read these 30 SQL files and summarize what each pipeline produces.” If the task needs back-and-forth with you, keep it on the main thread. If you find yourself coordinating five subagents, what you actually wanted was an agent team (Chapter 13), not a hub of one-offs.

10. Building Without Tests, Then Asking Claude to “Make It Work”

The mistake. You wrote 800 lines of cohort SQL. Nothing tests it. You hand it to Claude and say “fix the bugs.” Claude makes plausible-looking changes. You can’t tell whether they are correct. Two days later somebody asks why the deceased-patient count dropped by 3%.

What to do instead. Tests are how you let Claude work autonomously. The most powerful single instruction in Claude Code is: “Refactor X. Run the test suite. Fix every failure before calling it done.” That instruction can produce a 2–3× quality improvement on the result, but only when there is a test suite. For clinical work, the test is the eval suite against the deceased-patient cohort. Wire it into a Stop hook so Claude can’t claim “done” without it.

💡 Tip. If you can’t test it, you can’t autonomously refactor it. Investing in the eval suite is investing in your ability to use Claude Code on the harder problems later.

Try This

Open whichever Claude Code project you’re working in right now. Check three things, in order:

  1. Does .claude/settings.json exist? Does it have a deny list for .env, *.key, and any patient-data folder?
  2. Does CLAUDE.md exist? Is it under 200 lines?
  3. Is there a test command in the project that Claude knows about (mentioned in CLAUDE.md or wired to a Stop hook)?

If any answer is no, fix it before your next session.

Watch Out

The most expensive mistake on this list is not any single one of these. It is complacency. The moment you stop reading the diff is the moment Claude starts shipping bugs with your name on the commit. Stay in the loop.