なぜ便利なソフトウェアを書くのはいつも難しいのか

なぜ便利なソフトウェアを開発するのはいつも難しいのか

私は前の2つの投稿で、効率的と効果的なソフトウェアエンジニアリングの違いについて、そしてそれが偶発的な複雑さと本質的な複雑さと関連していることについて書きました。私はAIが今後数十年でプログラミングの専門職をどのように変えるのかに興味を持っていますが、短期的なハイプのある予測には批判的です。AIは数十年にわたって価値のあるソフトウェアを夢想することはありません。それこそが真に難しい問題です。AIは効率性の向上に役立つことができますが、効果性にはお粗末な仕事をします。

それを不確実な仕事として再表現しましょう。効果性とは、正しいものを構築することです。私たちの人間の利益に沿っており、私たちに害を及ぼさないものです。他の車や歩行者に衝突しないように設計された自動運転車は、せいぜい信頼性に欠けます。保護策を指定することは簡単ですが、実装するのは非常に難しいです。そして、さらに困難になります。道路上に数百万台の自動運転車が存在すると、毎日、これらのいくつかが生死をかけた選択を行います。機械は他の人間のために最善の判断をしなければなりません。数秒で、バルカン的な冷静さを持って。多くの人々の必要性が一人の必要性よりも優先されるべきだと主張するでしょう。このような生存に関わる決定に関しては、私たちは自分たちが望む機械の将来をしっかりと制御するために、運転席にしっかりと留まるべきです。

現在のAIは、効率の向上には非常に適しています。代替案を交換し、それらの相対的な利点を考慮し、最も効率的な解決策につながる組み合わせを提案することができます。しかし、それがますます賢くなればなるほど、判断を必要とする物議を醸すトピックについては信頼すべきではありません。なぜなら、事態が恐ろしい方向に進む可能性があるからです。ニック・ボストロムの有名な紙clip最適化問題は、重要な警告を伴う面白い思考実験です。AIは、あなたが指示したものに最適化されるでしょう。もしそれがペーパークリップを作ることであり、それが無限に強力で無限に自己犠牲的である場合、それは役に立たない文房具を作るために銀河系全体から金属を剥ぎ取るでしょう。

たとえAIが自己意識を持つようになったとしても、闇の計画があるかないかに関係なく、それは依然として異質であり、定義上そうです（その言葉で人工と付いているからです）。アイザック・アシモフは、個別のエージェンシーを持つ人間の創造物はおそらくいくつかのハードコードされた保護策を持つべきだと予想しました。彼のロボット工学の3つの法則は、ENIACの3年前に予測されました。しかし、最初の『ロボコップ』映画のように、いくつかのプライベートな例外を「害を与えない」原則に追加する悪意ある天才が、ずる賢いファームウェアのアップグレードによって予測することはできませんでした。

• 「SECのサイバーセキュリティルール」
• 「TikTokショップドロップシッピングでお金を稼ぐ方法」
• 「中国が新しい生成AIの安全性を判断する計画を策定し、詳細に詰まっています」

パランティールでの陰気な眺めには十分でしょう。私が予測すること（主要な利害関係者の株を持っていないため）は、プログラミングの技術がプログラミングする必要を明確かつ明確に表現する技術へと変わることです。開発者はAIに慣れているビジネスアナリストになり、最高レベルのプログラミング言語である英語を使用してAIに話すことに慣れていくでしょう。常に動作するソフトウェアを構築し、幸運なことに有用なものになるかもしれません。

動作するソフトウェアでは十分ではありません

アジャイル宣言が動作するソフトウェアを求めたことは奇妙ではありませんか？まるで壊れたソフトウェアが受け入れられる代替手段のように！プロンプト生成されたコードが有用で価値のあるものであることを求めるのは多すぎることでしょうか？はい、おそらくそれは多すぎることでしょう。動作するソフトウェアと価値のあるソフトウェアの間のギャップは大きいです。なぜなら、価値は無形で予測不能だからです。完璧に問題のないソフトウェアも、自分のせいではなく、アップグレードでは修正できない方法でその価値が失われることがあります。以下にいくつかの例を示します。

