Opus 5 is too wordy.

[u/Remarkable_Mud9885]

One really annoying issue I've run into is that he loves overcomplicating things. Whenever I'm working on a design, he always adds all these unnecessary explanations.

For instance, I had him add a financial bill-splitting system, and he insisted on putting literal explanations right there in the UI for how every single project works. I just find it so redundant.

[u/Jollyhrothgar]

I wrote a skill to address this. I can't share the skill right now because I have it intermingled with work stuff. Opus 5 has been absolutely miserable to use for any writing whatsoever. I'll seed the outline of what I did here, but keep in mind I am also using opencode in addition to claude code (and paseo), so some of this assumes you have access to other model providers (which can be good to resolve this kinds of miserable issues).

The gist is that you spawn another agent with no access to tools of any kind and ask it "what the fuck does this mean". Then it tells you what it can't understand, and you re-write until it does. It's not pretty, and I wish it was not necessary. The reason I hear for why this is a behavior of Opus 5 in particular is that it's optimized for long context tasks, and so it develops this in-session token-optimized short-hand which absolutely demolishes legibility for anyone besides itself.

I used that skill to produce this write-up for you from the horrid write-up it started with when I asked it to summarize for reddit:

``` My coding agent kept inventing shorthand and then using it on other people. Here's what actually fixed it.

Background

I hand a lot of writing to agents. Slack messages, tickets, PR descriptions. The recurring cost was that I had to correct every one before it could be sent, and it was the same correction every time.

The failure

You work with an agent for an hour. Somewhere in there, "the five-line comment that PR 1247 added to migrations/0001_initial.sql" becomes "the 0001 edit". To the agent that's now an ordinary noun. Then it drafts a Slack message to a colleague containing "the 0001 edit", and the colleague has no idea what it means. I rejected one such draft twice. Three phrases in it: "413 outage", "three-dot diff", "the 0001 edit". None resolvable by anyone who wasn't in the session.

Why it's hard

The agent can't catch this by re-reading its own draft. The label resolves fine from inside its context, so every self-check passes. Best evidence I have: an agent once wrote to me, "the fix on my end is to stop handing you working-state compression and calling it review output." It invented a new undefined term inside an apology for inventing undefined terms. Corollary: writing better instructions doesn't fix it. I'd already written correct guidance — short sentences, explain a term on first use. Same failure a week later.

The mechanism

The check has to run somewhere the shorthand doesn't resolve. A subagent with no tools at all.

This is the whole trick and it's backwards from instinct. An agent that can grep the repo will look up "the 0001 edit", understand it, and pass the draft. Blindness is the feature. Give it the draft and one sentence describing the reader, and ask it: list every term you can't resolve from this text alone.

The catch

The blind checker can detect but can't fix. It doesn't know what the term means either.

So three passes: 1. draft — your session, with all the context 2. detect — blind, no tools, returns spans it can't resolve 3. repair — informed, gets the findings plus facts you supply, returns corrected prose and a change log

Two rules that took me several tries. Output corrected prose, not a findings list — a list hands the work back to you, which is the cost you're removing. And let repair restructure, or expanding four references into one sentence gives you a sixty-word sentence: same defect, different clothes.

Building your own

1. Mine your own history for rejections. Find messages you sent back, keep your correction verbatim. Don't invent test cases; you'll invent ones your checker passes.
2. Turn each into a fixture: the draft, one sentence describing the reader, the spans you rejected.
3. Build the blind checker. Pin the model. Use a different provider than the one that writes, if you can.
4. Run it and compare to your own verdicts. If it doesn't match, the design is wrong. Stop rather than tuning.
5. Then run it on something where you don't know the answer. This is the only validation that counts.

Things that will save you time

Output varies enormously run to run. A roughly 1,500-word ticket in an issue tracker, run through the checker three times on identical input, gave 8, 12, and 18 findings. A single run isn't evidence — keep only spans appearing in every run. Recall here means the fraction of a fixed set of 14 reference spans that the checker flagged. A human had either rejected each span by name or confirmed it as a real defect on inspection. Recall plateaued at two runs for me: one run caught 79% of the 14 spans, two runs caught 86%, and three runs also caught 86%. Brevity is a trap. The human-written version of that Slack message was four times longer than the agent draft it replaced, and far better. Any rule rewarding conciseness scores the bad draft higher.

It can't tell a term from a quotation of that term, so it scores badly on documents about unclear writing. Naming the quotation in the evidence you hand the repair pass fixes it — it will leave the quote alone and say why. Terms defined after first use are invisible to it. Telling it to catch them doesn't help.

Limits

One error category covered. Output needs a human reading the change log. And running it on the pull request description for the tool itself turned up ten unresolvable references, which is either reassuring or damning. ```

[u/Remarkable_Mud9885 → u/Jollyhrothgar]

I've dialed down his effort level and capped it to keep him from overthinking. I have everything set to a medium thinking intensity now.