I started noticing this phrase everywhere.
Not in the way you notice a new word and suddenly see it in three places at once. I mean everywhere. Pull requests. Code reviews. Design docs. LinkedIn posts. Even Slack messages from people I know don't spend their days chatting with Claude.
The phrase is "load-bearing." And once you see it, you can't unsee it.
A "load-bearing claim" in a docstring that has no test coverage. A "load-bearing assumption" that would collapse half the system if removed. A "load-bearing config file" that nobody touches because it might bring the whole thing down. The pattern is always the same: take some noun, stick "load-bearing" in front of it, and suddenly you sound like an engineer making a precise architectural observation.
I should know. I've definitely written this phrase myself. And I'm fairly sure Claude wrote it for me.
The numbers that made me feel insane
I went digging through my own Claude transcripts to check whether this was just selective attention. Across roughly 60,000 Claude assistant turns and 1.7 million words, I found the phrase in 151 separate turns, with 188 total occurrences. That's only about 0.25 percent of turns, but it was concentrated enough to feel like a verbal tic. Every single use was the tidy hyphenated form: "load-bearing." Never "load bearing" as two words or "loadbearing" as one. Always the same.
Once I knew what to look for, I started seeing other people noticing it too. A LinkedIn post called "load-bearing" Claude's new catchphrase, specifically blaming Opus 4.7. The comments were full of people saying the same thing: they had also started wondering why Claude kept calling things load-bearing.
The Google Trends moment
Google Trends confirms this isn't just my imagination. The phrase "load-bearing" shows a clear spike starting in February 2026. Two related AI-adjacent phrases, "quality gate" and "verification pass," had already started climbing around August 2025. But the load-bearing spike is particularly clean.
That February spike lines up neatly with Claude Opus 4.6, which landed on February 5, 2026. Anthropic described that release as better at coding, code review, debugging, and longer agentic tasks. I can't prove causality here, but it's one heck of a coincidence that the phrase started leaking from coding-agent output into real search behavior right when Claude got better at coding.
The phrase wasn't born yesterday
"Load-bearing" didn't originate in a large language model's training data. It came from civil engineering. A load-bearing wall literally supports the weight above it and transfers that load down to the foundation. The metaphor has been floating around software for a while, though mostly as a niche loan phrase rather than something you'd expect a junior developer to casually drop in a code review.
Jeff Kaufman wrote about "Accidentally Load Bearing" on LessWrong, framing it as an extension of Chesterton's Fence: before removing something, ask why it was originally added and what hidden roles it may have picked up since. Scott Radcliff used load-bearing walls as a metaphor for software teams in 2017, where senior developers carry enough weight for the team to grow. Eric S. Raymond wrote about "Load-Bearing Internet People" in 2019, describing maintainers of critical services who carry the work without institutional support. Jason Gorman wrote about "load-bearing code" around the same time: code that sits on critical paths, changes often, has many dependents, or would hurt badly if it failed.
So the concept is real and useful. A load-bearing claim, test, assumption, invariant, citation, parser, schedule buffer, or weird little config file holds the local structure together. Remove it, and things break.
How Claude stretched it
The interesting part shows up where the phrase clusters in transcripts. It's almost always in code review loops. Claude uses "load-bearing" as a portable label for dependency. The nearby words tell the story: claim, finding, signal, assumption, invariant, correctness, citation, safety, regression.
A claim bears the paper's argument. An invariant bears a refactor. A citation bears a factual assertion. A regression test bears future safety. Claude even uses the negative form, "not load-bearing," for things that may be stale or ugly without being structurally dangerous. It's a compact way of saying "this is the dependency that everything else rests on," all wrapped into one adjective.
Why it stuck
This efficiency is probably why the phrase survived post-training so well. I don't know whether Anthropic applied any specific pressure around this word, but we have evidence that preference data can shape what language models say. Researchers Tom Juzek and Zina Ward showed this with the word "delve": preference training made it spike in model output, and then real people started avoiding it once it became an AI tell.
"Load-bearing" has exactly the right shape for that kind of survival. It's concrete and diagnostic, and it lands in a single word. That word gives you a precise label for a nuanced structural observation.
The real problem
Here's the uncomfortable part. The phrase isn't wrong. "Load-bearing" is precise, compact, and often exactly what I mean. When I call something a load-bearing assumption, I'm making a real point about structural dependency.
But usefulness doesn't protect a phrase once model output makes it suspicious. That's what happened to em dashes, which became a tell for LLM writing. Same for "delve," which people still avoid even after the models seem to have moved on. And "gate," as in every check being called a "quality gate" or "verification gate."
Once enough model output uses a phrase, using it yourself stops feeling like a deliberate choice and starts feeling like you're failing to hide the autocomplete. I've caught myself reading my own code review comments and wondering, "Did I write that, or did Claude?" And the worst part is, I'm not sure it matters, because the reader's asking the same question either way.
Load-bearing used to be a useful metaphor. Now it's a signal. And the signal is drowning out the signal.