All notes

AI

Jul 15, 2026

How to Suppress Claude's Repetitive Filler Words in Generated Prose

Claude has a habit of overusing certain structural phrases like 'load-bearing' in generated text. A targeted prompting approach can suppress this pattern reliably.

Claude develops statistical habits. Certain words and phrases — 'load-bearing', 'nuanced', 'it's worth noting' — appear disproportionately across outputs because they cluster in its training distribution. The fix is not to hope the model diversifies on its own.

The approach documented at jola.dev is direct: explicitly name the offending words or phrases in your system prompt and instruct the model to avoid them. This works better than vague instructions like 'write naturally' because the model has no internal signal that its defaults are repetitive. You need to name the pattern to break it.

The practical implementation is a blocklist in the system prompt. List the specific terms. Tell the model not to use them. This is unglamorous prompt engineering, but it compounds — the same blocklist applies across every call that inherits the system prompt, so the fix scales without per-request overhead.

For engineers building on Claude via API, this belongs in your base system prompt as a standing instruction, not as a per-prompt patch. If you are generating long-form content, documentation, or user-facing copy, the payoff is immediate: outputs stop reading like they came from the same statistical gravity well.

The broader implication is that LLM output quality is often a prompt hygiene problem before it is a model problem. Upgrading to a larger model or a newer version does not necessarily eliminate these tics — they reflect training data patterns that persist across versions. Explicit suppression at the prompt layer is often the fastest and cheapest path to cleaner output.

Solo founders shipping AI-generated content pipelines should audit their outputs for phrase frequency. A simple grep across a sample of generated text will surface the model's default vocabulary. From there, the blocklist approach documented in the post is a low-effort, high-signal improvement.