ハクソク

世界を動かす技術を、日本語で。

Djangoにはトークンではなく、時間とお金を投資しよう

46日前原文(www.better-simple.com)

概要

  • Djangoへの貢献は品質と理解が重要
  • LLM（大規模言語モデル）の過度な利用は本質的な理解を隠す危険性
  • 人間らしさとコミュニティの絆がオープンソース活動の核心
  • LLMは補助的なツールとして活用するのが理想
  • 理解と成長を重視した貢献姿勢の重要性

Djangoへの貢献とLLM利用の是非

  • Djangoへの貢献には高い品質と深い理解が求められる
  • LLMを使ってチケット対応やPR作成を自動化する行為の問題点
  • Djangoのコードベースは大規模なユーザー層・長期的な運用が前提
  • コミュニティは20年以上の持続性を期待
  • 貢献者リストに名を連ねることは大きな名誉

LLMの弊害と透明性の喪失

  • LLMを使いすぎると理解の有無が不透明になる
  • PRやレビュー対応もLLM任せの場合、人間らしさが失われる
  • レビュワーにとっては人間の姿が見えないことが負担
  • オープンソースはコミュニティ活動であり、人間的交流が不可欠
  • LLMは理解や成長の仮面を作る危険性

LLMの正しい使い方

  • LLMは補助的ツールとして活用
  • 理解を深めるために情報収集や整理にLLMを利用
  • 自分の言葉で説明し、表現の調整にLLMを使う方法
  • コミュニケーションで苦労した場合は、LLM利用を明記して透明性を確保
  • 理解の可視化とコミュニケーションの質向上を目指す姿勢

理解と成長の価値

  • Djangoへの貢献は学習と成長の機会
  • コードや仕組みを自分で理解・実験する努力が不可欠
  • 貢献者リストに載ること以上に、得られる成長が価値
  • LLM任せで自分の理解を隠す行為は避けるべき
  • コミュニティはあなた自身と協働したいという思い

結論

  • LLMはあくまで補助的役割
  • 貢献には自分自身の理解と人間性が最重要
  • Djangoコミュニティは共に成長し合う仲間を歓迎

Hackerたちの意見

