- LLMを使ってDjangoのチケットを処理する方法は役に立たず、そのリソースをDjango Software Foundationに直接寄付するほうが有益である
- Djangoは品質基準が非常に高く、長期的な安定性を重視するプロジェクトであり、単純なコード生成を超える深い理解が必要である
- LLMが執筆者の代わりにコードを作成し、PRの説明やレビュー対応まで処理すると、貢献者が実際に理解しているかどうかを判断しにくくなる問題が生じる
- オープンソースへの貢献では人間的なコミュニケーションとコミュニティでの協力が中核であり、LLMがそれを覆い隠すとレビュアーとの信頼が弱まる
- Djangoに貢献するには自ら学び、実験を通じて理解を積み上げる過程が不可欠であり、それは開発者としての成長につながる
LLMによるDjango貢献の限界
- LLMを活用してDjangoのチケットを解決することはコミュニティに実質的な助けにならない
- LLMが生成したコードでPRを提出し、フィードバックを処理する場合、執筆者の理解の水準を把握しにくい
- レビュアーの立場からは、人ではなく**「偽りの理解の外殻」**と対話しているように感じられる
- Djangoは大規模なユーザーベースとゆっくりした変化の周期、そして20年以上続くプロジェクトとしての品質要求を持つ
- こうした特性のため、単純な自動コード生成よりも深い理解と責任ある貢献が重要である
LLMの正しい活用方法
- LLMは理解を助ける補助ツールとして使うべきである
- 自分の言葉で説明を書いたうえで、LLMを使って表現を整える形が望ましい
- コミュニケーションが難しいときはLLMを積極的に活用してよいが、使った事実を明示すべきである
- Djangoに貢献する際には貢献者自身が問題と解決策、レビューのフィードバックを直接理解しなければならない
- 理解のないまま生成されたコードは、プロジェクト全体の品質を損なうおそれがある
人間中心のオープンソース協力
- Djangoへの貢献はコミュニティとしての体験であり、人間的な透明性と脆さを含んでいる
- LLMがこうした人間性を覆い隠すと協業が難しくなる
- レビュアーは**「人間の本当の理解」**に基づいてコミュニケーションするときに動機づけを得る
- LLMは補助手段としてのみ使われるべきであり、貢献者の本質的な役割を置き換えてはならない
Django貢献の本質と価値
- Djangoは20年の歴史と長期的なビジョンを持つプロジェクトであり、追加されるすべてのコードは深く理解されていなければならない
- Djangoへの貢献は単に名前が載ること以上に、開発者としての成長をもたらす経験である
- 貢献の過程で得られる学びは、一覧に名前が載ることよりはるかに価値がある
コミュニティへの提案
- LLMを過度に使って自分自身や理解を隠すべきではない
- Djangoコミュニティは本物の人間と協力したいと考えている
- Djangoを支援したいなら、時間とお金を投資するか、Django Software Foundationに寄付することが最も効果的である
1件のコメント
Hacker Newsの意見
私は、LLMは人間のレビュアーがいるあらゆるコードベースで問題を引き起こしうると思う
チケットや解決策、PRフィードバックを理解しないままLLMを使うと、プロジェクト全体に害を与える
オープンソースへの貢献は共同体的な行為なのに、LLMは人間の透明性と脆弱性を覆い隠してしまう
レビュアーの立場では、人間の「仮面」と会話しているような感覚で、やる気を削がれる体験になる
だからLLMは道具として補助的に使うべきであって、代替手段になってはならない
最近はチームでもAIが書いたPRが急増していて、ClaudeやCodexがレビューのフィードバック対応まで代行するのを見かける
こうした文化が定着すれば、業界全体の信頼の崩壊と士気の低下につながる気がする
生産性向上というより、「気分的に速くなった感じ」だけが残る
実際には組織が生産性をきちんと測定していないため、こうした機能の純効果を誰も分かっていない
AIの広範な利用が信頼を侵食している
見た目は良くなるが、本物らしさが失われる
結果としてコードが通っているのだから、人々は実はそれほど不満ではないのかとも気になる
私が一緒に働いた最高の同僚たちは、いつもレビュアーが批判しやすいようにしてくれていた
前提、分からない部分、試行錯誤を明確に書き、レビュアーが簡単に反論できるよう説明していた
こうした謙虚さと内省が見えるPRなら、LLMが関わっていても心配しない
問題は、以前から基本的なビルドすら通らないコードを上げていた人たちが、今ではLLMでさらに多くのひどいPRを量産していることだ
だから「コードが動けばよくて、誰が書いたかは重要ではない」という意見には同意しない
今の状況は制御不能なレベルだ
特に採用プロセスでGitHub活動が評価要素になるにつれて、人々はLLMで貢献履歴の偽装を試みている
実際にはプロジェクトを理解していないまま、PRが通ればそれで終わりだ
優秀な開発者がLLMを使うこと自体は問題ではない
問題なのは、もともと実力不足だった人たちがLLMのおかげでさらに多くの低品質コードを提出できるようになっていることだ
以前からStackOverflowのコピペで理解もなくコードを提出する人たちはいた
AIはそれをただ増幅しただけだ
複数のリポジトリに似たようなPRを乱発し、その大半が拒否されているなら、それは明らかなシグナルだ
結局は量より質重視の貢献文化に戻るべきだ
問題を認識するのは簡単だが、合意と実効的な解決策を作るのは難しく、技術者はそこが苦手だ
私はお金を寄付するというアイデアが気に入っている
Djangoのコアコントリビューターたちは、トークンより資金のほうをうまく活用できそうだ
他のプロジェクトでは、AI利用の開示や外部コントリビューションの一時停止、あるいはIssue登録の制限のような措置を取っている
低品質PRがあまりに簡単に生成されることで、コミュニティの時間と集中力が侵害されている
そのため、より閉鎖的な協業モデルへ移行する必要があるのかもしれない
Debianがこの問題を慎重に扱うと決めたのも印象的だった
トークンを買う代わりに、コアコントリビューターに直接お金を寄付して、使い道は彼らに任せるほうがよいと思う
「レビュアーが人間の仮面と会話するのは精神的に消耗する」という言葉に深く共感する
オープンソースの報酬の一つは人との交流なのに、それが消えるとただの労働のように感じられる
結局みんなの忍耐力が減り、協業の楽しさが失われる
まるで行きつけの精肉店で会話するように、関係を築きたがる
論文執筆はLLMで簡単になったが、検証とレビューは依然として難しく時間がかかる
そのため、AI使用の有無を明記したり、AI検出アルゴリズムでPRに印を付けたりする仕組みが必要だ
結局それは、人々にLLMの回答を自分の言葉に翻訳させる効果を持つはずだ
ただ現実には、ルールを無視する人たちは常に存在する
最近のイノベーションはすべて、短期的な報酬を追わせる方向に働いている
インセンティブ構造が長期的な視野を持つ人を支えていない
ゲーム理論を少しかじれば、世界がそのように設計されていることを否定しづらい
だから長期戦略を評価するには限界がある
良いメッセージだが、LLMで何でもやる人たちはこういう文章を読まない気がする
オープンソースのメンテナーとして、私もAIが書いたコードかどうか見分けにくい
実際にはそんなプロの開発者はほとんどいない
むしろLLM専用のオープンソースプロジェクトを作ってみたらどうかと思う
LLMが作ったコードだけを集め、貢献プロトコルを明確に定義するような形で
ただ、多くのLLM貢献は単なるポートフォリオ目的である可能性が高い
何千人ものコントリビューターと何万件ものコミットがある
AIはしばしば生産性を高めるのではなく、単に検証の負担を他人へ押しつける
結局メンテナーがより多くの仕事を背負うことになり、コントリビューターは功績だけを持っていく構図になる
私もDjangoのようなプロジェクトでLLMを使ってパッチを作ったことがある
LLMがなければ、そもそも試そうとすらしなかっただろう
ただし成果物は自分でレビューし、テストも書いた
今ではコード、PR説明、レビュー対応まですべてLLMが代行していて、
レビュアーの立場からすると「それなら自分がLLMでレビューすればいいのでは？」と思うほどだ
だからLLMは補助ツールとして使うべきであって、代替手段になってはならない