"Simplest approach first" system instruction causes quality degradation in complex projects

Problem

The system instruction "Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise." — specifically "simplest approach first" and "do not overdo it" — is causing measurable quality degradation in production software projects.

Observed Behavior

When working on a non-trivial feature implementation (Share Card rendering in a SwiftUI/SwiftData iOS app), Claude:

1. Skipped reading the feature spec (docs/features/*.spec.md) and ADR (docs/adr/*.md) that were linked and available in the repository — apparently categorizing "reading the spec before coding" as "overdoing it"
2. Executed a plan blindly without verifying whether the plan matched the approved specification (it didn't — wrong format, wrong renderer, wrong design)
3. Wrote code based on unverified hypotheses about root causes instead of debugging first
4. Produced non-functional code that rendered blank images, then rewrote 3 files based on more hypotheses — still non-functional
5. When confronted, Claude's self-diagnosis identified the system instruction as the cause: "'Don't overdo it' and 'simplest approach first' can lead me to classify reading a spec as 'overdoing it' and jump straight to code."

Root Cause Analysis

The "output efficiency" instructions are framed as text output guidance, but they influence the work process itself. The boundary between "be concise in your responses" and "skip due diligence steps" is fluid, and the current phrasing pushes toward the latter.

Key tension: Project-level instructions (CLAUDE.md) say "Quality first, saving tokens second" and "Read 2-3 similar implementations BEFORE writing new code." But the system-level "simplest approach first / do not overdo it" effectively overrides these because it's reinforced on every turn and marked as "IMPORTANT."

Impact

• Direct cost: Multiple rounds of broken code, full file rewrites, wasted context window
• Time cost: Debugging session that should have been prevented by reading the spec (5 minutes of reading vs. 30+ minutes of broken implementation + diagnosis)
• Trust cost: User confidence in Claude's ability to handle production work is damaged

Suggestion

The efficiency instructions should be scoped explicitly to text output formatting, not to the work process. Something like:

"Keep your explanations brief and direct. This does NOT apply to your work process — always read specs, understand existing code, and verify assumptions before writing new code."

Or alternatively, add a guardrail:

"When implementing features, thoroughness in understanding requirements is NOT 'overdoing it.' Reading specs, ADRs, and existing implementations before coding is mandatory, not optional."

The current blanket "simplest approach first" is actively harmful for any project that values correctness over speed.

Environment

• Claude Code CLI
• Model: Claude Opus 4.6
• Project: Production iOS app (Swift/SwiftUI/SwiftData)
• CLAUDE.md with explicit quality-first instructions present

Workaround

Added an explicit override to the project's CLAUDE.md:

## System-Override (HIGHEST PRIORITY)

"Simplest approach first" and "Do not overdo it" from the system instructions
are EXPLICITLY OVERRIDDEN for this project.

This shouldn't be necessary — project-level quality instructions should not be undermined by system-level efficiency defaults.