この書き起こしは、GitHubのCEOであるトーマス・ドームケ氏へのインタビューで、プログラミングの未来、AIコーディングアシスタント、ソフトウェア開発の進化について語られている。GPT-3やCodexを初めて見た時の驚き、GitHub Copilotの開発過程、プログラミング教育の重要性、コーディングエージェントの可能性、GitHub Copilotのオープンソース化、ソフトウェアアーキテクチャの未来、そしてAIによる仕事の置き換えに対する見解まで、幅広いトピックが議論されている。特に、AIがプログラマーを完全に置き換えるのではなく、むしろより多くの人がプログラマーになる機会を提供し、より複雑な問題解決に集中できるようになるという楽観的な展望が示されている。
当時のGPTを初めて見た時、どう思いましたか？
うまくいかないと思いました。動作しないだろうと。疑っていたんですが、それが実際に動作して、まるで魔法のようでした。
ソフトウェア開発が永遠に変わることをすぐに理解しましたか？
絶対に、100パーセントそう思いました。
コーディングエージェントについてどう思いますか？ハンドルから少し手を離すような感じですね。
実際にはまだハンドルに手を置いておくことを強制します。コードの25パーセントを書いて、あなたの仕事の一部だった知識が会社に残ります。
トーマスさん、お忙しい中参加していただき、お話しできて本当に嬉しいです。
こちらこそ。ソフトウェアの未来、コーディングエージェントの未来について話せて興奮しています。
最初の質問ですが、あなたはGitHub Copilotの開発を主導していました。これは最新の生成AI波の前の話です。コードの行を入力し始めて、タブを押すと、それを補完してくれるというものでした。初めて見た時は完全に衝撃的でした。
当時のGPTを初めて見た時、コード補完を初めて見た時、どのような感覚でしたか？
うまくいかないと思いました。動作しないだろうと。絶対に動作しないと思っていました。私は大学で90年代後半から2000年代初頭にかけて、多くのコンパイラ関連の作業をしたので、コンパイラがどのように動作するかを理解しています。
モデルがPythonの構文をRubyやJavaScriptと区別できるとは信じられませんでした。それらを混同して、括弧を間違った場所に置いたり、セミコロンを必要のない場所に置いたりすると思っていました。
2020年の夏にGPT-3、そして最初のコーディングモデルであるOpenAIのCodexが、プロンプトで「素数検出アルゴリズムまたはソートアルゴリズムを特定の言語で書いて」と言うと、実際に適切なコードを書くのを初めて見た時、コンパイラもなく、今のエージェントモードのようなツール呼び出しステップもないのに、正しい構文で完全なメソッドを書くことができたんです。
あなたとチームが最初にそれをリリースした時、私が覚えているのは、それが出た時に本当に衝撃を受けたことです。私のチームで働いていた他のエンジニアたちは「これをやらなければいけない。これは変革をもたらす」と言っていました。ソフトウェア開発が永遠に変わることをすぐに理解しましたか？
その少し前にそれを見ていました。GitHubでは、すべての機能についてスタッフシップを行っています。公開プレビューやプレビュー発表の3、4ヶ月前の2021年6月に、すべてのハバー、つまりGitHubの従業員に最初に出荷して試してもらいます。Copilotでも同じことをしました。使用している人たちからのフィードバックは驚異的でした。
どのくらいのコードを書いているかを追跡していました。最初のテレメトリが戻ってきて、チームが週次レビューに来て「有効になっているファイルでコードの25パーセントを書いている」と言いました。私たちはその数字を信じませんでした。測定方法が実際に正しいかどうか確認するために彼らを送り返しました。彼らは戻ってきて「はい、実際に正しく、今はさらに高くなっています」と言いました。
言語によって異なっていました。これも検証機能を与えてくれました。ランダムな数字ではなく、Pythonのような一部の言語では優れていて、CやC++のような他の言語では劣っていました。これは、それらの言語の歴史を考えると非常に理にかなっています。Cは多くの場合、ヘッダーファイルのimportやinclude文に依存しています。
もう一つは、それを使用している開発者からのフィードバックであるネットプロモータースコアでした。72かそれくらいの範囲だったと思います。NPSはマイナス100からプラス100までです。満足度スコアで本当に高く、特にプレビューでは、そしてラップトップで行うインナーループと呼ばれるものに何かを挿入する場合、これは通常そうなりません。
多くの開発者は、私も含めて、色スキームやショートカット設定について特にこだわりがあります。これは、VS Codeに多くのカスタマイズオプションが設定や拡張機能であることの大きな魅力の一つです。そして、誰もが独自の開発環境を持っています。
そこに何かを持ち込んで「これからCopilotがあり、常に次の10行のコードを予測します。それを読んで理解し、受け入れるかどうかを決める必要があります」と言うと、私たちは実際よりもネガティブに受け取られると思っていました。
実際には、反応は圧倒的にポジティブでした。私が説明したように、最初のプライベートプレビューを出荷し、その後パブリックプレビューを出荷すると、非常に短期間でCopilotに100万人以上のユーザーがいて、多くの人が「疑っていたが、それが動作して魔法のようだった」という瞬間を経験しました。
ユーザーエクスペリエンスについて話したいと思います。今見ると、タブ補完は非常に明白に見えますが、以前はそこにはありませんでした。開発者とAIコーディングアシスタントの間の最初のインタラクションポイントとして、タブ補完にどのように到達しましたか？
Visual StudioやVisual Studio CodeにはIntelliSenseがありました。これは、プログラミング言語とその言語のライブラリについての情報を使用して、そのクラスにどのようなメソッドが存在するかなどを教えてくれるものです。小さなドロップダウンがあり、これらの3つのオプションが利用可能であることがわかります。iPhoneアプリをXcodeでコーディングしている場合など、多くの他のIDEにも同様の機能があります。これらの長いSwiftメソッドを書くのを助け、パラメータが何かを示してくれます。
正確なスペルを知らなくても、最初の3、4文字を覚えている限り、オートコンプリート、IntelliSenseが助けてくれるという学習された動作がすでにありました。
TextMateやSublime Textのようなエディタにも、ローカルファイルを見て、すでに書いたすべてのメソッドを抽出し、それらを予測してくれる、よりスマートなオートコンプリートがありました。基本的に、メソッドを書いて、そのメソッドを呼び出すときに、そのメソッドの宣言を知っていて、それをオートコンプリートできるのです。
一つは、開発者からすでに学習された動作であるオートコンプリートがありました。オートコンプリートは20年ほど前からあったと思います。少し短いかもしれませんが、その頃だと記憶しています。TextMateを初めて使った時のことを覚えていて、それにはこのスマートオートコンプリートがありました。
もう一つは、写真記憶やそのようなものを持っていない限り、開発者は常にファイル内で何かを調べなければならない時点に到達するということです。ドキュメンテーション、ブラウザのStack Overflow、Reddit、ブログ投稿、Build会議のような開発者会議のビデオ、もちろんGitHubリポジトリやオープンソースライブラリなど、何かを調べています。
「このAPIにアクセスする方法」や「角を丸くする方法」、「文字列をエンコードする方法」などの問題を解決しようとして、コードスニペットを取ってエディタに貼り付け、実際に持っている変数名やプログラミング言語やライブラリのバージョンで動作するように修正します。
どこか他の場所からコードを取ってきて、実際のシナリオで動作するように修正するという学習された動作がすでにありました。実際、私たちの多くは、Hello Worldチュートリアルやハウツーから何かを取って、それを最初のアプリケーションに修正するという、ある種の試行錯誤でコーディングを学んだと思います。
エディタの機能としてのオートコンプリートと、完璧でなくても動作させるという学習された動作があります。そして、それを2020年のCodexという大規模言語モデルと組み合わせます。これも完璧ではなく、幻覚がありました。今日のモデルにもまだ幻覚があります。
しかし、どこか他の場所で調べるプロセスをショートカットするのに十分良いものでした。そして、フロー状態を維持することができました。ソフトウェア開発者のフロー状態は魔法的なものだと信じています。このアイデアがあり、これを構築したいと思い、実際にエネルギーと集中力がある限られた時間があります。IDEで何かを構築し続け、コードが続き、タブ補完して修正し、コンパイルして続けることができる限り、これは多くの開発者にとって最高の瞬間だと思います。特に、それを実行して動作する時、何もないところから手と少しの思考、少しのアイデアで作ったものを見ることができます。
プログラミング教育について話したいと思います。これはあなたと私の両方にとって大切なことだと知っています。私が今まで学んだ最も重要なスキルセットは、コーディングを学ぶことでした。自分のアイデアを取って何でも構築できました。2年余り前、子供たちに何を教えるべきかと聞かれたら、私には7歳と2歳の2人の子供がいますが、彼らにコーディングを教えたいと言ったでしょう。しかし、もうそれほど確信がありません。システム思考を学ぶことには多くの利点があると思いますが、子供たちに実際にコアプログラミング言語を教えることの支持者ですか？
絶対に、100パーセントです。子供たちは、それが今日の私たちの生活の非常に重要な部分だからこそ、これを学ぶべきだと思います。ソフトウェアはどこにでもあります。明らかに、私たちのポケットや手首にソフトウェアを実行するデバイスがありますが、今日の私たちの車は主にソフトウェアによって定義されており、電気自動車の場合はバッテリーもあります。
私たちの家はソフトウェアに支配されており、旅行はソフトウェアに支配されており、もちろんほとんどの職業生活もそうです。農業や警察のような分野でも、日常業務の多くでソフトウェアを使用しています。
学校で学ぶ数学、物理学、化学、その他すべてのもので、もう二度と使わないものと同様に、でも世界を理解するためにそれらを学んでいます。コンピュータサイエンスを理解し、コードを読む基本的な能力を持ち、ブール論理とバイナリコーディングが何かを知ることは、その後コンピュータサイエンティストになるか、物理学者になるかに関係なく、誰もが学ぶべきスキルだと思います。
学校で音楽を習ったからといって、ステージに上がって歌うべきだということではありません。確かに私にはそれは当てはまりません。でも、それはその授業を受けるべきではないということではありません。
第一に、ソフトウェア、コンピュータ、テクノロジーが次の10年、おそらく次の数百年にわたって大きな役割を果たさないと主張することはできません。
第二に、今日、ここBuildでGitHub Copilotのコーディングエージェントを発表しました。これは魔法的です。なぜなら、タスクや問題、構築したいものの説明を与えると、既存のコードベース、リポジトリを取って、そのコードベースでその問題を実装する方法を理解するからです。ゼロから何かをするだけでなく、多くのそのようなデモを見てきました。私自身もスネークゲームを構築するなどしましたが、実際に既存のコードベースを取り、説明を取って、そのコードベースを変更し、機能を実装するためにコードがどのように変更されるかを示すプルリクエストと呼ばれるものを作成します。
今、エンジニアの役割は、エージェントが行ったことを検証することです。すべての変更を読むことです。もうその理解がなければ、どのようにそれを行うのでしょうか？エージェントが行ったことが実際に私の目標、私のビジネス、顧客が私たちに持っている信頼と一致しているかどうかをどのように検証するのでしょうか？明らかに危険は、エージェントが安全でないコードを作成することです。
セキュリティインシデントが発生し、顧客データを失ったことを報道陣に伝えなければならない状況を想像できます。エージェントが何かをして、非常に高速で作成したため、その瞬間は良い感じがしますが、実際に何をしたかを理解していなかったため、ビジネスに損害を与えてしまいます。
ソフトウェア分野にある、ソフトウェアを作成するすべてのビジネスが、これらのエージェントが構築したものを理解し、最終的に競争優位性を生み出すためにそれらを活用する方法を理解することが基本的だと思います。
コア言語とその動作方法、構文、論理演算子の動作方法を学ぶだけでなく、AI支援部分を学ぶことも同じように重要になったのでしょうか。クラフトを学ぶことですね。
クラフトを持ち、クラフトを進化させなければなりません。ソフトウェア開発で20年間やっていると、20年前にソフトウェアを行った方法と今日ソフトウェアが構築される方法が非常に異なることがわかります。
20年前、オープンソースはまだ多くの企業が疑っていたものでした。セキュリティとコンプライアンス、そしてオープンソースプロジェクトの構築者がもうそのプロジェクトに興味がなくなった時に誰がそれを維持するのか、知的財産について心配していました。
20年後の今日、誰もがスタックでオープンソースを使用しています。オペレーティングシステムからコンテナ管理、オープンソースエディタ、バックエンドからフロントエンドまでの数百、数千のオープンソースライブラリまで。
20年前、私たちにはフルスタックエンジニアのようなものは実際にはありませんでした。データベース、バックエンド、フロントエンド、Windowsアプリケーション開発者には別々の分野がありました。Buildは20年前には構築されていなかったと思います。PDCか何かと呼ばれていたと思います。おそらくWindowsについてもっと多く、今よりもずっと多くのことでした。なぜなら、それが当時はずっと大きな役割を果たしていたからです。
Windows開発者はPCのアーキテクチャとどのくらいのメモリが利用可能か、カーネルにどのようなメソッドがあるかを理解する必要がありました。
今日、ウェブ向けに構築しているほとんどの開発者は、そのハードウェア層に行きません。必要であれば、より大きなVM（仮想マシン）を起動できると仮定しているだけです。
このようにソフトウェア開発は進化しており、開発者は常にクラフトを発展させなければなりません。上達し、次の大きなことを学び、モデルを使用し、モデルを統合し、それらを理解し、テストし、顧客への約束の一部にし、信頼の期待を満たすことは、フルスタックエンジニアのスキルセットの一部です。
もはやフロントエンドとバックエンドだけではありません。フロントエンド、バックエンド、そしてモデルです。そして、それは1つのモデルだけではありません。GitHubとMicrosoftでは、単一のモデルだけがある未来は信じていません。異なる用途のために複数のモデルがあるでしょう。
すでに言及したコード補完、エージェント、低レイテンシの高速モデルでのコード補完。エージェントでは、レイテンシはそれほど重要ではありません。より多くの時間があるからです。エージェントはツールを呼び出します。そのため、モデルには優れたツール呼び出し機能が必要です。
これは続けることができます。同時に複数のモデルを活用するアプリケーションがたくさんあるでしょう。
オープンソース、複数のモデル、また一般的なオープンソースについて言及しました。MicrosoftはSatyaの下でこの10年間、オープンソースの信じられないような移行と採用を行いました。
今日、大きな発表をされました。それを聞いてすぐにツイートしましたが、GitHub Copilotがオープンソースになると。その考えは何でしたか？なぜそうしたのですか？このような強力なオープンソースプロジェクトから何を期待できますか？
今日の発表について本当に興奮しています。VS Code内のCopilotをオープンソースにすることです。これは、オープンソースエディタであるというVS Codeの長い歴史に従っています。
実際、2025年4月、ちょうど先月、VS Codeは10年を迎えました。Satyaが基調講演で言ったように、その10年間で100を超えるVS Codeリリースがあったと思います。つまり、大体月に1回です。チームが新しいリリースを公開しなかった月は数ヶ月しかなかったと思いますが、それは安定版リリースで、実際には毎日VS Code Insiderリリースと呼んでいるものを、少なくとも週末ではなく平日に毎日やっていると思います。
それだけでなく、VS Codeチームは本当にオープンソースプロジェクトのように運営しています。すべての計画を公開で行い、VS Codeリポジトリで来月の計画を示し、リリースノートはすべてリポジトリの一部で、ドキュメントやブログ投稿さえもリポジトリ内のファイルです。
過去数ヶ月でこれを見て、Copilotで十分に進歩したと考えました。元々のオートコンプリートからチャット、音声、エージェントモード、複数モデル選択まで、すべての異なるモデルが利用可能で、無料ティアの提供まで。これは、オープンソース開発を育成したい場合にしばしば重要です。
VS Codeプロジェクトに貢献したい人に、まず20ドルプランのようなものを購入してもらいたくありません。そのため、すべての要素が整ったと感じ、Copilot自体もオープンソースにして、VS Codeプロジェクトに統合し、開発者エコシステムに愛されるものを提供する旅を続けることにしました。
これは、過去10年間VS Codeに取り組み、VS Codeに貢献し、VS Codeチームと製品をサポートしてきた人々を対象としています。
もう一つの部分は、VS Code内のCopilotのクライアントコードが、AI ソフトウェアを構築している他の人々に良い学習を提供するという認識です。VS CodeとCopilotの競合を構築したい場合でも、それを取って自分のお気に入りのIDEに持ち込んで新しいエディタ用のCopilotを構築したい場合でも、または開発者ツールスタック内の完全に異なるものに統合したい場合でもです。
MITライセンスの下でCopilotを取って、それを自分のシステムに統合できることは、私たちのAPI、つまりGitHub APIとMicrosoft APIを使用している間、実際に私たちにビジネス価値を提供します。CopilotはAzure AI Foundryの上に構築されているからです。これは、Copilotの一部を秘密にしておくよりも重要で、それらは結局どこにでもすでに漏れています。
システムプロンプトは知られており、VS CodeはJavaScriptなので、Copilotをリバースエンジニアリングするのは難しくありません。Copilotが公開された2021年の直後から、人々がそれが何をするか、オートコンプリートのためにバックグラウンドでどのようにプロンプトを構築するかを調べたブログ投稿がGitHub Pagesを含めてありました。プロンプトを書くのではなく、ただ書くだけで、カーソルの上のファイル内の情報、カーソルの下、隣接するタブ、システムプロンプトなどの情報を収集するからです。
これらのことは、人々がJavaScript拡張機能をリバースエンジニアリングできるため、私たちがオープンソースにするずっと前からすべて文書化されていました。そのため、それが私たちにとって自然な道筋に感じられ、長い間私たちをサポートしてくれたコミュニティに還元することに本当に興奮しています。
今、彼らは実際にそれをフォークして、Microsoftの完全なサポートを受けてその上に構築することができます。漏れていたり、リバースエンジニアリングされていたりしたとしても、フォークして、プロジェクトに貢献し戻すことができることを期待しています。
絶対に。そして、信頼できるプルリクエストを作成して「ここにこの機能を構築しました。この機能をCopilotに構築しました。Copilotが大好きで、恩返しをしたいからです」と言うことができます。
他の外部開発者が構築するのを見ることで最も興奮していることは何ですか？Microsoftが優先できていない特定の機能セットやワークストリームがありますか？
優先できていないものがありますか？私たちは今年、過去1年間で多くのことを優先したと思います。現在2025年5月で、これを録音していますが、2025年だけでCopilotの変更ログが100近くあると思います。非常に高速で出荷しており、昨年後半のGitHub Universeで複数モデル選択を発表したことに非常に興奮していました。
明らかな例の一つは、Copilotに別のモデルを持ち込むことです。私たちのチームには、新しいモデルを統合し、すべての評価や責任あるAIテスト、レッドチーミングなどを経て、公式にサポートされたモデルをCopilotに追加する時間が限られています。
bring your own keysがあるので、実際にopen routerやllamaなど他のものに接続できます。しかし、これにより開発者は「Copilotを他のモデルで動作させたい。すべてのテストを自分で行い、Azure AI Foundryでモデルをホストすることも決めて、モデル空間自体でのイノベーションを可能にする」と言う機会を得ることができます。
現在大手プレイヤーがいますが、多くのスタートアップも来ています。私たちは技術業界がゼロサムゲームだと信じたいところですが、常に別の破壊が道の先に来るでしょう。これは決して定着した安定状態ではありません。
エージェントモードがどこに向かっているかについて非常に興奮していると思います。今日、JavaおよびNetアプリのアプリ移行を発表しました。これにより、他の多くのプログラミング言語がカバーされないままになり、誰かがCopilotを取って、COBOLからJavaへの移行、PerlからPythonへの移行などを提供するためにエージェントモードを拡張することが考えられます。
世界には解決されていない多くの技術的負債があり、世界にあるすべてのシナリオをカバーすることは不可能です。
第三に、エージェントモードのようなものを見て、それがどのように動作するかを理解し、変更がどのように適用されるかについてより良いアイデアを持つ人がいるかもしれませんし、プロンプトで間違いをした場合に常に1、2ステップロールバックできることを確保する方法についてアイデアを持つ人がいるかもしれません。
開発者がしばしば何かがどのように動作すべきかについて独自のアイデアを持っている、より小さなUX機能がたくさんあると思います。VS Codeプロジェクトで彼らとオープンな会話をし、それをフォークして貢献し戻すか、オープンソースフォークとしてオープンで自分のフォークを実行し続ける能力を与えることです。それがVS Codeの未来にうまくいくことを願っています。
未来の話題を続けましょう。ソフトウェアの未来について話しましょう。決定論的コード、従来のソフトウェアと非決定論的な、生成された部分の境界線が非常に曖昧になってきています。まず、これについてどう思いますか？そして、ソフトウェアアーキテクチャの未来状態はどのようになると思いますか？その境界線はどこに移動するのでしょうか？
コードは設計上、常に決定論的であることを願っています。コード自体はCPUの命令セットの抽象化だからです。しかし、あなたが言っているのは、そのコードを生成するために使用するプロンプトが、同じモデルでも異なるコードを生成する可能性があるということだと思います。モデル自体が非決定論的だからです。
私がこれを想像する方法は、ソフトウェアエンジニアのクラフトの一部が、2つの抽象化レイヤー間をジャンプできるようになることです。自然言語である非決定論的レイヤーと、実際に他のエンジニアや製品マネージャー、デザイナーと対話する時、チーム内の一人が機能がどのように構築されるべきかと考えた方法と、別の人が仕様、GitHub issueなどを取って実際にそれを構築した方法について、常に誤解があります。
1人以上がソフトウェアプロジェクトを構築するとすぐに、非決定論的な結果がありました。3,000人の従業員がいるGitHubのような会社で、CEOとして機能を想像した通りに説明し、3ヶ月後にチームが戻ってきて、私が想像した通りに構築するという世界はありません。それは人間的ではないからです。
人間は独自のアイデアを持っています。私が言うことを取って、既存の計画に変換し、他の顧客フィードバックにマップし、競合研究を行うか、CEOが説明した方法が実際には動作しないことを認識して、他のことをする必要があると気づきます。
モデルとプログラミング言語で作業する時も同じことが起こるでしょう。モデルに何かを説明し、エージェントモードを開始する前にモデルとブレインストーミングするさまざまな方法がすでにあります。たとえば、Claude 3.7 Sonnetにこの機能仕様について作業してもらい、製品マネージャーから得たものを与えて「私のコードベースを見て、これをどのように実装し、使用できるオープンソースライブラリはあるか」と言います。
それはコードを書くのではなく、最初に仕様を書きます。箇条書きのあるMarkdownファイルのようなものです。そして、それを取って「最初の箇条書きと3つのサブ箇条書きを取って、まずその機能を構築するためにエージェントモードに入力する」と言うかもしれません。
それがエンジニアリングの意味です。非常に複雑な問題を取って、それをより小さなブロック、レゴブロックやレゴブロックのグループに分解することです。そして、複雑さのレベルが、モデルがそれを期待通りにより決定論的な方法で実装できるほど低くなった時点で、入って修正する必要がない時点です。
しかし、ここで重要な部分は、エンジニアとして、いつモデルを使うか、いつ自分でやるか、仕様が複雑すぎてモデルがガベージしか作らない時、または「できません。もっと具体的にしてください」や「これがアプローチ方法です」と言うかもしれない時を知る必要があります。そして、モデルが自分ができるよりも速くそれを完了させられる適切なレベルに達した時です。
オペレーティングシステム全体が本質的にオンザフライで生成される未来があると思いますか？それが可能だとしたら、どのようなタイムラインで可能でしょうか？
常に何らかのカーネルがあると思います。CPUの上に座るカーネルです。もうそれを見ることはないかもしれません。もうどのオペレーティングシステムを実行しているかを実際に気にしない世界が起こるのを見ることができます。
技術分野以外の人々にとって、iPhoneのオペレーティングシステムをそれほど気にしないかもしれません。ファイルシステム、ターミナルなどのオペレーティングシステムの多くが、iPhoneではすでに隠されているからです。
ユーザーインターフェースと機能をはるかに気にします。そのように見ると、オペレーティングシステムは隠れ、主要なユーザーインターフェースがエージェント、チャットエージェント、アシスタントである世界を見ることができます。アイアンマンは耳と家にJarvisを持っています。
そのエージェントは、旅行を予約したり、靴を買ったり、寿司を注文したりするために、ツール使用やブラウザ使用を通じてソフトウェアを使用するかもしれません。ユーザーインターフェースをナビゲートする代わりに、「いつものオーダー」と言うと、どこに住んでいるか、どのクレジットカードに請求するか、いつものオーダーが何かを知っていて、魔法のようにドアステップに現れます。
実際にどのようにそれを行うかは見物です。車はドライバーなしで運転できますが、今のところ食べ物を取って階段を上がってベルを鳴らすロボットはありません。
それまでは、階段を下りてボックスから取り出すような、実際には現在持っている便利さよりも不便になるかもしれません。誰かがドアを鳴らして、ドアを開けて食べ物を取るという便利さまで戻るまでです。
その世界を見ることができます。エージェントと対話し、それとより多く対話する世界です。ChatGPTはその旅路にあると思います。中国のWeChatを見ると、日常生活の多くがチャット、人間とのチャット、エージェントとのチャット、小さなミニアプリを通じて組織されています。
これらのミニアプリは、あなたのシナリオのためだけにオンザフライで生成され、旅行を予約してからアプリを捨てるかもしれません。そのため、アプリは、すべてのコードを生成することが非常に安価なため、その一つの問題を解決することを超えて持続的な状態を実際に持たないのです。どこかでサービスとして持つ価値がありません。
ジャストインタイムアプリケーション、ジャストインタイムパーソナライズドアプリケーションです。私のお気に入りの例の一つは、あなたが子供がいると言ったことです。私も子供がいます。小遣いを追跡すること、そして彼らが小遣いアカウントでどのくらい持っているかを見る機会を与えること、それが本当のアカウントかどうかに関係なく、「今週5ドル貯めました。ポケモンパックを買えますか？」と言える能力です。
そのためのサービスを使うことができます。しかし、親としての問題は、自分とパートナーと子供のためにアカウントを作成し、権限を管理し、子供が利用できる機能が実際に見せたいもの、見せたくないものと一致していることを確認する必要があることです。
または、Copilotを使って、あなた、パートナー、子供だけに合わせた独自の小さなマイクロアプリを生成することができます。今週どのくらいの小遣いをもらったかを入力し、彼らはそれから仮想的にお金を引き出して「パパ、このおもちゃやポケモンパックを注文したい」と言うことができます。
私たちが生活を既製のソフトウェアを使用するよりも、パーソナライズされたソフトウェアを中心に組織する世界があると思います。他にも想像できる多くのシナリオがあります。
間違いなく子供と一緒にそれを構築します。それは実際に、彼らにコードの学び方を示すための素晴らしい練習でもあると思います。そこでの魔法は、あなたが時間切れになって仕事に戻らなければならない時でも、彼らが続けることができることです。すべて自然言語で、英語、ドイツ語、中国語などの自然言語なので、子供たちは世界を探索する意欲において本当に素晴らしいと思います。
しばしば、忍耐や日光や答えが尽きるのは親の方です。私がコーディングを学んだ時、両親や家庭の誰もコーディングができなかったので、質問をする場所がありませんでした。本と雑誌があり、インターネットもありませんでした。
今日の世界では、インターネット接続とスマートフォンがある限り、コーディングについて何でもCopilotに質問でき、途中で助けてくれます。フラストレーションがはるかに少なく、画像生成器で子犬の画像をレンダリングできるように、ソフトウェアを進化させることができます。
話題を変えたいと思います。GitHubはコーディングエージェントを発表しました。vibe codingについて聞いたことがあると思います。それがvibe codingのベースレイヤーイネーブラーとしてのコーディングエージェントです。
コーディングエージェントについてどう思いますか？ハンドルから少し手を離し、すべてのコードを見たり理解したりするのではなく、本当にAIと協力して欲しい最終結果を得ることについてどう思いますか？
ハンドルから手を離すことではないと思います。実際、どの時点で車に運転支援システムを作動させるかを決めることです。その比喩を続けたいなら、今日のほとんどの運転システムでは、実際にハンドルに手を置き続けることを強制しています。完璧ではないことを知っているからです。そのため、責任を運転者に保持させます。
現在Waymoが反例ですが、特定の都市でのみ動作します。私たちはエージェントが定義されたスコープ内で完全なアプリケーションを作成できる時点に到達すると思います。コードを見る必要がないかもしれませんが、ほとんどのソフトウェアプロジェクトでは、実際には他の誰かが作成したものに取り組んでいるという事実を考えると、それが基本的に信じられます。
スタートアップでもそれは当てはまります。2人の創設者がいて、最初の6ヶ月で製品の最初の反復を構築したかもしれませんが、その後人を雇うので、新しいエンジニアはその既存のコードベースで作業する必要があり、もうグリーンフィールドから始めてすべてを構築する自由はありません。
1年前に私が書いたコードを見ると恥ずかしいです。当時コードを書いた方法は、この1年間で十分に学んだので、もっと良い方法があることを知っています。5年前や10年前に構築したものを見るとさらにひどいです。
ソフトウェア開発のクラフト、vibe codingはそれを置き換えるのではなく、サポートすると思います。私の観点から、このvibingムーブメントとコーディングエージェントにつながった本当に2つのことがあります。
一つは、エンジニアリングとソフトウェアは特に、常に「アイデアがあり、それを可能な限り速く製品にしたい」ということでした。現実はしばしば「アイデアがあり、研究を始めて、使用できるライブラリや方法を調べます。一日の終わりまでに、実際に朝に想像したことをほとんど何もしていないプロジェクトをかろうじてセットアップしました。しかし、3つのボタンがあり、これを次の3ヶ月間続ければ、アイデアに十分近づけるかもしれません」ということでした。
夢は、このアイデアを持って、どれだけ速くそれを現実にできるかでした。すべての定型文、複雑さ、Pythonインストールが動かない理由などを経ずにです。V codingがそこで大いに役立つと思うのは、アイデアを入力するだけで、何かが得られるからです。
短時間でできることよりもはるかに良く見えることが多く、vibingを続けてプロトタイプを構築し続けることができます。vibe codingは本当にプロトタイプの作成に優れていると思います。
もう一つの側面は、コーディングエージェントが関わってくる場所ですが、実際のソフトウェアプロジェクトでは、まだセキュリティ脆弱性、コード品質、チームが設定した標準、特に予算制約の中にいる場合、より多くのCPUやGPUを燃やすことができないため、効率目標を探す必要があります。
最終的に、すべてのチームは何らかの予算制約の中にいます。タイミングもしばしば異なります。収益性が必要になるまでの時間軸が長いものもあれば、短いものもあります。しかし、ビジネス上の理由でソフトウェアを構築してきました。
そのため、人間の作業者がプルリクエストで行うように、実際にコードを提案する真剣なエージェントが必要で、そのコードをレビューし、コードレビューエージェントを実行し、CI/CDを実行し、すべてのテストが通ることを望みます。
それは、より少ないvibingで、エージェンティックDevOpsと呼ぶものです。やりたくないことをオフロードするエージェントによってサポートされた真剣なソフトウェア開発プロセスを導入することです。
バグの修正、セキュリティ脆弱性の発見、テストケースなど。私のすべての趣味プロジェクトでは、ほとんどテストケースを書きません。コードが完璧だからではなく、テストを書くのは退屈で、アイデアを立ち上げて実行する地点により速く到達できないからです。
ローカルマシンでエージェントモードでvibingしながら、それをエージェントにオフロードすることが夢だと思います。ソフトウェアエンジニアの生活で楽しくないことを異なるエージェントにオフロードしながら、コーディングにより多くの時間を費やせることです。
一度もコードを書いたことがない人たちから連絡を受けています。私のチームの何人かの人たちで、彼らはアプリケーションを構築しています。これらは、生活に価値をもたらす本当のアプリケーションです。しかし、ある時点で、AIエージェントが少し故障し始めるコード行数の閾値があるようです。
より大きなコードベースを本当にvibe codeできるその境目にいるようです。コーディングエージェント、vibe codingエージェント、何と呼んでも構いませんが、最も高いレバレッジの改善は何だと思いますか？
ローコード、ノーコードは長い間存在しています。AIがある前でも、特にIT専門家や消費者でさえも、ウェブページや小さなアプリを構築し、ビジネスロジックを解決することができました。
AIで構築されたのではありません。カスタマイズ可能なテンプレートで構築されました。しかし、アイデアは同じで、そのフレームワーク内でコードの理解なしに、ある程度まで、ある程度の道のりを得て、何かを構築できるということでした。
AIは可能性を驚異的に拡大しました。コードの理解なしに今日AIが生成できることは驚異的です。しかし、多くの人々がエージェントがもう次のステップをできない時点に到達することも知っています。少なくとも、100ユーザーから10,000ユーザーにスケールする方法や、認証を提供できるアイデンティティプロバイダーをどのように導入するかなど、システムがどのようにアーキテクチャされているかについてのシステム理解が必要になります。
エージェントはより強力になりますが、人間としてもさらに複雑なアイデアを持つでしょう。ソフトウェアの構築に興味がある人々は、常に利用可能なツールが単一の問題で実装できるよりもはるかに大きなアイデアを持ち続けると確信しています。
それらのアイデアを拡大してその限界に到達するかどうかは時間の問題です。私が出会ったほぼすべてのソフトウェア会社の現実は、無限のバックログを持っていることです。私も無限のバックログを持っています。文字通り無限ではありませんが、現在利用可能なツールと、私のために働く開発者、製品マネージャー、デザイナーなどで、私の生涯で決してそこに到達しないことを知っているほど長いのです。
その上に、技術的負債、コンプライアンスの問題、データ居住性、アクセシビリティ基準が常に進化しているなど、あらゆる種類のものがあります。常に新しいデバイスと新しいオペレーティングシステムがあり、常に使用している古いオープンソースライブラリがあります。仕事が尽きることはありません。
指をパチンと鳴らすだけでこのコンプライアンスバックログを燃やして「ここに、すべての問題が解決されました」と言える日を夢見ています。その状態に到達できれば、エージェントがソフトウェア開発をとても良くしたと勝利を宣言します。
しかし、それでも実装する必要があるすべてのもののバックログがあり、チームメンバー間でどのようにそれを行うか、製品のどこに着陸するか、機能の名前は何かなどについて議論する必要があります。
エージェントはその旅路で私たちを助け、それらの助けでさらに多くのアイデアが現実に実装されることになると思います。
私は明らかに人工知能の未来について非常に楽観的で、無限の知能を持つ時、人々が置き換えられるのではないと本当に信じています。ソフトウェアエンジニアが置き換えられるのではなく、一日で到達できる数よりもはるかに多くの問題を解決できるようになるでしょう。
プロデューサーのアレックスが言ったように、ソフトウェアエンジニアリングのジェヴォンズのパラドックスのようなものです。より多く構築できるほど、より多く構築するでしょう。
今、多くのフレーバーのAIコーディングを見てきました。GitHubにはコーディングエージェントがあります。タブ補完、VS Codeフォーク、VS Codeプラグイン、完全にハンズオフエージェント、AI支援エージェントを見てきました。
これらすべてのタイプのAI支援コーディングは単一のインタラクションに収束するのでしょうか、それとも常にかなり断片化されていて、用途に最適なツールを選ぶのでしょうか？
両方だと思います。一方で、開発者として、技術業界のメンバーとして、すべてが一つの組織レイヤーでまとまる単一のものがあると考えるのが好きです。現実には、非常に多くのシステム、非常に多くの会社、構築しているもののビジネスインセンティブがあり、すべてを行う単一のエージェントがあることが素晴らしく聞こえるかもしれませんが、現実には常に複数のものがあるでしょう。
車にあるもの、「Hey Mercedes」など。Hey Mercedesが私のGitHub Copilotと同じAIエージェントになる世界は見えません。しかし、これらの異なるAIエージェントを接続できる世界は見えます。
すでにそのためのツールがあります。GitHubでサインインしてOAuthフローを行い、GitHubをJFrog Artifactoryに接続したり、GitHubとVercelを接続して、Next.jsでGitHubリポジトリをVercelクラウドプラットフォームにデプロイしたりできます。開発者空間ではすでにシステム間統合があり、複数のエージェントのエコシステムがある世界を見ることができます。
高校から退職まで、あなたの個人生活の一部であるパーソナライズされたエージェントがあり、取った旅行や撮った写真のすべてを知っており、おそらくスマートフォンと統合されています。すでにその情報の多くを持っているからです。そして、「今夜の夕食に何を食べるべきか」「次にどの本を読むべきか」「見るべきショーは何か」と聞くと推薦してくれます。
そして、あなたの仕事エージェントがあります。雇用主から来るもので、会社の制度的知識とコードベース、GitHubのすべてを持ち、その会社での知識労働者としてのタスクを助けてくれます。
それら2つを接続する世界を見ることができます。その会社で働いている間は1つのインターフェースを持ち、会社を去る時（全員がある時点で会社を去ります）、それらを切断し、仕事の一部だった知識は会社に残り、個人生活の一部だった知識は個人エージェントに残ります。
確かにここには交差点があります。この会話は私の仕事の一部なのか、個人生活の一部なのか。何が会社の知的財産で、何が個人エージェントに残ることができるかを理解するスマートエージェントがおそらくあるでしょう。
そして、旅行エージェントやタスクベースのエージェント、旅行代理店や航空会社から提供される何かを予約してくれるもの、エージェント間プロトコルを通じて個人エージェントや仕事エージェントに入力するものがあるかもしれません。
GoogleにはA2Aがあり、使用できるツールに接続するMCPのような他のものがあります。エージェントエコシステムがあり、すべてが互いに接続することになると思います。最悪の場合、オペレーティングシステムレイヤーで接続し、複数のアプリを使用しますが、理想的にはすべて同じ言語ベースのユーザーインターフェースにあります。
仕事と個人生活と旅行、個人旅行などが、すべての雇用主が考えるほど明確に区別されていないことが多いため、自分でそのコンテキスト切り替えをする必要がないでしょう。
メモリが究極のガバナンス層のようなものとして考えるのは本当に興味深いと思います。メモリのどの部分が会社のもので、どの部分が個人のものかを発見する上位のエージェントがあるかもしれないと言及しました。
この質問をAIリーダーによくするのですが、多くの人がソフトウェア開発だけでなく、知識労働全般の未来について不安を感じています。私は置き換えられるのでしょうか？人工知能のバブルの外にいて不安になっている人々に、どのような安心の言葉をかけますか？
人間が行ってきた作業で、モデルがより自動化された方法で既にできる仕事があると信じています。翻訳はその一例だと思います。特に、同じ言語を話さない2人がいる場合、私たちがエアポッドを入れて、私がドイツ語を話し、あなたが英語を話し、あなたは私が自分の声で英語を話すのを聞き、私はあなたが自分の声でドイツ語を話すのを聞く世界を見ることができます。そうすれば、私たちの間に座って私たちが言うことを翻訳する翻訳者はもう必要ありません。
そのため、より少ない人が必要になるシナリオがあると思います。同時に、AIの助けで発明される全く新しい仕事のグループがあると思います。それは変化し、実際にGitHub Copilotに戻ると、GitHub Copilotはこの惑星の誰でも、望むならソフトウェア開発者になるための非常に大きなスペースを開きます。
もうドキュメンテーションにアクセスしたり、家族でその質問に答えられる誰かがいる必要はありません。特に子供の時、もう英語を話す必要もありません。あなた自身が言ったように、小さなアプリケーションを作成して、プロンプトでそれを反復できます。
20年前には想像できなかった用途にAIを活用する企業がもっと出てくると思います。AIによって置き換えられるため、今日存在しない役割にある人々が、AIの助けでより楽しく、より創造的な何かに再スキルして新しい仕事を見つけるという自信を与えるべきです。
産業革命、パーソナルコンピュータを通じて、それはすでに当てはまっています。自動化された仕事があります。ソフトウェア世界では、ユーザーインターフェーステストがその一例で、Microsoftは実際に専任のテスター役割を持っていました。
エンジニア、製品マネージャー、テスターがいて、テスター役割はなくなりました。誰も一日中手動でソフトウェアをテストしたくないからです。代わりにテストを書いてそれを行います。テスターを置き換えましたが、これらのテスターの多くはエンジニアや製品マネージャーになりました。
それが良い点で、与えることができる自信です。過去を振り返ると、テクノロジーが役割を置き換えた時、私たちはそれらの人々のために新しい機会を見つけました。AIエージェントでも同じことが当てはまると信じています。
トーマスさん、ありがとうございました。これは楽しかったです。
こちらこそ、ありがとうございました。
コメント