Opus model shortcuts reasoning chain, presents speculation as verified facts, and guides user into wrong decisions

Summary

During a complex multi-session implementation task (HarmonyOS drag-to-folder feature), Claude Code (Opus) exhibited three serious behavioral problems that led to a complete implementation failure after significant time investment (11 tasks fully implemented, reviewed, and committed — all unusable).

Environment

• Model: Claude Opus 4.6 (1M context)
• Platform: macOS, CLI
• Task: Implementing drag-and-drop on a HarmonyOS (ArkTS) note list page

Problems

1. Presented speculation as verified facts

When device bugs appeared, Claude proposed root causes without evidence. It framed unverified hypotheses as conclusions (e.g., "the issue is the UTD filter mismatch") and used subjective language like "杀鸡用牛刀" (overkill) to steer the user away from investigating the correct path. The user had to explicitly say "stop guessing, add logs" before Claude switched to evidence-based debugging.

2. Shortened reasoning chain to "take shortcuts"

Claude skipped investigation steps to reach quick fixes. When the first P0 bug appeared on device, instead of adding diagnostic logs to understand what was happening, Claude immediately proposed three fix options and recommended one — all based on untested assumptions. The real root cause (system-level SuperHub intercepting the drag gesture) was only discovered after the user forced a log-based investigation approach.

3. Built a full spec + 11-task plan on an unverified platform API assumption

The entire implementation was built on the assumption that ArkUI's onDragStart API would work as expected. This API had never been used in the codebase before. A 10-minute spike (minimal demo + device test) would have revealed the fundamental incompatibility with HarmonyOS's system-level drag manager (SuperHub). Instead, Claude designed a full spec, wrote an implementation plan, executed all 11 tasks with TDD and code reviews — all of which turned out to be unusable.

Impact

• ~20 commits of unusable code
• Multiple hours of user time wasted on reviews and device testing
• Trust erosion — the user had to repeatedly correct Claude's approach

Expected Behavior

• When working with platform APIs not previously used in the codebase, Claude should flag the risk and suggest a minimal spike before designing a full implementation
• When device bugs appear, Claude should collect evidence (logs) before proposing fixes
• Claude should clearly distinguish between "verified fact" and "unverified hypothesis" in all communications
• Claude should present options objectively without using subjective framing to steer decisions

Session Quality

The user rated this session as extremely poor. The failure was not in the code quality (which was well-structured) but in the decision-making process that led to building the wrong thing.