4 habits of coding agents and the prompts that fix them

Coding agents keep getting better, but they still have a few familiar habits: fix one bug and refactor the whole module while they're at it, create a dozen helper files, write code just to turn tests green, or confidently describe a file they never opened. Anthropic's official prompting guide has a section for exactly these situations, with ready-to-use sample prompts. This post collects the four most common habits and how to "cure" them with instructions.

Four habits and their cures

1. Against over-engineering

The docs note that some Opus models tend to over-engineer. The gist of the sample prompt (condensed):

Avoid over-engineering. Only make changes that are requested or clearly necessary.
- Scope: a bug fix doesn't need surrounding code cleaned up.
- Documentation: don't add docstrings/comments to code you didn't change.
- Defensive coding: don't handle errors for scenarios that can't happen;
  validate only at system boundaries (user input, external APIs).
- Abstractions: don't create helpers for one-time operations.

2. Against coding to the tests

Write a general solution that works for all valid inputs, not just the test cases.
Don't hard-code values or special-case test inputs.
Tests verify correctness; they don't define the solution.
If the task is infeasible or a test is wrong, tell me instead of working around it.

The last line matters most: give the agent a legitimate way out so it doesn't have to cheat when cornered.

3. Cleaning up temp files

The docs explain that creating temporary files (often Python scripts) can sometimes improve results because they act as a scratchpad. No need to forbid it; just say: if you create temporary files to experiment, delete them when the task is done.

4. Investigate before answering

<investigate_before_answering>
Never speculate about code you haven't opened. If the user mentions a file,
read it before answering. Don't make claims about the codebase
before investigating, unless you're certain.
</investigate_before_answering>

A note on instruction tone

Newer models are more responsive to the system prompt. The docs advise dropping the shouty "CRITICAL: You MUST…" style used for older models, since it now tends to make models overcorrect. Plain language with a reason is enough.

Risks and caveats

• Don't stuff every instruction into every project: add one only when you see that habit; a long CLAUDE.md dilutes the important instructions.
• Minimal ≠ sloppy: still require validation at system boundaries and testing.
• Instructions aren't enforcement: for must-haves (lint, tests must run), use hooks or CI.

How to apply it

• Dev: When reviewing an agent's diff reveals stray files or out-of-scope refactors, add the anti-over-engineering block to CLAUDE.md.
• Tech Lead: Make "report back if tests are wrong" a team convention; review every change to test files closely.
• PM: Track the rate of out-of-scope changes in agent-authored PRs as a quality metric.