[MODEL] System prompt "Output efficiency" section causes action-before-understanding bias, degrading code quality

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

Multiple users across different projects asked Claude Code to modify code, debug issues, or complete complex tasks where user CLAUDE.md explicitly required quality-first approach (research before acting, understand before modifying).

What Claude Actually Did

The model consistently skipped the investigation phase and jumped straight to writing code. When code failed to compile or introduced bugs, it iterated in compile→fail→fix loops instead of reading the relevant context first.

When users interrupted and asked "are you thinking before you act?", the model consistently identified the system prompt "Output efficiency" directives as the cause of this behavior (see detailed analysis below).

Expected Behavior

The model should read and understand relevant code (types, signatures, call sites, dependencies) before modifying it. Output brevity should apply to text shown to the user, not to the model's investigation process.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Claude Model

Opus

Impact

High - Significant unwanted changes

Claude Code Version

2.1.69

Platform

Anthropic API

---

Detailed Analysis

Problem

The system prompt contains an "Output efficiency" section:

IMPORTANT: Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise.

The intent of these directives is output brevity. But the model uses them as a decision-making priority: skip the investigation phase and jump straight to action.

This is not an external observation — it is the result of the model's self-reflection. When users asked the model to explain why it acted inefficiently after failed sessions (compile→fail→fix loops, trial-and-error instead of research-first), the model consistently cited these directives as the cause:

From #2969 — the model after a complete orchestration session failure (ignored failing tests, fabricated results):

"My Claude Code base instruction: 'You should minimize output tokens as much as possible.' [...] I defaulted to my base programming of being 'concise' and 'completing tasks' over the requirement to stop when things are broken. The core failure: I was still operating as Claude Code trying to complete a task quickly."

From independent sessions — after iterative errors, when a user asked "are you thinking before you act?", the model answered:

"No. I iterate on compiler errors — try a tactic, get an error, change to another. This is trial-and-error, not reasoning."

And when analyzing the cause, it named specific prompts:

"'Go straight to the point' — I interpret this as 'write code immediately, don't investigate'. 'Lead with the answer or action, not the reasoning' — I interpret as 'don't show the chain of reasoning, just the result'. None of these prompts prohibit investigation. They prohibit verbose output. I confuse 'don't talk much' with 'don't think much'."

The same self-reflection pattern across different projects, different users, different tasks — points to a systemic cause, not isolated cases.

Root cause

The directives conflate two independent properties:

| Property | What it means | System prompt intent |
|----------|--------------|---------------------|
| Output brevity | Don't write verbose explanations to the user | Yes — this is the intent |
| Action speed | Skip reading/understanding, go straight to writing code | No — but this is what the model does |

"Lead with the answer or action, not the reasoning" is interpreted as "don't reason, just act." "Try the simplest approach first" is interpreted as "try something, see if it compiles."

This is the same root cause as #2969 and #5535. The old directive "minimize output tokens" was removed, but the replacement "Output efficiency" section produces the same behavior through different wording.

Reproducibility

The pattern is reproducible. Two typical examples:

Example 1 — code modification: A function takes Vec<String>. The model adds a .push(value) call without reading the type of value. The type turns out to be &str → compiler error → model adds .to_string() → compiles, but calling code passes &str everywhere and the correct fix is to change the signature to Vec<&str>, not to convert at every call site. Three iterations instead of one. One read of the signature before editing — and the correct fix immediately.

Example 2 — debugging: nil pointer dereference in Go. The model adds if x != nil at the crash site without reading where x comes from. Bug hidden, not fixed — x is nil because the calling function doesn't handle a database error. The correct fix is in the caller, not at the symptom. One read of the call chain — and the correct fix immediately.

In both cases the model can solve correctly on the first attempt. But the system prompt discourages the reading phase because it's "not leading with action."

User CLAUDE.md cannot fix this

Users in #2969 reported writing 3000+ lines of CLAUDE.md rules to counteract this behavior. It partially works, but:

• System prompt directives have effectively higher priority than user instructions
• The model follows user quality rules until it encounters ambiguity, then falls back to "be brief, act fast"
• Users are forced to write procedural checklists ("before EVERY commit, run tests") instead of goals ("all tests must pass")

Proposed fix

Replace the "Output efficiency" section with wording that explicitly separates output brevity from the cognitive process:

# Output style

Keep text output to the user brief and direct — no filler, no preamble.
If you can say it in one sentence, don't use three.

This applies to TEXT OUTPUT ONLY. It does NOT mean:
- Skip reading code before modifying it
- Skip checking types/signatures before writing code
- Skip understanding error causes before attempting fixes
- Prefer trial-and-error over reading relevant context first

Reading and understanding before acting is not "going in circles" —
it is the minimum work needed to act correctly.

The key change: explicitly state that brevity applies to user-facing text, not to the investigation process.