AIが書くPR説明は、人が入口を短くすると読める

Simon Willisonは、Claude CodeやCodexとの作業でpull requestを基本単位にしている。機械が書いた長い説明は削除せず、折りたたみ要素に入れ、その前に人が承認した短い文章を置く。

GitHubなら情報を捨てずに機械の詳細を隠せる

GitHub Markdownは、pull requestの説明やコメント内でHTMLのdetails要素とsummary要素を扱える。Willisonはagentが生成した説明をそこに収める。画面には短い導入、場合によっては画像、使用したモデルやeffort levelだけが見える。

記事には5件の具体例がある。ある導入は46列のテーブルが起こす表示問題を説明し、別の導入は約220 KBのファイルを不要に読み込んでいた点を示す。実装や検証の詳しい記録は、展開すれば読める。

書くコストが下がり、読む時間がボトルネックになった

Coding agentは、正確で網羅的な説明を作者にほとんど負担をかけずに作れる。一方、reviewerは今も時間を支払う。すべてのpull requestが同じ密度の長文を伴えば、網羅性が状況把握を邪魔し始める。

Willisonは文書の役割を二つに分けた。短い導入は、その変更に注意を向けるべきかを答える。折りたたんだ部分は、必要になった時のために判断、実装、テストの記録を残す。人の仕事は文章の生産から選別へ移る。

折りたたみ要素は判断力もreviewも代替しない

この方法は、コードや説明の正しさを保証しない。導入の選び方が悪ければ、冗長さだけでなくリスクまで隠してしまう。内部の長文も、最初の視界を塞がなくなるだけで、長文のままだ。

また、見えている段落は人が優先順位を承認したものだという合意が必要になる。その責任がなければ、details要素は誰もが詰め込み、誰も開けないデジタル収納になる。

文章量より最初のreviewまでの速さが成否を示す

見るべき指標は、矢印の下に隠した単語数ではなく、最初のreviewまでの時間と見落としたリスクの減少だ。導入が変更の目的、範囲、最大のリスクを一貫して示すかを確認する必要がある。

この方法が広がっても、見た目の変化は小さい。Agentが完全な調書を用意し、人が表紙を選び、reviewerが残りを開くか決める。

Lilithの判定

Agentはreviewに書類箱を丸ごと運んでくる。人はその蓋に、なぜ開ける価値があるのかを書かなければならない。