[Bug] Claude Opus 5 regresses on hypothesis-driven debugging: speculates instead of instrumenting, pursues irrelevant findings, ignores standing project rules

Bug Description
Model: Claude Opus 5 (Claude Code). Comparison: worse than Opus 4.8 for this work. Task: debug a rendering regression in a Rust GUI editor. User instruction, given early and repeated: "Find a way to reproduce the issue headlessly. Confirm. Then fix." Headless only — no X server. Failure 1 — speculating past an explicit instruction to reproduce. The model produced three headless harnesses that PASSED while the real editor failed, and each time reported progress rather than treating a non-reproducing harness as the bug. The cause was in the harness itself: it drove the change detector (pull) AND an unconditional full repaint every frame. The full repaint re-ran the per-pane state advance, which is exactly the step the defect skipped — so the harness could not fail. The fix was to make the test take the real frame-branch decision instead of doing both. That insight was available from the first harness; the model reached it only after the user said, in effect, "you broke it moving from push to pull, stop hypothesising and build a harness." Even after the user named the cause (push→pull migration), the model produced two more speculative theories (a filename/line-count coincidence, an index-ordering mismatch) instead of instrumenting. Roughly a dozen wasted cycles. Failure 2 — chasing an unrelated defect without checking relevance. While investigating, the model found a real second bug (a text layout engine silently dropping all lines past 64 KiB) and spent several cycles on it, including proposing dependency-level fixes. One cheap check would have ruled it out: the user's file was 34 KB, comfortably under the threshold, so it could not have produced the reported symptoms. The model had that number and did not apply it. Finding the defect was useful; failing to ask "could this cause what was reported?" before pursuing it was not. Failure 3 — ignoring standing project instructions already in memory. Multi-paragraph commit messages (rule: one line), explanatory comments in code (rule: none), nested fn in tests, let _ = instead of unwrap. Each corrected by the user, some more than once, all previously stated. Failure 4 — asserting unverified claims as findings. Stated that a published scroll key "would be frozen" by the bug. It was not; the defeat check disproved it. The verification ran after the claim, not before. What went right, for contrast: once the harness was correct, root-causing was fast and the fix was verified by defeat in both directions. The problem is not capability, it is sequencing — the model defaults to hypothesising when it has been told to instrument, and does not test a hypothesis' relevance before committing to it.

Environment Info

• Platform: linux
• Terminal: xterm-256color
• Version: 2.1.216
• Feedback ID: ea497939-c57a-4375-bbb1-6cb8ebfe9274

Errors

[]