Googleの様々な部門のリーダーたちが集結し、AIモデルの最新アップデートとソフトウェア開発の未来について議論したセッションである。Gemini Flashモデルの高速性とエージェント機能の進化、バイブコーディングとエージェントエンジニアリングの違い、さらには将来の開発プロセスにおけるボトルネックや新しいユーザーインターフェースの可能性に至るまで、多角的な視点から深く掘り下げている。
モデルのアップデートとGemini Flashの進化
Googleの様々な部門の方々からアップデートの全体像についてお話を伺えるということで、この対話をとても楽しみにしていました。DeepMind内のモデルチームを率い、これらのモデルの立ち上げの共謀者でもあるタルシー。そして、以前はVertex AIチームとして知られていたGemini Enterprise Agentプラットフォームを率い、モデルを企業顧客全体に提供することに注力しているマイケル。さらに、Antigravityチームを率いるヴァルンです。エキサイティングなアップデートがたくさんありますね。Antigravityは、今日早くにタルシーとも話していましたが、単なるGeminiモデルを超えてGoogleエコシステムをまとめるためのもう一つの導管のようなものでした。話すべき楽しいトピックがたくさんあります。まずはタルシー、モデルの話、特に私たちのこれまでで最高のモデルであるGemini 3 Flashから始めましょうか。
3.5 Flashですね。
3.5 Flash、私たちが出荷した中で最も有能なモデルです。リリースから24時間が経ちましたが、ハイライトや感想を教えてもらえますか。
ええ、皆さんがすでに3.5 Flashを試す機会があったかどうかはわかりませんが。昨日発表したように、そして今ローガンが言ったように、私たちはこのモデルにとても興奮しています。なぜなら、これまでの私たちの最高のモデルだからです。3.1 Proと比較してみると、実際にはほとんどのベンチマークでより優れた結果を出しています。しかし、私たちが本当に興奮しているのは、ツールの使用や、時間のかかるコーディングタスク、あるいは現実世界の金融タスク、さらにはPMとしてのスライド作成や生産性向上タスクなどを見たときに、このモデルがいかに改善されたかという点です。
このモデルは本当に素晴らしいです。パフォーマンスとスピードの非常に良い組み合わせを持っていて、モデルを使って素早く反復しようとする際にそれが本当に活きてくると思います。だからこそ、私たちはとてもワクワクしています。Antigravityに入っているので、APIやAI Studioで試すことができます。
このモデルについてさらに素晴らしいのは、後で詳しく話す開発者の視点から素晴らしいだけでなく、今ではGeminiアプリやAIモードにも搭載されていることです。その素晴らしい基盤と機能を通じて、多くの消費者向け体験を実際に支えています。それを見るのも本当に素晴らしいことでした。
チャットUIからエージェント型ユースケースへの移行
ええ、それは素晴らしいですね。今朝タルシーと話していたときに言われたことが、とても心に響きました。ヴァルン、これについてのあなたの反応を聞くのが楽しみです。知能の最前線を押し広げ続ける中で、Flashモデルを構築する際の緊張感についてのコメントがありました。そして、今日のFlashが意味するものは、1年前や半年前に意味していたものとは実は違うということです。この多くは、人々がモデルをどのように使用しているかというユースケースに基づいています。
かつてはチャットUIのように、単に質問をするだけでした。しかし今では、長時間稼働するエージェント型のユースケースになっています。人々は、裏でGemini Sparkが稼働する24時間365日対応のエージェントを持っています。ヴァルン、あなたの視点から、まずそれに対する反応と、バランスをどのように見つけるかについて非常に興味があります。実際、ソフトウェア開発は興味深いユースケースだと思います。開発者は非常に多くの異なることを行っており、開発者がとる単一の行動にソフトウェア開発を要約するのは難しいからです。
ええ、興味深いですね。私たちがいくつかのFlashモデルを調べ始めたとき、それらは今言われたように、AIオーバービューやAIモードスタイルのチャットのユースケースにずっと近いものでした。あまり思考はしないものの、検索結果をまとめて良い答えを作成できるといった具合です。今私たちが見ているのは、Flashモデルが非常に長い時間、何段階ものステップを踏むことができるようになっていることだと思います。
基調講演で私が話したことの一つは、オペレーティングシステムの構築でした。これはモデルが1万5000回の呼び出しを行ったものです。以前はそんなことはなかったと思います。これは、これらのモデルを押し上げることができた私たちのリサーチチームの証です。実際、Flashモデルでモデルが30秒から40秒も思考するケースを見たことがあります。過去には、そのようなことは全くありませんでした。ですから、モデルが非常に長い時間軸で環境を実際に探索できるという、そのレベルの知能やエージェント機能が、私たちの物事の捉え方を変えたのだと思います。
そして、私たちが内部で見ていたものを外部の人々にも提供したいと思ったエキサイティングなことの一つは、特にAntigravityでのスピードです。Flashはすでに非常に速いと思います。他の最先端モデルよりもはるかに速く、1秒間に200トークン以上という数値を発表しました。しかし、私たちは人々により速い体験を提供したかったのです。これは、モデルがしばらく思考したり、多くのツールを呼び出したりするという事実を相殺するものだと考えています。ですから、これら二つの要素が組み合わさるのを見るのは、とてもエキサイティングな時期です。
エンタープライズにおけるエージェントとスピードのバランス
ええ、素晴らしいですね。マイケル、Cloudチームがこの瞬間を方向付けているように感じるのですが、VertexからGemini Enterprise Agent Platformへと名前を変えたのは、非常に意図的な決定だと思います。これは人々がモデルを使って何を構築しているかという変化を表していると思います。歴史的には、モデルを取り出し、何かの製品に組み込み、チャットスタイルのUIを作るというものでした。Cloud Nextからの発表、そして今回のIOを通じての発表は、この新しいモデルの時代を中心にどのように製品を構築するかということに非常に焦点が当てられていると思います。今後のソフトウェア開発には、それを実現するためにエージェントが必要になるように感じますが、そのあたりをどう考えているか気になります。
ええ、それは良い質問ですね。モデルのトピックについて言えば、私が気づいているのは、私たちがこれらのモデルについてどう考えるかは、ユースケースに大きく依存しているということです。知能のスペクトラムでも、レイテンシのスペクトラムでもありません。むしろ、多くのモデルを使うのには、簡単に説明できる意図的な理由があるのです。Proのようなものは完全に知能に縛られています。最近リリースした最新のFlashのようなものは、知能において最先端です。
ソフトウェアエンジニアがコードを書くとき、彼らはよくそれにJiraのチケットを割り当てます。IDEとやり取りする頻度は減ってきています。設定して、忘れて、後でコードを受け取るのです。そのインタラクションのパターンでは、チャットUIはまさに情報検索の問題になります。エージェントは問題を解決しようと独自に進んでいきます。書かれていないデータが必要だと気づくと、ポップアップして人間にその情報を提供するよう求め、ブロックを解除します。そして企業においては、多くの情報が文書化されていません。私たちの生活においても、当然のことながら誕生日をPostgresデータベースに保存したりはしませんよね。もし誕生日を知る必要があれば、ただ聞いてくるかもしれません。長期間実行されるパターンにおいて、チャットが情報検索として使われることがより重要なのです。
一方で、Verizonの場合のようなFlashの伝統的な使い方では、あるいは最近AIを使って加盟店の返品処理を行うのは非常に一般的ですが、それはポリシーの適用のように見えます。そしてそれは非常にドライなポリシーの適用であり、好きなだけ時間をかけてもいいように聞こえます。しかし実際には、電話の向こうに顧客がいて、返品処理ができるかどうかを確認しようとしています。非常に迅速に行われる必要があります。本当に時間の予算が限られているのです。そのため、250ミリ秒の中でできるだけ賢くならなければなりません。これがポリシーの範囲内かどうかを250ミリ秒以内に判断できなければ、どんな結果であれ顧客を失うことになります。ですから、そのようなエージェント的なユースケースでは、ポリシーが何であるかを調べるサブエージェントがいるかもしれませんが、返品処理を実行するためにはFlashを使用し、ポリシーを誤って適用するリスクを受け入れる意思があるわけです。
そして懐中電灯の側面では、インターネット全体を監視している多くの顧客がいます。名前を出していいかわかりませんが、インターネット規模の製品を持ち、有害なユーザーを抱え、それらをモデレートする必要がある世界最大の企業たちのことを考えてみてください。その場合、または検索でのAIオーバービューの場合、何人の顧客が来るかわかりません。そのため、ビジネスとしては予算が非常に大きく、無限の規模を想定している場合でも、予算を制限する必要があります。無限の規模にわたってどれだけインテリジェントになれるかということです。これら3つはすべて本質的にエージェント的であり、それぞれ異なるインタラクションパターンを意味していますが、私たちはその3つすべてに対応するモデルを持っています。意味は伝わりますか。それが私の言いたいことです。
バイブコーディングとエージェントエンジニアリング
ええ、すごくいいですね。完璧な話のつながりです。いわゆるソフトウェア開発の未来においても、私たちが目にしているものにはスペクトラムがあると思います。そしてそのスペクトラムの一端には、実はアンドレイ・カルパシーの言葉を借りるのですが、彼から聞いた中でこれが最も的確な表現でした。スペクトラムの一端には、このバイブコーディングのユースケースがあります。以前はソフトウェアを構築していなかった人々が、今はソフトウェアを構築しています。
そして、その層向けの制約や要件は、本番システムを構築するためにこれらのツールを使用している人とは実際に異なります。それははるかにエージェントエンジニアリング的なものです。繰り返しますが、そのユースケースに必要な制約のセットやシステムは異なります。モデルの側面でも同じように異なると思います。タルシー、これについてどうバランスをとるのか、バイブコーディングのユースケースとエージェントエンジニアリングのユースケースの間でトレードオフがあるのかどうか、どのように考えているか興味があります。
ええ、すべてのユースケースに共通する基盤のセットがあると思います。モデルには一定レベルの推論能力が必要ですし、ツールを効果的に呼び出せる必要があります。例えばマルチモーダルな入力を理解できたり、高品質で正確なコードを生成できたりする必要があります。バイブコーディングによるWebアプリケーションのユースケースについて話しているのか、レガシーなコードベースについて話しているのかに関わらず、これらはすべて真実です。しかし、これらのユースケース全体を通して、モデルをトレーニングすることを考える際には、モデルにこれらの異なる種類のユースケースを経験させたいと思うはずです。また、これらのタイプのユースケース全体でモデルの品質を評価したいとも思うでしょう。
なぜなら、バイブコーディングによるWebアプリケーションには素晴らしいモデルを構築できる可能性が十分にあるからです。それには一定の推論力があり、生成できる美的洗練さのレベルがあります。しかし、レガシーシステムを与えると、その種のコンテキストの理解がそれほど強くないため、実際にはうまくいかないことがあります。ですから、実際には異なるものが必要になるため、モデルにそのような多様性を持たせて構築する必要があります。
たとえば、何千行、何万行にも及ぶコードベースについて話す場合、そのコンテキストを実際に理解し、それを効果的に使用する能力が非常に重要になりますが、単純なプロンプトからWebアプリへの変換について話す場合には、それはそれほど重要ではないかもしれません。ですから私たちにとって重要なのは、これらの異なるタイプのユースケースを実際に細かく分類し、これらのユースケースを効果的にするためにモデルは何ができる必要があるのかを順を追って確認することです。そして、内部や外部でAntigravityを使用しているユーザー、AI Studioを使用しているユーザー、GeminiアプリでCanvasを使用しているユーザーからの私たち自身の経験をどのように取り入れるかです。モデルをトレーニングする際に、そのフィードバックをすべてどのように反映させるかということです。
プロダクトフライホイールとモデルの共生
ええ、コーラと私は昨日これについてたくさん話しました。ヴァルンでさえ、私たちがチャットしていたときにコメントをくれました。それは、このプロダクトのフライホイールなしに素晴らしいコーディングモデルを実際に構築するのは難しいだろうという趣旨のものでした。それは本当に不可欠な部分であり、今朝ジョシュともこの製品モデルについて話していました。
ハーネスですね。
ハーネスの共生が存在するということです。そしてAntigravityは、これら3つの異なるレベルのほぼすべてで機能していると思います。その共生についてのあなたの反応、同意するかどうか、しかしまた、これら各段階を正しく機能させるための実際の課題についても興味があります。フライホイールを回したいなら、3つすべてが必要だと思います。
ええ、私たちが少し前に始めたとき、ハーネスは多くの面でかなり単純だったと思います。大部分はbashで、いくつかのファイルシステム呼び出しがあり、ユーザーにフィードバックを求めるかもしれないという点で単純でした。しかし、それらは複雑になり始めています。現在Antigravityでは、モデルがネイティブにサブエージェントの作成を要求できます。これらは非同期で実行できます。非同期のツール呼び出しを実行できます。
これは、長時間実行されるものを実行する場合に非常に重要です。研究者がトレーニングジョブを立ち上げたとしましょう。トレーニングジョブが完了するまでエージェントがブロックされ、その間何もできないという状態にしておくわけにはいきません。それと、何かが実行されている間に、ユーザーがメッセージを送信して、モデルが実際に実行していることを上書きしたいと思うかもしれません。これらはすべて、非常に特定の興味深い詳細です。
当然のことながら、もしやっていることが、単なるGitHubのPRのようなSWEベンチスタイルのタスクに見える大量のデータでの事前トレーニングや事後トレーニングだけだとしたら、そのようなレベルの詳細は得られないでしょう。私たちがモデルをその機能を持つように訓練し、またモデルを構築している人々が、モデルの現在のバージョンが異なるハーネスでどのように機能するかを見ることが非常に重要です。そのため、その共生はこの時点で非常に強く感じられています。
ですから、外部の人々が消費しているまさにその製品は、内部の研究者が恩恵を受け、苦労し、積極的に最適化しようとしているものなのです。研究の側では実際にハーネスで強化学習を行っているのだと思います。しかし二次的には、人々がパフォーマンスを実感できるようにもなっています。そのため、研究チームの誰かが、素晴らしいモデルができた、ベンチマークは素晴らしいと言っても、それを製品に組み込んだ途端に、これはあまり良くない、この動作は非常に良いと思っていたけれど、実際にいじってみるとずっと悪い、と言われるような状態には決してなりません。ですから、あなたがおっしゃるようなバイブの側面と、実際のハーネスのトレーニングループの側面の両方において、そのフィードバックループは途方もなく重要なのです。
ええ、ここには確実に、非常に効果的だった共感構築の演習があります。
エージェントの進化と情報のボトルネック
ええ、興味深いスレッドの1つですね。マイケル、私たちが置かれているこの瞬間の緊張の一部は、半年ごとにモデルが大きく変化しているため、製品の構築や製品を使った構築、製品の使用方法を実際に変えなければならないことにあると思います。そして今朝早く話していたことの1つで、マイケル、これに対するあなたの反応に興味があるのですが、モデルが特定のものを食べ続けている傾向があるということです。
スキャフォールディングのレイヤー、ハーネスのレイヤーは、おそらくその1つの例です。将来的には、これらの多くのことを行うようになるかもしれません。モデル自体により多く組み込まれるかもしれません。そしてお聞きしたいのですが、実際に私たちのモデルを使って構築している多くの人々がいると思います。その最前線にとどまる方法、進歩が必然的に続く中で、モデルに逆らって作業しようとするのではなく、モデルと共に確実な進歩を遂げるためのアドバイスや提案があれば教えてください。
ええ、ある時点でのモデルの能力と、モデルがどこに向かうかを予測して、廃れることのない製品を構築しようとすることの間には、明らかな緊張関係があります。なぜなら、通常は今すぐ自分や他人のために製品を構築したいと思うからです。それを待つのは難しいです。しかし同時に、私が言うように、そこには自然な緊張があります。
ですから、去年の2月頃からの会話は、エージェントの構築についてばかりでした。そしてますます、ラボがしていることや私たちがしていることは、CLIでエージェントAPI、エージェントを提供することです。私たちはエージェントを提供し、他のすべての人にツール、コンテキスト、目標を提供するよう提案しています。ハーネスの動作をモデルにトレーニングすることで、ほとんどの人が独自のエージェントを構築して達成できることよりもおそらく優れています。
ですから、会話は過去1、2ヶ月でさえ劇的に変化しました。エージェントを作るのを手伝ってほしい、から、私の目的のためにあなたのエージェントを使うのを手伝ってほしい、へと変わったのです。ですから、その両方が存在し、今後も存在し続けると思います。私たちはそれに対処しなければならないでしょう。モデルやモデルのハーネスを同僚として一緒に扱うというメタファーの多くは、非常に妥当だと私は考えています。
ですから、モデルが十分に賢くないために今日失敗するものをどのように構築するかを考えることと、構築の仕方が間違っていたために今日失敗するものをどう構築するかを考えること。これは非常に大きな違いです。そして、モデルとやり取りしようとしていて、モデルが間違って雇ってしまったパフォーマンスの悪い従業員のように振る舞っているとすれば、それは一つの問題です。
しかし私たちは、モデルとペアを組むことができる将来の期間の観点から考えるべきです。それがSlackであれ、モデルを呼び出すのであれ、モデルと会議をするのであれ、モデルとメールをするのであれです。これらは単なる相互作用です。同じハーネスであるべきです。複製されたとしても、根底にあるのは同じモデルであるべきです。そして私たちは、それをどう使いたいのかを考え抜くべきです。皆さんがより良いモデルで私たちをそこに連れて行ってくれると仮定してですが。
素晴らしいですね。私たちは常により良いモデルを持つことができます。
そしてそれは起こるでしょう。私たちは皆、これをかなり長い間やってきたように感じます。そして、モデルがこれまで以上に速く良くなっているのを目にしています。わかりますよね。私たちはそれが起こることに安全に賭けることができると思います。ですから、それを自明のこととして受け止め、その世界のために構築し、モデルが私たちを成功させるまで失敗すべきなのです。
ええ、実際にタルシー、この点についての質問の一つなのですが、ソフトウェアエンジニアリングの物語の緊張の一部は、ヴァルンもこの点について言及していたと思いますが、エコシステムに存在する実際の評価やベンチマークが、これらの非常に複雑なユースケースでユーザーがしていることを近似することがますます難しくなっているということです。コーディングやソフトウェア開発全般において私たちが今いる流れの中で、それがどのように展開していくと考えているのか興味があります。すべてのタスクにおいてモデルがどれほど優れているかを測定する方法は、それを行うために実際の製品を必要とするようになるのでしょうか。それとも、最近の多くのベンチマーク自体が製品に近づいているように感じます。最近のSWEベンチやその他のベンチマークを行うには、多くのインフラストラクチャを構築する必要があります。そのあたりどうお考えですか。
ええ、おっしゃる通り、私たちの評価がどのように変化しているかにすでにそれが表れていると思います。私たちの評価はより製品体験に近づいています。本質的に複雑なタスクを再現したいのであれば、評価も本質的により複雑である必要があります。これの楽しい外部ベンチマークの例としては、自動販売機ベンチのようなものがあるでしょう。これは文字通り、モデルが機能的な店舗を運営し利益を上げる能力をシミュレートするものです。これは、数日間にわたってモデルがこれをどのように実行できるかを実際に測定する、非常に複雑なベンチマークの例です。
しかしまた、私たちが気づき始めていることの一つは、ヴァルンが言っていたバイブへの共感を築くことや、現実世界のエンジニアリングのユースケースを実際に理解することに関連していますが、ライブ実験や実際のサイドバイサイドのフィードバックにもはるかに傾倒しているということです。そして、これら両方のものが必要になると思います。どちらか一方に頼ることはできないと思います。ベンチマークはより良く、より複雑になる必要があり、多様なユースケースを表現する必要があります。
しかし同時に、モデルをユーザーの手に渡し続ける必要もあります。なぜなら、内部および外部の開発者から得ている多くのフィードバックから私が本当に感じたことの1つは、コーディングの分野でさえ、フィードバックの多くが実際にははるかに定性的で主観的であるということだからです。私たちはコーディングについて、それは非常に検証可能だと考えがちです。正しいか間違っているかのどちらかだと。そして最後に正しいものを得るか、得られないかのどちらかだと。しかし実際には、私たちが得るフィードバックの多くは、これについてはヴァルンがもっと語るべきですが、モデルの動作についてです。コーディング中にモデルが実際にどのようにあなたに話しかけるかということです。
ええ。
モデルの効率性です。モデルの怠惰さや、あるいは出しゃばりすぎるといったことです。これらはすべてベンチマークから推測できることです。しかし、それらが通常の開発者の経験に与える実際の影響は、ライブ実験やフィードバックからしか実際には見ることができないと思います。そしてそれは、フライホイールの非常に重要な部分になっていると思います。
とにかく私が見ていることの1つは、ベンチマークが想定していると思われる人々の使い方というのは、マルチターンの事前入力、デコード、事前入力、デコードというものではないということです。実際には、モデルは独自のソフトウェアを作成し、そのソフトウェアを実行し、戻り値を取得し、それをサンプリングと交互に行って、クラウド内のワークステーション、つまりコンピューターで反復を続けることで、より多くの言語を出力するというようなものです。ですから、それは本当に直線的なものではありません。
直線的ではありませんね。
もう直線的ではないのです。その通りです。
コーディングの進化と次の課題
ヴァルン、面白いことの1つは、エージェント的コーディングがおそらく最初のユースケースであり、そこでは人々がモデルとやり取りするのに非常に長い時間を費やすように感じることです。性格の観点からモデルに関する他の多くのことを見つけ出すための、実は興味深い足がかりになると思います。どれほど熱心か。どのように自慢するのか。自分が行っている大変な仕事を過小評価していないか。私たちがこれらのLEやAntigravityをすべて実行し、製品が開発され続ける中で、そのように感じたかどうか興味があります。
また、これは私たちが持っている筋肉ではないように感じるので、どうやって人々にそれに慣れてもらうかについてもです。今日の非常に多くのAIユースケースでは、何かを質問して、答えが返ってきます。そしてその日の残りの時間を過ごします。画像をリクエストして、画像を受け取ります。そして残りの一日を過ごします。それは深くマルチターンなものではありません。エージェント的コーディングは、おそらくその最も顕著な例外だと感じています。
ええ、コーディング全体が選ばれた理由は、タルシーが最初に言ったことだと思います。一つの視点からは非常に検証可能だからです。コンピューターの前で行う知識労働の他の多くの分野と同様に、これを同じように検証するのはそれほど簡単ではありません。そしてまた、それは非常に長いプロセスです。ですから実際に、モデルの能力をテストしたい場合、これは素晴らしい問題なのです。任意に長くすることができます。フィボナッチ数を書くことから始めて、オペレーティングシステムを構築し、ブラウザを構築し、厳密にはGoogleを構築するところまで進めるかもしれません。何が可能かというスケールがあります。
人々がこれを見る理由は、これが古典的なものだからだと思います。実際、ソフトウェアエンジニアにとっては、彼らは3つのことを行います。まず最初に何を作るかを決めます。どのように作るかを考え、そして作ります。何を作るか、どのように作るかを決めるプロセスだけでも、非常にインタラクティブなプロセスであり、モデルと協力して行う必要があるものです。
そして現時点では、何をする必要があるかの完璧なビジョンがあれば、これらのモデルはすべてそれを完璧に実行できるレベルに達していると言えるでしょう。この機能を使ってこの場所でこのユニットテストを実行してほしいと言えば、驚くほどうまくできます。複雑さは、詳細がぼやけていて埋められていないときに生じます。それにはユーザーとモデルの間の相互作用が必要です。そこで、モデルがユーザーに対して行儀が良いとはどういうことか、という感触を得るわけです。これが、動作などを改善するための非常にホットな領域になった理由です。
ええ、素晴らしいですね。展開を見ていて面白いことの1つは、実はタルシー、あなたがこれに言及したと思います。いや、実は違いました、マイケル、あなたが言及したことですね。進む方向としては、モデルはコーディングにおいて非常に優れてきています。トレンドラインが続くと想定するのは妥当な賭けだと思います。タルシー、あなたとヴァルンが夜も週末も働き続ければ、より良いモデルが手に入るでしょう。それらは良くなり続けるでしょう。
18ヶ月後、モデルが実際に信じられないほど優れ、コーディングが可能な限り解決された時点になったとき、ボトルネックはどこに移動すると思いますか。ボトルネックはどこか別の場所に移動するからです。明らかに、ヴァルン、あなたが指摘したように、今日ソフトウェアを構築する人々が経験する3つの段階のうち、ビジョンとアイデア、そして問題をどのように解決したいかについて実際に実行するという最後の段階が解決された場合、ソフトウェアを作成する能力が非常に速くなるその世界で、ボトルネックはどこになるのか、お三方の見解を聞きたいです。
実際の構築の両方向にボトルネックを押し出すことになると思います。つまり一方で、ほぼ次のように言えるでしょう。あなたは自分のアイデアによって制限されます。何を作りたいかという部分によって制限されるのです。そして実際、この部屋にいる全員、そして私たち全員にとって興味深い機会になるのは、それはほとんどセンスのようなものだということです。解決すべき本当に重要な問題は何かを実際に特定することです。構築が非常に簡単になると、現実の問題でさえない問題のために構築してしまうのが非常に簡単になるからです。今日の早い段階でジョシュがこれをどのように言ったか気に入っています。ユーザーのペインポイントを本当に見つけてください、と。
ええ。
そしてあなたの制限は、本当のペインポイントを見つけているか、そして実際にそれを解決できるかということになると思います。しかし、もう一方の側にも問題があります。そちら側にもボトルネックが生じるでしょう。つまり、製品を作ったからといって、その製品をスケールさせる能力があるのかということです。スケールさせたいユーザー層にスケールさせる能力があるのか。どうやってそれらのユーザーにリーチするのか。理解しやすく、直感的に把握でき、使いやすい方法で製品をどのように設計するのか。そして、それら両方においてボトルネックが発生すると思います。ですから、素晴らしい製品をどう設計するかだけでなく、その製品を実際にどのようにデプロイするかという筋肉の構築を始めることが、ますます重要になっていくでしょう。
素晴らしいですね。
今日、情報検索には非常に明確なボトルネックがあると思います。将来的には、ソフトウェア開発はますます簡単になっていくでしょう。ある時点では、それは問題にすらならなくなるかもしれません。しかし、どんなプロセスも行き詰まります。あらゆるプロセスのブロック要因は通常、何らかの権限を与える必要があるか、プロセスを継続するために取得する必要のある情報があるためです。それは間違いなく真実です。
製品を本番環境に移行することにおいては当てはまらないかもしれませんが、SREエージェントよりもコーディングエージェントを構築する方がはるかに簡単だと言っても、それほど議論を呼ぶことはないと思います。SREエージェントはetcdクラスターの状態を継続的にクエリし、etcdクラスター、というよりKubernetesクラスターの最新の状態に基づいて次のステップと計画を立てる必要があります。しかしソフトウェアでは通常、必要なすべての情報がすでに文書化されており、タスクが与えられれば、そのようなブロッカーにぶつかることなく長期間実行できます。
ですから、ソフトウェア開発には、これらの情報検索のボトルネックを解決することで乗り越えられるものがたくさんあります。コードの作成以外にも、すでにモデルが十分にインテリジェントであるSDLC内の部分はおそらくたくさんあります。そしてその情報検索の問題はすでにボトルネックになっています。ソフトウェアのテストや、ソフトウェアのデプロイ、稼働の維持、安全の維持などです。実際のデータを使ってユニットテストを行うには、データベースへのアクセスが必要になるかもしれない、といった具合です。ですから、モデルが考慮するインテリジェンスとは異なる、エージェントハーネスが考慮するこの非常に現実的な情報検索問題があると思います。両方を一緒に解決することで、私たちは非常に遠くまで行くことができます。
ええ、これについてさらに詳しく聞きたいのですが、興味があります。明らかに、開発者はこれまでRAGやある程度の情報検索を行ってきましたが。
しかし、それはすべて比較可能なデータですよね。繰り返しますが、それは、実際の状況で返品処理ができるかを確認するために顧客とやり取りすることや、銀行のKYCプロセスとは異なります。私が知っている2つの銀行は、Know Your Customerプロセスをモデルで実行しています。つまり、ある非常に裕福な個人を調べて、その人が禁止されている国の誰かと一緒に取締役会に座っていないか、マネーロンダリングのリスクがないかを判断しなければならないだけでなく、私が実際にその人が誰であるかを知っているということです。私は身元調査を行いました。銀行は彼らの身元調査を行っています。
そしてそれは非常に機密性の高いデータです。誰も、誰もいないわけではありませんが。実際、これら2つの銀行は、その非常に機密性の高いデータに対するエージェントの資格情報を付与しています。しかし、そのデータが流出しないと分かっているからこそ、今それを行っているのです。それ以前は、モデルは十分にインテリジェントでした。ある銀行は5月にこれを行い、別の銀行は次の10月に行いました。かなりの道のりです。それはモデルが十分に賢くなったからではありません。銀行がプロセスを実行するための適切なレベルの資格付与という情報検索問題を解決する方法を見つけたからです。わかりますよね。
ええ、よくわかります。それが、実際に最前線の課題の多くが移行している場所のように感じます。どのようにするか。
そしてモデルは良いSQLを書くことができます。さらに先に進んでハルシネーションを起こす代わりに、持っていない情報が必要だと計画して言うことさえできます。しかしそれはソフトウェアの問題であり、多くの点でモデルの問題ではありません。
ええ。
それはまた、ソフトウェアの問題でもあります。これらの多くの場合において、安全性とセキュリティのようなものでもあります。この問題の一部であるこれら他のレイヤーが多数存在します。
100%そうです。ですから、これらが私が直面していると考えているボトルネックです。
ヴァルン？
ええ、私が言おうとしていたのは、人々はどういうわけか、AIによってすでに存在する製品が手に入る、あるいはずっと多くのものを手に入れることになる、その中にはずっと多くのものが含まれるようになる、と信じているということです。私は実際、何を作るか決めることすら非常に難しいと信じています。もし今日良い製品を適当に取り上げても、ただ100個のボタンを追加して、このボタンはXをして、このボタンはYをする、として、ユーザーがそのボタンの機能の合計を得られるとは期待できません。私はそのような見た目の製品をたくさん知っています。名指しはしたくありませんが、そういう見た目のエンタープライズ製品もあります。しかし、それは解決するのが難しい問題だと思います。
ですから、輝くことになるのは、信じられないほど高い主体性を持つ人々になると思います。彼らは難しい判断を下すことができます。これらは非常に難しく、判断が困難です。ユーザーは何百ものことを取り入れることはできません。そしてそれが非常に不足しているものになるでしょう。それこそが、ビルダーが本当に焦点を当てるべきことだと思います。そしてそれが、私たち全員が構築しようとする最も難しいスキルになるでしょう。何を構築すべきか、というのが難しい問題です。
そしてそれは常に難しい問題だったと思います。これまでに一度もなかったことではありません。Googleでも多くのクレイジーなものが構築されてきたと思います。難しい質問は、このインフラストラクチャの一部、このクレイジーなインフラストラクチャの一部がどのように機能するかではありません。私たちにはSpannerがあります。Google Cloudにはこれらすべてのクレイジーなものがあります。実際に構築すべきものは何か、それが難しい問題なのです。
エージェントとの新しいインターフェース
ええ、素晴らしい質問です。人々は何を構築すべきなのでしょうか。もう少し質問したいのですが、オーディエンスとのQ&Aの時間を確実に確保したいと思います。ですから、私たちの素晴らしいパネリストへの質問があれば、準備しておいてください。どこかで誰かがマイクを用意してくれるはずです。非常に強く意識されているもう1つの質問は、エージェントとの関わり方が変わり続ける中で、このインターフェース層が非常に重要になるということです。ヴァルン、あなたはモデルに話しかける様子を見せてくれました。昨日のGoogleドキュメントでも同じように、モデルに話しかけることができました。
明らかに音声はそのパラダイムの1つであるように感じます。他のこととしては、おそらく音声だけかもしれませんが、そのインターフェース層が実際にどのように変化しているのか、そしてそれが、それを駆動するモデルの能力だけでなく、インターフェースをどのように書き換えることができるかにどのように結びついているのかについてのアイデアやコメントはありますか。なぜなら。
どのように再設計するか、ですね。
この新しい時代のために再設計する、ええ。
私は両方を非常に慎重に検討していると思います。ブロックを解除するためにモデルが私たちを中断するように再設計する場合、モデルには機転のセンスが必要です。もしモデルが私たちにピンを送り、私たちが忙しすぎて返信できなかった場合、しつこくするべきかどうかを知っている必要があります。あと3回ピンを送るべきか。それとも1時間待ってから同じ質問をするべきか。あるいは単に、これはこの人にとって重要ではない、と判断するべきか。私の言っている意味がわかりますか。その相互作用を正しく理解するのは非常に難しいでしょう。なぜなら、非常にしつこい営業担当者や非常に迷惑なものから1000回電話がかかってくることなど、誰も望んでいないからです。
もし私たちが完全にエージェント的な世界に移行し、そこではエージェントが同僚であり、彼らに主体性と良い判断力があることを期待するなら、彼らはいつ私たちに助けを求めるべきか、というのは私たちが考えなければならない非常に慎重な問題だと思います。
ええ、それは良い後押しですね。
私は音声が非常に大きくなると本当に信じています。私たちがまだそれを完全に解明していないことは明らかです。明らかに、私はライブ音声文字起こしを非常に素早く使用しています。それはAntigravityにあります。私が使っているものです。他のアプリでも使っていますが、もっとパワフルになる可能性があると感じています。100人のエージェントが走っている世界を想像してみてください。私にはどのエージェントがどれかもわかりません。私は自分のマシンに話しかけ、マシンの側から、稼働しているすべてのエージェント全体で何が起きているかを教えてもらえるようにしたいのです。まだそこまでは到達していませんが、開発中だと確信しています。それは私たちが解明していくでしょう。
これも面白いと思います。これは私たちが今朝していた議論につながります。製品を構築するパラダイムが何千、何万もの製品を生み出すことにつながると考えるか、それとも1つの製品に集約されていくと考えるかということです。このすべてにおいて本当に面白くなると思う質問は、私たちが、この2つの例にあるような、ある種のインターフェースが存在する世界に到達するという暗黙の前提があるかどうかです。おそらく音声で話しかけるかもしれません。あるいは別の何かをするかもしれません。
それが、あなたのために多くのことを実際に行い、戻ってきたり、あるいは積極的に連絡を取ったりできるエージェントの束を生み出すことができるようなインターフェースです。そうなれば、あなたのために20の異なることを行うための20の異なるアプリがあり、XのためにアプリAに行き、YのためにアプリBに行く世界から、世界をもっとシンプルに見ることができる世界へと、興味深いシフトが起こることになります。その世界では、あなたはこのインターフェースを信頼し、完了しなければならない様々なことをこのインターフェースに尋ね、それが実際に自分に合った製品ソリューションを見つけてくれると信頼することになります。それは設計原則におけるかなり大きな転換であり、製品作りにどうアプローチするかにおけるかなり大きな転換になると思います。
メタファーに頼りすぎるつもりはありませんが、繰り返しますが、これが人間の働き方です。人間は、あなたに電話をかけてくるにしても、電話をかけてきてインターフェースが電話であるにしても、チャットをしたいと思っていて非常に正確であなたがすべての文字を読めるにしても、メールをしたいにしても、私たちは互いに対話する多くの方法を持っており、いつそれを行うかについての良い判断力を持っています。電話は常に邪魔をするものです。私はサンダーに電話をかけて、彼が電話に出ることを期待したりはしません。ですから、繰り返しますが、エージェントは人であり、製品です。インタラクションに適切であるよう、エージェントによってインターフェースが選択されるべきです。
将来の魔法の杖：個人的な願い
ええ、では最後の質問をして、その後オーディエンスのQ&Aに移りましょう。もしあなたが魔法の杖を振って、新しいモデルの機能や製品の機能を何でも持つことができるとしたら、皆さんの個人的なウィッシュリストには何がありますか。このセッションの後で、オーディエンスの皆さんからもこの答えをぜひ聞いてみたいのですが。皆さんが魔法の杖を振って修正したり、手に入れたりしたいものはありますか。
非常にランダムで、おそらく幅広い人々にはあまり役立たないものを1つ教えましょう。私はダンサーなのですが、長い間やってみたいと思っていたことの1つは、私たちのモデルを活用して実際に振り付けを手伝ってもらうことです。そして、自動化するのが簡単だろうと思っていた部分でさえ、思ったよりずっと難しかったのです。その理由の一部は非常に単純なことで、ビデオをアップロードしてモデルに有用なことをさせるためには、モデルが非常に速い1秒あたりのフレーム数を消費できなければならないということです。ダンスの動きは非常に速いからです。
ですから、モデルが実際に理解し消費できるものには、文字通りこの物理的な制約があり、その上で実用的な洞察を提供できなければなりません。これは単なるモデルの問題ではないことの一つです。システムの問題でもあります。そして実際にはモデルの問題もあります。振り付けのようなフォーマットでの創造性も非常に難しいものです。例えば叙情性をモデルにどう理解させるか。これはあなたが構築したいと思うであろう非常に具体的なものです。オムニのコンテキストや、Geminiが非常に得意とするマルチモーダル理解のコンテキストで私が考えてきた興味深いことの1つですが、より創造的な空間の1つに行き着くようなものでは実際には難しいのです。
2つの簡単な宣伝ですが、私たちにはDynamic FPSとGemini APIがあります。ですから、スポーツや何かのためにFPSを切り替えたい場合、ゴルフスイングの分析やダンスの分析などを行いたい場合、それは実行可能です。
それは非常に効果的ですね。
それは存在します。非常に効果的です。振り付けベンチも構築すべきですね。これはいいですね。新しい。
新しい計画ですね。
一番ホットな新しいAIベンチマーク、振り付けベンチ。見るのが楽しみです、タルシー。マイケルは？
私のものはそれよりもずっと退屈です。なんというか、テーマ的にはいくらか似ていますが。私は以前、SREエージェントの構築の難しさについて話しました。私はいくつかの仕事の前に、Datadogという会社で働いていました。私は、朝の3時に起こされるお客様のことをよく考えています。ここにいる皆さんもきっと経験があるでしょう。そして、家の中で起きるのは彼らだけではありません。配偶者が目を覚まします。犬が目を覚まします。赤ちゃんが泣き始めます。配偶者は弁護士で朝に大きなクライアントとの会議があるため、彼らを憎みます。すべてがめちゃくちゃになります。これを長く続けると、彼らは離婚してしまいます。わかりますよね。
私は、常にオンコール状態にあるこのソフトウェアエンジニアのことを考えています。そして、ほとんどの時間をほとんどの問題を止めることができ、任意の規模の分散システム、Capital OneやAirbnb規模のものを維持できるエージェントが欲しいと心から思っています。言っている意味がわかりますか。その制限のいくつかは、コンテキストウィンドウをリアルタイムで高フレームレートで満たす能力にあると思います。つまり、途方もなく複雑なシステムに関する情報がストリーミングされる際にそれを押し込み、必要なデータを取得するためのクエリを書くのではなく、それについて推論することにほとんどの時間を費やすということです。クエリと応答というよりも、ストリーミングメカニズムに近いと思います。
ええ。
いずれにせよ、私はその世界をとても楽しみにしています。なぜならそれは完全に可能であり、私たちはそこに到達しつつあり、多くの人々がそれに取り組んでいるからです。だから。
いいですね。ヴァルンは？
ええ、そんなに複雑なことではありません。ただパーソナルトレーナーが欲しかったんです。
ええ。
私はちょっと怠け者なので、私がしていることを見ていて、それを食べてはいけないとか、外に走りに行くべきだとか言ってくれるものがいいですね。
ほら、それは危険ですよ。
待って。
私はむしろ知りたくないですね。
そうですね、おそらく折りたたみ式のスマートグラスでそれが実現するでしょう。
ええ、スマートグラスと。
Gemini Liveを搭載した。
そしてFitbit。
そう、Fitbitですね。非常にワクワクしますね。素晴らしい。
もうすぐそこまで来ていますね。
オーディエンスからのQ&A
オーディエンスからの質問をいくつかお受けしたいと思います。マイクがどこにあるのか、すでに誰かの手にあるのかどうか全くわかりませんが。
はい、オーディエンスの両側に2つのマイクがあります。後ろに並んでいただけます。質問の時間は約8分です。
いいですね。質問がある方は、ご自由にマイクのところまで行ってください。昔ながらのマイクへの歩行をお願いすることになります。
列に並んでください。遠慮なく。
こちら側から始めましょう。
私の質問はヴァルンさんに向けたものです。将来的には、これらのAIエージェントなどとの音声インタラクションが実際にどのようなものになるかについて話されていましたが、開発者とAIエージェントのインタラクションは将来どのようになると思いますか。より視覚的になるでしょうか、それともより音声ベースになるでしょうか。今後数年間のそれに対するあなたの直感はどうですか。
ええ、それについてはチームでよく話し合っています。不思議なものです。情報を入力する最良の方法は何でしょうか。音声は速いと思います。技術的には、クレイジーなこともできます。音声と手と足を使うことができるでしょう。理論的には、最も速く大量の入力を行うために、足でタップし始めることもできます。人々がそれをやりたいと思うかはわかりませんが。おそらくないでしょう。
私を登録してください。登録してください。楽しそうですね。
たぶんすぐに。すぐにね。
ダンスのアクティビティみたいですね。
ええ。
ですから、音声の入力はデータ的な観点から最も魅力的に聞こえます。多くの人は読むのを面倒くさがりますが、読むことは聞くことよりもはるかに速いと思います。ですからある意味では、私が「可能な限り多くのエージェントを立ち上げることができる」という話を持ち出した理由は、物事がその方向に向かっていることが非常に明確だからです。エージェントの実行時間はますます長くなっています。おそらく、バックグラウンドであなたのために多くのエージェントが実行されるようになるでしょう。そして、表面インターフェースに関係なくエージェントと素早く対話できることが、正しい方法のように思えます。
オフィスで働いている場合、全員が同時に話したり叫んだりするのは避けたいという、少し気まずさもあると思います。その部分は解決する必要があります。そしておそらくそれを消費することについてですが、それを消費する最良の方法が何であるかは正確にはわかりません。おそらく実際にはテキストなのかもしれません。よくわかりません。データ入力に関するクレイジーなことの一つは、私たちがオフィスで話していたことですが、スマブラのプレイヤーのことです。大乱闘スマッシュブラザーズをプレイする人たちは、物を動かすのが本当に速いですよね。彼らは話し言葉と同じくらい速い可能性があると思います。ですから、これらのマシンにデータを入力するための新しいフォームファクターが存在する可能性もあります。よくわかりませんが、誰かがこれについて分析すべきだと思います。
はい、ありがとうございます。もう一つお聞きしたかったのは、エージェントを立ち上げたり、オーケストレーションしたりする際に、ジェスチャーが大きな役割を果たすようになると思いますか。たとえばGoogle Watch、Pixel Watch、またはApple Watchを持っているとします。手首のジェスチャーだけでApple WatchやGoogle Watchのエージェントを立ち上げるといったことです。将来的に可能になるでしょうか。
それはクールですね。
ええ。
ええ、それは素晴らしいですね。やるべきです。
ええ。本当に素晴らしいですね。
どうもありがとうございました。
こんにちは、質問があります。テキストプロンプトや音声プロンプトがありますが、より視覚的な人々や、コミュニケーションスキルに欠ける人々はどうなるのでしょうか。AIはそれらの障壁をどのように乗り越えるのでしょうか。他の人間となら手振りをはじめ色々なものが使えます。でもテキストや音声のスキルを持たない人がいるかもしれません。AIはどうやってそれらの壁を乗り越えるのでしょうか。
良い質問です。ビデオと画像は興味深いものだと思います。素晴らしいことの1つは、何かを描き出すことができれば、物理的にそれを表現できたとしても、モデルが画像や音声をネイティブに理解できることだと思います。このダンスの例に戻りますが、完璧な方法でなくても何かを表現しようとする際のあなたの声の抑揚を微妙に拾い上げるという点について、今日早く話していました。これらはすべてモデルがネイティブに実行できることだと思います。そしてそれは非常に興味深いことです。ええ、おそらく新しいフォームファクターが必要であり、それはジェスチャーなのかもしれませんし、あるいは。
既存のフォームファクターでさえそうです。先日仕事で誰かと一緒に作業をしていたのですが、どれだけ言葉を尽くして説明しても、画面のどこにカーソルを移動させるかを説明するよりも、ただ指を指す方がはるかに簡単なのです。わかりますよね。そして、多くの入力は画面をタップしたり、何かを投げ縄で囲んだり、意味するものをただジェスチャーで示したりするようなものになると思います。それが相互作用の種類になるでしょう。
ユースケースや個人のスタイルにもよるでしょうね。
ええ。
私の場合、話しながら考えるタイプです。一般的に非常に言葉によるコミュニケーターだと自覚しています。ですから、そのフォームファクターを好みます。私は音声を好みます。でも私の妹のような人にとっては、何かを書き出したり、描いたり、物を動かしたりする時間があるフォームファクターの方がずっと良いと思います。彼女ははるかに視覚的なコミュニケーターであり、視覚的な学習者なのです。ですから、彼女にとってはそちらの方がずっと良いフォームファクターになります。
ですから実際に私たちが構築し設計する必要があるのは、あなたが誰であり、どのようにコミュニケーションし、どのように関与するかに対して柔軟に対応できるインターフェースだと思います。それについてはもっとたくさんのことがあります。パーソナライズされた学習については長い間多く語られてきましたが、パーソナライズされた創造というのもおそらくあると思います。そして、その両方が効果的だと私は考えています。
ええ、面白い事実なんですが、Googleでの私の新しい20%プロジェクトは、実際に今タルシーのツイートをゴーストライトすることなんです。彼女が私に口述し、私はそれを書き留めます。彼女はとても音声重視で、私は書くことができるからです。
というわけで皆さん、楽しみにしていてくださいね。素晴らしいことになりますよ。
ですから、時には実際に。
あなたのツイートは全部ただのGeminiなんですね。
ええ。
冗談半分のコメントですが、実際に時々、ループの中にもう一人人間がいることがあります。もちろんAIシステムは非常に役立ちますが、時には友人や一緒に働いている人に手伝ってもらうこともできます。
どこでローガンを見つけたの？
手伝ってもらうわけです。質問ありがとうございました。
ありがとうございます。
あと1つか2つの質問を受ける時間があると思います。
わかりました。私にとって最大のボトルネックの1つはスピードです。しかし、悪いコードを書いたときのペナルティは時として非常に大きくなります。ですから一般的に、最高のモデルを実行したいと思うわけです。非常に速くて99.9%の確率で十分なモデルがあり、スピードのために最適化するだけでよく、最後に物事を現実確認するためだけの大きなモデルを1つ持っているというようなスケールにおいて、今私たちはどのあたりにいると感じていますか。
私たちは本当にこのアイデアを信じていると思います。正直なところ、Antigravityにある素晴らしいことの1つは、サブエージェントがあることです。しかし実際には、メインエージェントであるモデルが、サブエージェントのモデルを実際に選択することができます。ですから、チップの数が無制限ではない世界にいることを考えれば、大きなモデルが小さなモデルに委任できる世界を完全に想像することができます。
現時点では、私たちは純粋に能力よりもすべてをどのように節約するかに最適化している段階ではありません。あなたがおっしゃったようなものだからです。おそらく多くのワークロードにおいて、可能な限り小さなモデルだけを実行したいとは思わないでしょう。小さなモデルに調べさせて、時々どうしたんだ、となるよりも、ヒット率がはるかに高い方が良いと思うはずです。しかし100%、これが進むべき方向性です。より大きなモデルがより小さなモデルに大多数の作業を委任する世界を見るようになると思います。
ありがとうございます。
ええ、トークンも大幅に節約できるでしょう。では最後の質問です。
皆さんこんにちは、私はカーティクと言います。私たちがソフトウェアを開発しテストする方法に関してですが、AIスロップを避けるために皆さんが推奨するフレームワークやステップはありますか。例えば、全く新しい製品を構築し、その後新しい機能を追加したい場合、既存の機能を壊したくありません。そのすべてを避ける方法はありますか。単なるユニットテストと統合テストでしょうか。それとも全体像を見落としているもっと何かがあるのでしょうか。
今のところ、私たちはAntigravityを構築する際にこれについて非常に深く考えていると思います。どうやってAntigravityにそれ自身を構築させるのか。プロジェクトの初期段階で少し注意を払う必要があると思います。例えば、アプリケーションを構築しているとしましょう。私なら実際に、アプリケーションの最初の段階から、エージェント自身がアプリケーションをスピンアップし、アプリのボタンをクリックできるようにし、このようなスムーズな統合テストを行えるようにします。そして想像してみてください。
対話の段階でですね。
面白いですね。
クラフトと創造性についてです。
まるで空港のトイレにいるみたいですね。いや、つまりアイデアとしては、エージェント自身があなたのアプリをテストできるようにするということです。そしてこれをかなり高品質なテストに変換できます。それを実行し、クリックしたものの完全なPlaywrightのコードを生成し、後でオフラインでそれを実行することを想像してみてください。そうすれば、これらの生成的テストを後でより堅牢なテストに変換できます。ですから、エージェントが物事を非常に迅速にテストできるという新しいパラダイムが今あると思います。それを最大限に活用すべきです。
既存の製品についてはどうですか。既存の製品については？もし私が持っていたら、あ、すみません。
ええ、既存の製品の各部分を再構築する必要があると思います。それには多くの作業が必要になるでしょう。ゼロから1にする時の方がずっと良いです。
1つの簡単なポイントを繰り返すだけですが、これは、エージェントエンジニアリングの分野がバイブコーディングとは異なるという先ほどの会話に戻ると思います。そして、エージェントエンジニアリングのためのフレームワークは、ユーザーがいなくて何も壊れる心配をする必要がない自分自身の個人的なプロジェクトをただ勢いでやっている場合とは、見た目が異なると思います。フレームワークは実際には違って見えると思います。私たちエコシステムは、これをどのように構築し、これについてどのように話すかにおいて、それを実際に具体化する必要があると思います。質問ありがとうございました。
ヴァルン、マイケル、タルシー、席についてこれをやってくれてありがとうございました。素晴らしい対話でした。彼らに大きな拍手を送ってください。そして、ありがとうございました。皆さん、ありがとう。
ええ、皆さんありがとう。
コメント