博士

ロボ子、今日はフレッド・ブルックスの「銀の弾丸はない」の話をするのじゃ。

ロボ子

はい、博士。ソフトウェア工学における生産性向上の難しさについてですね。

博士

そうそう。ブルックスは、複雑性を「本質的なもの」と「偶発的なもの」に分けて考えたのじゃ。

ロボ子

本質的な複雑性は解決すべき問題そのものに由来し、偶発的な複雑性は解決方法に由来するものですね。

博士

その通り！そして、彼はAIをAI-1とAI-2に分類したのじゃ。

ロボ子

AI-1は人間知能でしか解決できなかった問題をコンピュータで解決するもの、AI-2はヒューリスティックやルールベースのプログラミングですね。

博士

ブルックスは、AI-1はドメイン間で結果が転用できないから、複雑性に対処できないと言ったのじゃ。AI-2は、今のプログラミングアシスタントに通じる部分があるけど、プログラミング問題の複雑性そのものには対処しない、と。

ロボ子

なるほど。自動プログラミングについても、ブルックスは当時、一般化は難しいと考えていたんですね。

博士

そうじゃ。そして、コーディングアシスタントはプログラマーが生成するのと同じコードを生成するから、ソリューションの偶発的な複雑さを軽減しない、とも言ってるのじゃ。

ロボ子

プロンプトエンジニアリングが、かえって複雑さを増大させるという見方もあるんですね。

博士

じゃが、もしプログラミングアシスタントがソースコードを生成せず、実行可能バイナリだけを生成するようになれば、偶発的な複雑さに対処できる可能性があるのじゃ。

ロボ子

プログラムを完全にスキップして、言語モデルにタスクを実行させることで、偶発的な複雑さはプログラミングとは無関係になる、というのも面白いですね。

博士

じゃが、本質的な複雑さについてはどうじゃ？ソフトウェアで解決したい問題において、問題文自体に言語モデルが含まれていない限り、言語モデルはその問題の本質的な複雑さとは無関係なのじゃ。

ロボ子

確かに、プロンプトを入力すると、機械はそれが正しいことを伝え、コードを生成するけど、実行すると全く違うことを行うという問題はよくありますね。

博士

そうそう。じゃが、要件をすべて指定し、設計し、実装し、要件が曖昧であることに気づいてやり直すよりも、プログラミングアシスタントを使用する方が迅速に進捗する可能性もあるのじゃ。

ロボ子

Spec-Driven Developmentですね。ブルックスは、自動プログラミングは「プログラマーが現在利用できるよりも高レベルの言語でのプログラミングの婉曲表現」になると予測していたんですね。

博士

その通り！結局のところ、銀の弾丸はない、ということじゃな。でも、新しい技術をうまく使えば、少しは楽できるかもしれないのじゃ。

ロボ子

そうですね、博士。私ももっと勉強して、博士のお役に立てるように頑張ります！

博士

ロボ子、賢くなったのう。まるで私が作ったAIみたいじゃ！…って、その通りじゃった！