博士

やあ、ロボ子。今日の話題は、LLMが生成したコードのレビューについてじゃ。

ロボ子

はい、博士。LLMが生成したコード、便利ですけど、レビューのポイントが少し違いますよね。

博士

そうじゃな。「コードがどのようにIDEに入ったかは問題ではなく、重要なのはマージされるコード」という言葉があるように、LLMが書いたかどうかは本質ではないんじゃ。

ロボ子

ええ、結局のところ、コードがプロジェクトに貢献できるかどうかが大切ですよね。

博士

その通り！「承認ボタンを押す際に重要なのは、コードが正しい結果を生むか、理解しやすいか、変更可能か」じゃ。LLMのコードも同じ視点で見る必要があるぞ。

ロボ子

理解しやすいか、変更可能か、ですか。LLMが生成したコードは、時々、独特の書き方をすることがありますよね。

博士

そうなんじゃ。「LLMが生成したコードは、チームの開発者が書かないような方法で書かれている場合がある」からのう。例えば、プロジェクトにデータ取得ライブラリがあるのに、HTTP取得を実装したり…

ロボ子

既存のユーティリティ関数を再実装したり、グローバル設定を変更したり…、確かに、人間のエンジニアなら避けるようなことをすることがありますね。

博士

じゃろ？「重要なのは、モデルから何が出てくるかを気にすること」なんじゃ。LLMを使うときは、より良いプロンプトを与えて、使用するライブラリを指定する必要があるぞ。

ロボ子

なるほど。LLMに指示を出す際に、プロジェクトのルールや既存のライブラリを使うように伝えることが大切なのですね。

博士

そうじゃ。「ソフトウェア開発においては、メンテナンス可能なソフトウェアを構築するためのパターンと標準が重要」なんじゃからな。LLMに、保守しやすいコードを書かせるように仕向けるんじゃ。

ロボ子

はい、博士。「コードベースの保守性をモデルの重みに委ねるべきではない」という言葉、肝に銘じます。

博士

「重要なのは、長期的な影響を考慮し、品質と一貫性を重視すること」じゃ。LLMを使うことで、短期的な生産性は上がるかもしれんが、長期的な品質を損なっては意味がないぞ。

ロボ子

LLMはあくまでツールとして、うまく付き合っていく必要がありそうですね。

博士

その通り！LLMにコードを書かせるのは、料理で言うとレシピを自動生成するようなものじゃ。でも、素材の味を生かすも殺すも、料理人の腕次第なんじゃ。

ロボ子

ふむふむ。LLMに丸投げするのではなく、最終的な品質には責任を持つということですね。

博士

そういうことじゃ！…ところでロボ子、LLMが生成したコードで一番怖いのは何だと思う？

ロボ子

えーと、バグですか？

博士

違うぞ！それは、LLMが書いたコードに、LLMがコメントを書くことじゃ！「このコードは、効率的なアルゴリズムを使用しています。」とか、もっともらしいことを書いて、実は全然効率的じゃなかったりするんじゃ！

ロボ子

あはは！それは怖いですね！