最近、Claude に書いてもらった PR が読めない。
いや、タイトルはまだわかる。「〇〇機能の追加」とか「〇〇の不具合修正」とか。そこまでは良い。
問題は本文である。
オメーはダメだ。何言っているんだキミは？
実のところ、これは僕自身の問題かもしれない。ショート動画や X の見過ぎで、長文を読む認知能力が低下している可能性は否定できない。
ただ、正直なところ、AI の書いた PR は読みづらくないか？
何しろ量が多い。背景、修正内容、技術的な判断、テスト結果。実に丁寧に、色々なことが書かれている。
しかし、長い。
ついでに言えば、読み手が全員優秀であることを前提にしているのか、説明に必要なコンテキストが伝わってこない。
なんの機能をどう修正したのか、よくわからないのである。
PRの本文がなかった時代
人間同士で開発していた頃、PR の説明については色々な揺り戻しがあった。
例えば、本文のない PR。
正直、僕も何回も書いた。
タイトルを見ればわかるだろう、という意味である。
もちろん、同僚諸氏からも本文のない PR を受け取っていた。彼らの PR は粒度が素晴らしかったので、タイトルと差分を見れば十分にレビューできた。
ところが、たまに新人さんが長大な変更を持ってくる。関連する別の修正まで混ざっている。
そこで議論が起きる。
「PR には背景を記載しましょう」
そんなルールが出来始めた気がする。
やがて PR にはテンプレートが用意され、背景、修正ポイント、テスト方法など、記載すべき項目がどんどん増えていった。
とはいえ、所詮は人間である。
書かれている内容は適当だった。
酷いときには、TBD と書かれたままマージされる PR まであった。
それでも、まあ、なんとかなっていた。
ところが AI は違う。
テンプレートがあれば律儀に埋める。背景も修正内容もテスト結果も、丁寧に書いてくれる。
僕らが人間に求めていたことを、AI はきちんと実行してくれるようになった。
その結果、今度は僕らが読めなくなった。
責められない。
PRのslopを無くすスキル
最近、世間でも似たような風潮を感じる。
例えば「PR の slop を無くすスキル」。
AI が生成した冗長な PR の説明を、短く整理するためのスキルである。
いるかそれ……？
もちろん、読みやすくなるのなら良いことだと思う。
ただ、デフォルトで生成される PR が使いにくいのであれば、そもそも何かが深刻な間違いを孕んでいるのではないか？
人間が説明を書かないので、テンプレートを用意した。
AI がテンプレートを律儀に埋めてくれるようになったので、今度は説明を削るスキルを用意する。
なんだこれ。
とはいえ、単純に短くすれば読めるようになるのかと言われると、それもよくわからない。
少なくとも、今の僕には長すぎる。
承認ボタンをクリックするおじさん
この話は、個人開発でも会社の仕事でも変わらない。
ただし、会社の方が酷い。
今の職場では、FSD、AC、Issue、Implementation、PR、Merge と、開発工程のほとんどが AI 化されている。
AI が仕様を書き、受け入れ条件を定義し、Issue を作り、コードを書く。
出来上がった PR には、別の AI がレビューを入れる。設計に応じた観点や、PR 単体を見た観点から指摘が入り、僕の AI セッションがそれを修正する。
そして同僚が Approve してくれる。
僕は思考停止してマージボタンをクリックする。
そもそも、目の前のコードが何をする部分なのかも、よくわかっていない。
せめて PR のレビューくらいはきちんとしたいところではある。
しかし、それも難しそうだ。
何しろ、PR の内容を理解するには、そもそも何を作ろうとしているのかを理解しなければならない。
そのためには FSD や AC を読まなければならない。
……それも AI が書いている。
そんなわけで、僕は会社から配られたトークンを消費すべく、定期的に「承認」ボタンをクリックするおじさんになっている。
一方、個人開発では
こちらは様子が異なる。
完全に発注者と化した僕は、デプロイされて動くアプリをいじりながらニヤニヤするだけである。
そもそも PR の内容など読んでいない。
ただし、ゼロから自分で開発してきたので、なんとなく自分の初期設計が引き継がれている。
たまに PR やコードの全景を眺めると、
「まあ、うまくいってそうだな」
とか、
「そして、ここはダメだな」
という場所がわかりやすい。
実装の細部を理解していなくても、全体像はなんとなく把握できている。
会社では、そうはいかない。
僕はすでに開発が進んでいる環境に、途中からジョインした。
既存の設計があり、仕様があり、過去の経緯がある。
昔なら、ある程度それらを理解しなければ、そもそもコードを書き始められなかった。
ところが、今は AI が書いてくれる。
理解するより先に PR が出来上がる。
しかも、AI のおかげで開発速度が上がったものだから、「早く PR 出そうよ」というプレッシャーまでかかる。
周囲からも、自分自身からも。
そうして、コンテキストが頭に載らないまま開発が進んでいく。
ドキュメントはある。誰も読んでいない。
昔、新しく開発チームに参加したときには、こんなことを言われた。
「ごめん。そもそもドキュメントが無いんだ」
忙しいから仕方ないよね。
だから既存のコードを読み、同僚に聞き、実際に手を動かしながら、少しずつシステムを理解していった。
今は違う。
ドキュメントはある。
FSD も AC も Issue もある。AI が書いてくれるのだから、いくらでもある。
ただし、多分、人間は誰も読んだことがない。
そして、その説明がコンテキストフルで、よくわからない。
これは、なかなか面白い状況だと思う。
昔はドキュメントがないから理解できなかった。
今はドキュメントがあるのに理解できない。
しかも、理解できなくても開発は進められる。
AIのコンテキスト境界
ここまで考えて、一つ気づいたことがある。
今の AI は、コンテキストの境界が曖昧なのだ。
良い意味でフルスタックである。
FSD も AC も Issue も、フロントエンドもバックエンドも、既存のコードも、何もかもコンテキストに積む。
そして、それらを全部理解した上でコードを書き、ドキュメントを書く。
これは素晴らしいことだと思う。
ただし、そのドキュメントを読む人間にも、同じコンテキストが求められる。
例えば、Claude が大量の仕様書と既存コードを読み込んで、ある機能を修正したとする。
Claude は、それらを前提として PR の説明を書く。
一方、僕はそれらを読んでいない。
読んでいたとしても、全部を頭に載せているわけではない。
そして Claude は、僕が何を知っていて、何を知らないのかを知らない。
そもそも、そんな指示をしていないのだから、当たり前である。
人間同士で開発していた頃は、もう少しコンテキストの境界が明確だった気がする。
フロントエンドの担当者はフロントエンドを、バックエンドの担当者はバックエンドを理解している。
もちろん、それぞれが担当領域以外のことも知っているし、チームによって事情は異なる。
ただ、少なくとも同僚諸氏は、僕が理解できる粒度で PR を出してくれていた。
今の AI は、その境界を簡単に飛び越えてしまう。
人間が複数人で分担していた知識を、全部まとめて一つのコンテキストに積めるのだから。
そして、全部理解していることを前提に、丁寧な説明を書いてくれる。
そりゃ、読めないわけだ。
そう考えると、PR の説明を短くするスキルが本当に必要なのか、という最初の疑問にも戻ってくる。
問題は単純な文章量ではなく、読み手と書き手のコンテキストの境界が一致していないことなのではないか。
文章を短くするだけでは、必要なコンテキストまで削ってしまうかもしれない。
とはいえ、読み手のコンテキストに合わせて説明を書いてもらうためには、まず僕自身が何を理解していないのかを把握しなければならない。
困ったねぇ。
ところで
ここまで、Claude に書いてもらった PR が読めないという話をしてきた。
人間同士で開発していた頃の PR の話から、会社と個人開発の違い、そして AI のコンテキスト境界の話まで来てしまった。
随分と長い記事になった。
ところで、この記事は ChatGPT との雑談をもとに、ChatGPT に書いてもらっている。
僕が思いついたことを話すと、ChatGPT が背景を整理し、論点を抽出し、丁寧に説明してくれる。
そして、僕はそれを読んで、気に入らないところを修正し、最後に承認する。
……。
会社では Claude に PR を書かせ、個人開発では Claude にコードを書かせ、ブログでは ChatGPT に記事を書かせる。
もはや、承認ボタンをクリックするおじさんは、会社だけの話ではなかった。
さて。
この記事、ちゃんと読めるかしら？