Load-Bearing - GitHub PR vocabulary trend analysis
Show HN: The load-bearing vocabulary of Claude
Load-Bearingは、GitHubのPull Requestから収集した語彙の傾向を分析するツールです。毎日100件のPRをスクレイピングし、KLダイバージェンスを用いたk-meansクラスタリングで、2025年以降のPRを8つの語彙クラスタに分類します。その中でも、2026年に出現したクラスタは、全PRの45%を占めるまでに成長しました。このクラスタの代表的な単語は、コーディングエージェントを使用する人には馴染み深いものばかりです。このツールは、AIによるコード生成の影響を可視化し、開発トレンドの理解を深めるのに役立ちます。
コーディングエージェントを使う人なら誰でも見覚えのある単語が、PRの45%に現れています。
HNでの議論
314- nater5000
スクロールしようとしたら、著者が伝えたいことがすべて画面に収まっていることに気づいて、嬉しい驚きを覚えました。このサイトが、過度に冗長でも複雑でもなく（LLMにはなかなかできないことですが）、これほど明快で説得力のあるプレゼンテーションを実現しているのは、ほとんど皮肉ですらあります。提示されている内容を深読みしすぎるつもりはありませんが、著者は自分の偏見をプレゼンテーションに注入しないようにうまくやっています。
今後、人間は徐々にLLMの言語、あるいはLLMとのやり取りから生じる特定の言語的癖を採用し始めるのではないかと思います。私自身の文章でも気づいたことですが、今では例のリストを一貫した方法で提示するようになりました。「... のようなもの、例えば<例1>、<例2>など、...」という感じです。最近、このパターンをかなり頻繁に使っていることに気づき始めましたが、自分のソーシャルメディアの投稿をざっと見返すと、かなり前から使っていたことに気づきました。この種の言語に慣れてしまったのは、特に初期の頃、LLMが私が提供した具体的な例に焦点を当てすぎてしまい、実際には自分が求めているものの感覚を与えようとしていただけだったからです。例を2つ挙げて「など」を付け加えると、LLMが具体的な例にあまり焦点を当てず、明示的に提示した以上のことを考慮する必要があると理解してくれることを、私はただ学んだだけでした。もちろん、今ではソーシャルメディアのコメントやSlackでもそのように書いています。
- ben30
Claudeの応答で興味深かったのは、その応答における「load-bearing」を減らそうとしたときのことです。
私はグローバルプロンプトに以下を追加しました：
- オーウェルの第一の規則：印刷物で見慣れた比喩を使うな。「load-bearing」「the crux」「first-class citizen」は、洞察を示す代わりにそれを示唆しているだけだ。具体的なメカニズムを挙げよ。
その変更についてどう思うか尋ねたところ、彼の返答は次の通りでした：
「オーウェルの箇条書きは、私自身のシステムプロンプトと戦っています。私のハーネスの指示は、何か『load-bearing』なものを見つけたら、それを明示的に示すように言っています。」
- Labo333
著者です！ 温かい言葉に感謝します。HNのような人間のコミュニティは、一日中お世辞を言い、でたらめを言うエージェント（このページを作るためも含めて）とチャットしていると、本当に特別に感じられます。
現在、検索バーを追加し、データを1日あたり1000 PRに増やしています。
メインページではわかりにくい良い点として、データセットと分析はGitHub Actionsを使って毎日更新されています（少なくとも、停止が発生しない限りは ^^）。このようなアプリを「バックエンド」なしで構築できるのは、とてもクールだと思います。
- SalariedSlave
最近、これをHNやredditでますます多く見かけるようになりました。これらの出力パターンは悪化しているようです。Claudeだけではなく、現在のすべてのモデルにこのスタイルの問題があるという印象です。彼らの文章は、ほとんど理解不能になりかねません。
各モデル世代で何らかのフィードバックループや複合的な問題が発生しているのでしょうか？
もしかすると、新しいモデルはAIコンテンツを過剰に取り込んでいるのでしょうか？
トレーニングデータに占めるAI生成コンテンツの割合がますます高くなっている（AI生成コンテンツの量が全体的に増加しているため）なら、これは複合的なバイアスとなり、トレーニングを汚染している可能性があるのでしょうか？
- prmph
ええ、最近のClaudeの文章は変です。文脈にそぐわない奇妙で非標準的な単語を使いますし、文の構造も時々変です。
コードでClaudeと作業していると、次のような奇妙な単語の選択が頻繁に見られます：
- 「name(s)」を動詞として使う（「specify/specifies」などの代わりに）。例：「...the function names the argument」
- 「carries」を「contains」の代わりに使う
- 「verdict」を「result」の代わりに使う
- 「judge」を「validate」の代わりに使う
非常に奇妙です。また、コメントやドキュメントを書く際、名詞が何を指すかを省略するなど、文章が解釈しにくくなるほど簡潔です。例えば、「abc does not accept...」ではなく「The abc function does not accept...」と書くべきところを、前者のように書きます。
私は特定の単語の使用を禁止し、文章をもっと明確に書き直すように何度も依頼せざるを得なくなりました。
- sosull
これは本当に素晴らしいです。包括的で、データを論点が事実上「自らを証明する」点にまで凝縮し、提示の仕方も読者の時間を尊重しています。また、（少なくとも私にとっては）言語問題の主題をこれほど狭く特徴づけようとするのは、興味深い挑戦でもあります。
スライドの山も、物語もありません。ただ、美しくも痛ましい結論があるだけです。
- Jordan-117
これは、最適ではないRLHFの結果なのか、それともモデル本来の知性が言語をより複雑にし、人間が簡単に解釈するのを難しくしている結果なのか、どの程度なのだろうかと思います。一方で、高度な教育を受けた人々が、専門用語を知らない一般の人々には混乱し煩わしい話し方をするというのはよくある話です。しかし他方で、複雑な情報を効率的に本質だけに凝縮し、わかりやすく伝えることは、熟練したコミュニケーターの特徴でもあります。もちろん、それはこれらのモデルがより高いレベルで機能しており、ある程度私たちに見下すように話す必要があることを示唆しているようにも思えます。あるいは、「Claudish」は「caveman」や生の思考連鎖、ニューラリッシュなどと同様のもので、それらも同様により密度が高く効率的ですが、解釈が難しいだけなのかもしれません。
- stabbles
語彙に加えて、文の構造にも興味があります。
「X, not Y」はよく知られていますが、もう一つ気になるのは、「It doesn't <verb> <noun>」の代わりに「It <verb>s no <noun>」を使うことです。
例えば：「the list contains no string」や「it changes no behavior」、「it holds no directory」など。
- loglog
現時点では、分割には自然言語のクラスタが2つしかありません：Claudishとスペイン語/フランス語です。一目見たところ、他のクラスタはテクノロジーを中心としているようです（「最も代表的な」単語の中にコマンドラインのフラグや略語がたくさんあります）。英語の使用傾向を調査するのが目的なら、英語の単語だけに基づいてクラスタリングする方が良いかもしれません。
- wavewrangler
最近「shipped」という言葉の使用について話していたところ、新しくエンジニアになったばかりの人たちに、そんな変な質問をするなんてと笑われました。彼らがそれを馬鹿げていると思ったのも無理はありません...それは彼らのキャリア全体、つまりほんの数週間のキャリアを通じて、彼らの語彙の一部だったのですから。あの人たちが今何をしているのか気になります。これは約1か月前のことです。彼らが「shipped」したものは、結局「landed」したのでしょうか？