ソフトウェア工学の創始者の一人であるグレイディ・ブーチが、業界の歴史を振り返りながら、AI時代における開発者の存在意義を再定義する。彼は、現在AIによるコード生成が引き起こしている開発者の実存的危機は、実は過去に2度経験済みの現象であり、今回も乗り越えられると主張する。コンパイラの登場時も高級言語の登場時も、当時の開発者は同じ不安を抱えたが、結果として抽象化レベルが上がり、より大きな問題に取り組めるようになった。現在は第三のゴールデンエイジであり、AIツールは単なる次の抽象化レベルに過ぎない。重要なのはコーディングスキルではなく、複雑なシステムを設計し、技術的・経済的・倫理的要因のバランスを取る能力である。Anthropic CEOダリオ・アモデイの「12ヶ月でソフトウェア工学は自動化される」という予測に対し、ブーチは明確に反論する。それはソフトウェア工学の本質を誤解した「完全に間違った」見解であり、コーディングは工学の一部に過ぎないと指摘する。
- ソフトウェア工学の歴史的転換点
- ソフトウェア工学の黎明期とマーガレット・ハミルトン
- ソフトウェア工学の第一のゴールデンエイジ
- 防衛産業とリアルタイム分散システムの台頭
- 第一のゴールデンエイジの終わりとソフトウェア危機
- 第二のゴールデンエイジの幕開けとオブジェクト指向の台頭
- パーソナルコンピュータ革命とホビイストの台頭
- オブジェクト指向パラダイムと第二のゴールデンエイジ
- SaaSビジネスモデルとソフトウェアの社会浸透
- 第三のゴールデンエイジの到来とAIの役割
- ソフトウェアエンジニアの実存的危機への歴史的視点
- 開発者の不安と過去の類似事例
- 実践例と新しい抽象化レベルの意味
- 時代の変化とスキルの進化
- システム思考と抽象化レベルの上昇
- 成功への道筋と想像力の解放
ソフトウェア工学の歴史的転換点
AIが驚くほど優れたコードを書くことで、ソフトウェア工学の終焉を心配する人もいます。しかしグレイディ・ブーチはそうは考えず、私たちはソフトウェア工学の第三のゴールデンエイジに入っていると言います。
グレイディ・ブーチは、現在知られているソフトウェア工学の創始者の一人です。彼はUMLを共同開発し、オブジェクト指向設計の先駆者となり、IBMフェローとして数十年を過ごし、1970年代以降この業界が経験してきたあらゆる大きな変革を目撃してきました。
今日の対話では、ソフトウェア工学の三つのゴールデンエイジと、歴史が大きな技術的変化を生き抜き繁栄することについて私たちに何を教えてくれるのかを議論します。なぜコーディングは常にソフトウェア工学のほんの一部に過ぎなかったのか、そしてなぜ技術的、経済的、倫理的な力のバランスを取る人間のスキルはどこにも行かないのか。
ダリオの「ソフトウェア工学は12ヶ月で自動化される」という予測に対するグレイディの直接的な反応もあります。ネタバレすると、彼は遠慮しません。そして他にもたくさんあります。
AIがもたらす大規模な変化が実は以前にも起こったことがあり、それも一度だけではないということを理解したいなら、このエピソードはあなたのためのものです。
このエピソードは、フラグ、分析、実験などのための統合プラットフォームであるStatsigによって提供されています。彼らと他のシーズンスポンサーについて詳しく知りたい方は、ショーノートをご覧ください。
では、グレイディ、再びポッドキャストに来ていただきありがとうございます。
お招きいただきありがとうございます。アロハ。
ソフトウェア工学の黎明期とマーガレット・ハミルトン
ソフトウェア工学の歴史に少し触れると、あなたは以前何度も、ソフトウェア工学の全歴史は抽象化レベルの上昇の歴史だと言っていますね。この点を理解するのに役立つ主要な変曲点を教えていただけますか。そしてもちろん、AIがこれにどのように結びついているのかも。
そうですね、ソフトウェア工学という用語そのものが生まれたのは、マーガレット・ハミルトンがおそらく最初にそれを命名するまでありませんでした。当時彼女は有人軌道実験室プロジェクトを離れたばかりで、アポロ計画に取り組んでいました。彼女はハードウェアや構造エンジニアである男性が大半を占める中で、ソフトウェア開発者である数少ない人物の一人でした。彼女は自分を他の人たちと区別するフレーズを考え出したかったのです。そこで彼女はソフトウェアエンジニアという用語を使い始めました。私たちは彼女を最初にその言葉を作った人物として正当に認めることができると思います。
他にも続く人たちがいました。特に人々はソフトウェア工学に関するNATO会議について話します。組織者がそれを設立したとき、これは実際にはマーガレットの仕事の数年後でしたが、彼らはそれをある種物議を醸す名前として行いました。西海岸での最初の会議で人工知能という用語が物議を醸すように名付けられたのと同じようにです。
他にも続く人たちがいて、一定期間の後にそれは定着しました。そしてそれが意味したものの本質、マーガレットや他の人たちがやっていたことは、それについて工学的な何かがあると言うことでした。つまり、私たちの分野は合理的に最適な解決策を構築しようとするという意味で。完璧な解決策を持つことはできませんが、構造、電気、化学エンジニアがするように、周囲の静的および動的な力のバランスを取ります。
ソフトウェアの世界では、もちろん私たちは非常に柔軟で弾力的で流動的な媒体を扱っていますが、それでも同じ種類の力が私たちに働いています。ここには物理法則の力があります。光速より速く情報を伝達することはできません。これは場合によってはかなり厄介ですが、まあ、それと共に生きていかなければなりません。
どれだけ大きなものを構築できるかという問題があり、主に私たちの下にあるハードウェアによって制約されています。アルゴリズム側にも制約があります。ヴィタビアルゴリズムのように、理論的に何かを行う方法を知っているかもしれませんが、携帯電話の開発に不可欠だったこのアルゴリズムは、長い間実装方法がわかりませんでしたが、確かに計算可能な解決策がありました。
高速フーリエ変換に関しても同様の話があります。私たちは理論を知っていましたが、フーリエ変換が計算可能なものに変えられるまで、進歩することができませんでした。そして私たちには他の制約もあります。これらの科学的なものやコンピュータサイエンス的なものだけでなく、人間的な制約などもあります。
私が必要なことをするのに十分な人を集められるか? やりたいことをするチームを組織できるか? 理想的には、ソフトウェアのために欲しい最大のチームサイズはゼロです。まあ、それはあまり実用的ではありません。次に良いのは一人で、そこから増えていきます。そして、小規模なグループの人々によって行われることを想像できない、ある規模のプロジェクトが単純に存在します。
大規模プロジェクトに大勢の人々がいるのはなぜでしょうか? それは、これらのシステムの規模とその永続的な経済的・社会的重要性が非常に大きいからです。個人だけに頼ることはできません。そのソフトウェアは彼らを超えて存続しなければなりません。そしてソフトウェアが世界の隙間空間にますます移動するにつれて、デジタル著作権管理などで見られるような法的問題がありますが、より重要で包括的なのは倫理的問題だと思います。
私たちは特定のものを構築する方法を知っていますが、それを構築すべきでしょうか? 私たちの人間性においてそれは正しいことでしょうか? これらがソフトウェアエンジニアに重くのしかかる静的および動的な力の集合です。だから私は私たちはエンジニアだと言えるのです。なぜなら他の種類のエンジニアと同じように、私たちはこれらの力のバランスを取るシステムを構築し、絶対的に素晴らしい媒体でそれを行うからです。
ソフトウェア工学の第一のゴールデンエイジ
それがソフトウェア工学です。さて、前回の電話で触れたように、ソフトウェア工学には特定の時代があり、後ろを振り返るレンズから見ると、ソフトウェア工学には少なくとも2つの識別可能な主要な時代があると思います。
最も初期の頃はソフトウェアというものがありませんでした。なぜなら私たちがしていたことは単に機械を管理することであり、ハードウェアとソフトウェアの違いは完全に区別がつきませんでした。
ENIACで起こったようにプラグボードにプラグを差し込むこと。これはプログラミングですか? まあ、そうですが、そこには本当のソフトウェアはありません。何か別のものです。そして1940年代後半、1950年代初頭に私たちの機械がある地点に達するまで、それらの違いを見つけ始めることはありませんでした。
当時書かれたほとんどのソフトウェアはビスポークでした。実際、すべてがそうでした。そして事実上すべてのソフトウェアが特定の機械に結びついていました。しかしソフトウェアの経済性は、私たちはこれらの機械を愛しているというようなものでした。より高速になってほしいですが、ソフトウェア自体に多くの投資をしました。これらの種類のものを切り離す方法はありますか?
私たちの世界の最近の歴史について話すと、デジタルという用語は1940年代後半まで作られませんでした。ソフトウェアという用語は1950年代までありませんでした。したがって、ソフトウェアがそれ自体の実体であるという認識さえも、私の人生のちょうど中にありました。これは考えると恐ろしいことです。
そうですね。70年か80年前のようなものですね。すごい。
ええ、まさに。だから私たちは驚くほど若い、若い業界なのです。カール・セーガンの宇宙カレンダーを取ってソフトウェアをそこに入れるとしたら、私たちはその宇宙カレンダーの最後の数ナノ秒にいることになります。瞬きよりも短いでしょう。
とにかく、ソフトウェアがハードウェア自体から切り離され始めると、グレース・ホッパーなどの人々は、これをビジネスや業界として、それ自体の制度として扱うことができるということを理解し始めました。
最も初期のソフトウェアは、もちろんソフトウェア自体がアセンブリ言語であり、これは非常に機械に結びついていました。少し先に進むと、IBMが1960年代に登場し、共通の命令言語を持つ機械の全体的なアーキテクチャを確立する方法があることを認識したとき、ソフトウェア投資を保持し、ソフトウェアを捨てることなくハードウェアを改善できるような方法でハードウェアからそれを切り離すことが可能になりました。
その認識が起こったとき、それはエンジニアリングの決定であり、ビジネスの決定であり、全体的な経済的決定でしたが、その後洪水門が開き、突然書かれる必要があり、書かれることができるソフトウェアがはるかに多くなりました。
これがソフトウェア工学の第一のゴールデンエイジでした。その中でソフトウェアはそれ自体の産業でした。そしてその世界が直面した本質的な問題は複雑性の問題でした。
複雑性とは、私たちが理解するのが難しいものを構築していたこと、ある賢い方法で機械を操作しようとしていたことですが、今日の基準からすれば、笑ってしまうほど単純な複雑性でした。
これはハローワールドに相当するものですが、それ自体が難しい問題でした。そして私たちは機械に非常に結合していたため、ソフトウェア工学の第一のゴールデンエイジで使用された主要な抽象化はアルゴリズム的抽象化でした。なぜなら、それが私たちの機械がしたことだからです。
私たちの機械のほとんどは数学的な種類の操作を意図していたので、Fortranで行われたように、数式変換を行うことができるソフトウェアを構築することが問題でした。
それが第一世代の領域であり、直面した問題でした。
そして第一世代は、タイムライン的にはどこに置きますか?
時間的には1940年代後半から1970年代後半くらいまでだと思います。
そしてそれがその時間枠を支配していたのですね。見られる人物はエド・ヨードン、トム・デマルコ、ラリー・コンスタンティンです。これはERPが、すみません、実体関係の考えが生まれたときです。そしてそのような抽象化の考えはソフトウェアだけでなくデータ側にも注ぎ込まれました。
これはソフトウェア工学において非常に活気のある時期でした。例えばフローチャートの発明があり、これらの種類のシステムを構築する方法について考えるのを助けるものでした。
労働の分業があり、システムを分析する人々、それをプログラムする人々、解決策をキーパンチする人々、コンピュータを操作する人々がいました。そして繰り返しますが、これは主に経済的理由によって駆動されました。なぜなら機械のコストは、それらに関わる人間のコストよりもはるかに大きかったからです。
起こっていたことの多くは、非常に稀少なリソースであった機械の使用を最適化するために行われました。ソフトウェア工学自体と同様に、次の世代で戻ってくることになる教訓は、これらの力がソフトウェアの業界そのものを形作ってきたということです。経済と社会的文脈全体もそれらに影響を与えます。
第一世代では、主に数学的ニーズと既存のビジネスプロセスの自動化に焦点が当てられていました。つまり、会計や給与などを行う人々がいる文字通りのオフィスのフロアを持つ企業がありました。そしてこれが低く垂れ下がった果実でした。なぜなら突然、これらのプロセスを加速し、人間をそこから引き出して自動化することで、実際にその精度を向上させることができたからです。
その時期に書かれた膨大な量のソフトウェアはビジネスおよび数学的および数値的な種類のものでした。さて、これは重要なことです。なぜなら、これが焦点であった一方で、これは唯一の種類のものではなかったからです。周辺、あるいは当時プログラマーだった人の視点から言えば、支配的な場所はIBM、保険会社、銀行などのように見えましたが、その世界の外、防衛産業でも多くの作業が行われていました。
人々がソフトウェアとハードウェアを破壊の機械、航空機、ミサイルに移動させているのを見ました。天気予報に移動しているのを見ました。医療機器自体に移動しているのを見ました。したがって、集中は一般大衆が見るものでしたが、周辺でも多くのことが起こっていました。
ソフトウェア工学の第一のゴールデンエイジでは、ビジネスや数値的なものへのアルゴリズム的抽象化の中心的な推進がありましたが、本当のイノベーションはその縁で起こっていました。特にそれはビジネスケースではなく防衛ケースでした。なぜなら当時ロシアは私たちにとって明確かつ現在の脅威だったからです。
防衛産業とリアルタイム分散システムの台頭
リアルタイムの性質を持つ分散システムを構築する必要がありました。私が話したこれらのシステムのほとんどはリアルタイムではありませんでした。
そこでWhirlwindのような実験的機械の台頭を見ました。すべてのデモの母と呼ばれる作業を見ました。これは当時のソフトウェア開発の重力の中心ではなかった、縁にあったさまざまな人間インターフェースの種類の実験でした。
デビッド・パーナスのような研究者がシーンに登場し、これらのシステムの形式主義を見て、ソフトウェア開発を実際に形式的な数学的活動として扱うことを禁じているのを見ました。
グレイディはちょうど形式的手法と形式的数学とソフトウェア工学について言及しました。ソフトウェアがすべきことを行うことを検証できることは、ソフトウェア工学の初期の頃からの問題でした。これは私たちのシーズンスポンサーであるSonarにうまくつながります。
グレイディが第三のゴールデンエイジと呼ぶかもしれないものを生きているように、AIコーディングアシスタントは私たちがこれまで可能だと思っていたよりも速くコードを生成します。この急速なコード生成は、コードレビューという大規模な新しいボトルネックをすでに作り出しています。私たちは皆それを感じています。
すべてのその新しいAI生成コードは、セキュリティ、信頼性、保守性についてチェックされなければなりません。しかし答えるのが難しい質問です。リスクの山を引き継ぐことなくAIのスピードを得るにはどうすればよいでしょうか?
Sonar、SonarCubeのメーカーは、これをフレーム化する本当に明確な方法を持っています。Vibe then verify。Vibe部分は、チームにこれらのAIツールを使用して革新し迅速に構築する自由を与えることです。Verify部分は本質的な自動ガードレールです。それは人間とAI生成の両方のすべてのコードを品質とセキュリティ基準に対してチェックする独立した検証です。
開発者と組織のリーダーが、品質、セキュリティ、保守性を高く保ちながらAIを最大限に活用できるようにすることは、今度のSonar Summitの主要テーマの一つです。これは単なるユーザーカンファレンスではありません。開発者、プラットフォームエンジニア、エンジニアリングリーダーがこの新しい時代のための実用的な戦略を共有するために集まる場所です。
私もそこで講演することを共有できることに興奮しています。コード品質を犠牲にすることなくAIを採用する方法を理解しようとしているなら、Sonar Summitにぜひ参加してください。
3月3日のイベントのアジェンダを見て登録するには、sonarsource.com/pragmatic/sonarsummitにアクセスしてください。
これで、グレイディとソフトウェア開発を数学的活動の一形態として扱うことに戻りましょう。
そして私が言った分散およびリアルタイムシステムの台頭を主に防衛世界で見ました。
Whirlwindから、SAGEと呼ばれるシステム、半自動地上環境が生まれました。これは1950年代と60年代に登場し、実際最後の一つは1990年代に廃止されたと思います。これはロシアの脅威に基づいていました。これは、ミサイル以前のロシアが爆撃機の艦隊を北極圏に送り、アメリカを侵略するというものです。
こうしてカナダを横断する遠距離早期警戒システムであるDEWラインが生まれました。そしてそのすべてのデータは、SAGE、半自動地上環境と呼ばれる一連のシステムに供給されました。
このシステムは非常に大きく、報告によれば当時アメリカのすべてのソフトウェア開発者の数の20から30パーセントを容易に消費したそうです。
うわー、それは多くの人々ですね。しかし当時を思い出してください。おそらく数万人のソフトウェア開発者しかいませんでしたが、これは最大のプロジェクトでした。
基本的に軍が最大の支出者でした。ソフトウェアの研究と業界を前進させることに、そうですよね? なぜなら彼らは持っていたから。
絶対的に、絶対的に正しいです。彼らは持たなければなりませんでした。なぜならそれは明確かつ現在の脅威だったからです。そして多くのイノベーションは防衛世界で起こっていました。
私がドキュメンタリーで使ったこのフレーズを以前あなたに伝えたと思いますが、コンピューティングにおいて、コンピューティングの歴史には2つの主要な影響があると使います。一つは商業です。私たちはすでに経済について話しました。そして二つ目は戦争です。
したがって、私は主張します。そしてそれを擁護する多くのものがあると思います。現代のコンピューティングの多くは実際に悲しみの織機の上で織られています。
ジャカードの織機に言及しています。とにかく、ここで私たちは1970年代後半、1980年代初頭にいます。また、非常に活気のある時期でもありました。なぜなら多くのクールなことができたからです。
第一のゴールデンエイジの終わりとソフトウェア危機
ええ。そしてこれはまだ第一のゴールデンエイジでしたか? 私たちは第一のゴールデンエイジを通過しました。これらは第一のゴールデンエイジで起こっていることです。しかし私が指摘しているのは、ある種の質量の中心がありましたが、縁で起こっている多くのことがソフトウェアをその主要なルーツから押し出していたということです。
要約しましょう。第一のゴールデンエイジでは、主に数学的およびビジネスの種類のアプリケーションに焦点が当てられていました。そして主要な分解手段はアルゴリズム的抽象化でした。私たちはプロセスと関数を通して世界を見ていました。データを通してはあまり見ていませんでした。
しかし縁には、私たちをその単純な場所を超えて押し出していた組織、ユースケースがありました。分散を要求するユースケース、複数の機械の結合を要求するユースケース、リアルタイム処理を要求するユースケース、人間のユーザーインターフェースを要求するユースケース。
ええ、今日私たちが扱うインターフェース、それらはWhirlwindとSageにルーツがありました。これは最初のUIインターフェースであり、グラフィックチューブ、CRTでした。そしてこれらの種類のものはそこから生まれました。
これが最初で、私が思うにこれからの教訓は、ソフトウェアは素晴らしく動的で、流動的で、可変的な領域であるということです。しかしそれはまた、成長する傾向があるものでもあります。なぜなら、一度何かを構築し、それを構築する方法を知り、そうするためのパターンを持つと、突然、経済的に興味深い方法で他の場所でそれを適用できることを発見するからです。
これが第一世代、ソフトウェア工学の第一のゴールデンエイジでした。しかし1970年代後半から1980年代初頭にかけて、ファサードに亀裂が見え始めているのがわかりました。
ソフトウェア工学に関するNATO会議は、大きな公の場でこれを行った最初の一つでした。彼らNATOにとって、私たちNATOにはソフトウェア問題があることを認識していました。ソフトウェアに対する飽くなき需要がありますが、速度で品質のあるソフトウェアを生産する能力、私たちはそれをどうやって行うか知りません。
これがいわゆるソフトウェア危機でした。人々は何をすべきかわかりませんでした。
危機が何についてだったのか理解するのを助けていただけますか? 人々が何と言っていたのか、ああ、これが問題だと。
ええ、要約すると問題は、ソフトウェアが明らかに有用だったということでした。それを使用する経済的インセンティブがありましたが、業界は規模のある品質のソフトウェアを十分な速さで生成できませんでした。
なるほど、なるほど。つまり、それは高価で、遅く、そして良くなかったのですね。
もう一つあります。遅いと言いましたが、需要が非常に大きかったということです。これは、わあ、これはもっとこれが欲しい。もっとソフトウェアをくれ、というようなものです。
この4つのことが一緒になって、私たちに危機感を与えました。今日私たちが抱えている危機の種類とは微妙に異なることに注意してください。監視について心配し、クラッシュについて心配するような。問題の性質は変わりました。そしてそれらはすべてのゴールデンエイジで変わります。
この問題が存在したことは魅力的です。私たちの現在の現実に生きているのに。
はい。はい。それは非常に異なる世界そのものです。しかしそれは当時の明確かつ現在の危険でした。そしてそれは刺激的で活気のある時期でした。なぜなら非常に多くのことができたからです。
ソフトウェアはそのような可変的で弾力的で流動的な媒体であるため、私たちは主に私たちの想像力によってのみ制限されていました。
これにマイクロミニチュア化を加えてください。なぜ集積回路が登場したのでしょうか? なぜフェアチャイルドが登場し、シリコンバレーを確立し、その基盤となったのでしょうか? それはトランジスタのためです。フェアチャイルドの最初の顧客は誰でしたか? 主に空軍の彼らのミサイルのためでした。
実際、シリコンバレーの初期の頃に作られていたトランジスタのほとんどは、私たちの冷戦プログラムに行きました。
しかしそれは素晴らしいことでした。なぜならそれがそれを行うための全体的なインフラストラクチャの経済的基盤を確立したからです。そしてそれが規模で行うことが可能になり、もちろん私たちはそれが集積回路を生み出し、それがパーソナルコンピュータを生み出したことを知っています。
そこで今、私たちは1970年代後半にいて、ソフトウェア危機は非常に明確でした。特に一つの話に焦点を当てると、米国政府は、バベルの問題があることを認識しました。軍事システム全体で使用されている非常に多くのプログラミング言語がありました。彼らの数えによれば、少なくとも14,000の異なるプログラミング言語がありました。
ああ、すごい。当時ソフトウェアが今日よりもはるかに小さかったときに。すごい。
第二のゴールデンエイジの幕開けとオブジェクト指向の台頭
絶対的に。信じられないことです。そしてJovialのような言語は非常に人気がありました。COBOLなどのしゃれのようなJovialです。Algolの台頭がありました。これは軍事言語ではありませんでしたが、Hoare、Dijkstra、Wirthの形式的な力が、私たちの言語に数学的厳密性を適用するこの規律につながりました。形式的言語研究の考えが生まれました。
1970年代後半までに、政府がバベルの数を言語の問題があることを認識したとき、彼らはAdaプロジェクトに資金を提供しました。当時はジョイント・プログラム・ワーキンググループのようなものと呼ばれていました。これは存在する言語の数を減らし、それらすべてを支配する一つの言語に減らそうとする試みでした。
興味深いのは、その時期に多くの興味深い研究がそこに供給されていたことです。抽象データ型の研究がGutt…からありました。David Parnasからの情報隠蔽のアイデア。関心の分離。今日私たちがクリーンプログラミング、クリーンコーディングと呼ぶもののアイデアですが、Knuthからのリテラートプログラミングのアイデアです。
これらの種類のことは1970年代後半と1980年代初頭に泡立っていました。そしてAdaは大規模でそれを実現させるための少しのプッシュでした。他の産業や企業は本当にそれを行うことができませんでした。なぜなら彼らには当時米軍が持っていたような露出、重み、威厳、経済的パワーハウスがなかったからです。
同時に、Bellのような研究所でいくつかの興味深い作業が行われていました。それはCとUnixなどを生み出し、それは信じられないほど重要になりつつありました。しかし当時、Bjarne Stroustrupという名前のこのクレイジーな研究者がいました。彼はわあ、これはかなりクールだけど、ねえ、Simulaからのこれらのアイデアを取って、Cに適用できるか見てみようと言っていました。
Cには問題があるから、動かせるか見てみようと。バックグラウンドで学界とこれらの縁で起こっていたことは、新しい種類の抽象化が必要だという認識でした。そしてそれはアルゴリズム的抽象化だけではありませんでした。しかしそれはオブジェクト抽象化でした。
その二分法の背後には興味深い歴史があることがわかります。Platoにまさにその種の分裂についての議論があります。彼は世界をどう見るかについて話している二人の人々の間の対話を持っています。そして彼らの一人は、私たちはプロセスという観点から世界を見るべきだと言います。これはキリスト以前の古代ギリシャの哲学者です。
そのPlato、彼は彼はいくつかの並列的なアイデアを提起しました。
彼は二つのレンズを通して世界を見るという二分法のアイデアを提起しました。彼の作品が非常に急進的だったために、現在特定のアメリカの大学で禁止されているまさにそのPlatoです。そうですか?
しかしこれらの対話の一つで、彼は作家の一人が、ああ、私たちはプロセス、物事がどのように流れるかを通して世界を見なければならないと言ったことを観察しました。そしてもう一人は、いや、いや、いや、私たちは物を通してそれらを見なければならないと言いました。
そしてこれが原子のアイデアが生まれた場所です。原子という用語そのものがギリシャ語とその用語から来ました。
したがって、世界を見て世界を見て、世界を見るというアイデアは、基本的に抽象化は新しいものではありません。しかしParnasや他の人々、Simulaの設計者のような人々は、ちょっと待って、これらのアイデアをソフトウェア自体に適用できる、そして世界をアルゴリズム的抽象化だけでなく、オブジェクト抽象化を通して見ることができると言いました。
さて、ここに別の要因がありました。そしてここでFortranの発明者が登場しました。Fortranの後、彼は去り、もちろんこれをIBMで行いました。彼はフェローになり、そして彼は去ってこれは楽しかったが別のことをしたいと言いました。そして彼はプログラミングの異なる方法を見てみようと言いました。
それは関数型プログラミングのアイデアでした。これは数学的関数、ステートレスな種類のものを通して世界を見るというものでした。ここで私たちは1970年代について話していますが、関数型プログラミングのアイデアが生まれました。
彼が亡くなる数ヶ月前に彼にインタビューする機会がありました。そして彼になぜ関数型プログラミングは決して大きくならなかったのかと尋ねました。そして彼の答えは、関数型プログラミングは難しいことを簡単にするが、簡単なことを驚くほど不可能にするからというものでした。
簡単なこと。
ええ。だから関数型プログラミングには役割があります。疑いの余地はありません。そして私はその基盤が当時Johnによって築かれたと思います。しかし今日でさえ、それには役割があります。それにはニッチがありますが、まさにその同じ法則のために支配的にはなっていません。
とにかくここで私たちはソフトウェア工学の第一のゴールデンエイジの終わりであり、第二に移行しています。私たちをそこに導いた力は何でしたか?
まず第一に、それは複雑性の増大でした。
グレイディはちょうど、複雑性の増大が業界をソフトウェア工学の新しいゴールデンエイジに押し込む力だったと言及しました。今日に早送りすると、ソフトウェアの複雑性はAIが多くのコードをはるかに速く生成することもあって、成長し続けています。
これは私たちのシーズンスポンサーであるWorkOSにうまくつながります。WorkOSは、アプリをエンタープライズ対応にすることを簡単にするプリミティブを提供します。しかし内部では、非常に多くの複雑性が発生します。
私はこれを知っています。なぜなら私は最近、Hilltop reviewと呼ばれるWorkOSでのエンジニアリング計画会議に参加したからです。エンジニアが提案された実装を説明します。
このレビューで、ユーザーがWorkOSを使用している複数のプラットフォームで認証するときに、顧客の認証を実装する方法について議論しました。たとえば、ユーザーがモバイルバージョンでログアウトした場合はどうなるべきでしょうか? ウェブバージョンではログインしたままであるべきでしょうか? 逆の場合はどうですか?
私たちは10以上の同様の質問を取り上げました。私が学んだように、答えは、WorkOSを使用している顧客が何を望むかによります。WorkOSチームは、私が存在することを知らなかったエッジケースを説明し、それらの決定を管理パネルの設定可能な動作に変換します。これにより、顧客はこのロジックをすべて自分で構築して維持することなく、自分の製品とユーザーに適切なトレードオフを選択できます。
しかしこれは常に十分ではありません。そして顧客が独自のニーズを持っているとき、Workエンジニアリングチームはしばしば彼らと直接協力して、非常に具体的な問題を解決する方法を見つけます。その後、これらのソリューションを一般化して、みんなのためのプラットフォームの一部にします。
この計画セッションの後、私はWorkが吸収する複雑性の量に新たな感謝を持っています。プロダクトとエンジニアリングチームがそうする必要がないように。同じ計画がすべてのWork製品に入り、顧客はすべての利益を得ます。
workowwise.comで詳しく学んでください。
これで、グレイディとソフトウェア工学の第二のゴールデンエイジがどのように生まれたかに戻りましょう。
私が言及したように、複雑性の増大、十分に速く十分に大きなソフトウェアを構築することの困難、そして私はこれに、分散的な方法でシステムを構築したいという欲求と明白な価値という防衛世界で生まれたものを加えたいと思います。
さて、シーンに登場してください。なぜならほぼ同じ時期に起こっていたことは、マイクロミニチュア化の成果が生まれ、それがパーソナルコンピュータにつながったからです。これはトランジスタのためでしたよね? そしてエレクトロニクスなどでのブレイクスルーと。
パーソナルコンピュータ革命とホビイストの台頭
正確に。そしてこれもまた活気のある時期でした。なぜなら、これらのものをまとめてゼロから構築できるホビイストがいたからです。そして当時パーソナルコンピュータはありませんでした。
これはコンピューティングの歴史の中で、ホビイストが実際に有意義にそれに手を伸ばすことができた最初の時期でしたか?
本当に? 規模で言えば、そうだと思います。Pascalのようなホビイストがいました。彼の父が彼の会計作業に非常に退屈して取り組んでいたので、Pascalは彼のために小さな機械を作りました。
だからその当時ホビイストの仕事がありました。間違いなく。しかし規模の面で、また第二次世界大戦後を思い出してください。特にアメリカでは、ホビイストが実際にこれらの種類のことを行うことを可能にしたより多くの可処分所得がありました。
そして最後に、集積回路とトランジスタを生産していた軍がありました。そして突然、特にシリコンバレーでは、FryまたはFryに相当するものに行くことができました。これはFriesの前で、これらのものを買うことができました。それらはただそこにありました。だから人々が遊ぶことができました。そして遊びはソフトウェアの歴史において重要な部分です。
だからこの素晴らしいことが起こっていました。1970年代後半と1980年代初頭と言いますが、これは実験の活気ある時期でした。
The Dormouse Saidという楽しい本があります。これは、パーソナルコンピュータの台頭がヒッピーカウンターカルチャーの台頭とも結びついていると仮定しています。そしてこの、人々に力を、そして戦争ではなく愛を作ろう、これらの種類のものへの推進。
これはStewart Brand、Merry Prankstersなどの時代です。そしてそれはWELLのようなものにつながりました。これは今日私たちが掲示板と呼ぶ最初のソーシャルネットワークで、シリコンバレーで育ちました。
ちょっと脱線しますが、Stuartはただ素敵な人です。彼は実際、彼らについての本でMerry Prankstersの一人として言及されました。彼はまだシーンにいて、ちょうどMaintenance Part Oneという素晴らしい本を出版しました。これはシステムの問題を見ています。
ソフトウェアはその一つで、それらに関連する保守の問題です。とにかく、ここで私たちは1970年代後半、1980年代初頭にいます。また、非常に活気のある時期でもあります。なぜならできる非常にクールなことがたくさんあるからです。
ええ。そしてそれはStrikepress実際にこれを出版しています。だから、ショーノートの下にリンクを残します。それは本当に素晴らしい本のように見えます。そしてStride Pressは優れた品質を生産することで知られています。だから、私は実際にこれを調べることに興奮しています。
ええ、素晴らしい素晴らしい本です。だから認識は、私たちは今、プロセスではなくオブジェクトとクラスを通して世界を見る理論の始まりを持っていたということでした。
分散システムの需要プル、ますます複雑なシステムを構築しようとすることからの需要プルがありました。だからこの第二のゴールデンエイジを本当に立ち上げた完璧な嵐もありました。そして率直に言って、それは私がシーンに登場したところです。
私はちょうど幸運な場所に幸運な時期にいました。私は当時ヴァンデンバーグ空軍基地でミサイルシステムと宇宙システムに取り組んでいました。軍事スペースシャトルが構想されていて、私もそのプログラムの一部でした。素晴らしかったです。
楽しい場所でした。なぜなら週に2回のような打ち上げがあったからです。かなりクールでした。走って行って、わあ、それを見てと言うでしょう。かなりワイルドでした。
私が働いていたビルでは、打ち上げがあるたびに避難しなければなりませんでした。なぜならそれがタイタンの打ち上げだった場合、タイタンの発射台が私たちに本当に近く、もし発射台で爆発していたら、私たちのビルを吹き飛ばしていたでしょう。それは本当に迷惑だったでしょう。だから、ええ。
良いことです。
そしてもう一つの速い話、秘密の打ち上げ、秘密のスパイ衛星がいつ行われるかはいつでもわかりました。なぜなら2つの主要な明確な兆候があったからです。最初はすべてのホテルがいっぱいになることです。なぜなら請負業者が入ってくるからです。そして二番目は、打ち上げの日、打ち上げを見ることができる近くの高速道路がそれを見る人々でいっぱいになるでしょう。
だからその世界には秘密はありませんでした。ここで私たちは1980年代後半にいます。世界は世界を見る新しい方法の準備ができていました。そしてそれはオブジェクト指向プログラミングとオブジェクト指向設計でした。
オブジェクト指向パラダイムと第二のゴールデンエイジ
それは第一世代とどう違いますか? それは、私たちが世界に異なる抽象化のレイヤーでアプローチするという意味で異なります。
ここにあるこの生のレイクであるデータを見るだけでなく、それらを操作するために持っているアルゴリズムを見るだけでなく、私たちはそれらを一つの場所にまとめます。オブジェクトとプロセスを一緒に組み合わせました。そしてそれは機能しました。
私の天よ、それは以前できなかったことを私たちができるようにしてくれます。それは多くのシステムの基盤でした。コンピュータ歴史博物館に行って、MacWriteとMacPaintのソフトウェアを見てください。それは初期のオブジェクト指向プログラミング言語の一つであるObject Pascalで書かれました。
私が見た中で最も美しいソフトウェアの一つです。よく構造化されています。よく組織化されています。そして実際、そこで行われた設計決定の多くは、今日でもPhotoshopのようなシステムで持続しているのを見ることができます。
それらはまだ存在します。これはソフトウェアの寿命についてのそれ自体興味深い話です。だからオブジェクトのレンズを通してソフトウェアを見ることは非常に効果的であることが証明されました。なぜならそれは新しく新しく新しい方法でソフトウェアの複雑性問題を攻撃することを私たちに許したからです。
そして第一のゴールデンエイジと同じように、これもまた非常に活気のある時期でした。1980年代と1990年代と言いますが、そこでは三人組、私、Ivar Jacobson、Jim Rumbaughのような人々がいました。Pete Coadがいました。Larry Constantineがシーンに戻ってきました。Ed Yourdonがシーンに戻ってきました。
プロセスからではなくオブジェクトからソフトウェアを見て、それについて考えようと言っていた多くの人々がいました。
さて、これは素晴らしかったです。私たちはいくつかの間違いを犯しました。継承のアイデアに過度の強調がありました。私たちはこれが最も素晴らしいことになると思いました。それはちょっと間違っていました。
しかしクラスとオブジェクトから世界を見るというアイデア、それはある種組み込まれていました。そして何が起こり始めたか、これもまた経済的なことでした。
人々がこれらのものを構築し始めると、突然、プラットフォームの台頭を見ました。さてこれには前例がありました。なぜなら第一のゴールデンエイジで人々は何度も何度も同じ種類のものを構築し始めたからです。
一般的に使用されるアルゴリズムを収集するプロセスを収集するというアイデア。ハードドライブやドラムをどのように操作するか? テレタイプにどのように書くか? 画面にどのように置くか? これらの種類のアルゴリズムをどのようにソートするかは、成文化することができ、だから意志を持つ場合、それらを再利用可能なものにパッケージ化する最初のアイデアが生まれました。
これは少なくともビジネスシステムの世界でIBM Shareが生まれたときです。ShareはIBM Shareが生まれたときです。Shareは顧客が組織したグループで、文字通りお互いにソフトウェアを共有しました。完全に。
そしてこれは第一のゴールデンエイジでしたよね?
これは第一のゴールデンエイジです。そうですよね?
だからこれはある種原始的なようなものでした。つまり振り返ると、関連するかもしれないソートアルゴリズムやあなたが言ったようにIBMのような、ただ関数のようなものや物事にただパッケージ化するより原始的な方法です。
IBMはそれをしていませんでした。完璧でした。それは完全に公に駆動されました。IBMはそれをサポートしましたが、それのために行われました。
ええ。だからポイントは、これが最も初期のオープンソースソフトウェアだったということです。だからオープンソースのアイデアは存在しました。そしてその時代のソフトウェアとハードウェアの経済性も思い出してください。ソフトウェアは主要メーカーによってほとんど無料で提供されていました。
IBMは1960年代後半になるまでソフトウェアに課金しませんでした。彼らは私の天よ、お金を稼ぐことができると気づきました。そして彼らはソフトウェアとハードウェアを切り離し、それに課金し始めました。しかし最も初期の頃、あなたがこう言えるこの活気あるコミュニティがありました。これを書きました。どうぞ使ってください。
それは結構です。問題ありません。だから、オープンソースはその時期には遅れていました。そして同じことが第二のゴールデンエイジで起こり始めました。オペレーティングシステムの台頭、オープンソースソフトウェアの台頭と同じように、同じ現象が第二のゴールデンエイジで適用されましたが、今度は新しい抽象化のレイヤーでした。
ああ、今これらの新しいCRTに書くための新しいライブラリが欲しいです。ここにあります。私がそれを持っていることに競争的価値はありませんが、私の天よ、それは本当にクールなものを構築することを可能にしてくれます。あなたもそれを持つことができます。
だから、オープンソースはそのルーツを置き、第一のゴールデンエイジからそのアイデアを取り、第二のゴールデンエイジでそれ自体を適用しましたが、異なる種類の抽象化で。バックグラウンドに潜んでいたもの。経済について言えば、プラットフォームの台頭でした。なぜなら今、突然これらのライブラリがますます大きくなっているからです。
そして私たちが分散システムに移行したとき、当時私たちがサービス指向アーキテクチャと呼んだものの台頭がありました。HTMLなどがありました。リンクを前後に渡すことができましたが、画像を共有できるようなことができたらクールだろうと言ったクレイジーな人々がいました。
それはNetscapeが許可したものの一つでした。彼らはHTMLにこの追加を生成し、画像を置くことができるようにしました。
HTMLを介してメッセージを前後に渡すことができたらクールだろう。だから突然、インターネットはHTML、HTTPプロトコルを介して情報とプロセスを渡すためのより高いレベルの抽象化での媒体になりました。
しかしそれをパッケージ化する必要がありました。こうしてサービス指向アーキテクチャ、SOAP、サービス指向アーキテクチャ、サービス指向プロトコル、今日私たちが持っているものすべての前身が生まれました。
そしてこれは第二のゴールデンエイジでプラットフォーム時代の始まりの基礎を築いていました。Bezosや他の人々が私たちを本当にもたらしたもので、これらのAPIのようなものがその周りにあるこれらの島を持っているところです。しかしそれは第二のゴールデンエイジで生まれていました。
そしてプラットフォームと言うとき、プラットフォームの台頭と言うとき、どういう意味ですか? プラットフォームをどう考えますか?
AWSは良い例でしょう。Salesforceは別の例でしょう。その中で私はこれらの経済的に興味深い城を持っています。それらの周りに堀によって守られています。そしてSalesforceのようなそれらの組織は、わずかな料金でその堀を越えてアクセスを提供します。
まあ、わずかな料金でさえありません。
ええ。わずかな料金ではありません。
ええ。Salesforceのような私たちの下で、自分でやるコストが非常に高いので、私たちから買うのが理にかなっているという前提の下で。
SaaSビジネスモデルとソフトウェアの社会浸透
だから第二のゴールデンエイジの間、私たちはこれらの種類のビジネスの台頭を見ました。なぜなら特定の種類のソフトウェアのコストが十分に高く、複雑性は確かに高かったので、それはこれらの種類のSaaS企業のビジネスと業界を可能にしたからです。
だから、1990年代後半、2000年代初頭を見てみましょう。また活気のある時期でもあります。第一のゴールデンエイジと同じように。私たちはインターネットの成長がありました。最初のメールアドレスをいつ手に入れましたか?
私の最初のメールアドレスは2005年か6年のどこかで手に入れました。Gmailが立ち上がったときにはまだ非常に新鮮でした。しかし最初のメールアドレスはいつ手に入れましたか?
1987年、ARPANETのときでした。そして実際、その時、そうです、私たちは小さな本を持っていました。おそらく100ページほどで、世界のすべての人のメールアドレスをリストしていました。かなりクールでした。オンラインで見つけることができ、私のメールがそこにあるのを見ることができます。
もう機能しません。なぜなら同じトップレベルドメインの種類のものを持っていないからです。だから私はメールがクールになる前からメールをやっています。
そして第二のゴールデンエイジのソフトウェアでメールのようなこれらの種類の構造が商品的なものになるのを見ると、これはソフトウェアが文明の隙間空間にフィルタリングし始め、ビジネスや特定のドメインに燃料を供給するこの一つのものだけではなくなったときです。それは文明の構造そのものの一部になった何かになりました。
これは重要でした。そして今、私たちが第一のゴールデンエイジで心配していたこと、私たちはそれらをほとんど解決しました。それらは非常に雰囲気の一部でした。私たちはアルゴリズムについてあまり考えませんでした。なぜならみんながそれらについて知っているからです。
そしてこれは技術があるべき姿です。最高の技術は蒸発して消え、私たちが呼吸する空気の一部になります。
そしてそれが今起こっていることです。しかしそれは第二のゴールデンエイジでした。今日私たちがいる場所の基盤はここにあります。
だから2000年頃に何が起こったのでしょうか? まあ、その時までにインターネットは大きく、多くのビジネスが構築されていましたが、その時期にクラッシュがありました。なぜなら経済的にそれは単に意味をなさなかったからです。だから大きな後退がありました。
また起こっていたのは、Y2K全体の状況で、多くの努力がその問題を解決することに注がれました。振り返ってみると、まあ、それについて心配する必要はなかったと言う人もいます。しかしその真っ只中にいると、ああいや、多くの英雄的な仕事があったことに気づきます。そしてそれが行われていなかったら、多くの問題が起こっていたでしょう。
だからこれは最高の技術が単に見えない良い例です。問題を覆すために多くの努力と多くのお金が費やされ、それは単に自己を示しませんでした。それは素晴らしいことです。
グレイディはちょうど、最高の技術は単に見えないものだと言及しました。これは過小評価されている観察であり、ほとんどのミッションクリティカルなソフトウェアに当てはまります。それが機能するとき、それは見えません。壊れたときだけユーザーはそれがそこにあることに気づきます。
しかし信頼性の高い見えないソフトウェアを構築することには問題があります。物事を壊す可能性のある少数のガードレールで速く移動するか、安定性のためにより多くのガードレールを入れるが出荷速度を遅くするかの間にしばしば緊張があります。
まあ、両方の文化、継続的な出荷と実験の最良のものを可能にする第三の方法があります。これは私たちのプレゼンティングスポンサーであるStatsigにうまくつながります。
Statsigは統合プラットフォームを構築し、両方の文化の最良のものを可能にします。フィーチャーフラグは自信を持って継続的に出荷させてくれます。ユーザーの10%にロールアウトします。問題を早期にキャッチします。必要に応じて即座にロールバックします。
組み込みの実験は、すべてのロールアウトが自動的に学習の機会になることを意味し、適切な統計分析がフィーチャーがあなたの指標にどのように影響するかを正確に示します。そしてそれはすべて同じ製品データを持つ一つのプラットフォームにあるため、すべてを置き換えるべき分析、あなたの組織全体のチームはコラボレーションしてデータ駆動型の決定を下すことができます。
Notionのような企業は、Statsigで四半期あたりの一桁の実験から300以上の実験に移行しました。彼らはフィーチャーフラグの背後で600以上のフィーチャーを出荷し、メトリックの回帰から保護しながら速く移動しています。
Microsoft、Atlassian、Brexは同じ理由でStatsigを使用しています。それは規模でスピードと信頼性の両方を可能にするインフラストラクチャです。
彼らは始めるための寛大な無料ティアを持っており、チームのプロ価格は月150ドルから始まります。詳しく学び、30日間のエンタープライズトライアルを取得するには、stats.com/pragmaticに行ってください。
これで、グレイディが話していたY2Kイベントに戻りましょう。
ええ、私は2000年までの時期がどれほどストレスだったか覚えています。いくつかの映画さえ出てきたと思います。世界がどのように崩壊するかを予測して。しかしすべてのこれらのシステムがクラッシュするかもしれないというこの恐れがありました。そしてそれは数ヶ月前にかなり激しくなり始めました。
だから私は当時子供のようなものでした。しかし2000年になったとき、それはおそらく最もストレスの多い新年でした。なぜならあなたは確信が持てなかったからです。あなたは願っていました。そして何も起こらず、あなたはああ、それはただのでっち上げだったと言いました。
だから誰でもそこを通過した人は、これらの予測を信頼しないことを学びました。しかしあなたは正しいです。今知っているように、オーバーフローが間違った場所で当たらないようにするために非常に多くの仕事がありました。
第三のゴールデンエイジの到来とAIの役割
ええ。だからここで私たちは精神的に2000年代の最初の10年に自分を置いてください。楽しい場所です。なぜならクラッシュはありましたが、まだとても多くの楽しいことをすべき、書くべき素晴らしいソフトウェアがありました。私たちはまだ主に私たちの想像力によってのみ制限されていました。
さて、私は一瞬停止して、私が言及していなかったいくつかの歴史で埋め戻します。私たちは一般的にソフトウェアについて話してきました。AIにおいて進行中の並行歴史があり、そこでもいくつかの世代を見ました。
AIの第一のゴールデンエイジは1940年代と1950年代で、Herbert SimonとNewell、特にMinskyのような人々がいました。そこでの焦点は、記号的方法を使用して人工的に知能を構築できるというものでした。
これがAIの第一のゴールデンエイジ、第一の偉大な時代でした。そしてニューラルネットワークのアイデアが試されました。彼らが構築したものはsnarcで、最初の真空管人工ニューロンでした。単一のニューロンを作るのに5つの真空管のようなものが必要でした。
そして英国から出てきた報告書があり、ここで多くのお金を使っていると言いましたが、私の天よ、それは機能しません。
そして第一のゴールデンエイジは、彼らが本当に興味深いものを構築できないことに気づいたときに終わりました。さらに、ニューラルネットワークは行き止まりです。
主に行き止まりです。なぜなら私たちはそれらを行うための計算能力を持っていなかったからです。私たちはアルゴリズムの概念、一度規模でそれらを持ったらそれらで何をすべきかを知るための抽象化を持っていませんでした。
AIの第二のゴールデンエイジは本当に1980年代で、Falconのような人々が登場してねえ、それを見る別の方法があり、それはルールを通してそれを見ることだと言ったときでした。
こうして機械学習のアイデアが生まれました。mなどのようなものがシーンに登場しましたが、そこでも私たちはAIの冬が訪れるのを見ました。
ところでその時期にハードウェアの興味深い台頭がありました。Lisp Machine、Thinking Machineはすべてこの時期に構築されました。
コンピュータアーキテクチャの活気ある時期でした。だからあなたはこれらがお互いに供給しているのを見ますが、最終的にはそれは失敗しました。なぜなら数百のif-then文を超えると、それらは拡張しなかったからです。
私たちはそれらで何かをすることができる推論エンジンを構築する手段を単に持っていませんでした。だからここで私たちは再び刺激的な時期、2000年代の最初の10年にいます。AIはある種、バックルームに戻っていました。
私たちにはまだ多くのクールなことをすべきであり、それに加えてより多くの分散的な種類のシステムがありました。さらにそれに燃料を供給していたのは、ソフトウェアが今パーソナルコンピュータを通して個人の手にあったという事実です。
だからソフトウェアへの需要はさらに大きくなりました。私は主張します。そしてこれは少し物議を醸すかもしれません。私たちはソフトウェア工学の第三のゴールデンエイジにいますが、実際にはそれはミレニアムの変わり目頃に始まりました。今ではなく、それからです。
そしてその台頭の最初の兆候は、私たちはソフトウェアプログラムの個々のコンポーネントから、私たちのプラットフォームの一部である全体的なライブラリとパッケージへの抽象化のレベルの新しい台頭を見たということです。
ああ、メッセージングをする必要があります。まあ、私は自分のマシンでそれをするつもりはありません。メッセージングをするこのライブラリに行くことができます。このデータの全体的なチャンクを管理する必要があります。Hadoopや何かのようなものを使いましょう。
当時は周りにありませんでしたが、それが成長していた種がありました。だから私たちは単純なプログラムからシステムのサブコンポーネントへの抽象化のレベルの成長を再び見ました。そしてそれが起こった次の大きなシフトでした。そして私たちの方法論と私たちの言語などすべてが従い始めました。
だから私たちがすでに数年間いた第三のゴールデンエイジ。そして自分自身より先に行かないために、コーディングスペースでAIアシスタンスなどで起こっていることは、多くの点でこれらの種類のものの成長への反応です。なぜなら私たちはそれらの使用を加速したいからです。
私たちはそこにそのような種類のライブラリが非常に多くあり、それらについて知っている人が十分ではありません。私たちはそうするのを助ける援助を持つことによってそれらの使用を加速したいです。
だからそれが私がCursorやChatGPTのようなAIエージェントを置く文脈です。そして彼らはある意味、私たちをすでにこの第三のゴールデンエイジに導いた力のフォローオンです。
だから私たちは今非常に活気のある時期にいますが、問題は第一と第二の世代とは異なります。今は何が問題ですか?
まず、私たちには非常に多くのソフトウェアがあるという問題です。どのようにそれを管理しますか? そして私たちは安全性とセキュリティの問題に対処しなければなりません。誰かが私が信頼できないものを忍び込ませることができますか? どのようにそれから自分を守りますか?
ソフトウェアサプライチェーンに何かを注入することは非常に簡単です。どのようにそこに悪者が物を置くことを防ぎますか? どのように私はそれから守りますか?
Stuxnetなどの背後にある全体的な歴史は、ソフトウェアにおけるスパイ活動を示す良いものです。そして突然、ソフトウェアの歴史のほとんどで私たちが隔離されていた人間の問題、なぜならそれは文明の非常に多くの部分だったので、これらの人間の問題は私たちの世界にとって最前線で明確かつ現在のものになりました。
そしてもう一つの要素はそれに対する経済的問題です。私たちは今、失敗するには大きすぎる企業を持っていました。Microsoftが倒れたら何が起こるでしょうか? Googleが倒れたら何が起こるでしょうか?
彼らは世界にとって経済的に非常に重要であり、彼らがすることは、彼らが世界のある部分でくしゃみをすると風邪をひきます。
そして今ソフトウェア工学のこの第三のゴールデンエイジで私たちが持っている問題は第一と第二の世代とは異なりますが、同じように刺激的です。
そして最後に、私たちには倫理的問題があります。なぜならこの種のソフトウェアをすることができるので、一日のすべての瞬間にあなたがどこにいるかを追跡することが私にとって可能です。私はそれをすることができます。私はそれをすべきでしょうか?
はいと言う人もいます。なぜならそれは人類にとって良いことだからです。他の人はそれについて確信が持てないと言うでしょう。
ソフトウェアエンジニアの実存的危機への歴史的視点
だから、あなたがそれを置いた方法が好きです。非常に興味深いです。特にあなたの経験と、すべてがどのように始まったかという歴史を共有することを通して。私たちの多くが本当に振り返らないと思うものです。そしてそれがどれほど若いか正直に言って。
もし70年か80年は、あなたがどれくらいの年齢かによって長いかもしれませんが、それは世代ではない、またはかろうじて世代です。
それはカップルの世代です。ええ。
開発者の不安と過去の類似事例
しかし今業界全体で見ている一つのことは、このセットアップは意味をなすと感じますが、多くのソフトウェアエンジニアにとって今日矛盾しているように感じる一つのことがあります。
実存的恐怖があるようです。特に冬休みにわたって加速しています。冬休みに何が起こったかというと、冬休みの前に、これらのAI LLMは自動補完にかなり良かったです。時々これやそれを生成できました。
そして冬休みにわたって、私は新しいいくつかで遊んだかどうかわかりません。私は新しいモデルで遊びました。彼らは実際に本当に良いコードを生成します。私が彼らを信頼し始めているという点まで。
そして
ええ、
ソフトウェアの歴史がある限り、私の理解では、ソフトウェア開発者がコードを書いてきて、それは難しいことです。そして私たちの多くは、学ぶのに何年もかかります。それにさらに長く優れていることに。
そして私たちの多くは、この本当に実存的危機を持ち始めています。まず第一に、機械が本当に本当に良いソフトウェアコードを書くことができるようになりました。WTFのように、そしてこれはここ数ヶ月でどのように起こったのか。そして次は何ですか?
これは職業を揺さぶる可能性があるように感じます。なぜなら私はコーディングがソフトウェア工学に非常に密接に結合されていると感じるからです。そして今それはそうではないかもしれません。
振り返ってみると、歴史と両方を通して、あなたの何が起こっているかについてのあなたの見解は何ですか? まあ、これは開発者が直面した最初の実存的危機ではないと言わせてください。もっと教えてください。
彼らは第一と第二の世代で同じ種類の実存的危機に直面しました。だからそれが私がこれを見て、これもまた通り過ぎるだろうと言う理由です。それについて懸念している人々に話すとき。心配しないで、基本に焦点を当ててください。なぜならそれらのスキルは決して消えることはないからです。
私はグレース・ホッパーに会う機会がありました。彼女はただ楽しかった、消火栓のような女性でした。ただ素晴らしい、素晴らしいものでした。
あなたの読者のために、グレース・ホッパーとデビッド・レターマンをグーグルしてください。そして彼女がデビッド・レターマンショーに出演したこれがあり、彼女の性格の感覚を得るでしょう。
まあ、ショーノートの下にリンクします。
彼女はもちろん、ここで私たちは1950年代にいますが、ソフトウェアをハードウェアから分離することが可能だと認識した人です。
これは初期の機械を構築していた人々にとって脅威でした。なぜなら彼らは、効率的なものを決して構築できないだろうと言ったからです。なぜなら機械に非常に密接に結びつかなければならないからです。
そしてその分野の多くの人々、そして彼らはそれについて書きました。これは私たちがすることを破壊するだろうという懸念を表明しました。そしてそうすべきでした。だから私たちはここに最初のコンパイラの始まりを持っていました。
Fortranの発明でも同じことが起こりました。人々はわあ、私たちは他の誰よりも良い、どんな機械ができるよりも良いタイトなアセンブリ言語を書くことができると言っていました。しかしそれはアセンブリ言語からより高次のプログラミング言語に抽象化のレベルを上げたときに間違っていることが証明されました。
そしてあなたは同様に懸念し、抽象化のレベルの変化によって苦しんでいた一連の人々を持っていました。なぜなら彼らは、その時期に持っていたスキルが消えて、彼らが自分自身で作ったまさにそのものによって置き換えられようとしていることを認識したからです。
今、あなたは当時私たちがそれほど多くいなかったので、それほど多くの危機を見ませんでした。私たちは数千人について話しています。今、私たちは何百万人もの人々について話しています。彼らは非常に正当に、私にとって何を意味するのかという質問をします。
だから私はあなたが持っていると確信していますが、多くの、特に若い開発者が私のところに来て、グレイディ、私は何をすべきかと言うのを持っています。私は間違った分野を選んでいますか? 私は何か違うことをすべきでしょうか?
そして私は彼らに、これは実際にソフトウェアにいるのにエキサイティングな時期だと保証します。以下の理由で。
私たちは機械言語からアセンブリ言語へ、アセンブリ言語からより高次のプログラミング言語へ、より高次のプログラミング言語からライブラリへと起こったのと同じように、抽象化のレベルを上げています。同じ種類のことが起こり、私たちは抽象化のレベルの同じ変化を見ています。
そして今、ソフトウェア開発者として、私はそれらの詳細について心配する必要がありません。だから私はそれを、私がしなければならなかった退屈から非常に解放するものとして見ています。しかし基本はまだ残っています。
私が持続するソフトウェアを構築することを選択している限り、つまり私はそれを構築してそれを捨てるつもりはありません。捨てるつもりなら、やりたいことをやってください。それは素晴らしいです。そして私は多くの人々がまさにその目的でこれらのエージェントを使用しているのを見ます。それは素晴らしいことです。
以前にプロとして行うことができなかったことを自動化するつもりです。そして一人のユーザーであれば、もっとあなたに力を。これはホビイストのより希少でホビイスト側のソフトウェアです。ちょうど私たちがパーソナルとコンピュータの最も初期の頃に見たように、人々はこれらのものを構築するでしょう。素晴らしいもの。素晴らしいアイデアがそこから来るでしょう。
比較が好きです。ええ。
ええ。素晴らしいアイデアがそこから来るでしょう。人々はスキルを構築するでしょう。以前できなかったことをするでしょう。経済的に可能ではなかったことを自動化するでしょう。しかし彼らは必ずしも持続しないでしょう。しかし私たちは価値ある影響を与えたでしょう。
そして最初の時代のように、個人が人々がそれを買うことができたところで、業界に入ってくる人々がいるでしょう。正直に言って何の関係もありません。そして彼らは素晴らしいアイデアを持ち込むかもしれませんよね? 当時のように、学校の先生がパーソナルコンピュータを買ったかもしれません。
今日、私はちょうど上の階の隣人、会計士と話しました。彼女はChatGPTに彼らの会計チームがより良く処理するのを助けるためにいくつかのAppScriptを構築するよう指示しました。なぜなら彼女はそのものがどのように機能するかを知っているからです。ソフトウェアとは何の関係もありませんが、今は彼ら自身の個人的な使い捨てソフトウェアを作成しています。
ところで。
ええ、絶対に。同じ平行線です。そして私はそれを祝います。私はそれを奨励します。私はそれが最も素晴らしいことだと思います。だからこそ私たちはこの活気のある時期にいるのです。
パーソナルコンピュータの初期の頃、まさに同じことが起こりました。特にPCとAmigaに引き寄せられたアーティストを見つけました。ゲーマーを見つけました。彼らは以前持っていなかった表現のための新しい媒体を持っていることに気づきました。だからこそそれは非常に活気のある時期でした。
同じことが起こっています。そしてああ、実存的危機を持っているという多くの嘆きは、彼らの業界に狭く焦点を当てている人々であり、ここで起こっていることが実際には業界を拡大していることに気づいていません。
専門家ではない人々によってより多くのソフトウェアが書かれるのを見るつもりです。そして私はそれが周りで最も素晴らしいことだと思います。なぜなら今私たちは、パーソナルコンピュータのカウンターカルチャー時代のようなソフトウェアを持っているからです。
同じことが今日も起こっています。あなたが言っていることが好きです。しかしながら、一つしかしながら、しかしながら一つのことも私が業界全体で注意を払っている一人の人物は、Anthropicの CEOであるDario Amodeiです。
そして私が彼に注意を払う理由は、私はCEOに注意を払わない傾向がありますが、彼は実際に約1年前に何か興味深いことを言いました。彼は、ほとんどのコードがAIによって生成されるだろう、おそらく1年で約90%、そしてもっと多くなると思うと言いました。
そして私たちはそれはばかげていると思いました。そして彼は正しかったです。そしてコードは生成されました。そして今彼はまた別の興味深いことを言いましたが、次のものは怖く聞こえます。
彼は引用すると、ソフトウェア工学は12ヶ月で自動化可能になるだろうと言いました。さて、これは私たちが知っている理由でずっと怖く聞こえます。コーディングはソフトウェア工学のサブセットですが、彼はこれを言いました。これに対するあなたの見解は何ですか? そしてあなたはすでに強い反応を持っています。だから。
私はそれについて言うことが一つか二つあります。だからまず第一に、私はClaudeを使います。私はAnthropicの仕事を使います。私はそれが私の頼りのシステムだと思います。私はJavaScript、Swift、何とPHP、Pythonの問題にそれを使ってきました。
だから私はそれを使います。そしてそれは私にとって素晴らしいことでした。主に私が使いたい特定のライブラリがあるからです。Googleの検索は最悪です。
これらのもののドキュメンテーションは最悪です。だから私はこれらのエージェントを使ってそれらの理解を加速することができます。しかしまた思い出してください。私はこれらのスペースで少なくとも1年か2年の経験の基盤を持っています。数十年で、私は基本を理解しています。
だからこそ私は基本が消えることはないと早く言いました。そしてこれはすべてのエンジニアリング分野で真実です。基本は消えることはありません。私たちが適用するツールは変わるでしょう。
だからDario、私はあなたが言っていることを尊重します。しかし私とは異なる視点を持っていることも認識してください。彼はお金を稼ぐ必要がある会社を率いています。そして彼が彼のステークホルダーに話す必要がある会社です。
だからそのような途方もない声明が言われるでしょう。私は彼がダボスでこの種のことを言ったと思います。もし私が間違っていなければ。
それは非常にそうでした。ええ。
そして私は丁寧に言いますが、私がDarioが言ったことを特徴づける方法とそれを文脈に置く科学的用語を使います。
完全にそれは技術的用語です。なぜなら私は彼が深刻に間違っていると思うからです。そして彼は私が思うに多くの理由で間違っています。まず、私は彼のいくつかのことを加速するだろうという視点を受け入れます。それはソフトウェア工学を排除するつもりですか? いいえ。
私は彼がソフトウェア工学が何であるかについて根本的な誤解を持っていると思います。
私が最初に言ったことに戻ってください。ソフトウェアエンジニアはこれらの力のバランスを取るエンジニアです。だから私たちはコードを私たちのメカニズムの一つとして使いますが、それは私たちを駆動する唯一のものではありません。
彼または彼の同僚のいずれもが話しているもののどれも、ソフトウェアエンジニアが対処しなければならないそれらの決定問題のいずれにも対処しません。
自動化の領域内で見るもののどれも。彼の仕事は主に最低レベルでの自動化に焦点を当てています。これは私がコンパイラで起こっていたことに類似して置くでしょう。だからこそ私はそれは別の抽象化のレベルだと言います。
恐れるな、開発者たちよ。あなたのツールは変わっていますが、あなたの問題はそうではありません。
私が彼が言っていることに反発する別の理由があります。それは、CursorやそのようなものをCursorやそのようなものを見ると、彼らは主に私たちが何度も何度も見てきた一連の問題に訓練されてきたということです。そしてそれは大丈夫です。
第一世代、最初のゴールデンエイジで言ったように、私たちは特定の一連の問題を持っていました。だからライブラリはそれらの周りに構築されています。同じことがここで起こっています。
CRUDの上にUIを構築する必要がある場合、それはサブウィンターまたはいくつかのWebセントリックな種類のものです。私はそれをすることができます。そしてあなたの友人のように、彼らにもっと力を。彼らは自分自身でそれをすることができます。なぜならそうする力があるからです。
彼らはおそらくそれを中心にビジネスを構築することはないでしょう。彼らのうちのいくらかの小さなパーセンテージはそうするかもしれません。しかしそれは以前できなかったことをすることを可能にしました。なぜなら彼らは今より高い抽象化のレベルにいるからです。
Darioが無視するもの、そして私はシェイクスピアから少し言い換えを使いました。Dario、あなたの哲学で夢見られているよりもコンピューティングにはもっと多くのものがあります。コンピューティングの世界は規模のWebセントリックシステムよりもはるかに大きいです。
だから今日適用されているものの多くは、これらのWebリックシステムで見られます。そして私はそれが素晴らしく素晴らしいと思います。しかしそれはまだ自動化されていない多くのものがそこにあることを意味します。
だから私たちはこれらの縁を押し続けます。だから私は最初にあなたにそれらの物語を話しました。なぜなら歴史は繰り返しているからです。歴史が再び韻を踏んでいると言う人もいます。
同じ種類の現象が今日適用されています。ただ異なる抽象化のレベルで。だからそれが最初のものです。ソフトウェアは彼が見ているものよりも大きいです。ソフトウェアの世界はソフトウェア集約的システムよりも大きいです。
そして二番目に、ほとんどのこれらのエージェントが扱うシステムの種類を見ると、彼らは実際に私たちが何度も何度も見るパターンを自動化しています。それらのために訓練されてきました。
パターン自体は新しい抽象化であり、単一のアルゴリズムや単一のオブジェクトだけでなく、一緒に働くオブジェクトとアルゴリズムの社会を表します。
これらのエージェントはパターンの生成を自動化するのが得意です。この種のことをしたいです。そして私はそれをどのように説明するかという英語であなたに話すことができます。なぜならそれが私がパターンを説明する方法だからです。
とにかく、だからこそ私は彼が間違っていると思います。彼にもっと力を。しかし、これは実存的に心配することよりもエキサイティングな時期だと思います。
抽象化のレベルのシフトをどのように見るかに関して別の話をさせてください。英語は非常に不正確な言語であり、曖昧さとニュアンスなどに満ちています。
人はどうやってそれを有用な言語にすることができるのだろうと思うでしょう。そして答えは私たちはすでにこれをソフトウェアエンジニアとして行っているということです。私は誰かのところに行って、ねえ、私のシステムにこれをさせたいと言います。それはこのようなものに見えます。そして私は彼らにいくつかの例を与えます。私はすでにそれをします。
そして誰かが行ってそれをコードに変えます。私たちは抽象化のレベルを上げて、これをさせたいと言います。具体例をあげます。
実践例と新しい抽象化レベルの意味
私は以前触れたことのないライブラリで作業しています。それはJavaScript D3ライブラリで、本当に魅力的な視覚化をすることができます。
私はVictorian Engineering Connectionsというサイトを検索しに行きます。それは紳士がこれを博物館Andrewのためにやったこのただ素敵な小さなサイトです。そしてGeorge Booleのような名前を入れることができます。彼の名前が見えます。彼についてのものを見つけます。彼の周りの彼のソーシャルネットワークを見つけます。
そしてそれに触れて探索することができます。非常に、非常にクールです。そして私はそのようなものが欲しいが、私の天よ、どうやってそれをするか知らないと言いました。だから、私は何ができますか?
彼は私に彼のコードをくれました。私はそれがD3ライブラリを使用していることに気づきました。私はD3ライブラリについて何も知りませんでした。だから私はCursorに、可能な限り最も単純なものを構築してくださいと言いました。
5つのノードから行ってください。そして見せてください。だから私はコードを研究することができました。そして私は、まあ、彼らが本当にやりたかったことはこれです。ノードをこのように見せてください。彼らの種類によって、と言うことができました。
ちょうど人間とするように、私は今、突然それを現実に変えるために労働する必要がなかった英語で私のニーズを表現していました。
私は単に私がそれをするのを助けるために私のツールと会話することができました。だから私はそれが素晴らしいと思います。それはブレイクスルーです。
しかしDarioに言ったように覚えておいてください、これは私が人々が何百回も何百回もやってきたことをやっているこれらの状況でのみ機能します。
私は自分自身でそれを学ぶことができました。Feynmanが言ったように、自分でやってください。なぜならそれがあなたが理解する唯一の方法だからです。そして私の反応はそれは素晴らしいです。しかし世界には私が好奇心を持っているものが非常に多くあります。私はそれをすべて理解することはできません。
私が何をしたいか決めましょう。だから私のためにそれをやってください。だからこそ私はこれらの種類のツールは抽象化のレベルの別のシフトだと言います。なぜなら彼らは私が言っていることから私の英語からプログラミング言語までの距離を減らしているからです。
最後に言うことは、実行可能なアーティファクトを構築するのに十分に正確で表現力のある言語を何と呼びますか? 私たちはそれらをプログラミング言語と呼びます。
そしてたまたま英語はCOBOLがそうだったように、十分に良いプログラミング言語です。十分に構造化されたドメインでそれらのフレーズを与えると、それは基本を知っている私がナッジし始め、ピースを掃除することを可能にする十分に良い解決策を私に許します。
だからこそ基本はとても重要です。
時代の変化とスキルの進化
そして歴史が韻を踏むことと言えば、第一の時代とセカンド第二のゴールデンエイジの両方で起こったこと、または私たちが抽象化を飛び越えたとき、または抽象化があったときはいつでも、いくつかのスキルが時代遅れになりました。そして新しいスキルの需要がありました。
たとえば、アセンブリレベルから、特定のボードの命令セットを知り、それを最適化する方法を知るスキル、それはより高いレベルで考えることを支持して時代遅れになりました。
この今のジャンプでは、もうコードを書く必要がないと言うのは安全だと思います。そしてコンピュータはそれをかなり良くするでしょう。そして私たちはそれをチェックして微調整します。
ソフトウェアプロフェッショナルとして、何が時代遅れになり、何がより重要になると思いますか?
素晴らしい質問です。ソフトウェア配信パイプラインはあるべきよりもはるかに複雑です。
何かを実行させるだけで、パイプラインがない場合は難しいです。GoogleやStripeのような会社内にいる場合は
その周りに巨大なインフラストラクチャがあります。
カスタムなものです。
ええ。カスタムなものです。ええ。
だからそれらの自動化のための低く垂れ下がった果実があります。つまり、私はそれらの種類のものの縁を埋める人間を必要としません。
ところで、私は実際にはインフラストラクチャはソフトウェアだと言っています。
単なる生のコード行だけではありません。だからこれは低く垂れ下がった果実で、私たちがこれらのエージェントが、ねえ、この世界のこの部分のために何かを立ち上げてほしいと言うのを見始めることができます。
私はそのもののためにコードを書きたくありません。なぜならそれは複雑で混乱しているからです。私はそれをするのを助けるエージェントを使いたいです。だからそこには、仕事の喪失があるだろうと思う場所があります。それは混乱していて複雑な場所です。なぜなら自動化には明確な経済とセキュリティの面での価値があるからです。
それは人々が再スキルする必要がある場所です。単純なアプリケーションの構築などで。まあ、私はあなたが知っている、iOSまたは何かのためにこのものを構築したいと言うスキルを持っていた人々は、いくつかの仕事を失うつもりだと思います。
なぜなら率直に言って、人々は単にそれをプロンプトすることによってそれをすることができるからです。それは素晴らしいことです。それは結構です。なぜなら私たちは、専門家が過去に行ったことをする全体の別の世代の人々を可能にしたからです。
システム思考と抽象化レベルの上昇
まさにPC自体の時代に起こったことです。これらの人々は何をすべきか。抽象化のレベルを上げてください。システムについて心配し始めてください。
だからシフトは今、プログラムやアプリを扱うことからシステム自体を扱うことへのものだと思います。そしてそこに新しいスキルセットが入るべきです。
規模で複雑性を管理する方法を知るスキルを持っている場合、ソフトウェアエンジニアとしてこれらの複数の力、技術的なものだけでなく人間的なものでもある、それらをどのように扱うかを知っている場合、あなたの仕事は消えることはありません。
何でも、あなたがしていることに対するさらに大きな需要があるでしょう。なぜならこれらの人間のスキルは非常に稀で繊細だからです。
だからあなたは強い基盤を持つことの重要性に言及しました。そしてあなたは以前に言いました。実際にあなたを引用しています。この分野は深い基盤と強い理解のモデルを持たない人々にとって理解できないペースで動いています。
どの基盤を見ることを人々に勧めますか? 学生、大学で勉強している人々、または最初の仕事を探している人々、そしてまたソフトウェアプロフェッショナル、今実際に戻って役立つであろうそれらの基盤を強化したい人々の両方に。
私の幸せな場所、私の甘いスペースを見つけます。難しい問題に直面したときに私が退却して戻るところ、システム理論の中に。
SimonとNewellのThe Sciences of the Artificialの仕事を読んでください。Santa Fe Instituteから出てきた複雑性とシステムに関する一連の作業全体があります。
それらの種類のシステム理論の基本が、私が構築したい次のものの中で私を基礎づけます。私たちの以前の議論の一つであなたに言及したと思いますが、私はNASAの火星ミッションで本当に興味深い仕事をしていました。
私たちは、ねえ、長いミッションで人々を行かせたい、火星の表面にロボットを置きたいという問題に直面していました。そこで私はしばらくそれについて考えに行くよう委託されました。そして実際、私はNASAがHALを構築したいことに気づきました。
そしてあなたは私がここにHALを上に持っていることに気づくでしょう。
ええ。
これは私は歴史に素晴らしいです。これは私の後ろを通過するDamoclesの剣です。Damoclesの剣の背後にある歴史を知っているなら、王Damocles、彼は常に謙虚に保たれていました。なぜなら彼の玉座には、糸の上に剣が彼の真上にあったからです。だから彼は絶えず不安を感じました。
そしてこれが私がHALも後ろに持っている理由です。何らかの理由で、NASAはすべての宇宙飛行士のユースケースを殺したくありませんでした。なぜ理解できませんが、私たちはそれを一種の外に投げました。
しかしそこでの問題を見ると、これはシステムエンジニアリングの問題です。なぜなら宇宙船に具現化されたものが必要だったからです。
今日私たちが持っているAIのソフトウェアの多くは具現化されていません。Cursor、Copilotなどのように、彼らは物理世界との接続を持っていません。
だから私たちの仕事は主に具現化された認知にありました。ほぼ同じ時期に、私は脳のアーキテクチャをより良く理解しようとして多くの神経科学者の下で勉強していました。
そしてここが基本が私にとって一緒になった場所です。なぜなら私は、本当に大きなシステムの構造に適用できるシステムエンジニアリングで見る特定の構造があることに気づき始めたからです。
Marvin Minskyの社会of mindのアイデアを取ります。これは複数のエージェントをアーキテクチングするシステムの方法です。私たちは今エージェントプログラミングにいます。これは人々がこれらのことがどのように適用されるかをちょうど叩き始めていると思います。
彼らはシステム理論を見に行く必要があります。なぜならその問題は複数のエージェントですでに見られているからです。Minskyの社会of mindを読んでください。あなたはそこであなたを導くいくつかのアイデアを見るでしょう。複数のエージェントを扱うことで。
Hearsayのような初期のAIシステムで明示されたbearsのアイデア。グローバルワークスペース、ブラックボードなどのアイデア。
別のアーキテクチャ要素。Rodney Brooksからのサブサンプションアーキテクチャのアイデア。
彼のは生物学的なものに影響されました。ゴキブリを見ると、ゴキブリは非常に知的なものではありません。しかし私たちはそれにそこに中央の脳がないことを知っています。それでもそれはいくつかの素晴らしいことをします。
私たちは一般的な虫の全体的なニューラルネットワークをマッピングすることができました。私たちは世界中を走り回る邪悪な虫で溢れていません。そこで何か他のことが起こっています。
しかし生物学的システムにはそれらへのアーキテクチャがあります。だからあなたの質問に戻ると、生物学から、神経学から、システムの視点からアーキテクチャを見ることによって、Herbert Herbert SimonとNewellがこれをした、実世界のシステムから、これが次の世代のシステムに私を導いているものです。
だから私は今システムを見ている人々にそれらの基本に戻ることを勧めます。多くの点で、太陽の下に新しいものは何もありません。私たちはただ異なる方法でそれらを適用してきました。
工学におけるそれらの基本、それらはまだそこにあります。
成功への道筋と想像力の解放
そして終わりに、あなたは読むため、熟考するため、自分自身を教育するため、そしてこの新しい世界で役立つであろうアイデアを得るための本当に良い推奨を与えました。特に多くのエージェントを持つことになるので。
たとえば、私はちょうどエージェントがWindows 11とオペレーティングシステムの一部になると聞きました。だから彼らはどこにでもいるでしょう。
しかし抽象化の以前の台頭と以前のゴールデンエイジも振り返ると、新しいゴールデンエイジの始まりで、または新しい抽象化の始まりで素晴らしかった人々、たとえ彼らが以前のものでは素晴らしくなかったとしても、あなたはそれらの人々が何をするのを見ましたか?
そして何を、そしてこの歴史的教訓に基づいて、もし私たちがただ成功した、知っている、種類のことをコピーしようとしているなら、何を勧めますか? なぜなら私はこれも機会だと感じるからです、そうですよね?
私たちはこの抽象化の台頭を持っています。多くの人々は麻痺するでしょう。しかし新しいスーパースターが生まれるでしょう。彼らは基本的に波に乗っているでしょう。そして彼らはエージェントの専門家になるでしょう。AIの、以前できたよりもはるかに複雑な、これらの新しく複雑なものを構築することの。
だから早く述べたように、ソフトウェアで私たちを制約する主なものは私たちの想像力です。まあ実際それは私たちが始めるところです。私たちは実際には想像力によって制約されていません。私たちは素晴らしいものを夢見ることができます。それでも私たちは物理法則、アルゴリズムをどのように構築するかなどによって制約されています。倫理的問題などのように。
だから今起こっていることは、あなたが実際に解放されているということです。なぜなら摩擦のいくつか、制約のいくつか、開発のコストのいくつかが実際にあなたのために消えているからです。
これは今、単に以前は不可能だったものを構築するために私の想像力に注意を向けることができることを意味します。私はそれらをすることができませんでした。なぜなら私はそれらをするチームを集めることができなかったからです。
私はそれを買う余裕がありませんでした。私はできませんでした。なぜなら以前のように世界で手が届かなかったからです。だからそれを機会として考えてください。だからそれは損失ではありません。
これの経済に既得権益を持っている一部の人々にとってそれは損失になるでしょう。しかしそれはネットゲインです。なぜなら今、突然これらのものは、以前単に実世界では不可能だったことをすることを許す私の想像力を解放するからです。
これは業界にいるのにエキサイティングな時期です。同時に恐ろしいです。しかしそれはあるべき姿です。あなたが何か素晴らしいものの先端にいる機会があるとき、あなたは深淵を見て、くそ、私はそれに落ちるつもりだと言うことができます。または私は飛躍するつもり、そして私は舞い上がるつもりだと言うことができます。
これは舞い上がる時です。
グレイディ、概要、見通し、そして少しの視点を私たちに与えてくれて本当にありがとうございます。私は個人的に本当にこれを感謝します。
そして私はまた希望も提供したことを願っています。
私はあなたが確かに提供したと思います。これは本当に感動的なエピソードでした。ありがとう、グレイディ。
私に本当に突き刺さった一つのことは、グレイディが、開発者がこのまさに実存的危機に以前直面したことがあると指摘したときでした。実際複数回です。
コンパイラが登場したとき、アセンブリプログラマーは彼らのキャリアが終わったと思いました。高級言語が登場したとき、同じ恐怖が業界を引き裂きました。そして毎回、実際に何が起こっているかを理解した人々、それが単なる新しい牽引のレベルだったということ、彼らは前に出ました。
これは私たちのうちの何人かがAI能力の日々の不安に巻き込まれているときに、しばしば見逃していると思う歴史的レンズです。私はソフトウェア工学の終わりにいるとは思いません。グレイディもそうではありません。
私たちは別の章の始まりにいます。そして歴史が何かガイドを持っているなら、それはかなりエキサイティングなものになるでしょう。
このエピソードが興味深いと思ったなら、お気に入りのポッドキャストプラットフォームとYouTubeで購読してください。ショーに評価を残していただければ特別な感謝をします。ありがとう、そして次のエピソードでお会いしましょう。
コメント