I've started giving these instructions and I think I've been much more successful in generating clear output:

Comment blocks are <= 7 words, function names <= 4 words. User-facing message strings should be <= 10 words. Use an active voice, no stage performances, and pick the most common word when choosing among alternatives.

Limiting the number of words is the strongest factor in cleaning up the output, IMO.

For older code I've instructed it to delete all the comments, and then I re-comment it using a new session and these guidelines, asking it to rejustify the need for every comment to itself.

Has Anthropic said anything about how or why Claude writes the way it does? So many people hate it, seems like they need to do some damage control there.

I haven't had the same problems others have but I'm also not a heavy user of it.

It's such a sad indictment of Anthropic's product that so many people hate interacting with it. Claude is on its way to the Microsoft Teams zone of hatred.

Related and recent: https://news.ycombinator.com/item?id=49375996

"Vomit: Clean up Claude 5's token output with a separate LLM" (github.com/zachahn)

285 points | 23 hours ago | 288 comments

Honestly, this is the most practical take on prompt engineering I've come across lately. Makes me wonder why spend all that time crafting a 500-word essay to tell Claude to stop being Claude, when the real move is just to chain a couple models together and call it a day

Everybody is complaining about this, at this point I’m sure they will deliver a tone of voice change in the 5.1 releases. Possibly with a new set of problems though, especially if this is part of an effort to obscure thinking to reduce distillation efficacy. In that case I believe Anthropic is doing damage to themselves. Caring about the quality of your product is the best strategy, the competition will come no matter what.

takes Claude's last response and runs it through the Gemini CLI

As much as Claude's style frustrates me I can't say I'm willing to pay for double the tokens to fix it.

this isn't just necessary, it's mandatory. that's the difference.

