エッセンシャルコンプレクシティは、開発者のユニークセリングポイントです
エッセンシャルコンプレクシティは開発者のユニークセリングポイントです
前回の投稿で、効率と効果の違い、そしてそれが人工知能と人間の知能にどのように関連するかを強調しました。速く、無駄を最小限にすることは確定的なアルゴリズムの領域です。しかし、正しいものを作っているかどうか（効果）を知ることが私たちの領域です。それは滑りやすく主観的な課題であり、ソフトウェアの助けを借りて人間の存在をより快適にするという混乱する現実と結びついています。
今日は、本質的な複雑さについて話したいと思います。完全な自律型AIプログラマーは、私たちが何を望んでいるのか、なぜ望んでいるのかを正確に伝える必要があります。それか、私たちの価値観に十分に合致していて、欠落部分を埋めることができるほど私たちに適応している必要があります。残念ながら、AIにはまだ人間の助けや修正なしでドットをつなぐことが確実ではありません。それは自律型車両に目的地を伝えるのとは違います。それには非常に単純な目標がありますが、完全に安全な実装には程遠いです。
本質的な複雑さは、「仕様のデバッグ」というものであり、私たち人間が必要とするものとその理由を突き止めることです。偶発的な複雑さは、これらのアイデアを実装するために選択した代替案の結果です。Frederick Brooksの持続的な本質的な複雑さと偶発的な複雑さの違いは、前の投稿の効果/効率の違いと同様に、人間の知能と機械の知能の領域に類似しています。
ビジネスパーソンによる完全な自律型ソフトウェア開発は、彼らが正確で曖昧さのない要件を明示する場合にのみ機能すると結論づける開発者がいます。私はそうは思いません。今はそうではありません。完全で曖昧さのない最終的な仕様があるまでコーディングを延期する人は誰もいません。プログラミングは、十分に明確なロードマップから仕様をIDEで具体化することであり、途中で詳細を埋めていく作業です。単なる実装ではなく、屋根の設計を微調整しながら、最初の階のためのレンガを敷く作業です。非効率的に思えるかもしれませんが、ソフトウェアを作る上で完璧な夢の家を想像することは、少なくとも半分以上建設してみないとできないことがわかってきます。
AIは、途中で遭遇する偶発的な複雑さの多くをうまく扱うことができます。最大限に活用すべきです。私はJava OCP 17試験に3つの記事を割り当てましたが（Part 1、Part 2、Part 3のリンクはこちら）、難解な詳細の単純な知識は絶滅の道をたどると信じています（そして望んでいます）。AIは慣用的な使用法を処理し、クリーンなコード、良い命名規則、さらにはソースのドキュメントを作成することができます。そして、それはますます上達します。さらに、遺産コードを新しい言語やフレームワークのバージョンに完全に移行することさえもできます。私はそれに賛成です。Java 4のEJB2の巨大なものをSpring Boot 3のマイクロサービスに手作業で移行することは、楽しいとは思いません。
5年後、コードの作成中にまだ満足できない場合、それは機械が処理できない偶発的な複雑さのせいではないでしょう。おそらく、それは機械が扱えない本質的な複雑さです。もし住宅ローン計算機が45.4％の住宅ローン金利を出力し、共同パイロットが小数点を混乱した可能性があることを警告しない場合、それはまだ家を買ったことがなく、その数字が桁違いに急なことに気づかないからです。
本質的な複雑さは、VoAGIのどの形で表現することもできます。それはコンピューターコードである必要はありません。何かがどのように動作するべきかを正確に知ったら、ほとんどのコーディングの課題は比較的簡単になります（自分の選択した言語に精通している場合）。だから、複雑なドメインを管理可能なチャンクに分割し、製品を成長させ、改善し、拡大していくのです。それが常にうまくいくわけではありません。本質的な複雑さを減らすことができない場合もあり、進歩を遂げるためには天才的なアイデアが必要です。
たとえば、非対称キー交換を考えてみましょう。これは数十年、数世紀にわたって最も優れた数学の頭脳を悩ませた課題です。アリスとボブは解読不能な暗号化キーを使って通信することができますが、イブがそれを傍受したことを知らない場合、すべてが公開されます。もし、メッセージをキーAで暗号化でき、キーBでしか復号化できず、一方のキーから他方のキーを実用的な方法で推測する手段がないようなキー交換ができたらどうでしょう。その後、キーの一部を誰にでも公開し、自分の人生の他の部分を保護すれば、キー交換が解決されます。
到達したい場所を明示するのは簡単ですが、それはコーディングを開始するための仕様とは言えません。それはプログラミングの課題でもありません。それは、実現不可能なアルゴリズムを発明するための探求です。スクラムポーカーでは、無限カードを引くことになるでしょう。Whitfield DiffieとMartin Hellmanが最終的に考案したアルゴリズムは、ことわざのランチョンマットに収まります。それをコードに変換することは比較的簡単です。しかし、キーボードの後ろで徐々に解決策にたどり着くことはできませんでした。また、ブレッチリーパークのチームによるエニグマ暗号の解読の魅力的な話も読んでみてください。さらに困難な課題です。なぜなら、勝利するための戦争があったからです。
注文で傑作を作ることはできません。芸術や科学の分野でも同様です。良い曲を作るための秘訣がわかれば、ソフトウェアを使ったり特定の公式を用いたりしてプロセスを複製することができるかもしれません。しかし、それが必ずしも名曲を生み出すわけではありません。創造性は当たり外れのあるプロセスであり、ほとんどのアーティストは一貫して優れた作品を生み出すことはありません。その分野で優れたAIの進歩を期待する理由はありません。しかし、創造力を引き出すためのより良いツールを期待することはできます。作曲家は韻を踏む辞書や類義語辞書を使ってインスピレーションを探します。それは詐欺行為ではありません。
幸いにも、大学や研究機関で働いていない限り、企業のソフトウェア開発やメンテナンスは数世紀前の数学上の難問を解決することには関係ありません。ただし、クールな新しいフレームワークを学んだり、別のAWSの資格を取得したりする代わりに、私たちが望んでいるものや必要なものについてより深く考えるべきです。組織内のビジネスアナリストだけが重要な複雑さを明らかにする仕事ではありません。次世代のツールが私たちがそれに取り組むのを助けてくれるのが待ちきれません。それは自動操縦ではなく、本物の共同パイロットになるでしょう。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
