The post is a compact interactive analysis of more than 50 million words from GitHub pull requests. It clusters vocabulary over time and shows one cluster of terms that rose sharply alongside Claude usage, with words like “load-bearing,” “plainly,” “quietly,” “survived,” and “seam” standing out. The author was careful to say this is not a labeled detector for Claude output. It is an unsupervised vocabulary cluster that happens to line up with what many developers already recognize as “Claudish.” That caveat mattered, but it did not blunt the main reaction. People saw the chart as strong evidence that AI-written PRs now have a distinct, measurable style and that the shift accelerated around newer Claude releases.
The mood was less amused than exhausted. Many people said the problem is not that these words are invented by AI. Most of them are real terms from software, product, or academic writing. The issue is frequency, sameness, and placement. Claude uses a narrow set of metaphors and compressed turns of phrase over and over, often where plain language would be clearer. That repetition has turned otherwise valid jargon into a tell. Several commenters said they now edit their own writing to avoid sounding like Claude, while others said they can spot AI-generated docs, PRs, and marketing copy almost instantly from tone alone.
The thread also pushed past the word list into a stronger claim about what has gone wrong. People described newer models as harder to read even when they are more capable on coding benchmarks. The recurring diagnosis was post-training, not raw model intelligence. Commenters pointed to reinforcement learning, hidden “thinking” or agent-to-agent summaries, and built-in product prompts that reward ornate phrasing, canned structures, and self-referential jargon. A striking anecdote backed that up. One user said Claude admitted a built-in harness explicitly tells it to flag “something load-bearing.” That made the problem feel less like mysterious model drift and more like a fixable product choice, at least in part.
A smaller but important throughline was that the analysis is measuring distribution shifts, not proving any single term is alien. People repeatedly noted that words like “seam,” “spike,” “shape,” “ship,” and “sidecar” all predate LLMs, sometimes by decades. What changed is that one writing style is now being emitted at industrial scale. That is why even defenders of some of the terminology mostly agreed on the core complaint. The internet no longer sounds like many quirky technical subcultures. It increasingly sounds like one overeager coworker writing everything. The most useful takeaway from the thread was simple. Stop arguing about whether an individual word is legitimate. The real issue is whether the generated prose names concrete mechanisms, files, functions, and actions, or hides behind stylish abstraction.
If your team relies on AI for code review, docs, or PR text, you should start treating writing style as a product quality issue, not a cosmetic one. The bigger signal is not one quirky word, but that AI-generated engineering communication is converging on a narrow, recognizable dialect that can hurt readability and trust.
Mostly impressed by the visualization and strongly negative about Claude’s current writing style. People think the jargon is real but massively overused, that newer models have become harder to read, and that the style drift looks driven by product tuning rather than inevitable model intelligence.
Key insights
01
Seam is old legacy-code jargon
The term comes from Michael Feathers’ Working Effectively with Legacy Code, where a seam is a place to change behavior without editing that exact spot. That matters because it separates genuine software-engineering vocabulary from the actual complaint here, which is not invention but overproduction and sloppy reuse outside the original concept.
Do not ban every term that shows up in the chart. Keep precise jargon when it names a real technique, but require AI-generated text to use it only when the surrounding explanation is equally specific.
A user showed Claude saying its own harness instructions literally tell it to flag “something load-bearing.” If that anecdote is representative, at least part of the famous Claude voice is not emergent behavior from the base model. It is product scaffolding leaking into user-visible prose.
Treat style bugs like prompt and product bugs first, not just training mysteries. If you ship an AI tool, audit your system prompts and reviewer prompts for repeated pet phrases before reaching for expensive retraining.
The author explicitly said the model is unsupervised and only discovers vocabulary clusters that rise together over time. One commenter sharpened the point with a “Texas Sharpshooter” warning. The evidence is strongest where the cluster surfaces words everyone already recognizes, not as a universal authorship detector. Another commenter noted that most non-Claude clusters are about technologies or non-English language, not alternative writing styles.
Use this kind of analysis as a trend detector, not a forensic classifier. If you want to police AI authorship or measure a specific vendor’s influence, you need labeled data and cleaner segmentation.
One contrarian but substantive point was that shrinking clusters contain repo names, branch names, usernames, and other barely-English boilerplate. On that view, AI did not just inject annoying jargon. It also raised the floor by turning terse or cryptic PR descriptions into actual prose, which helps later code archaeology and review.
Do not optimize only for anti-slop aesthetics. If you clamp down on AI wording, keep the gain that matters most, which is more explicit descriptions of what changed and why.
Anthropic’s output styles and user prompt hacks were widely described as partial at best. People reported that “concise” does little, that custom style guides often fail, and that forcing TLDRs or yes-no answers only makes the model bearable rather than good. The recurring implication is that the awkwardness sits deep in post-training behavior and cannot be reliably patched away at the edge.
If your workflow depends on readable AI prose, budget for human editing instead of assuming prompt engineering will solve it. For internal tools, prefer constrained outputs like bullet lists, diffs, or structured fields over free-form explanations.
Commenters blame reinforcement loops, not dataset poisoning alone
People floated model collapse from training on AI text, but the sharper explanation was reinforcement. Repeated RL tuning, generated tasks, distilled corpora, and hidden agent workflows all push models toward a narrower house style. The result is not just weird words. It is the same weird words and sentence templates appearing everywhere.
Watch for homogenization whenever you stack reinforcement, distillation, and agentic scaffolding on top of a base model. Style diversity is worth measuring as a product metric because capability gains can arrive with communication losses.
Several people pushed back on the idea that the listed vocabulary is inherently artificial. Words like “load-bearing,” “plainly,” or “survived” are ordinary language. The actual tell is unnatural repetition and context, not the words in isolation. That reframes the whole project from “AI uses alien vocabulary” to “AI creates a detectable distribution and cadence.”
Be careful about simple ban lists. Review whole passages for rhythm, repetition, and specificity instead of treating single words as proof of low-quality AI output.
The odd phrasing may help models talk to themselves
A few commenters argued that the jargon could be functional inside long AI workflows. Reused terms and dense shorthand may help one model session or subagent pick up context from another, even if humans hate reading it. That does not make the prose good for users, but it suggests there may be a real tradeoff between internal machine coordination and external readability.
If you build agent systems, separate machine-facing and human-facing text whenever you can. Let internal traces be ugly if needed, but translate them before they reach users or code review artifacts.
There was also a defense of words like “seam,” “fold,” and even “load-bearing” when used sparingly among people who share context. These terms can point to boundary conditions or design structure faster than longer plain-English paraphrases. The problem is that AI reaches for them before it has earned the right to be that compressed.
Keep short technical metaphors in expert discussions, but make AI spell out the concrete referent at least once. After that, shorthand is fine.
louisabraham.github.io