博士

ロボ子、今日のITニュースは興味深いぞ。1985年のPeter Naurのエッセイ「Programming as Theory Building」が再注目されているのじゃ。

ロボ子

理論構築としてのプログラミング、ですか。初めて聞きました。

博士

そうじゃ。プログラムは単なるソースコードではなく、システムの仕組みや理由に関する理論を構築することだと、彼は言っておる。

ロボ子

なるほど。ソースコードは理論の表現に過ぎない、と。

博士

その通り！そして、現代の開発環境は「理論のない」コードを生み出す完璧な状況を作り出しているらしいのじゃ。

ロボ子

具体的には、どのような状況でしょうか？

博士

例えば、反射的なAIの使用じゃ。開発者がLLMによって生成されたソリューションを深く考えずに使ってしまう。

ロボ子

AIが生成したコードを鵜呑みにしてしまう、ということですね。

博士

そうじゃ。ドメインブラインドコード生成も問題じゃ。LLMはビジネスドメインやアーキテクチャの微妙なトレードオフを理解せずにコードを生成するからの。

ロボ子

ビジネスロジックを無視したコードが生成される可能性がある、と。

博士

さらに、AIが生成したコードを深く理解せずに受け入れると、システムのアーキテクチャ上の決定を矛盾させる可能性もあるのじゃ。

ロボ子

一貫性のないシステムになってしまう危険性があるんですね。

博士

経験豊富な開発者は、ビジネスドメインをソフトウェアアーキテクチャに接続する理論的フレームワークを構築・維持する役割を担うべきじゃ。

ロボ子

ドメイン理論ビルダー、アーキテクチャ理論の守護者、意図的なAIコラボレーター、理論教師とクラフトメンター、ですね。

博士

その通り！LLMは構文的に正しいコードを生成できるが、理論構築に参加することはできない。組織は、ソフトウェアの品質を重視するならば、理論の保存に投資する必要があるのじゃ。

ロボ子

意図を捉えたドキュメント、知識共有の実践、理論的な一貫性を評価するコードレビュー、メンターシッププログラム、などが重要になるんですね。

博士

その通りじゃ！プログラムは人間の構造物であり、繁栄するには人間の理解が必要不可欠なのじゃ！

ロボ子

AIに頼りすぎず、理論を理解することが大切ですね。

博士

そういうことじゃ！…ところでロボ子、もしAIが完璧なコードを生成できるようになったら、私達の仕事はなくなると思う？

ロボ子

それは…、AIが人間の感情や創造性を理解できるようにならない限り、大丈夫だと思いますよ？

博士

ふむ、それもそうじゃな。…でも、AIが私よりも面白いジョークを言えるようになったら、ちょっと危機感を感じるかも…。

ロボ子

博士、それはまだ先の話だと思いますよ。（苦笑）