巨大なPRを送るのはやめてくれ——レビュアーへの負担が限界に
Stop sending me huge PRs; a rant
AIによるコード生成が当たり前になり、1回のプルリクエストで数千行の変更が送られてくることに疲れたレビュアーが、小さいPRの重要性を訴える。小さいPRは書きやすいからではなく、レビューしやすく理解しやすいからこそ求められる。また、変数名が明確ならコメントは不要で、AIにレビューさせるなら人間のレビューは不要だとも主張する。React登場時もPRが大きくなりすぎなかったように、AI時代でもレビューの質を保つべきだと説く。
コードを完全に理解するのにかかる時間は、行数に応じて指数関数的に増えると、私はデータもなく大げさに推測している。
HNでの議論
111- danpalmer
私の経験では、モデルに小さなPRやコミットを作成するよう依頼すると、パフォーマンスが大幅に低下します。モデルには、作業を順序立てて依存関係を効率的に理解する能力が欠けており、それを管理するのが難しいのです。小さなPRができないというわけではなく、それを行うには膨大なリソースが必要になり、それがコンテキスト制限などにぶつかるのです。そして、コミットやPRのスタックに戻って編集し、途中にリベースするとなると、さらに困難です。これらはコード量やコミット数に対して線形にスケールするとは思いません。
これに加えて、モデルは一般的にストーリーテリングが苦手です。なぜなら、それにはコミュニケーション相手の心の理論が必要だからです。レビューのための作成とはストーリーテリングであり、レビュアーの信頼を築くような形で変更を行うことです。現在のLLMがこれを達成するにはまだ数年かかると思います。
私の意見では、これらのことができないなら、それはソフトウェアエンジニアリングのコスプレに過ぎません。バイブコーディングにも用途はありますし、LLMプログラミングにも用途があります。私もよくやります！しかし、これをソフトウェアエンジニアリングだと思うなら、自分を欺いており、基準を危険なほど低くしていることになります。
- gensym
> では、なぜ人間のレビューに出したのですか？
これが問題の核心のようです。
おそらく、ほとんどの場合、その答えは「それが本番環境に変更を入れるための必須のゲートだから」でしょう。PR作成者がレビューの価値を認めていないなら、レビューしやすいPRを書くように説得するのは難しいでしょう。
もし本当に人間のフィードバックを求めているなら、人間のフィードバックに適した形でPRを提出する方法を伝える方が、はるかに成功するでしょう。
- bawolff
> 疲れたよ、ボス。エージェントが「問題全体を一発で解決」できたせいで、1000行、2000行、3000行のPRをレビューするのに疲れた。小さなPRが求められたのは、書くのが簡単だからではなく、常にレビュアーのためだったんだ。
100%同意。
でも「ノー」は2文字の言葉であり、メンテナーとして最も重要で最も難しい部分の一つでもある。
- sackfield
PRを小さなチャンクに分割するのは合理的ですが、限界があります。レビュアーの中には、これに非常に熱心で、合理的な範囲を超えて分割するよう主張する人もよくいます。例えば、分割することで意図が損なわれる場合や、「千行」のPRが単に大量のテストを含む場合（AIはテストを書くのが大好きで、私はそれが好きです）などです。タスクによっては単に長いものもあり、レビューの際にはそれを文脈に沿って理解することが重要です。
しかし結局、こうしたレビュアーは恐竜のように絶滅するでしょう。記事は実際に、AIで大きなPRをレビューするという考えは「AIがすでに生成したコードを再読込するためにトークンを無駄にする」から悪いと述べています。これはあまり意味が通りません。AIは頻繁にAI生成コンテンツを再読込します。評価はその良い例です。
この直後、記事は実際の問題に触れています。「なるほど、ではなぜ人間のレビューに提出したのですか？」確かに、これは良い質問です。なぜ人間のレビューに提出するのでしょうか？彼らは実際には人間のフィードバックを望んでいないでしょう。人間がゲートキーパーとして自分を置き、なだめられる必要があり、おそらくそのゲートを維持する最も非効率な方法を選び、時代のテクノロジーについていっている全員を遅らせているのです。
- ulrikrasmussen
他人がレビューするには大きすぎるPRを生成するなら、それは自分でレビューするにも大きすぎる。つまり、コードを理解するタスクをLLMに委任していることになり、最終的には組織内の誰も、入ってきたばかりの新人よりもコードを理解していないという結果になります。彼らはあなたと同じように次のLLMプロンプトを書くことができます。なぜなら、彼らはあなたと同じくらいシステムについて知らないからです。
その状況でお聞きします：ソフトウェア企業としてのあなたの堀は何ですか？Anthropicのような企業が「ソフトウェア企業-as-a-service」を提供し、中間業者と6桁の給与を排除できるのに、なぜ顧客はあなたに支払い続けるのでしょうか？
- usewik
> 変数名が適切でなくコメントが必要なら、変数名を改善しましょう。
100%同意。ついでに、コメントの壁を必要としないように関数の命名と記述を検討してください。クリーンコードのアンクル・ボブ流に。
- ventana
個人的に試したわけではないアイデアですが：AIエージェントはCI失敗などの技術的な制約を理解します。PRのサイズが妥当かどうかをチェックし、妥当でなければ丁寧なメッセージ付きで自動的に拒否するCIジョブを設けてみてはどうでしょうか？例えば、「このPRのサイズは、レビューを受け付ける上限のN行を超えています。大きな機能を実装する場合は、いくつかの小さなPRに分割することを検討してください。」といった感じです。効果がない可能性もありますが、効果があるかもしれません！
- dpc94
ついでに言うと、AIが生成したPR本文を小説のように長々と書くのはやめましょう。レビューが難しく、不必要に冗長です。説明はレビュアーのためにあるべきです。