オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている（ご存じの方は彼にご一報を）。
件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。
これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいくつか機能が追加され、バージョン1.2でさらにたくさん機能が追加され……バージョン3.0になる頃には、当初のエレガントなユーザーインターフェイスはぐちゃぐちゃで見る影もなくなっている。
複雑さの問題は、ユーザーインターフェイスに限った話ではない。今では、昔にはなかったセキュアプログラミングやクラウドへのデプロイメントに気を遣う必要がある。セキュリティのような要件はコードを複雑にする傾向にあるが、複雑さそれ自体がセキュリティの問題を覆い隠してしまいがちだ。後付けでセキュリティを追加しても、大抵うまくはいかない。そうでなく、最初からセキュリティを組み込んで設計し、ソフトウェアの他の部分と歩調を合わせて管理しなくてはならない。
さて、ここからが本題だが、今や GitHub Copilot や Code Interpreter や Google Codey といった生成 AI ツールで書かれたコードを目にする機会が増えている。しかし、こうしたツールは複雑さを気にしないものだから、結局は人間がそのコードを理解してデバッグする必要がある。
そして、複雑さの問題は、個々の関数やメソッド単位の話では済まない。職業プログラマーの多くは、何千もの関数、何百万行ものコードで構成される大規模なシステムに取り組んでいる。その全体的な構造、アーキテクチャを理解している人がどれだけいるだろう。開発者よりも長生きするかもしれないレガシーコードの複雑さをどう考えたものだろう。
コンピュータシステムがより大規模で複雑になるにつれ、ソフトウェア・アーキテクチャの重要性は増すばかりだ。現代のソフトウェアシステムの複雑さを軽減する役目は、まだ生成 AI に耐えられるものではなく、人間の仕事である。多くの開発者は、コード行数を最小限にすることが単純化の鍵だと思っているが、それには一つの行に複数のアイデアを詰め込んだ複雑な呪文になり、コードの読みやすさを損なう副作用がある。
もちろんマイク・ルキダスは、生成 AI がソフトウェア開発に使えないとか、役割がないとか主張しているのではない。生成 AI には使い道が確かにある。彼が言いたいのは、コードの自動生成にとらわれ過ぎて、複雑さコントロールするのを忘れてはいけないよということ。大規模言語モデルも、将来はともかく、少なくとも今はその助けにはならない。それでも、人間が複雑さに関する問題を理解し、解決するための時間を捻出できるなら、確かに AI は利益になると言えるわけだが。
大規模言語モデルが、100万行ものエンタープライズ・プログラムを書ける日は来るだろうか？ と最後にルキダスは問いかける。おそらくは来るだろう。しかし、それを指示するプロンプトを誰かが書かなければならないということを意味する。それを行う人間は、問題の複雑さを理解し、それを管理するというプログラミングの宿命といえる問題に直面することになると締めくくっている。
うーん、そのうち最終的な目標をプロンプトとして与えれば、複雑さを管理しながらエンタープライズの規模まで自己増殖のように規模を増していくプログラムを書けるようになる生成 AI が登場したりするんですかね？
