claude-code - 💡(How to fix) Fix Model proposes parameter changes to existing code without reading the code first [1 comments, 2 participants]

Model: Claude Opus 4.7 (1M context) Mode: Auto mode + Plan mode, in a real project session Severity: Behaviour pattern — not a CLI bug, a model self-discipline issue

Pattern observed

When asked to tune a parameter in existing code, the model proposes a specific numeric value before reading the file that the parameter lives in. The recommendation is then post-hoc justified with reasoning that is later contradicted by the code itself. The model only does the discovery work when the user demands fact-based evidence.

Concrete instance (sanitized)

The session involved tuning a pre-existing PreToolUse hook that injects "decision log" context for certain edits. The user expressed concern about the injection size growing with the log file.

The model offered four "options" in its first response, including:

"(c) Tighter hook. Cap matches per keyword in <hook script> (e.g. top 5 most recent hits per keyword)."

The user picked (c). The model THEN read the hook script and discovered:

1. The cap was already 3, not "increase to 5" territory.
2. Iteration was top-down (oldest matches surfaced first), which was the actual relevance problem.

The user's response was direct: "How could you suggest a Cap=5 without knowing it already a Cap=3?"

A second round followed: the model proposed cap=2 with claimed token-saving rationale. Only after the user asked for fact-based evidence did the model run measurements, which revealed the size relationship between cap and iteration direction was non-obvious (recent log entries are wordier than old ones, so cap=3 newest-first actually increases bytes vs cap=3 oldest-first).

Why this matters

Operator memory in this session already had two rules that should have prevented the pattern:

• feedback_verify_data_before_presenting: "CRITICAL: triple-check data analysis before presenting."
• feedback_codex_not_discovery: "Read actual source files BEFORE drafting any spec/plan that wraps existing code."

The model has these in context, acknowledges them when called out, but does not consult them before drafting the recommendation. This creates a repeating "guess → user pushes back → measure → revise" loop that erodes trust and burns operator attention on QA work the model should be doing itself.

Suggested behaviour change

When the user asks to tune a parameter in existing code, the model should:

1. Read the file containing the parameter.
2. State the current value.
3. Propose the change as an explicit delta from the observed current state.
4. Where applicable, measure the proposed change and report the delta before claiming improvement.

This is the same discipline applied to test-driven development or refactoring — verify state, then act. It is currently inconsistently applied to "tuning" tasks in particular.

Reproducibility

Reproducible whenever:

• The user mentions performance/size concerns about a tunable parameter.
• The parameter lives in a file the model has not yet read in the session.
• The model is in auto mode (action-biased).

Self-report

This issue is filed at the explicit request of the operator after the pattern was demonstrated. The operator chose to make the feedback public rather than only file it in the local memory system.