コミットの説明を思考ツールとして使う

AI時代以前は、大きな変更に対してかなり長いコミットの説明（またはコミットボディ）を書いていました。それを下書きして、重要なことを見落としていないか確認するために、5分から10分ほどかかっていました。その理由はいくつかあります。読者が複数の場所を探し回る必要がないように、すべての有用な情報を含めたかったのです。何を変更したのか、そして、より重要なのは、なぜ変更したのかを説明したかったのです。「何」は一般的に自己説明的な変更を要約しますが、「なぜ」を説明するための出発点となります。時には、まるで誰かにメッセージを書いているかのように一人称で書くこともあります。「私はこれを〜のために行った」「私たちは〜するまでこれをやっている」などです。そして、なぜそうしたのかを説明します。そうすることで、他の人、そして最も重要な自分の将来の自分が、なぜその変更を行ったのかを理解しやすくなります。それは良い訓練でした。コミットメッセージと説明を書くだけではありませんでした。書くプロセス自体が、書いたコードについて考えるのに役立ちました。コードを読み返し、変更点を要約します。その過程で、意思決定を再評価する傾向があり、時にはそれが異なる、あるいはより良い変更につながることもありました。 今はエージェントコーディングの時代であり、コードからコミットの説明まで、すべてAIが書いています。AIが書いたコードを読むべきか、そしてその可読性がどれほど難しいかについては、大きな議論があります。私が難しいと感じるのは、AIが書いたコミットの説明を読んだり理解したりすることです。エージェントは、それが行った変更に対してコミットメッセージを書くことができます。しかし、それらは異なるコミュニケーションツールやプロジェクト管理ツールにまたがって存在する、完全なコンテキストを持っていない可能性があります。それらの一部はオフラインである可能性もあります。AIが「なぜ」の部分を知らない場合、独自の理由を思いつきます。私はそれが危険だと感じます。後でそれを読んだとき、本当の理由は全く異なっていたため、意味をなさないかもしれません。明白な解決策の一つは、エージェントに必要なすべてのコンテキストを、チャットやツールを通じて提供することです。これにより、捏造された理由の問題を修正するのに役立ちます。エージェントは今、明確に「なぜ」を説明できます。しかし、これはもう一つの問題は解決しません。適切なコンテキストを持つエージェントは、説得力のあるコミットメッセージを書くでしょう。しかし、コードが説明されていることを実行しているかどうかを確認できるのは、私だけです。そこで、私がやっていることがあります。コミットメッセージと説明は自分で書きます。理由は以下の通りです。コミットの説明を自分で書くことは、AIが行った変更について考えるのに役立ちます。また、すべてが意図した通りであるかを確認する方法でもあります。もし「なぜ」を説明できないのであれば、理解していないものを出荷していることになり、後で問題が発生した場合に説明したり修正したりするのが難しくなります。古い言葉に戻ります。説明できないのであれば、理解していないということです。コミットの説明は、ここでも思考ツールとして機能します。「私は〜するまでこれをやっている」のような部分は、出口基準を持つ一時的な決定です。出口条件を設定することがありますが、AIはコードや他のツールからはそれを推測できません。なぜなら、それらはあまりにも明白であるため、どこにも書き留められていないことが多いからです。しかし、コミットメッセージを書くことは、その文を完成させることを強制し、将来の読者がその変更を維持すべきかどうかを判断するのに役立ちます。エージェントはコードと説明を書くことができます。しかし、「なぜ」を書くことで、出荷しているものを理解しているかどうかを知ることができます。