以下はhttps://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/の翻訳です。
もちろんです。以下に翻訳した文章を示します。
メディアでは、ソフトウェア開発者が間もなくAIによって職を失うという話題で持ちきりだ。私はそうは思わない。プログラミングの終わりではない。それは、私たちが今日知っているプログラミングの終わりだ。それは新しいことではない。最初のプログラマーたちは、物理的な回路を接続して各計算を実行していた。彼らの後には、コンピューターの前面のスイッチをフリップして1ビットずつ入力するバイナリコードとして機械語の命令を書くプログラマーたちが続いた。その後、アセンブリ言語プログラミングがそれを終わらせた。それは、プログラマーが人間のような言語を使って、コンピューターにデータをメモリ内の場所に移動させ、それに対して計算を実行するように指示することを可能にした。そして、Fortran、COBOL、そしてその後継であるC、C++、Javaのようなさらに高レベルのコンパイル言語（compiled languages）の開発は、ほとんどのプログラマーがもはやアセンブリコードを書く必要がないことを意味した。代わりに、彼らはより高レベルの抽象化（abstractions）を使ってコンピューターに彼らの要望を表現できるようになった。
最終的に、デバッグがはるかに容易なインタプリタ型言語（interpreted languages）が標準となった。
これらの最初の大成功を収めた言語の一つであるBASICは、当初はおもちゃのように見られていたが、すぐに未来の波であることが証明された。プログラミングは、大企業や政府機関の裏方の聖職者だけでなく、子供やガレージ起業家にもアクセスできるようになった。
コンシューマー向けオペレーティングシステム（Consumer operating systems）もまた、物語の大きな部分を占めていた。パーソナルコンピューターの初期には、すべてのコンピューターメーカーが、メモリボード、ハードディスク、モデムやプリンターなどの周辺機器への読み書き作業を実行できる低レベルのドライバー（low-level drivers）を書くことができるソフトウェアエンジニアを必要としていた。Windowsがそれを終わらせた。それは、訓練を受けていない個人がコンピューターをはるかに容易に使えるようにするグラフィカルユーザーインターフェース（graphical user interface）を提供したから成功しただけではない。それはまた、彼の会社Netscapeがマイクロソフトによって圧倒されようとしていたマーク・アンドリーセンが、軽蔑的かつ（誤って）「単なるドライバーの袋」と呼んだものも提供した。Win32 APIを前面に押し出したそのドライバーの袋は、プログラマーが機械を制御するために低レベルのコードを書く必要がなくなったことを意味した。その仕事は事実上、オペレーティングシステムにカプセル化（encapsulated）されたのだ。WindowsやmacOS、そしてモバイルではiOSやAndroidは、今日、ほとんどのプログラマーが以前の世代のプログラマーが知っていたことの多くを知る必要がないことを意味している。
プログラマーは減るどころか増えた (There were more programmers, not fewer)
しかし、これはプログラミングの終わりとは程遠かった。プログラマーはかつてないほど増加したのだ。数億人ものユーザーが彼らの創造性の成果を享受した。需要の弾力性（elasticity of demand）の古典的な実証として、ソフトウェアが作りやすくなるにつれてその価格は下がり、開発者はより多くの人々が支払いをする意思のあるソリューションを作成できるようになった。
ウェブもまた、別の「プログラミングの終わり」だった。突然、ユーザーインターフェースは人間が読めるドキュメントで構成され、ブラウザに表示され、そこからリモートサーバー上のプログラムを呼び出すリンクが含まれていた。誰でも最小限のプログラミングスキルで簡単な「アプリケーション」を構築できた。「ノーコード（No code）」は流行語になった。すぐに、誰もがウェブサイトを必要とするようになった。WordPressのようなツールは、プログラマーではない人々でもコーディングなしでウェブサイトを作成できるようにした。しかし、テクノロジーの能力が向上するにつれて、成功したウェブサイトはますます複雑になった。「フロントエンド（frontend）」と「バックエンド（backend）」のプログラミングの間にますます分業が進んだ。PythonやJavaScriptのような新しいインタプリタ型プログラミング言語が主流になった。モバイルデバイスは新しい、ユビキタス（ubiquitous）なフロントエンドを追加し、新しいスキルを要求した。そして再び、その複雑さはフレームワーク（frameworks）、関数ライブラリ（function libraries）、そしてAPI（APIs）の背後に隠され、プログラマーがほんの数年前には学習が不可欠だった低レベルの機能についてそれほど多くを知る必要がないように保護された。
ビッグデータ（Big data）、ウェブサービス（web services）、そしてクラウドコンピューティング（cloud computing）は、一種の「インターネットオペレーティングシステム」を確立した。Apple Pay、Google Pay、Stripeのようなサービスは、かつては困難でハイステークス（high-stakes）な、支払いを受け取るなどの企業タスクを、最小限のプログラミング知識で可能にした。あらゆる種類の深く強力な機能がシンプルなAPIを介して利用可能になった。しかし、このインターネットサイトとそれらを接続するネットワークプロトコルおよびAPIの爆発的増加は、最終的により多くのプログラマーの必要性を生み出した。
プログラマーはもはや、数年ごとに更新される静的なソフトウェア成果物を作成するのではなく、継続的に開発（developing）、統合（integrating）、そして維持（maintaining）する長寿命サービス（long-lived services）を構築していた。さらに重要なことに、Google検索、Googleマップ、Gmail、Amazon、Facebook、Twitterのようなこれらの広大なサービスにおける作業の大部分は、大規模に自動化（automated）されていた。プログラムは人間によって設計・構築されたものであり、AIによるものではなかったが、作業自体の多くは、今日の汎用AI（general purpose AIs）の前身である特殊目的プログラム（special-purpose predecessors）によって行われていた。これらの企業で大部分の重労働を行っている労働者は、すでにプログラムなのだ。人間のプログラマーは彼らの「マネージャー」である。現在、何十万人ものプログラマーがこのような監督業務（supervisory work）を行っている。彼らはすでに、仕事がデジタルな共同作業者を作成し、管理することである世界に生きているのだ。
Google、Facebook、Amazon、あるいは最近のシリコンバレーの多くのスタートアップ企業は…何万人もの従業員を雇用しています。20世紀の工場のような考え方で考えるなら、これらの従業員は産業時代の先人たちと同じように、製品を生産するために日々懸命に働いており、ただ今日では物理的な製品ではなくソフトウェアを生産しています。しかし、21世紀の考え方で一歩引いてこれらの企業を見ると、これらの企業の仕事の大部分 — 検索結果、ニュースや情報の提供、ソーシャルネットワークのステータス更新、および関連する商品の販売 — はソフトウェアプログラムやアルゴリズムによって行われていることに気づくでしょう。これらが真の労働者であり、それらを作成するプログラマーが彼らのマネージャーなのです。—ティム・オライリー、「ボットを管理するビジネスの管理」、MIT Sloan Management Review、2016年5月21日
これらのそれぞれの波において、古いスキルは陳腐化しました — まだ役立つものの、もはや不可欠ではなく — そして新しいスキルが成功の鍵となりました。今でもコンパイラを書くプログラマーはごく少数、人気のあるJavaScriptフレームワークやPythonライブラリを書くプログラマーは何千人もいますが、ウェブやモバイルアプリケーション、そしてそれらを可能にするバックエンドソフトウェアを書くプログラマーは何千万人もいます。何十億ものユーザーが彼らが生産するものを消費しています。
今回は違うのか？ (Might this time be different?)
しかし、突然、プログラマーではない人がLLMや専門のソフトウェアエージェントに平易な英語（または選択した人間言語）で話しかけるだけで、有用なPythonのプロトタイプ（または選択したプログラミング言語）を返してもらえることが可能になったようです。これには「CHOP」または「chat-oriented programming」という新しい流行語さえあります。高度な推論モデル（reasoning models）の台頭は、達成すべきタスクを高レベルのプロンプトで説明するだけで、複雑なプログラムさえもAIが生成できることを示し始めています。その結果、「今回は違う」「AIがほとんどの人間プログラマー、そして実際にはほとんどのナレッジワーカー（knowledge workers）を完全に置き換えるだろう」と言う人が多くいます。彼らは、私たちは広範な人間失業（pervasive human unemployment）の波に直面していると言います。
私はそれでもそうは思いません。高度なコンピューティング能力がはるかに多くの人々の手に渡るようなブレークスルーがあったとき、確かに、一般の人々がかつては高度な訓練を受けた専門家の領域であったことを行えるようになります。しかし、その同じブレークスルーは、新しい種類のサービスとそのサービスへの需要も可能にします。それは、少数の人しか理解できない、新しい種類の深い魔法（deep magic）を生み出すのです。
今到来している魔法は、これまでで最も強力です。そしてそれは、私たちが探求と創造の深い時期に入りつつあることを意味します。その魔法を機能させ、その力から新しい利点を得る方法を理解しようと努めているのです。このテクノロジーを採用する賢い開発者は、より多くのことができるようになるため、需要が高まるでしょう。彼らは付加価値をもたらす高レベルの創造性に集中できるからです。
実践による学習 (Learning by doing)
AIがプログラマーを置き換えることはありませんが、彼らの仕事を変革（transform）するでしょう。最終的に、今日のプログラマーが行っていることの多くは、（組み込みシステムプログラマーを除いては）オシロスコープでデバッグする古いスキルと同じくらい陳腐化（obsolete）するかもしれません。熟練のプログラマーであり、先見の明のある技術観察者であるスティーブ・イエッゲは、置き換えられるのはジュニアおよびミッドレベルのプログラマーではなく、新しいプログラミングツールやパラダイムを受け入れずに過去に固執する人々だと述べています。新しいスキルを習得または発明する人々は高い需要があるでしょう。AIのツールを習得したジュニア開発者は、そうでないシニアプログラマーをしのぐことができるようになるでしょう。イエッゲはこれを「頑固な開発者の死（The Death of the Stubborn Developer）」と呼んでいます。
私の考えは、私自身のコンピュータ業界での過去40年以上の経験やイエッゲのような開発者の観察だけでなく、1800年代初頭のロウエル（マサチューセッツ州）の織物工場で最初の産業革命がどのように展開したかを研究した経済史家ジェームズ・ベッセン（James Bessen）の著作によっても形成されています。熟練した職人が「未熟練」労働者によって操作される機械に置き換えられたとき、実際、人間の賃金は抑制されました。しかし、ベッセンは、新しい産業工場で働く労働者の賃金記録と、以前の家庭を拠点とした職人の賃金記録を比較することで、奇妙なことに気づきました。見習い職人が熟練の職人の満額賃金に達するまでにかかる時間と、新しい入門レベルの未熟練工場労働者が満額の賃金と生産性に達するまでにかかる時間は、ほぼ同じだったのです。両方の体制で働く労働者は、実際には熟練労働者でした。しかし、彼らは異なる種類のスキルを持っていたのです。
ベッセンが見つけたところによると、産業革命の最初の50年間、賃金が横ばいまたは抑制され、その後上昇して広範な繁栄の増加につながった大きな理由は2つありました。1つ目は、工場所有者が新しい生産性の利益を労働者と共有せず、独占したことでした。しかし2つ目は、最大の生産性向上が実現するまでに数十年かかったことです。なぜなら、新しい技術を最大限に活用する方法に関する知識がまだ広く普及していなかったからです。発明家が機械をより堅牢にし、それらを使用する人々がより効果的にするための新しい種類のワークフローを考案し、それらで作れる新しい種類の製品を創造し、より広範な企業が新しい技術を採用し、そして労働者がそれらを活用するために必要なスキルを習得するまでに数十年かかりました。労働者は、機械を使用するためだけでなく、修理するため、改良するため、そしてそれらが示唆するもののまだ完全には実現できていない未来を発明するために、新しいスキルを必要としたのです。これらすべては、ベッセンが「実践による学習（learning by doing）」と呼ぶプロセスを通じて起こります。
数人の個人が新しいスキルを先取りして習得するだけでは十分ではありません。ベッセンは、「工場、産業、そして社会全般にとって重要なのは、個々の労働者を訓練するのにかかる時間ではなく、安定した訓練された労働力を創造するために何が必要かである」と説明しています（『実践による学習』、36ページ）。今日、この革命に影響を受けるであろうすべての企業（つまり、すべての企業）は、総力を挙げて取り組む必要があります。私たちはAIリテラシーのある労働力（AI-literate workforce）を必要としています。結局のところ、プログラミングとは、人間がコンピューターに命令を実行させる方法にすぎません。その「プログラミング」が人間言語にますます近づき、私たちの機械が私たちを理解できるようになり、私たちが0と1のネイティブな言語や、専門的なプログラミング言語のピジン語で彼らに話しかける必要がなくなったという事実は、祝うべきことでしょう。
人々はより多くのプログラムを創造し、使用し、洗練させ、そして私たちが創造するものを管理し、それに基づいて新しい産業が生まれるでしょう。歴史の教訓は、自動化によって人々が望むまたは必要とする製品を提供することがより安価で容易になったとき、需要の増加はしばしば雇用の増加につながることを教えてくれます。雇用が減少し始めるのは、需要が満たされたときだけです。プログラミングに関しては、私たちはまだその段階には程遠いのです。
- ジェボンズのパラドックス（Jevons paradox）が再び発生しています！AIがより効率的でアクセスしやすくなるにつれて、その使用は急増し、私たちがいくら使っても飽き足らない商品となるでしょう。
- プログラミングの中身が変わる (What programming is will change)
- ビジネスにおけるAIテクノロジー導入の課題 (The challenge of deploying AI technologies in business)
- AIエージェントがエージェントと話すとき… (When AI agents start talking to agents…)
- 私たちは未来を発明する初期段階にいる (We are in the early days of inventing the future)
- プロトタイプからプロダクションへの道のり (The Journey from Prototype to Production)
免責事項 ジェボンズのパラドックス（Jevons paradox）が再び発生しています！AIがより効率的でアクセスしやすくなるにつれて、その使用は急増し、私たちがいくら使っても飽き足らない商品となるでしょう。
意外なことではありませんが、ウォートン・スクール教授でAIエヴァンジェリスト（evangelist）のイーサン・モリリック（Ethan Mollick）もベッセンの著作のファンです。だからこそ彼は、「常にAIをテーブルに持ち込む（always bring AI to the table）」、つまり仕事のあらゆる側面にAIを関与させ、「ギザギザの端（the jagged edge）」（何が機能し、何が機能しないか）を探求することを説得力をもって主張しているのです。また、彼が企業にAIを使って従業員を強化し、置き換えないように促すのもそのためです。新しいテクノロジーをどのように応用するかについては、学ぶべきことが非常にたくさんあります。企業の応用研究開発（applied R&D）の最良の情報源は、従業員がAIを使って問題を解決し、新しい機会を模索する中で行う探求です。
プログラミングの中身が変わる (What programming is will change)
マイクロソフトの副CTOの一人であるサム・シラースは、私の分析に同意しました。最近の会話で、彼は私にこう言いました。「私たちは今、AIシステムを中心とした新しいプログラミングパラダイム（programming paradigm）を発明している最中です。デスクトップからインターネット時代に移行したとき、スタックのすべてのレベルは同じだったにもかかわらず、スタック内のすべてが変わりました。私たちはまだ言語を持っていますが、それらはコンパイル型からインタプリタ型に変わりました。私たちはまだチームを持っていますが、彼らはウォーターフォールからアジャイル、そしてCI/CDに変わりました。私たちはまだデータベースを持っていますが、それらはACIDからNoSQLに変わりました。私たちは、1ユーザー、1アプリ、1スレッドから、マルチ分散型など、様々なものに移行しました。私たちは今、AIで同じことを行っています。」
以下は、新しいAIスタックに組み込まれているテクノロジーの一部です。これには、AIモデル、それらのAPI、そしてそれらのクラウドインフラストラクチャの膨大な数さえ含まれていません。そして、すでに情報が古くなっています！
しかし、新しいツール、フレームワーク、および慣行の爆発は、プログラミングの変化のほんの始まりにすぎません。シラースが指摘した問題の1つは、モデルが人間のようにメモリを持っていないことです。大きなコンテキストウィンドウ（context windows）があっても、彼が「メタ認知（metacognition）」と呼ぶことを行うのに苦労します。結果として、彼は、AIの共同開発者が動作する文脈の多くを人間が依然として提供する必要があると考えています。
シラースは最近の投稿でこの考えを展開しました。「大規模言語モデル（LLM）やその他のAIシステムは、思考を自動化しようとしています」と彼は書きました。「産業革命における運動の自動化との類似点は驚くべきものです。今日、自動化はまだ粗野です。私たちは、水の汲み上げやハンマー打ちという認知的な同等のことを行っています—要約、パターン認識、テキスト生成のような基本的なタスクです。私たちはまだ、この新しいエネルギー源のための堅牢なエンジンを構築する方法を解明していません—AIの段階はまだ機関車の段階にさえ達していません。」
機関車の段階でさえ、物理的な物体を移動させる際に人間がもたらすことができた brute force（力づく）の拡大でした。不可欠な次のブレークスルーは、その力に対する制御（control）手段の増加でした。シラースは問いかけます。「従来のソフトウェアエンジニアリングはここでは完全に適切ではないのだろうか？ AIを構築するには根本的に異なる慣行と制御システムが必要なのだろうか？ 私たちは新しい種類の思考（運動のアナログ）を創造しようとしています。つまり、事前に設計されたパターンを繰り返す以上のことができる、より高レベルで、メタ認知的で、適応的なシステムです。これらを効果的に使用するには、まったく新しい働き方、新しい分野を発明する必要があります。初期の蒸気機関の課題が冶金学を生み出したように、AIの課題は認知、信頼性、スケーラビリティの新しい科学の出現を促すでしょう—まだ完全には存在しない分野です。」
ビジネスにおけるAIテクノロジー導入の課題 (The challenge of deploying AI technologies in business)
Salesforceの元共同CEO、Metaの元最高技術責任者（CTO）、そして昔はGoogleマップを開発したチームのリーダーだったブレッド・テイラー（Bret Taylor）は、現在、ビジネスでAIテクノロジーを開発・導入する中心にあるAIエージェント開発会社SierraのCEOです。最近の会話で、ブレッドは私に、企業のAIエージェントが、ウェブサイト、モバイルアプリと同じくらい重要、あるいはそれ以上に、主要なデジタルインターフェースになると信じていると語りました。企業のAIエージェントは、その主要なビジネスポリシーとプロセスをすべてエンコードしなければなりません。これはAIが最終的には単独で行えるようになるかもしれませんが、今日、Sierraは顧客ごとにエンジニアリングチームを割り当て、実装を支援しなければなりません。
「クールなプラットフォームと大量のビジネスプロセスを取り込み、エージェントを実現する『ラストワンマイル（last mile）』は、実際にはかなり難しいことです」とブレッドは説明しました。「今、エージェントエンジニア（agent engineer）と呼ばれる新しい役割が生まれており、これはフロントエンドのウェブ開発者に少し似たソフトウェア開発者です。これはソフトウェアで最も一般的なアーキタイプ（archetype）です。もしあなたがReact開発者なら、AIエージェントを作ることを学ぶことができます。これはスキルを再習得し、あなたのスキルを関連性のあるものにする素晴らしい方法です。」
問題を実際に解決できるAIエージェントと話せるのに、誰がカスタマーサービスの電話のたらい回しにわざわざ時間を費やしたいと思うでしょうか？しかし、それらのエージェントを適切に構築することは、真の課題となるでしょう。難しいのはプログラミングそのものではありません。ビジネスプロセスを深く理解し、新しい能力がそれらをどのように変革して新しい機能を活用できるかを考えることです。既存のビジネスプロセスを単に再現するだけのエージェントは、紙のフォームを単に再現するだけのウェブページやモバイルアプリと同じくらい恥ずかしい（embarrassing）ものとなるでしょう。（そして、ええ、そういうものは今でも存在します！）
Google Chromeのユーザーエクスペリエンス責任者であるアディ・オスマニ（Addy Osmani）は、これを「70%問題（the 70% problem）」と呼んでいます。「エンジニアはAIによって劇的に生産性が向上したと報告しているものの、私たちが日常的に使用する実際のソフトウェアは、目に見えて改善されているようには見えません。」彼は、AIコード生成ツールを使用する非プログラマーは、素晴らしいデモを作成したり、簡単な問題を解決したりできますが、複雑なプログラムの最後の30%で立ち往生すると指摘しています。なぜなら、コードをデバッグし、AIを正しい解決策に導くのに十分な知識がないからです。一方で：
CursorやCopilotのようなAIツールを使ってシニアエンジニアが作業するのを見ると、まるで魔法のように見えます。彼らは、テストやドキュメントを含めて、数分で機能全体をスキャフォールド（scaffold）できます。しかし、注意深く見ると、決定的なことに気づくでしょう。彼らはAIが提案するものをただ受け入れているわけではないのです… 彼らは、長年培ったエンジニアリングの知恵を適用して、AIの出力を形作り（shape）、制約（constrain）しているのです。AIは彼らの実装を加速させていますが、彼らの専門知識がコードの保守性（maintainability）を維持しているのです。ジュニアエンジニアは、これらの重要なステップを見落としがちです。彼らはAIの出力をより簡単に受け入れ、その結果、私が「砂上の楼閣コード（house of cards code）」と呼ぶものにつながります — それは完璧に見えますが、現実世界の圧力の下では崩壊してしまいます。
この点に関して、『AI Engineering』の著者であるチップ・フイエン（Chip Huyen）は、私へのメールで示唆に富む観察をしました：
AIが新しい種類の思考を導入するとは思いません。AIは、実際に思考を必要とするものを明らかにします。
どんなに手作業であっても、ごくわずかの高学歴者しかできないタスクであれば、そのタスクは知的（intellectual）であると見なされます。例えば、書くこと、つまり言葉を紙に書き写すという物理的な行為があります。かつて、人口のごく一部しか読み書きできなかった時代には、書くことは知的であると見なされていました。人々は書道に誇りさえ持っていました。今日では、「書く」という言葉は、もはやこの物理的な行為ではなく、アイデアを読みやすい形式に配置するというより高次の抽象化を指すようになりました。
同様に、一度コーディングという物理的な行為が自動化されると、「プログラミング」の意味は、アイデアを実行可能なプログラムに配置する行為を指すように変わるでしょう。
スタンフォード大学CS学科の学科長であるメフラン・サハミ（Mehran Sahami）は、簡潔にこう述べています。「コンピューターサイエンスは、コードを書くことではなく、体系的な思考に関わるものです。」
AIエージェントがエージェントと話すとき… (When AI agents start talking to agents…)
…問題を正確に表現することの重要性はさらに高まります。企業フロントエンドとして機能し、企業のあらゆるビジネスプロセスへのアクセスを提供するエージェントは、消費者だけでなく、消費者のためのエージェントや、他の企業のためのエージェントとも会話することになります。
エージェントの等式のその側面全体は、はるかに投機的（speculative）です。私たちは、独立したAIエージェント間の協力のための標準をまだ構築し始めてさえいません！「エージェントインフラストラクチャの必要性（the need for agent infrastructure）」に関する最近の論文は次のように述べています：
現在のツールは、エージェントが既存の機関（例：法的・経済システム）やアクター（例：デジタルサービスプロバイダー、人間、他のAIエージェント）とどのように相互作用するかを形成するように設計されていないため、大部分が不十分です。例えば、アラインメント技術は、ユーザーがエージェントに違法行為を指示した場合に、何らかの人間が責任を負うことを対向者（counterparties）に保証するものではありません。このギャップを埋めるために、私たちはエージェントインフラストラクチャ（agent infrastructure）の概念を提案します。これは、エージェントが環境との相互作用や影響を仲介し、影響を与えるように設計された、エージェントの外部にある技術システムと共有プロトコルです。エージェントインフラストラクチャは、新しいツールと既存ツールの再構成または拡張の両方を含みます。例えば、説明責任を促進するために、ユーザーをエージェントに結びつけるプロトコルは、OpenIDのような既存のユーザー認証システムに基づいて構築できます。インターネットがHTTPSのようなインフラストラクチャに依存しているのと同様に、エージェントのエコシステムにとってもエージェントインフラストラクチャが同様に不可欠であると私たちは主張します。私たちはエージェントインフラストラクチャの3つの機能を特定します。1) 特定のエージェント、そのユーザー、または他のアクターにアクション、プロパティ、その他の情報を帰属させる（attributing）こと、2) エージェントの相互作用を形成する（shaping）こと、3) エージェントからの有害なアクションを検出および修正する（detecting and remedying harmful actions）こと。
ここでは、解決すべき巨大な協調と設計の問題（coordination and design problems）があります。私たちが想像できる最高のAIエージェントでさえ、人間の指示なしにこのような複雑な協調問題を解決することはできません。AI支援を受けたプログラマーでさえ、少なくとも今後10年間は多忙を極めるほどのプログラミングが必要とされるでしょう。
要するに、発明されるべき新しいソフトウェアの世界全体があり、それはAI単独ではなく、AIをスーパーパワー（superpower）として使用する人間のプログラマーによって発明されるでしょう。そして、それらのプログラマーは多くの新しいスキルを習得する必要があります。
私たちは未来を発明する初期段階にいる (We are in the early days of inventing the future)
学ぶべきこと、なすべきことは非常にたくさんあります。そうです、大胆になり、AI共同開発者がプログラマーの生産性を10倍にすると仮定しましょう。（あなたの開発者が新しいスキルを習得する意欲によって結果は異なるかもしれません。）しかし、それが起こると同時に、ビジネス、科学、そして私たちの構築されたインフラの「プログラマブルな表面積（programmable surface area）」が並行して増加するとも規定しましょう。プログラミングが違いを生み出す機会が20倍になった場合、私たちは新しい10倍の生産性を持つプログラマーが2倍必要になるでしょう！
ユーザーの期待も高まるでしょう。より高い生産性を単にコスト削減に利用する企業は、新しい能力を活用してより良いサービスを構築するために投資する企業に負けるでしょう。
AI時代にプログラミングをより簡単でより良いものにできることを世界に示す最前線に立ってきた長年のソフトウェア開発者であるサイモン・ウィルソン（Simon Willison）が指摘するように、AIは彼にプロジェクトで「より野心的になる（be more ambitious）」ことを可能にします。
能力が爆発的に増加した別の分野から教訓を得ましょう。今日のマーベルのスーパーヒーロー映画の1フレームをレンダリングするのにかかる時間は、CPU/GPUの価格と性能がムーアの法則の恩恵を受けているにもかかわらず、最初のピクサー映画全体をレンダリングするのにかかった時間と同じくらいかもしれません。映画業界は、低解像度の粗いアニメーションをより速く、より安価に提供することに満足しなかったことが分かります。余分なサイクルは、リアルな毛皮、水、雲、反射、そしてより多くのピクセルの解像度における何千もの小さな改善に費やされました。技術の進歩は、単に安価で高速な提供だけでなく、より高品質な結果をもたらしました。安価で高速なことを優先し、高い制作価値を犠牲にすることで可能になった産業もあります（ユーザーが作成したオンライン動画の爆発的な増加を考えてみてください）ので、どちらか一方ということにはなりません。しかし、品質は市場でその地位を占めるでしょう。常にそうです。
ReplitやDevinのようなAIツール、あるいはSalesforce、Palantir、Sierraが提供するようなエンタープライズソリューションを使って、数千万人のアマチュアAI支援プログラマーが作業している様子を想像してみてください。彼らが何百万もの人々にアピールするようなユースケースに偶然出くわす可能性はどれくらいでしょうか？彼らの中には、AIと協力して作成される次世代ソフトウェアの起業家（entrepreneurs）となる人もいるでしょう。しかし、彼らのアイデアの多くは、既存のプロのデベロッパーによって採用され、洗練され、規模を拡大（scaled）されるでしょう。
プロトタイプからプロダクションへの道のり (The Journey from Prototype to Production)
企業においては、AIは問題を最もよく知る人々がソリューションを構築することを大いに可能にするでしょう。しかし、それらのソリューションの最高のものは、PalantirのCTOであるシャム・サンカー（Shyam Sankar）が「プロトタイプからプロダクションへの道のり（the journey from prototype to production）」と呼んだ道のりを進む必要があります。サンカーは、企業にとってのAIの価値は「自動化（automation）、エンタープライズ自律性（enterprise autonomy）」にあると指摘しました。しかし、彼が指摘したように、「自動化はエッジケース（edge cases）によって制限されます」。彼は、2005年のDARPAグランドチャレンジで優勝した自動運転車「スタンレー」の教訓を思い出しました。素晴らしいことを成し遂げることができたものの、都市での運転のエッジケースを完全に処理するにはさらに20年の開発が必要でした。
「ワークフロー（Workflow）は依然として重要です」とサンカーは主張し、プログラマーの仕事は、従来のソフトウェアで何ができるか、AIで何ができるか、依然として人間が行う必要があることは何か、そして実際にワークフローを達成するために物事をどう結びつけるかを理解することになるだろうと述べました。彼は、「フィードバックを捉え、エッジケースを学習してできるだけ早くそこに到達することを可能にするツールチェーン（toolchain）が、勝利のツールチェーンである」と指摘しています。サンカーが描く世界では、AIは「実際に開発者をビジネスにより深く関わらせ、彼らがもたらす影響をはるかにレバレッジ（leveraged）させる」でしょう。一方、トップティアの専門家（subject matter experts）は、AIアシスタントの助けを借りてプログラマーになるでしょう。失業するのはプログラマーではありません。AI支援プログラマーにならない人々 — あらゆる職務の — がそうなるでしょう。
これはプログラミングの終わりではありません。それは最新の再発明（reinvention）の始まりなのです。
免責事項
記事は、一般的な情報提供のみを目的としてのみ作成したものであり、投資家に対する有価証券の売買の推奨や勧誘を目的としたものではありません。また、記事は信頼できると判断した資料およびデータ等により作成しておりますが、その正確性および完全性について保証するものではありません。また、将来の投資成果や市場環境も保証されません。最終的な投資決定は、投資家ご自身の判断でなされますようお願いします。
