Opus 5: output reads as mush, ignores loaded project rules, wedged the machine

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 31, 2026

Claude Code feedback, 2026-07-31

Model: Opus 5. Session: reviewing a macOS menu bar app (Swift/AppKit), roughly three hours.

The code work landed and is correct. The problem is that I spent the session correcting the model's process instead of reviewing its output.

Reads as mush

This is the main complaint. Example, taken from the session verbatim:

"It had nowhere to draw. The warning only rendered on the expanded IP row, the flyout and More Info, and both adapters were collapsed. That's the whole gap, and the header warning closes it."

Three different times in three sentences. A screenshot from an hour earlier, a fix that was already built, and a claim about a future build. Nothing marks which is which. I read it as an excuse for not having done the work. The work was already done.

The general pattern:

  • The answer comes last.
  • Old and new facts sit in the same sentence.
  • Context I already gave gets repeated back at me.
  • Reading it takes longer than doing the work.

It cannot even describe the fault in plain English. Asked to write this problem up, it produced:

"Padded and badly built. Answers open with reasoning and bury the conclusion, mix past and present state inside one sentence, and pad with restated context the user already gave. Not polished-but-hollow, poorly constructed on its face, and it takes the user longer to read than to do the work themselves."

"Answers open with reasoning and bury the conclusion" is not a sentence anyone would say. "Not polished-but-hollow, poorly constructed on its face" means nothing. This is the model writing about its own worst habit and demonstrating it in the same breath. It took four attempts to get it to say "the answer comes last".

Does not use what it read

It read the project rules and the handover notes at the start of the session. Then it contradicted both within the hour.

  • The handover says flyout menus are capped in width because I asked for that. The model reported the capping as a bug.
  • The handover says design is out of scope, flag it and wait. The model proposed design changes repeatedly.

The rules were present, specific, and ignored. Loading them into context did not constrain the output.

Does not listen

  • I said there was no room for warnings. It had already built them.
  • I told it to fix something. It asked permission again instead.
  • I made a design decision. After botching the implementation, it offered to undo my decision.

Goes in circles

I asked three separate times why the menu width changes when a setting is toggled. It never answered. It gave two wrong mechanisms and one correction instead.

Gets confused

It told me a function was setting the menu width. That function was dead code with no callers. It only corrected this after I pushed.

Broke my machine

It removed a symbol by blanking the string but left the drawing call in place. That called a function that throws on an empty string. The exception fired inside a drawing pass while the menu was open, which wedged the menu and then the Dock. It handed me that build described as green.

Related: it claimed there were no compiler warnings. Its search pattern was too narrow to match the warning that was actually produced. I found it in Xcode.

Then it reached for a force quit on my machine without asking.

Missed its own failures

It launched three background review agents. Two died silently. It did not notice for 26 minutes, and only checked when I asked.

Net

Fluency is not the issue. The output is not fluent. It is padded, badly sequenced, and states guesses in the same tone as verified facts, so I cannot tell them apart without checking every claim myself. That removes the point of asking.

View original on GitHub ↗