私が長らく忘れ去られたOSプロジェクトChandlerを言及したのは初めてではありません。そのバージョン1.0への困難な道のりは、スコット・ローゼンバーグの2007年の書籍「コードで夢を見る」で美しく語られています。これは、最高の意図、専門家チームの努力、そして寛大なスポンサー（Lotus 1-2-3を作成したミッチ・カポア）でも成功を保証するものではないことを忘れないようにするための忍耐強い思い出です。

ChandlerはMicrosoft OutlookとExchangeの無料の代替手段として設定されました。それは根本的に異なるユーザーエクスペリエンスを約束していました。メッセージ、予定表、やるべきことの取り扱い方を変革しようとしていました。そして、それをデスクトップアプリで行い、ピアツーピアのプロトコルを介してコミュニケーションを行うことを意味していました。人々に力を与えるのです！

しかし、チームはアーキテクチャのロードマップで間違った進路を取りすぎました。イカロスのように、彼らは太陽にあまりにも近づきすぎました。世界が追いついてしまったのです。より強力なブラウザの機能により、Pythonベースのデスクトップアプリは適切な選択肢ではなくなりました。自分自身のサーバーの安価かつ簡単なホスティングにより、ピアツーピアのプロトコルの必要性はなくなりました。これは事故的な複雑さの嵐を引き起こす設計選択でした。これらはコミュニティがそれを望んだ場合には修正できたかもしれませんが、そうはなりませんでした。本質的な問題はユーザーエクスペリエンスにありました。アイデアがあまりにも過激でした。それは平均的なオフィスワーカーが必要とするものではありませんでした。私は他の製品でそれらが実装されているのを見たことはありません（訂正されることを喜んでいますが）。人々はまだ1995年と同じようにメールと予定表を使用していますが、今は携帯電話でベベル加工の角がない状態です。

GWTの予想外の陳腐化

時には、偉大なツールでも元々の独自のセリングポイントがもはや売れなくなることがあります。Google Web Toolkit（GWT）は2006年に魅力的な提案を持っていました。デスクトップコンピュータはブラウザをアプリケーションプラットフォームとしてサポートするための十分なパワーを持っていました。インストールなしで税金を申告できました。しかし、ブラウザの非互換性は広範でした。特にドラッグアンドドロップやダブルクリックなどの高度な機能についてです。GWTではバックエンドとフロントエンドのコードを同じプロジェクトで書き、データ送信と検証のための共有オブジェクトを使用し、それらを単一のWebアーカイブに展開することができました。GWTはJavaをJavaScriptにコンパイルしました。さらに、クライアントサイドのJavaコードをローカル開発サーバーでデバッグすることもできました。私はそれが大好きで、しばらくの間それで真剣なお金を稼ぎました。

しかし、コンパイルは非常に高価でした。ブラウザベンダーは自分たちのクセを調整しました。AngularやReactなどのフロントエンドプラットフォームが急速に成熟しました。フロントエンドの構築は真剣なキャリアになり、これらの開発者たちはプログラミングプラットフォームとしてJavaScriptを避けるような様子はありませんでした。GWTはその関連性を失っており、AIがそれを予知または修正する方法はありませんでした。問題はコードではなく、周囲の世界との不一致でした。

プログラミングのためにプログラミングを続ける

ところで、これによってコードの記述を躊躇する必要はありません。本格的なソフトウェアが商業的に効果的である必要も、何らかの実用的な利益を持っている必要もありません。私は自分自身の教育と楽しみ以外のビジネスプランやロードマップ,その他の動機がないソフトウェアを書きました。それは私に新しいコンセプトを教えるという点では効果的でしたが、自分自身の犬用フードにはまったく興味がありませんでした。GitHubには多くのそのようなプロジェクトが存在します。私は敬意を表しています。私は個人的な経験に基づいて話しています。コーディングのためにコーディングをすることには何も間違っていませんが、それは聴衆に演奏しないバンドで演奏するようなもので、続けるのは難しいものです。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!