Claude Code: Dos and Don'ts

How to get the most out of Claude Code for scientific work — and a hard list of the things that will get you wrong answers, retracted papers, or both.

Part 1 — Dos

1. Start in plan mode for anything non-trivial.

Press Shift+Tab until "plan mode" appears, or type /plan. A 30-second plan review catches wrong approaches before they cost you an hour of code. Make this a habit for all simulations, model fits, and report drafts.

2. Tell Claude what success looks like, not just what to do.

Worse: "Fit an occupancy model."
Better: "Fit a single-season occupancy model in unmarked with elevation + ndvi on occupancy and effort on detection. Print a tidy coefficient table and a parametric-bootstrap goodness-of-fit p-value. Save the model object to models/occu_v1.rds."

3. Maintain a CLAUDE.md at the project root.

Record your data layout, conventions, known issues, and decisions. Claude reads this automatically. Updating it once saves dozens of "let me remind you..." turns later.

4. Ask Claude to simulate first, fit second.

Before any real-data analysis, ask Claude to (a) simulate data under the model you plan to fit, with known parameters, and (b) refit and check that you recover them. This catches parameterization bugs that would otherwise corrupt your results. (This is Lab 9.)

5. Ask for tests, not just code.

"Write process_detections.py and a test_process_detections.py with at least three unit tests, including one for the case of an image with no detections." Tests make your code robust to Claude (or you) silently changing behavior later.

6. Use version control. Commit before and after a Claude session.

git init, then git add -A && git commit -m "before claude" every time you start. If a session goes sideways, git diff shows you exactly what changed and git restore rolls it back.

7. Make Claude show you its work.

"After fitting the model, print (i) the data dimensions you used, (ii) the formula you fit, (iii) the coefficient table, and (iv) the random seed." A model that "ran" but whose inputs you can't recite is a model you can't defend in a manuscript.

8. Split a long task into checkpoints.

For a multi-day analysis: ask Claude to do step 1, review, commit. Then step 2. A 3-hour autonomous session that produces 800 lines of code is almost always worse than three 1-hour sessions producing 250 lines each, because you can sanity-check between them.

9. Paste the exact error, not your paraphrase.

"I get an error in line 42" wastes turns. Paste the full traceback. Claude is very good at reading tracebacks.

10. Use /clear when you change topic.

A 100-message context where you went from data cleaning to model fitting to manuscript drafting will make Claude slower and more confused. Clear the context, summarise the state of the project in one paragraph, and start fresh.

Part 2 — Don'ts

1. Don't trust statistical model output you haven't validated.

Claude will cheerfully write a 200-line Stan model that "converges". That doesn't make it correct. For any statistical conclusion you will publish: simulate, recover parameters, write down what the model assumes, and check it.

2. Don't paste sensitive data.

Camera-trap GPS coordinates of endangered species, tribal partner data, embargoed datasets — treat anything you send to a cloud model as if it could be logged. If you must process such data, run Claude Code against local files (it does not upload them unless you explicitly attach them to a message).

3. Don't let Claude pick the statistical method for you.

If you ask "How should I analyze this?" Claude will pick something plausible-sounding. It will not always be the right thing for your sampling design. Decide the method yourself (from your training, an advisor, or a textbook), then have Claude implement it.

4. Don't accept the first answer to a numeric question.

"How many species are in this CSV?" → Claude says 47. Verify in your own head or with one line of code. The hardest mistakes to catch are the ones that look right.

5. Don't submit AI-generated scientific writing verbatim.

You're a scientist, and your conclusions in a manuscript must be in your own voice. Claude can edit your prose for clarity — that's fine, that's just a copy editor. It should not draft the interpretation of your results for you.

6. Don't give Claude blanket Bash permissions.

The convenience of approving Bash(*) is real. So is the day Claude misreads your intent and runs rm -rf data/. Approve narrow command classes (see the setup tutorial).

7. Don't ignore "I can't find that file" or "I'm not sure".

When Claude expresses uncertainty, take it seriously. The failure mode is not that it stops — it's that it guesses. If it's not sure where detections.csv lives, tell it explicitly. Don't let it pick a random CSV that happens to be nearby.

8. Don't use Claude as a citation generator.

Claude will produce confidently formatted references that do not exist. If you need a citation, look it up yourself (Web of Science, Google Scholar, your reference manager). Use Claude to find candidate keywords and to format already-real citations into BibTeX.

9. Don't ask Claude to "make the model fit better".

This is how p-hacking happens. If a model doesn't fit, the answer is to (a) check assumptions, (b) report the fit honestly, (c) try a different model with a written-down justification — not to keep tweaking until something is below 0.05.

10. Don't treat a passing run as a passing analysis.

Code that runs without errors is the lowest bar. Code that does the right thing on data it hasn't seen, with the right assumptions, and produces results that match a simulation — that's a passing analysis. Always ask: "How would I know if this were silently wrong?"

Worked example: prompt rewriting

A bad prompt and a good one for the same task.

Bad

"Use the camera trap data to figure out which species use the trail more at night."
Why it's bad: doesn't say where the data is, what "use" means, what "night" means, how to handle multiple detections of the same animal, what output is expected, what to test.

Good

"In this project, data/detections.csv has columns image, datetime, species, confidence, site. For each of the 6 species with ≥100 detections, compute the fraction of detections occurring between sunset and sunrise (use astral with site coordinates from data/sites.csv). Aggregate detections within 60-minute windows per site so we're not double-counting one animal lingering. Output a tidy CSV results/nocturnality.csv with columns species, n_indep_detections, frac_nocturnal, ci_lo, ci_hi, with 95% CIs from a binomial likelihood. Plot a forest plot to figures/nocturnality.png. Use the R packages we have in CLAUDE.md; if you need a new one, ask first."

A short checklist before you call an analysis done

  1. Can I describe, in one sentence, what model was fit and to what data?
  2. Did I simulate from this model and recover the parameters?
  3. Did I write down the assumptions and check the ones I can?
  4. If I removed the AI from the loop today, could I re-run this analysis tomorrow?
  5. Have I disclosed where I used AI in the manuscript or report?

If all five are yes, you're using Claude Code well.