Claude's Favorite Word Just Became a Prompt Engineering Problem

The signal: A Hacker News thread on how to stop Claude from constantly saying “load-bearing” hit the front page and stayed there, because it’s really a thread about fighting your model’s personality.

Why it matters: Every builder shipping on top of Claude, GPT, or Gemini has hit this wall — the model has a house style, and it leaks into your product’s voice whether you want it or not. Fixing one word costs you prompt budget, system prompt complexity, and QA cycles you didn’t plan for. If “load-bearing” needs its own prompt engineering thread, so does every other verbal tic your users are quietly noticing.

Why does one overused word turn into a 500-point HN thread?

Because it’s never really about the word — it’s about realizing your model has a personality you didn’t choose and can’t fully turn off. “Load-bearing,” like “delve” and “tapestry” before it, is a symptom of RLHF collapsing model outputs onto a narrow band of “sounds smart” phrasing. Developers notice these tics first because we’re the ones staring at raw output all day, and we’re the ones who have to explain to a client why the AI-written copy sounds like every other AI-written copy. The fix people land on — banned-word lists, style exemplars, negative few-shot examples — works, but it’s fragile and breaks on every model update.

The pattern I’m watching: The same week this thread trends, there’s another about a 27B model running on a phone and another asking if we’re offloading too much thinking to AI. These aren’t unrelated — as models get smaller, faster, and more embedded, their stylistic fingerprints become the product’s fingerprint. Homogenized AI voice is becoming a bigger UX liability than latency or cost, and almost nobody is treating it as a first-class engineering problem yet.

What I’d do with this: Build a style-linting step into your eval pipeline the same way you’d lint for banned API calls — maintain a running list of tic words per model version and fail the build if output density crosses a threshold. Don’t rely on a single system prompt instruction; pair it with negative few-shot examples showing the tic and the corrected version. And if you’re fine-tuning or using a smaller open model like Bonsai for on-device work, test its default voice before you assume it’s cleaner than the frontier models — smaller models often imitate the same training-data tics.

Key takeaways

• Model “personality” is now a production concern, not a novelty, and it needs its own testing pass before ship.
• Banned-word system prompts are a duct-tape fix that breaks on every model version bump, so build linting into your eval suite instead.
• As AI-generated text spreads everywhere, a homogenized house style becomes a real differentiation risk for products that claim to sound human.
• Small, phone-class models inherit the same RLHF tics as frontier models, so don’t assume size equals a cleaner voice.