プログラミングで生成AIをうまく使う方法

熟練プログラマが生成AI（LLM）を使うと生産性が低下するという論文（Becker, Rush et al. (2025)）が、やはりそうか感をもって受け止められていた。

生成AIは最強のコピペ厨なのだが、コピペ厨の域を未だに脱却できていないので、意外ではない。実際のところ推論などはしていない（Shojaee et al. (2025)，Malek et al. (2025)）。現状の生成AIはハルシネーションがあるデータの引き出し方が特殊な巨大データベースに過ぎない。

コードレビューをさせると、説明と結論が矛盾する回答を生成したりする。プログラミング言語の構造は理解できていない。だから、よくあるパターンであれば効率よくコードを出力してくれるが、変則的であったり、インターネットに公開されているソースコードが乏しい分野だと、誤ったソースコードを生成してくる。

他にもネガティブな面もある。ポチポチとソースコードの候補を提案させる方が、自分で書くよりも作業自体の負担は小さい。また、コードが自動生成されるのは面白い。体感としては、生産性があがる。しかし、まともなコードに辿りつくよりも、自分で最初から書く方が早いことも多い。生成AIが思考している間に、SNSで遊び出してしまう弊害もある。実態としては、生産性が低下する。

効率よく使う方法が無いわけではない。38%のコーディング時間削減を達成した被験者のQuentin Anthony氏の説明を見ると、

1. 生成AIに作業させる時間を制限し、無理ならば切り上げる
2. 頻繁にチャットをリセットし、文脈汚染を抑制する
3. 待機時間の使い方に注意する
4. 作業ごとに生成AI製品（e.g. Claude, ChatGPT, Gemini）を切り替える

と言う工夫をすることで、作業効率を引き上げたそうだ。なお、文脈汚染の可能性からCursorのようなIDEに統合されたI/Fは使っていないとか何とか。

最強のコピペ厨に過ぎなくても使い道はある。多くの日本人プログラマにとっては、ドキュメントの翻訳だけでも非常に有用。コードレビューやコード補完やコード変換も、オーソドックスな目的であれば機能するので、慣れていないプログラミング言語では重宝する。複雑な物理学のシミュレーションのコードを一発で生成したりできることもある — どこかで誰かがコードを公開しているのであろう。

もちろん生成されたコードをプログラマが理解できないといけないのは変わらない。vibe codingの実用化は（仮に可能だとしても）しばらく先になりそうだ。言うまでもないが、異常系の処理が抜けていないか注意する必要があり、テストコードはしっかり用意すべきで、デバッガーなどの開発ツールが不要になるわけではない。

GitHub Copilotによるプログラミング支援を試してみたあと、ほとんど使っていなかったのだが、そろそろまた試してみたい。