2026/04/22 5:21
PR をお受取りしない場合は、その旨を伝わるよう適切なご対応となるよう、具体的な表現文案をご用意いたします。
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳:
サマリー:
著者はプロジェクト戦略の重大な転換を発表しました。コラボレーションプロセスを簡素化するため、よりからプルリクエストは受け付けません代わりに、ユーザーは高品質なフィードバック、詳細なバグレポート、そして機能アイデアに集中すべきです。チームは今や、即座の実装よりも戦略的な設計議論を最優先しています。この決断の背景には、複雑なコードを迅速に記述できる大規模言語モデル（AI ツール）の急速な進化があります。これにより、外部からのコード提出を受け入れることで得られた従来の時間節約の利点は失われました。以前は、プルリクエストのマージによってメンテナが構文や依存関係の管理で数時間を節約できたのに、AI がコーディング速度を効率的に処理するようになり、手動でのレビューは負担となる一方、実際のアーキテクチャ的な加速をもたらすものではありません。効果的に貢献し続けるには、開発者はリポジトリフォークして独自のペースでカスタマイズの変更を行い、後にアップストリームブランチへ再ベース（rebase）するという独立したクリエイターとして振る舞うことを推奨されます。このモデルは、コミュニティダイナミクスを中央集権的な承認システムから、貢献者が高品質な作業を مستقلに統合する仕組みへと変革し、メンテナが面倒なコードレビューに費やす時間を減らし、代わって貴重な参考資料の評価に集中できるようにします。
本文
開発者様が私が維持しているソフトウェアを喜んでいただき、支援の意欲を示してくださっていることは、心から感謝しております。しかし、このコラボレーションの方法については再考が必要であり、互いの時間を無駄にすることが増えていると感じております。
あなたの PR をマージしたくない理由
あなたをよく知らないため、常にあなたが変更内容とともに何らかの悪意のあるコードをすり替えようとしているかもしれないと仮定しなければならない立場にあります。そのため、レビューしマージするリスクが、私が自分で実装する場合よりも高くなってしまいます。さらに、コードには多くの個人的・主観的な要素が関わっており、書式、スタイル、構造、依存関係、アプローチなどにおいてそれぞれ好みが異なります。結果として、レビューの実施、CI（継続的インテグレーション）の動作確認、マージ競合などを調整する必要があり、貢献者と保守者の間で往復する議論が続くことでプロジェクトが延期される傾向があります。
LLM の登場以前から、コードの記述そのものが私の最大のボトルネックではありませんでした。しかし、コード記述には時間がかかるため、安定して動作しレビューしやすい PR を用意することは、わずかな追加リスクや不便さを補うだけの価値がありました。一方、LLM がコード実装に非常に能力を身につけた現在では、もはやそのようなトレードオフがほとんど成立するなくなりました。私は依然として LLM が生成したコードのレビューが必要ですが、未知の貢献者からのコードに存在する可能性のある悪意といった懸念は抱きません。また、すでにコーディングの好みを多く規定化し、スタイルガイドラインを LLM に設定しており、異なるタイムゾーンにいる人間と同期を取る必要がないため、自分のペースで迅速に反復作業を行えます。
これらの理由から、コードの変更は自分が（LLM の助けを得て）行う方が効率的であると考えております。
ソフトウェア開発の性質が変化している
「ソースコード」という概念自体が、開発者の頭にあるアイデアとコンピューターの実行指示の間の正式化された中間層として機能する「コード」へと変質しつつあることが increasingly clear となっています。以前からそうであったように、コードそのものが自動的に生成されやすくなった現在では、その性質がより顕著に現れています。
コーディングエージェントに対する反応はさまざまで、禁止すべきだと主張する人から、「プログラミングは死に、『バイブコーディング』こそが未来である」と宣言する人まで幅広く存在します。私の個人的な見解では、現状ではその真ん中辺りに位置しています。設計案を立案し、その後でエージェントに実装の大部分を任せて、結果をレビューして洗練させるという流れを採用しています。
膨大な量のコード記述は可能ですが、以下の点でボトルネックになっています：
- 理解 —— 既存のコードを読むことでその構造を理解し、論理的に考えること；
- 設計 —— 適切な変更やアーキテクチャを考案すること；
- レビュー —— コードが期待通りに動作しているか確認すること。
あなたの PR に記載されているコードは、これらのいずれにも大きく貢献してくれません。したがって、この件では進めることを避け、マージ対象としてのコード実装を試みることは控えてください。
ではどのように貢献すればよいのか
「コードの記述」部分は価値が低下しているため、それ以外の形で保守者を支援する役割が相対的に高くなるのです。
Feedback を提供してください
私は現在多忙で実際の利用や改善のための調査に十分な時間を割ききれないことが多くあります。そのため、「何が機能しており」「何を改善すべきか」というユーザーの声は非常に貴重です。
アイデアを議論しましょう
私はすべてを知っているわけではありません。異なる経験と視座を持つ方々と話し合うことで、何を作るべきか、どのように作るべきかが明確になります。
バグの報告と調査をサポートください
質の高いバグ報告は、バグそのものの解決の 3/4 を占めることができます。問題を見つけた場合は、詳細な説明とともに再現手順や具体的な問題箇所を特定し、改善案について議論していただけると幸いです。
プロトタイプのコード変更を提示してください
関連する PR とその生成に用いたプロンプトを送付しても構いません。「PR は受け入れない」と以前述べましたが、これは誤解を生む可能性があります。LLM を活用すれば、自分自身の LLM に変更を行って自前でレビューすることも容易です。それでもなお、実装例としてのコード提示は意義があります。実際の機能を実装しているコードを一度見ると、マージせねばならないとは限りませんが有益な情報を得られます。さらに、「コード」を生み出すための元となる「ソース（プロンプト）」を共有してもらえれば、それを再利用・改良することで時間を節約できます。
コードのレビューをお願いします
私はレビュー作業でボトルネックに苦しんでいますので、追加の視点を持てる方が大いに助かります。
フォークして自由に開発してください
コードをフォークし、望むままに変更することを怖がらずにください。複数の利用シーンを支える設計を考えること、合意形成を図ること、最適な結果について議論すること、妥協点を探ることは非常に時間がかかります。LLM の発展により、ソフトウェアのカスタマイズ性は以前より大幅に高まっています。自分が求める変更を、かつてないほど速く・容易に行い、上位リポジトリへのマージ（または非マージ）を自分のペースで行うことができます。単にフォークし、自らの利用シーンをサポートする機能を追加し、独自のスタイルで開発していただければ十分です。許可も謝罪も不要です。このようにすることで、保守者としての私の負担も軽減され、最終的には互いに独自のアプローチから新たな知見を得られる可能性もあります。