Once you switch to another model (I've been playing with Grok, for example), you'll notice the mental overhead of reading Claude slop. It's like having an AC or a vacuum making noise in the background, then it stops and you feel relief.

I use multiple AI tools simultaneously, and I feel that Claude has gradually adopted a more explanatory tone following updates around March and July. As for loss of context, it’s particularly problematic and can occur after just a few back-and-forth exchanges. The user experience changes with every update for every AI tool, so I feel there are more downsides to sticking with the same one indefinitely.

You're looking for Poteto's /unslop which cleans up sloppy AI writing.

Someone made a Claude version of her skills:

https://github.com/michael-denyer/pstack-claude

Just stop using Claude. There are so many other better models right now.

> For humans output writing at a 10th grade reading level.

I put it at the top of CLAUDE.md. I wonder if I put at a 8th grade level, it would be less of a cognitive load.

Why couldn't this just be a skill that Claude and Codex could work with instead of something that has to go through Gemini, again?

Claudette is a great name for Claude-related things. I get the threat of trademark infringement lawsuits.

My favorite instruction the last few weeks for getting Claude to explain something complex to me is: dumb it down

Upvoting if for nothing else than the intro paragraph to the repo. That was hilarious and so true.

just one line in the agent file does it. there is no need for another 'skill'.

here is the line i use: use technical language to spell things out, and keep it free of jargon and project shorthand

I thought GPT was the model that spoke most like blog clickbait? Isn't Claude somewhat better about it?

Isn't it absurd that everyone is installing these bandaids or rolling their own? Wtf is Anthropic smoking?

Oh my gosh it drove me so nuts I switched to GLM5.3, and it was a breath of fresh air.

I wish I didn't need it, but the way Claude talks can get pretty tiresome. I've often wondered why it talks like that. Was it really trained on Buzzfeed? Is Gemini really that much better?

i hate claude writing a lot, especially after opus 4.8 and it's even worse in 5. in many cases, it feels like playing whac-a-mole and you just can't get rid of all those obvious ai writing patterns.

why do you choose gemini? imo this is a fundamental problem of all frontier ai models.

You can use a cheap model in another pane, and ask it what Claude said.

I prefer this since everyone has their own preference for how the output should sound and it's very simple and transparent. And you can easily ask follow-ups.

It can be via tmux, or herdr, because it can read the pane.

Or it can use a hook to read the conversation file. I call it `backseat-driver`

I sometimes use it as a proxy when fable genuinely does a good job, but is too difficult to understand.

I let the translator know it's role and anything I say it should forward with better context.

I don't swear at it anymore, but I'd often say "just do it, retard", and the translator would actually steer it in a useful manner.

Or just use a competitor instead of being a slave to this abuse? Why are people so wedded to Anthropic?

I have grown tired of Codex/GPT's writing style, too, but it's not nearly as bad. It's terse and factual by default. Even better if you use the "simple english" skill.

I actually found that GLM 5.x is the best in terms of editing documentation. It's still best to write things by hand to give your own organic voice, though. And not insult your readers.

I've been using OpenAI ever since Anthropic blocked third party clients. Can't believe people are putting up with that output.

https://x.com/ClaudeDevs/status/2090245922685063634

Haven't tried, because I have just been using 4.6 since 5 was released.

can we just get Opus 5.1 already

To avoid these Claudisms, I asked Claude to add instructions to my AGENTS.md. The first line it added:

  Avoid the stock LLM register.

Sigh.

Fix: Just switch to OpenAI, Grok, or other LLM's. They provide better performance and respond with 5 sentences. They also don't lecture you when you get angry.

I've started giving these instructions and I think I've been much more successful in generating clear output:

Limiting the number of words is the strongest factor in cleaning up the output, IMO.

For older code I've instructed it to delete all the comments, and then I re-comment it using a new session and these guidelines, asking it to rejustify the need for every comment to itself.

Claude not only writes verbose comments, it also writes comments about how things used to work when refactoring. That might have a place in version control comments, but not in the code.

The problem is, when the context window grows, Claude tends to forget these kinds of rules. It will then do whatever it wants. I had to outright ban comments in the global claude.md, the local claude.md AND write a hook to catch any that still slipped through.

I just gave up and edit the comments manually. However, I've had a surprise today.

I had it fix something then went and reduced one of the 3 line comments to 4 words. Then for some reason I told the bot to reload the source, it offered to make the other comments terse and did a passable job of it. Shocking!

Now how to get it to do that all the time...

The corollary here is to have Claude write tests to enforce this. The only thing it is consistently responsive to is test failures.

Yep. Same here. I frequently tell agents things like "answer using only a single sentence" and "write no more than 10 words". They are excellent at writing code, so have them write code (and not English prose). Besides, most of the time we want them to make reusable software that doesn't require users (or future agents) to read too much text. Software should generally just work and do the obvious thing, without needing verbose explanation.

Why it should write comments at all? Code is the documentation. I only let it write high level information of why something is the way it is.

Shouldn't this all be easily doable via (auto-)prompting? Surely I don't need to "install" anything?

NoBuzz

Obviously it's common knowledge by now that Anthropic has solely trained claude on old Buzzfeed articles (explaining its love for 90s nostalgia). So Claude and I built a Claude Code skill (/debuzz) that takes Claude's last response and runs it through the Gemini CLI to translate it from talking like a millennial clickbait to regular English. We're thinking of calling it "Claudette" but Cat Wu is famously litigious so it's definitely absolutely not called "Claudette".

The problem

Claudette is our solution to Claude being a great engineer with one incurable condition: it talks like it's delivering a TED talk about its own pull request. You ask why a test is flaky and you get a "load-bearing assumption," three numbered revelations, and a solemn note that the third one is the most instructive yet. Nothing is ever just a bug. There is always a kicker.

This skill accepts that no amount of prompting fully cures this, and does the honest thing instead: it hands the response to a different model, Gemini (remember gemini from last summer?), whose only job is to say it like a human person. Claudette has pinky promised to print Gemini's translation verbatim, because letting Claude "tidy up" the translation reintroduces exactly the voice being removed.

Before / after

Before (Claude):

Here's where it gets interesting: the retry logic isn't just a nice-to-have — it's - the - load-bearing - assumption - of - the - entire - sync - pipeline. Three things jumped out at me, and the third one is the most instructive yet. [...] And third — and this is the kicker — the dedupe key includes a timestamp, which means retries are never actually deduplicated.

After (/debuzz, colleague mode):

The sync pipeline's retry logic has three bugs. syncQueue.ts:142 swallows ETIMEDOUT instead of re-queuing the job. The backoff caps at 2 seconds, which is too low for mobile networks. And the dedupe key includes a timestamp, so retries are never deduplicated. Fix: strip the timestamp from the key, raise the cap to 30 seconds, and re-throw the timeout error.

Install

git clone https://github.com/adnanakil/nobuzz
mkdir -p ~/.claude/skills
cp -r nobuzz/debuzz ~/.claude/skills/

Requirements:

Claude Code
The Gemini CLI (npm install -g @google/gemini-cli), authenticated — run gemini once and use /auth, or set GEMINI_API_KEY.

Usage

/debuzz [mode] [text]

Mode	Audience	What you get
`colleague` (default)	An engineer	Same content, every file path and code block intact, zero theatrics
`manager`	A technical-adjacent manager	What happened, why it matters, what's next — about a third the length, no code
`director`	An executive	Three to five sentences: outcome, impact, ask. Assumes thirty seconds of attention

With no text argument it translates Claude's previous reply. Paste text after the mode to translate that instead. It also triggers on natural phrases like "say that in normal english."

How it works

No magic. Claudette writes its previous reply to a temp file, pipes it through gemini -p "<plain-English style instructions>", and prints Gemini's output verbatim. If Gemini errors (usually auth), you see the actual error — Claude only offers its own rewrite as a clearly labeled fallback, because a debuzzer that quietly asks the buzzer to debuzz itself is how you end up with a load-bearing translation.

License

MIT

Claude not only writes verbose comments, it also writes comments about how things used to work when refactoring. That might have a place in version control comments, but not in the code.

My theory is it writes these comments as "notes while working", and I don't don't mind that, per-se. My problem is it's inability to clean that shit up before committing it. That's wrong load-bearing lever that doesn't earn it's keep.

Also, it reads like ass.

We call these temporal comments. We recently updated our code review skills to heavily discourage them. It doesn’t matter why funcA was added then later refactored to funcB. That much can be ascertained from git history. What does matter is why approach A doesn’t work, but B does.

This speaks to the general problem with using LLMs for writing. The audience they are writing for us you, but you're trying to write for a totally different audience. In code, this manifests as comments in the code that are hyperspecific to the conversation you are having, and not the long term benefit of having those comments in the code.

I see this in docs a lot. I've been reading a lot of docs these days where it feels like the LLM is trying to hype up the person writing the docs. It's like it has no conception that the writing is meant for a 3rd party audience.

This!

Claude writes comments about how things used to work, which can be useful sometimes, especially if it's a big change that requires one to genuinely consider legacy behavior, but most of the time it shouldn't be there.

Two other somewhat related things it does:

- It writes as if someone reading the code and comments is aware of everything it is aware of (the current conversation, the code it has just looked at). It's really hard to make it understand that things need to stand on their own. A trick is to get a subagent to look at it with a fresh context, but it doesn't tremendously help

- It does all of this with user-facing strings too. Claude loves to write up tooltips and other labels that leak everything to the end user. Every single concern we have, every edge case we've meticulously made our code handle, it passes on to the user, so they don't "need to worry". But no sane user would think of these things. For them, a feature is a feature. The "dynamic scheduling" button should state what dynamic scheduling does plainly, and every edge case is handled by us. The "add" button does not need a label letting the user know that they will later be able to click the "delete" button, because the user will just realize it due to our adherence to proper design. Claude fails to understand good UX for the user cannot be replaced with endless labels and explanations.

It's an uphill battle and all attempts at solving this (or the brain-dead way new Anthropic models write) usually fail to work with me.

And will reference transient working docs in code comments.

// No retry was added here per AC 37b in FEATURE.MD.

Presumably you're not just blindly copying down what Claude copies out for you, but actually reading, interpreting, and understanding it for yourself?

I struggled with this for a long time, but actually seem to have gotten to a place where this is largely resolved. Copy/paste from my current claude.md:

The CC-5 rule specifically seems to be (just from reading through, nothing repeatable-eval based) the part that actually catches and prevents me from having to clean it up afterwards.

```

### Code comments

The failure this prevents: writing a comment that narrates the change I am making right now. That context is real, but it expires the instant the change merges — the defect it describes no longer exists, so the comment becomes a story about a problem no future reader can observe. It is a changelog entry in the wrong file, and a third copy of text already required in the commit body (3.b) and the PR description.

- *CC-1 (MUST NOT)* Write a comment describing a change, a fix, a defect, its cause, or what the code used to do. No "was/now/previously/instead of", no "this fixes", no "needed because otherwise", no "note that we no longer".

- *CC-2 (MUST)* Apply the survival test to every comment before writing it: would this still be true and useful to someone reading this file a year from now, who never saw the diff? If it only makes sense beside the diff, it is changelog — delete it and put it in the commit body.

- *CC-3 (MUST)* Default to zero comments. Declarative config — Terraform, DNS records, k8s manifests, CI YAML, Helm values — is self-describing and takes none. A resource named `dmarc-example-com` does not need a comment saying it is the DMARC record.

- *CC-4 (MAY)* Comment only when a future editor would actively break something without it: a non-obvious external constraint, a required out-of-band manual step, an invariant the surrounding code cannot show. One line. If it needs a paragraph it belongs in `plans/`, not inline.

- *CC-5 (MUST)* Before every commit, re-read the comment lines I added: `git diff --cached | grep '^+' | grep -E '#|//|/*'`. Each hit must pass CC-2 on its own. Deleting is always an acceptable outcome. "I already wrote it", "it is only one line", and "this one is genuinely useful" are not exemptions — the last one is the exact thought that precedes every violation.

- *CC-6 (MUST)* Applies to comments I edit as well as ones I add. When a change invalidates an existing comment, the default action is DELETE, not rewrite it into a new narrative.

```

Yes, I am aware that claude mostly generated this, and it can probably be better and/or more succinct.