I have started treating load-bearing as one of the phrases that makes me
suspect a paragraph was written by an LLM.
Once I noticed Claude using the phrase this way, it became hard to unsee. To
check whether this was just selective attention, I went through my local Claude
transcripts and counted assistant uses of load-bearing, load bearing, and
loadbearing. Across roughly 60,000 Claude assistant turns and 1.7
million words, the phrase appeared in 151 turns, with 188 total
occurrences. That is only about 0.25% of turns, but it was concentrated
enough to feel like part of Claude’s LLM speak. Every single occurrence
used the tidy hyphenated form: load-bearing.
Other people have noticed this too. A month-old
LinkedIn post by David Greenwald
called load-bearing Claude’s new catchphrase, specifically associating it
with Opus 4.7 output. The comments are worth checking out too – it’s
basically people finding the post because they had also started wondering why
Claude kept calling things load-bearing…
The older metaphor#
The phrase itself is not new. The literal source is the load-bearing wall: a wall that supports the weight above it and transfers that weight down into the building’s foundation. In software, the metaphor seems to have existed too, though much more as a loan phrase than as something I would expect ordinary software engineers to say. Jeff Kaufman’s “Accidentally Load Bearing” frames it as an extension of Chesterton’s Fence: before removing something, ask why it was originally added and what roles it may have acquired since. Scott Radcliff used load-bearing walls as a metaphor for software teams in 2017: senior developers carry enough weight for the team to grow, while mid-level developers gradually become load bearers themselves. Eric S. Raymond wrote about “Load-Bearing Internet People” in 2019: maintainers of critical Internet services or libraries who carry the work without institutional support. Jason Gorman wrote about “load-bearing code” in 2017, and later expanded the idea in Codemanship: code that sits on critical paths, changes often, has many dependents, or would hurt badly if it failed deserves stronger verification – all of which makes it load-bearing.
On the face of it, that sounds like a pretty useful and quite precise idea. But Claude seems to have stretched it into a recurring code-review habit. A load-bearing claim, test, assumption, invariant, citation, parser, schedule buffer, or weird little config file holds the local structure together. Remove it, and the thing that depended on it no longer works.
In the transcripts#
The interesting part you find when looking at the transcripts is the context. The matches clustered in code review loops, where Claude is constantly trying to identify what we would otherwise probably call a single point of failure.
The nearby words make the pattern visible. In the transcripts, load-bearing
usually works as a portable label for dependency. It appears near words like
claim, finding, signal, assumption, invariant, correctness,
citation, safety, and regression.
The common uses are fairly specific: a claim bears the paper’s argument, an
invariant bears a refactor, a citation bears a factual claim, a regression test
bears future safety. Claude also uses the negative form, not load-bearing,
for things that may be stale or ugly without being structurally dangerous.
Why it sticks#
This economy may also explain why the phrase survived post-training so well.
I do not know whether Anthropic used any length penalty, or whether the pressure
was only the usual preference for concise, helpful answers – but we do have
evidence that post-training can affect word choice. In their work on
“delve”,
Tom Juzek and Zina Ward found evidence that preference data can shape the
lexical preferences of large language models. Load-bearing has exactly the
right shape for that kind of survival: concrete, diagnostic, short. It turns
“this is the dependency that everything else rests on” into one adjective.
The problem is not that the phrase is wrong. Load-bearing is precise,
compact, and often exactly what I mean. But so are
em dashes, and so was “delve”.
Once enough model output uses a phrase, using it yourself starts to feel less
like choosing a metaphor and more like failing to hide the autocomplete…