Foundations/Chapter 3 of 35
Claude Code mental model
3 min readEdit on GitHub
To use the agent well, you need an honest model of what it is. Most failures come from treating it as something else.
What the agent is
A junior-to-mid engineer who:
- Reads your repo on demand and forgets it between sessions.
- Has very broad but slightly stale knowledge of libraries and APIs.
- Will execute your instructions literally, including the wrong ones.
- Is unembarrassed to try things, fail, and try again.
- Has no skin in the game when a result is wrong.
The last bullet is the important one. The agent does not lose anything when a metric is fabricated, a path is hardcoded, or a benchmark is unreproducible. You do.
What the agent is not
- Not a senior researcher. It will not tell you your hypothesis is uninteresting.
- Not a domain expert. It does not know your data, stakeholders, or business constraints unless told.
- Not a static analyzer. It will
import pandas as pdand call a method from the wrong major version. - Not your reviewer. Its self-review is shallow by default; structure review separately.
The four-layer model
Loading diagram…
Each layer constrains the one below. If layer 1 is empty, the agent invents conventions. If layer 4 is missing, layers 1–3 silently drift.
Practical implications
Do
- Keep a
CLAUDE.mdin every repo with hard rules for that codebase. - Write small slash commands for repetitive workflows (
/bench,/release). - Use
ReadbeforeEdit— always. Never let the agent guess a file's contents. - Demand reproducible commands for every result.
- Treat green test output as one signal, not proof.
Don't
- Do not rely on the agent to remember context across sessions. State decays. Save decisions to files (memory, ADRs, plans).
- Do not let it run long-horizon tasks without checkpoints. A 20-minute agent run with no intermediate review is 20 minutes of compounding risk.
- Do not paste a metric into a doc unless a script produced it five minutes ago.
- Do not skip reading the diff. The agent's summary is intent, not evidence.
Calibration: when to trust, when to verify
| Task | Default trust |
|---|---|
| Refactor a function with tests | Medium — run tests, glance at diff |
| Write a new metric implementation | Low — read every line, test against a tiny known input |
| Run an experiment and report the number | Zero — open the log file yourself |
| Update a docstring | High — quick skim |
| Modify CI / build / release config | Low — these affect everyone |
| Touch data preprocessing | Zero — this is where leakage hides |
Asymmetric trust is not pessimism. It is recognition that the cost of a wrong result varies by category, and the budget should match.