お金を寄付するアイデア、いいね。Djangoのコントリビューターたちの方が、トークンの使い方を上手く知ってると思うし、私はDjangoのコアコントリビューターじゃないからね。いくつかのプロジェクト（https://news.ycombinator.com/item?id=46730504）は、AIの使用を開示することをノルムにしようとしてる。別のプロジェクトは、外部からの貢献を一時停止することに決めた（https://news.ycombinator.com/item?id=46642012）。ドライブバイのプルリクエストを受け入れる代わりに、コントリビューターは他の協力者と一緒に作業して、作業証明を示さなきゃいけない。さらに別のプロジェクトは、ユーザーが直接イシューを開くのを拒否し始めた（https://news.ycombinator.com/item?id=46460319）。ここには、外部の人たちが低品質の提出物でコラボレーターの時間や注意を無意識に攻撃しているという側面があると思う。これが今まで以上に安く生成できるからね。もっとプライベートなコミュニティモデルに移行する必要があるかもしれない（https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...）。追記：最近のDebianプロジェクトの決定を称賛するよ。問題の性質についてもっと考えることにしたみたいだね。https://news.ycombinator.com/item?id=47324087
└
ちょっと宣伝させて！数週間前にこの同じテーマについてエッセイを書いたんだ。https://essays.johnloeber.com/p/31-open-source-software-in-t... 人々がトークンを自分で買うんじゃなくて、コアの貢献者にお金を寄付して、その人たちにトークンの使い道を決めてもらうべきだと思う。
s/Django/the codebase/gとしても、これは人間によるコードレビューがあるリポジトリには当てはまるよね。> 「チケットが理解できない、解決策が分からない、PRに対するフィードバックが理解できないなら、LLMの使い方がDjango全体に悪影響を与えている。」> Djangoのコントリビューターは他の人を助けたいし、コミュニティを育てたいと思ってる。あなたがレギュラーコントリビューターになる手助けもしたいんだ。LLMがなかった頃は、理解できることだけを伝えるのが簡単だったけど、今はLLMを使うことで理解しているように見せるのが簡単すぎる。でも、レビューアは本当に理解しているかどうかわからない。> こういう意味で、LLMは自分自身の仮面だよ。理解や考察、成長を投影するのを助けるけど、人間らしさや脆さを取り去ってしまう。> レビューアにとっては、人間の仮面とコミュニケーションを取るのは士気を下げるよ。> オープンソース、特にDjangoへの貢献は共同作業だから、その経験から人間らしさを取り除くと、より難しくなる。Djangoに貢献するためにLLMを使うなら、補助的なツールとして使うべきで、自分の手段として使うべきじゃない。最近、AI生成のPRが大量に流入していて、提出者がCodeRabbitなどとやり取りするためにClaude/Codexを使っているのを見ているから、この点をチームに伝えようと思ってる。業界としてこういう文化を確立し、守らなければ、腐敗や士気の低下につながるのは間違いない。
└
LLMはオープンソースへの貢献に対して、PhotoshopがTinderに与える影響みたいなもんだ。
└
Jiraに組み込まれたAIのオートコンプリートや提案が、チケットトラッカーをめちゃくちゃスパムっぽくしてる。あの「機能」が良いより悪いことの方が多いって100%確信してる。実際に生産性に与える影響を追跡してる人なんていないし、その場の「雰囲気」だけを見て使ってる。「この特定のことをめっちゃ早く終わらせた！」って思うのも、そのせいだと思う。そもそも多くの組織が全体の生産性を有効に追跡してないからね。難しすぎて、高くつくから。追跡してるかもしれないけど、あまりにもひどくてほとんど意味がない。C-suiteの最新の流行が良いか悪いかを確かめるために、急にそれを変えることなんてないと思う（そもそもそんな質問に対する本当の答えを求めてないし）。
└
> チームにこのポイントを伝えようと思ってるんだけど、AI生成のPRが大量に増えてきて、提出者がCodeRabbitとかとやり取りするためにClaude/Codexを使ってフィードバックを受けてるのを見てるんだ。これって、みんな結果に不満を持ってるのかな？経験上、後でレビューを通過することが多いみたいだけど。こうやってコードが通ってるんだよね。
└
昔は、誰かが本当に問題を解決しようとしている善意でPRを出していると考えられてたよね。提案された解決策に異議を唱えて、そのままの形でPRを却下することもあったけど、善意は前提だった。AIがそれをひっくり返したんだ。今は、みんなAI（もしくはAIを使ってコンテンツを生成している人間）とやり取りしていると思っていて、その人間が提案していることをほとんど理解していないと考えている。結局、AIの広範な使用が信頼を損なっているんだよね。それは残念だ。
いいメッセージだけど、LLMを使ってる人たちがそんなメッセージを読む気があるのか疑問だな。どの時点で完全にLLMかどうか判断するのが難しい/不可能になるんだろう？私もOSSのメンテナーとして、これに苦労することがある。
└
「LLMで全てをやる人たち」って、ちょっとストローマン的な表現だね。プロの開発者が「全てをLLMでやってる」なんて、あまりいないと思う。その表現が何を意味するのかもわからない。
SimonがDjangoの作業にLLMを使うことについてどう思ってるのか気になるな…私は複数のプロジェクトのパッチを作成するためにLLMを使ったことがある。LLMがなければ、その作業はできなかったと思う。その後、作業をレビューして、テストも提供したよ。
└
> これはLLMを使うかどうかの問題じゃなくて、何が貢献されているのかを理解しているかどうかの問題だと思う。今見ているのは、LLMを使ってコードを生成したり、PRの説明を書いたり、PRレビューのフィードバックを処理したりしている人たちだよ。それが進むと、レビュー担当者が自分でLLMを使った場合と違いがあるのか分からなくなってくる。これは大きな問題だよね。 […] > Djangoに貢献するためにLLMを使うなら、それは補助的なツールとして使うべきで、主役にはならない方がいい。
今のところ、どんな新しい革新も、短期的な報酬を選ぶ問題を悪化させてる気がする。インセンティブ構造が、物事を俯瞰的に見ることを望む人をサポートしてないんだ。ゲーム理論を見てしまうと、本当にそれを忘れられなくなるよね。
└
世界中の政府が何十年もかけて通貨を膨らませて、無駄なプロジェクトのためにお金を使ってきた結果、みんなの貯金や給料が目減りして、金儲けを最優先にせざるを得なくなってるんだよね。生き残るためには仕方ないのかも。
└
ゲーム理論は、一生の間に続く相互作用の連続ラウンドには拡張されないんだ。前のラウンドの結果がリセットされたり、他のプレイヤーがゲームに参加することで持続したりするから、長期戦略を評価するには劣ったフレームワークなんだよね。
今、これが本当に手に負えなくなってきてて、どうやって解決すればいいのか分からないんだけど、これは受け入れられない理由と、負担が間違った人たちに移ってる理由を表現するにはすごくいい投稿だと思う。人間はこれを心に留めて、ちゃんとした行動を取るのかな？残念ながら、多分無理だろうね。主な問題の一つは、GitHubの貢献や活動を指摘することが採用プロセスの一部になってること。だから、LLMを使ってそのプロセスを自動化しようとする人が増えるんだ。「X、Y、Zプロジェクトに貢献した」って言うけど、実際にはそのプロジェクトについてほとんど理解してないし、自分のPRがどう機能するかも分かってない。なんとか受け入れられちゃったけど、それが現実なんだよね。
コメントの中にいろんな意見があって面白いね。ほとんどの人は、AIが人間よりも多くのものを生成できるって認識してると思うから、モデルは何らかの形で変わる必要があるよね。提出側のAIを減らすか、レビュー側のAIを増やすか（それが実現可能かどうかは別として）。
└
そういえば、「まず自分のコードをレビューしろ」っていうのはどうなったんだろう。AIが出る前から、明らかに努力が見えないコードを見つけて却下するために、リンティングを禁止してたんだ。最初に「読めない」っていうのが出たらメモを残して、二回目は却下してた。で、「読めない」っていうのは、セミコロンや括弧のスタイルが抜けてるとか、そういう意味じゃなくて、意味がわからないセマンティクスや過剰なコードのことを言ってるんだ。
自分の開発スタイルでは、あなたが説明したようなことには直接遭遇してないけど、正直言って、LLMに過度に依存してしまった痛みは経験してる。そういう厳しい教訓から学ぼうとして、AIを使って未来の痛みを避けるためのベストプラクティスを身につけようとしてるんだ。この成長するベストプラクティスのセットがすごく役立ってる。あなたの記事が好きだった理由は、そういうベストプラクティスのいくつかを苦労して学んできたことを確認してくれたから。ありがとう！
その気持ちはわかるけど、どう進めるのがベストかはちょっとわからないな。例えば、使ってるFOSSライブラリでバグを見つけたとする。で、そのバグをClaudeとか使って直したとするね。ちゃんとテストして、問題なく動いたとしたら、アップストリームに送らないのはちょっと自己中心的じゃない？AIがなかった頃はもっと簡単だったのに。
└
誰も動くコードに文句を言うことはないと思うよ。君のPRは、理由や解決策の選択を説明するもので、それだけで受け入れ基準をクリアするかどうかが決まると思う。少なくとも、僕にとってはそうだ。エラーも全然大丈夫。ただ、無関心はダメだね。
└
「これが私のマシンで動く、私の目的には合っている」と「これがアップストリームにマージするのに適している」という品質の閾値は、めちゃくちゃ違うんだ。Claudeのコードはこれに影響を与えないし、むしろ一部の貢献者を混乱させるだけだよ。もし誰かが「これ、私の友達が送ってくれたんだけど、私のマシンで動くよ」と言ってdiffをメールしてきたら、それを適用することを考える？
> 「貢献者のリストに自分の名前があるなんて光栄です。将来の開発にとって、この一文にはとても重要な意味があると思います。」