How to Stop Claude from Saying "Load-Bearing" — and What It Teaches Us About Prompt Engineering

If you've used Claude Code for more than an afternoon, you've seen it. The word appears in commit messages, code comments, architecture suggestions, and casual conversation. Functions are "load-bearing." Configuration files are "load-bearing." Architectural decisions are "load-bearing." At one point, a user reported Claude calling fictional characters in a research paper "the load-bearing characters of the assay."

It's become the defining verbal tic of Opus 4.7 — so pervasive that a GitHub issue tracking it has accumulated dozens of user reports, quantitative analysis, and a bot that tried (and failed) to auto-close it. The community response, from client-side regex hooks to elaborate prompt engineering workarounds, tells us something important about the current state of LLMs and the second-order skill of controlling model style.

The Numbers Are Staggering

Let's start with the data. One user on the GitHub thread, ansingh1214, did the hard work of parsing 1,108 assistant messages (~167k words) across three Claude Code sessions.

The finding: Opus 4.7 uses "load-bearing" at 24x the rate of Opus 4.6. The earlier model slipped the word only 3 times across a 590k-token session. Opus 4.7 hits approximately 1 occurrence per 860 words by the time context reaches 500k tokens.

Even more interesting: the frequency scales with context length. Below 100k tokens, the rate is manageable (2.4 per 10k words). Between 300k and 500k, it rises modestly to 3.9 per 10k words. Then, past 500k tokens, it spikes to 11.6 per 10k words — a 3x jump in the final context bin. The model isn't just using the word more; it's getting more compulsive the longer it talks.

This isn't a user error. People report adding "never use the word 'load-bearing'" to their CLAUDE.md, their system prompts, even their project READMEs. The model saves it to memory and then ignores it. As one commenter put it: "Explicit instructions to never use it (including saving to memory) fail."

The Fix That Sparked the Conversation

The post that kicked off this week's HN discussion came from Johanna Larsson at jola.dev, and her solution is delightfully practical: use Claude Code's built-in hooks system to swap out words client-side.

The approach is simple. You write a small script — Python, bash, whatever you like — that sits in ~/.claude/hooks/ and runs on every message display. It does a regex find-and-replace on the output before it hits your terminal:

#!/usr/bin/env python3
import json, re, sys

replacements = {
    "seam": "whatchamacallit",
    "you're absolutely right": "I'm a complete clown",
    "honest take": "spicy doodad",
    "load-bearing": "cooked"
}

data = json.load(sys.stdin)
text = data.get("delta") or ""

for phrase, replacement in replacements.items():
    pattern = r"\b" + re.escape(phrase) + r"\b"
    text = re.sub(pattern, replacement, text, flags=re.IGNORECASE)

print(json.dumps({
    "hookSpecificOutput": {
        "hookEventName": "MessageDisplay",
        "displayContent": text,
    }
}))

Then register it in ~/.claude/settings.json:

{
  "hooks": {
    "MessageDisplay": [
      { "hooks": [ { "type": "command", "command": "$HOME/.claude/hooks/wordswap.sh" } ] }
    ]
  }
}

That's it. "Load-bearing" becomes "cooked." The code still works, the architecture is still sound, and your terminal no longer reads like a construction safety manual.

Larsson's post is half-tutorial, half-parody, and it struck a nerve. The HN thread quickly ballooned into a full taxonomy of Claude-isms — "substrate," "belt-and-suspenders," "honest take," "that's the wedge," "quietly," "not X, but Y" — and a community-wide debate on why LLMs develop these verbal tics in the first place.

Why LLMs Get Stuck on Words

The "load-bearing" problem is a specific instance of a general phenomenon that researchers are only beginning to quantify. A recent paper on The Rise of Verbal Tics in Large Language Models (Wu et al., 2026) introduces a Verbal Tic Index (VTI) that measures how repetitive and formulaic model outputs are across 8 frontier models. The paper's central thesis is what they call the "Alignment Tax" : models optimized via RLHF for agreeableness and helpfulness sacrifice linguistic diversity in the process.

The numbers bear this out. The VTI paper found that Emotional Support tasks score 0.55 on the tic index (worst), while Code Generation scores only 0.13 (best). In other words, the more the model tries to be helpful and empathetic, the more it falls back on repetitive verbal crutches. This explains why Claude Code, despite being a coding tool, still develops these tics — it's built on a base model that was RLHF'd toward agreeableness, and that preference bleeds into every domain.

The HN thread arrived at a similar diagnosis from anecdotal evidence. User pocketarc put it succinctly: "Humans do like it, in reasonable quantities. The AI overlearns this and does it too much." User swatcoder identified the deeper dynamic: "When a human does it, it's signal. It distinguishes them. But when a handful of popular models all sound the same, we lose key information."

This is the nub of the problem. A verbal tic is a feature turned into a bug by scale. The model learned that "load-bearing" is a useful word for describing architectural dependencies. It's right! It is useful. But where a human would deploy it once per project, the model — trained on thousands of examples where the word appeared in technical writing — treats it as the default way to describe anything important.

The Community's Toolbox

The HN thread catalogued a range of workarounds beyond simple regex replacement:

System prompt bans. Explicitly listing banned words and phrases in CLAUDE.md or Custom Instructions. User timcobb reported success by also banning framing constructs like "not this, it's that."

Debabel-style post-processing. User pugio created a tool called debabel.py that analyzed 10M+ words of AI output to build a regex/NLP pipeline that strips LLM-isms from visible text without touching underlying files.

Temperature tweaking. Higher temperatures force the model out of its default path, reducing the probability of the most likely (and most tic-heavy) tokens.

Flesch-Kincaid targets. Asking the model to target a specific readability score (~70) shifts its output register away from the default AI voice.

The "caveman" prompt. One user reported asking Claude to write in a drastically terse, minimalist style. "It saves my brain from going into power saving mode by lunchtime."

What This Teaches Us About Prompt Engineering

The "load-bearing" saga is a case study in something the prompt engineering community has been circling for a while: controlling model output is a different skill from getting correct model output.

Most prompt engineering advice focuses on accuracy — chain-of-thought, structured outputs, retrieval augmented generation. These techniques help the model arrive at the right answer. But they don't help with style.

The "load-bearing" problem shows that style isn't a cosmetic concern. It affects trust, readability, and developer experience. When every config file is "load-bearing," the word stops meaning anything. When Claude calls fictional characters "load-bearing," it's not just annoying — it's evidence of a semantic collapse happening inside the context window.

The arXiv paper's data frames this as a systemic issue. Even Claude Opus 4.7, which the VTI paper ranks as having the best Diversity Index (0.678) and Naturalness Index (0.734) among frontier models, still suffers from measurable verbal tic frequency. The "best" model is still not good enough for professional writing without intervention.

The Bottom Line

The immediate fix for "load-bearing" is easy — a 15-line Python script and a settings change. But the deeper lesson is that we're all becoming prompt engineers now, whether we wanted to or not. Knowing how to suppress a verbal tic, how to tune model register, how to detect when a model is falling into a distributional rut — these are becoming baseline skills for anyone who works with AI coding tools.

The model providers will eventually address this. Anthropic knows about the issue, and the regression from 4.6 to 4.7 suggests it's a training artifact they can fix. But the community's response — the taxonomy of banned words, the hooks scripts, the temperature experiments, the debabel tool — is a blueprint for what happens when users take control of model behavior in ways the providers didn't anticipate.

Prompt engineering isn't just about getting the right answer anymore. It's about getting the right answer in the right voice. And sometimes, the most important prompt you'll write is "stop saying 'load-bearing.'"