エージェント コーディング: 業界リーダーとのラウンドテーブル

こんにちは

この 2 日間、Android チームの多くの Google 社員から話を聞いてきました。

そこで、Android デベロッパー コミュニティの外部の方々からお話を伺い、カンファレンスを締めくくるのがよいと考えました。

今回は、エージェント コーディングと、それが現実世界に与える影響についてお話しします。

まずは自己紹介から始めましょう。

Android DevRel の Ben です。

このカンファレンスですでに私の話を聞いたことがあると思いますが、パネルを始めましょう。

皆さん、こんにちは。

Databricks で AI ツール関連の取り組みをサポートしている Vinay と申します。

お招きいただきありがとうございます。

こんにちは、Luis Artola です。

Google マップで働いています。

私は、AI を使用してエージェント エクスペリエンスを構築し、ソフトウェア開発サイクルを改善するチームを率いています。

こんにちは。Annyce Davis です。

私はフォードに勤務しています。

私は、サブスクリプションとポイント プログラムのプロダクトを開発するエンジニアリング チームを率いています。

皆さん、こんにちは。

Ty Smith です。

私は Uber でデベロッパーをサポートしています。

モバイルはかなり長い間、その役割を担ってきました。

ここ数年は、AI ツールがもたらす新しいエキサイティングな時代に大きな注目が集まっています。

皆さん、こんにちは。

Kaushik Gopal です。

私は Instacart でプリンシパル エンジニアとして働いており、Android デベロッパー向けの Fragmented というポッドキャストを始めました。

最近は、Ty が言ったように、戦略を少し変更して、AI 開発について話しています。

それでは

30 分あります。

あっという間に時間が過ぎてしまうと思うので、さっそく核心に迫る質問に入りましょう。

Android DevRel では、アプリをより迅速かつ簡単に構築できるようにしたいと常に考えてきました。

今や AI が登場し、私たちは「確かにそうだ。

アプリの構築がより迅速かつ簡単になると考えています。」

しかし、ここで疑問を投げかけたいと思います。私たちは実際にアプリをより速くリリースしているのでしょうか、それとも、どこにも行き着かないようなコードを大量に生成しているだけなのでしょうか。

Vinay さん、お願いします。

違いますね。

そう、みんなお互いを見ている。

すばらしい

純粋な数字だけを見ると、PR やコード行数という点での出力が大幅に加速していることがわかります。その結果、コードの保存場所などに関しても、スケーリングの課題に直面しています。

この加速は非常に現実的なものです。

明らかでないのは、それが成果にどのように影響するかということです。業界全体が、成果に関する適切な指標とは何か、それが収益にどのように影響するかを把握しようとしていると思います。

しかし、実際に使われているのを目にすることはあります。

過去 6 か月間にリリースしたコードは、それ以前の非常に長い期間にリリースしたコードよりも多かったと思います。

その結果、生産性の測定方法に関する戦略も変わったと思います。

これについてはさまざまな考え方があります。

中央値を上げる方法を考えているわけですよね？

外れ値と中央値を見ると、この 2 つのカテゴリの人々の間には 5 倍から 10 倍の差があります。私たちの焦点は、下限を引き上げ、中央値を引き上げ、それらの人々を、私たちが生産性が高いと見なしている周囲の同僚と同じくらい生産的にすることです。

ロールの組み合わせが表示されます。

一部の企業は、はるかに速いスピードで移行を進めています。

1 日に 100 件の PR を処理する人もいて、素晴らしい仕事をしています。

しかし、これは彼らが活動している空間の一種です。

これは、よりグリーンフィールドな場合や、ツールに精通している場合です。

また、ブラウンフィールドやプラットフォームの作業に携わっている人々は、人間の判断に時間をかけ、問題が発生しないようにする必要があるため、それほど加速されていない別の種類の作業をサポートしています。

この 2 つの組み合わせにより、以前よりも大幅に高速化されています。しかし、私たちにとって本当に興味深いトピックは、私たちがより多くのものを出荷しているにもかかわらず、ビジネスは実際にエンドユーザーにより多くのものを出荷しているのかということです。

これは、Google が昨年から投資してきた分野であり、コードのリリースを速めるだけでなく、機能のリリースを速めることができているかどうかを把握するためのものです。

初期の兆候は、私たちがそうであることを示していますが、それは単なる純粋な PR とはまったく異なるものです。

何が起きているかというと、明らかに、人々は PR の数、つまりカウントが増加しているようなものを出荷しています。

しかし、リアルタイムでも多くの考え方は、「AI と私たちが持っているこのツールをどのように活用して、既存のプロセスを強化するか」というようなものです。

必要があります

以前のコードのリリース方法の多くは、本番環境までずっとコードを導く人間のような存在を常に想定していたように感じます。

しかし、現在目にしているのは、そうした手法が有効であるということです。

出荷数が増加しています。

しかし、以前の世界では見られなかったあらゆるボトルネックに直面しています。

以前はこのような問題に直面したことはありませんでしたが、今では、複数のステップからなるサイクルの 1 つをターボチャージしているようなもので、そこが面白いところだと思います。

より多くの効果を提供していますが、今では効果が大量に押し寄せています。」

そのため、他の課題に直面しています。

これは非常に興味深い点です。なぜなら、さまざまなステップがあるものの、大まかに見ると、3 つのステージに分類できるからです。

コーディングは明らかに加速しています。

製品版の公開に向けた準備状況には、法律やプライバシーなど、何かをリリースできるようにするためのさまざまな要素が含まれます。そして、リリースがあります。

また、配送は地域によって意味が異なります。

完全にサーバーサイドのプロダクトであれば、リリースはより合理化されたプロセスを意味するでしょう。一方、コンシューマー向けのプロダクトをリリースする場合、テスト段階はプロセスの途中にすぎません。

それでも、多くのテストと測定を行う必要があります。これは、あなたが言っていたことに関連しています。つまり、大都市圏の高速道路にいて、渋滞に巻き込まれた後、加速し始めると、「よし、いいぞ。

「すごく速い」と感じるかもしれませんが、次のチョークポイントにぶつかります。

AI が非常に明確にしているのは、摩擦点がより明確に見えるようになっていることです。その中には、コーディングやテクノロジーとは関係のないものもあります。

プロセスや人間、そして AI を使ってそれらを最適化する方法に関係しています。

エンドツーエンドを効率化する方法については、非常に興味深い課題があります。

この分野について、私たちが少し考えている興味深い方法の 1 つは、個人またはチームが完全にリリースするにあたって、どの程度のエージェンシーを持っているかということです。

社内を見渡すと、内部ツールを構築しているチームや、お客様に提供しないものを構築しているチームが多数あります。

出荷が大幅にスピードアップしています。

代理店は、その情報をすぐに顧客に提供する全権限を持っています。

外部プロダクトの場合、ユーザーによるテスト、アプリストアでのロールアウト、デザインやプロダクトとの連携など、さまざまなボトルネックが重なり、コードを作成する人が迅速に動くことが難しくなります。

そのため、システム内の他のボトルネックにぶつかっているだけです。

そのため、これらを 2 つの異なる領域に分割することで、ビジネス プロセスの改善点を明確にできると思います。

そうですね。エンジニアリングがボトルネックになったことは一度もありません。

私は何年も前からこのことを言い続けています。

エンジニアリングには、非常に厳格なやり方があります。ビジネス側からは常に「何が問題なのか」と問われていました。

10 種類の異なる回答が得られます。

そして「わかった。

では、これをプロダクトを使用したソリューションに変換してみましょう。

この点について、少し考えてみましょう。

デザインについて少し話しましょう。

あっちに蹴って。」

エンジニアリングに移行する段階では、やるべきことがほぼ明確になっています。

そして、Stack Overflow にアクセスして、いくつかのものをコピーして貼り付け、そのものを出荷しようとします。

AI を活用することで、コンプライアンス業務のスピードアップが最も顕著に現れています。

XYZ をモダナイズしたい、Spring Boot のバージョンを迅速にアップグレードしたい、といった要望は常にありました。

そのスピードは非常に速いです。

しかし、実際の機能提供については、大幅な改善が見られたとは言えません。

皆さんのお話から、ボトルネックが移動した可能性があることがわかりました。以前はボトルネックではなかったプロセスが、現在はボトルネックになっているようです。

ただし、それらのプロセスは、過去の苦い経験から生まれたものかもしれません。

そこで、それらの変更を迫られていると感じていますか。最も明白なのはコードレビューだと思います。

コードレビューの未来はどうなると思いますか？

現在の取り組み

ぜひお聞かせください。

これは、先ほど私が述べたポイントに戻ります。

このようなボトルネックの多くは、私たちが次のように考えていたからだと思います。たとえば、魔法の杖があって、ソフトウェア エンジニアリングを再発明できるとしたら、そして、今日 AI があるとしたら、私たちは同じことをたくさんするでしょうか？同じことをするでしょうか？

たとえば、コードレビューは、人間が最終的なクロスチェックを行うために必要でした。

それも変わってきていると思います。たとえば、コードレビューについて、名前のリファクタリングやコードのリファクタリングを行う場合、優れたテストがあることがわかっているなら、そのアイデアを受け入れるべきかもしれません。

AI に書いてもらったから大丈夫。

いいえ、たとえば、そのエージェントよりもずっと良い仕事ができるかどうか、などです。

そうですね。その確認に時間をかけないようにする、とか。

また、バグをリリースして、CEO から「このバグのせいで X ドルの損失が出ている」という電話がかかってきた場合は、「これは重要な領域だ。

これは重要な領域ではない」と自分に言い聞かせ、もう一度想像してみましょう。

現在の運用方法とは異なると思います。

現在は「PR がある。

私はエンジニアです。

このことに集中しています。

上昇する。

深夜に Vinay にコードレビューを依頼することもあります。このコードをマージしたいからです。」

それに対して、それらの多くを再考する必要があるかもしれません。

まったく同感です。私はコードレビューを検証の問題と考えています。つまり、何かを検証する能力に完全な自信がある世界でも、私は PR の 100% をコードレビューするでしょうか？

おそらく、そうではないでしょう。

コードレビューには 2 つの目的があります。

1 つは、私たちが正しいことを行っていることを確認すること、もう 1 つは教育です。

たとえば、周囲の人々があなたの行動を把握し、その決定に同意するかどうかなどです。

そのため、コードやリリースに確実に反映されるように、安心して加速できる作業のカテゴリが確実に存在します。

これは 100% のケースに当てはまるわけではないかもしれませんが、非常に高い、2 桁の数字に当てはまると思います。

そして、私たちはそうした変化に備える準備ができていると思います。コミュニティとして、私たちは全員、システムがその変化に備えていることを確認する必要があります。なぜなら、変化は近づいているからです。

避けて通ることはできません。

ファネルの上部は非常に広く、さまざまなサーフェスがあるため、より多くの PR を作成できます。

そして、プロセスの最も遅いステップと同じ速度になります。

多くのチームにとって、それはコードレビューです。より迅速に開発を進めているチームは、この現実を理解し、受け入れています。

そうですね。正直に言うと、私が見た PR の 70% は問題ないように見えます。

たとえば、世界中のすべてのコードベースを検索すると、PR コメントは「問題ありません」（LGTM）ばかりになるでしょう。

エンジニアリングの専門家として、私たちは時として、自分たちを過大評価してしまうことがあります。

本当にその場にいるような感覚になります。

「コマンドパターンを使用しているか？」

「わかった。

うん、いいと思う。」

では、なぜエージェントにそれをさせることができないのでしょうか。

「Looks Good To Me」とはどのようなものか、どのような特性や行動がそう感じさせるのか、といったことが見えてくる未来がやってくると思います。

そして、エージェントが同じものを探すようにします。

逆に、さまざまなレビュー方法を考えることもできます。

最近の Twitter で、こういうことを言っている人がいますよね。

たとえば、PR を検証するときに、エージェントに別の方法で可視化してもらうなどです。

以前の様子を見せて。

アフターを見せて。

コードを 1 行ずつ確認するのではなく、作成したテストを見せてください。

しかし、それは挑戦です。ルイス、何か言おうとしていましたか？

いいえ、考えさせられることだと思います。

このようにして、人間の介入なしで CL や PR を処理することに本当に安心できる段階に到達します。

少しあえて反対の立場から言わせてもらうと、フリクションについて話すとき、フリクションは悪いものと考えがちですが、良いフリクションと悪いフリクションがあると思います。

レビューは、今でも「良い摩擦」のカテゴリに属していると思います。

開発者の負担をいかに軽減するかが重要です。

また、その時点でのレビューをより良く、より効率的に行う方法を考えるだけでは不十分な場合もあります。

AI を使って開発の上流工程をより正確にするにはどうすればよいか、ということですね。

AI の使い方によって、良い入力は良い出力を生み出し、悪い入力は本当にひどい出力を生み出すからです。

つまり、その魅力的な最終状態に到達するには、最初から AI を使用してプロセスを全体的に改善する必要があると思います。AI を使用してアーキテクチャをより深く理解し、開発者の労力を軽減しながら、非常に堅牢な仕様を作成することで、生成されるコードの品質が向上します。

そのため、審査はデベロッパーにとって負担が少ないものになっています。

この最終的な状態は、それほど議論の余地がないと思います。ほとんどの人は、このコードが最終的に人間によるレビューなしでリリースされると考えています。

その間、モデルが改善され、技術的なミスを犯す心配は減り、ビジネス上のミスを犯す心配や、判断やアイディエーションに問題がある心配が増えるという、進化する状況にあります。

そのため、審査段階でそれらを分離する必要があるシグナルにも含まれます。

たとえば、PR で 1 行ずつレビューするべきなのか、それとも、後でプッシュしようとしている意図をレビューするべきなのか、といったことです。

これについては、いくつかの異なる方法で考えています。

1 つ目は、ユーザーが優先順位を付けられるように、より関連性の高い情報をユーザーに提供する方法です。

もう 1 つは、このようなプログラムで、より安全に実験を行い、より迅速に移行できる領域はどこかということです。

Kaushik が言ったように、すべての領域で同じレベルの厳密さが必要なわけではありません。

これを特定して、一部のリリースを迅速化し、リスクを軽減しながら、コンプライアンス重視の領域や、非常に基礎的な領域では、モデルだけでなく、入力されるデータも信頼できる段階に達するまで、より高い摩擦を維持することができます。

正しい判断だった。

Uber アプリで新しい Android モジュールをリファクタリングする場合など、問題ない場合もあります。

すべての Android デベロッパーに無料乗車を提供しているため、コードを確認することをおすすめします。

CEO に確認する必要があります。

申し訳ありません、Kaushik。

しかし、これは解決済みの問題でもあると思います。

すでにフィーチャー トグルなどがあります。

すでに Blue/Green デプロイを使用しています。

すでに多くの要素が揃っています。

課題は、忙しすぎて実際に取り組むことができないことです。

すでに行動トラッキングを導入しています。

このようなデータはすべて揃っていますが、すべて異なるシステムに保存されています。

インシデントはすでに追跡しています。

データはたくさんありますが、それらを 1 つの包括的なトレースにまとめることができていません。

このようなエンジニアリング コンテキスト サービスが、さまざまな企業でどのように機能するかを最終的に把握できれば、PR がマージされるだけでも安全であるため、心配する必要はなくなります。

フィーチャー トグルの背後にあることがわかっているからです。

Blue/Green デプロイ。

すべてのオブザーバビリティが整っています。

そして、「パイプラインに入れて」と自信を持って言えるようになります。

何か悪いことが起こった場合、その過程にすべてのガードとゲートがあります。

対応のスピードも非常に重要だと思います。

たとえば、Android で変更をリリースする場合、Google Play ストア経由でリリースしてからユーザーにロールアウトする必要があります。この場合、すぐにホットフィックスを適用する能力は、内部デプロイ、内部オブザーバビリティ、エージェントをすぐに適用できる場合と比較して、大幅に制限されます。

そこで、皆さんに質問したいことがあります。これらのアプリで作業が必要になるという問題もありますが、より簡単なグリーンフィールド アプリもあります。また、ブラウンフィールド アプリもあります。そして、AI の使用を拡大するために、これらのチェックの多くを導入する時間が必要になる瞬間があります。

皆さんの多くは、大規模なアプリを開発していると思います。

この点について、どのようにお考えでしょうか。

「CEO、3 か月ください。このアプリを AI 対応にします」というような感じでしょうか。それとも、毎日追加していくような感じでしょうか。

うん

いずれにせよ、そのようなことはありません。

ないでしょうね。

ほとんどの企業には、そのような余裕はありません。

技術的負債と同じように、時間の 20% をこれに充て、そのうちの 5% をプロンプトの改善に充てる、というように、同じように取り組む必要があると思います。

さらに、プロンプトの動作を理解し、コンテキストを改善します。

これまでお話ししてきたように、エンジニアが仕組みを理解していないことが大きな要因だと思います。

まだ魔法のような神秘的なものに感じられるため、価値や効率を最大限に高めるような構成やチューニングは行われていません。

そのため、リーダーは「チームのレベルを上げて、この仕組みを理解し、より多くの成果を得るにはどうすればよいか」を考える必要があると思います。

また、その継続でもあります。

変化が非常に速いため、たとえば、チームに 1 週間かけて最新かつ最高の技術を学び、それを実践するよう依頼したとします。その後、チームに学習や実験を続ける時間がなく、翌年に確認したとしたら、新しい機能から大幅に遅れていることになります。

そのため、私たちは飛行機を操縦しながら組み立てているようなもので、ガードレールを設置し、学習し、状況に応じて調整しています。チームは常にこの状況を把握しておく必要があります。

大規模な組織では、Google のチームのように、そうした情報を抽出して、より関連性が高く、理解しやすいものにしようとするチームがあります。

しかし、これは現在、業界のすべての企業にとっての課題です。

少し変化をつけたいと思います。

デベロッパー インフラストラクチャのような分野で働いている人が多いと思います。

何千もの PR があると、テスト インフラストラクチャやサーバーがすべてダウンしてしまうのではないでしょうか？

ぜひ、苦労話を聞かせてください。

Ty？

はい。

燃えている。

私の CI は毎晩泣いて、泣いて、泣いて、泣きながら眠りにつきます。

現在、Google のデベロッパー インフラストラクチャ チームのほぼすべてが、コンピューティングのスケーリングの問題と効率性の問題に取り組んでいます。

コードレッドが発令されています。

この膨大な量の増加が見られます。

エージェントを使用してアーキテクチャの変更を行っています。

Bazel を使用したリモートビルドの実行とキャッシュをできるだけ早く拡張しようとしています。たとえば、メインのすべてを常にグリーンにする必要があるのか、特定の領域でエージェントを使用してフォワード フィックスを開始できるのか、エンジニアからの流入量を確認し、自己修復 CI やフィードバック ループの短縮などを試みています。すべてのチームが、一定レベルの効率を維持しながら成長に追いつくために、これらすべてに積極的に投資しています。

しかし、これは非常に困難な作業です。

Ty の意見に全面的に同意します。また、この状況は、今後 10 倍の規模に成長する準備ができているかどうかを、真剣に考えるきっかけにもなっています。

ほとんどの人にとって、答えはおそらく「いいえ」です。

その結果、将来を考えるにあたって、Google はインフラストラクチャがサポートできる規模に意図的に野心を合わせようとしています。

AI がもたらしたことの一つは、私たち全員をより野心的にしたことです。私たちはすでに有意義な飛躍を目の当たりにしているため、正直なところ、システムを再考しています。

そうですね。他にどのシステムが壊れるか、または壊れると予想されるか、そして、不意打ちを食らわないようにするために、先手を打つにはどうすればよいかを考えています。

実際には、予期せぬ事態を回避しようとしています。

そうですね。自分たちがコントロールしていると感じている限り、誰もが満足しています。

予期せぬ事態が発生した瞬間、それは誰にとっても悪いニュースであることがわかります。

必要があります

そのため、このタイミングで振り返り、監査を行い、次に何が壊れるかを把握することが重要です。

これは避けられないことです。

私たちは、この問題に先手を打ちたいと考えています。

Inflow の CEO から興味深い言葉を聞きました。

彼女は、Google が現在の数十億行のコードに到達するまでに 20 年ほどかかったことを説明していました。そして、この加速により、多くの企業が AI の加速に基づいて、わずか数年で同様の規模に到達することになるでしょう。

また、すべての企業が開発用に Google レベルのインフラストラクチャを導入する準備ができているわけではないと思います。

その点について、皆さんの会社では何らかの費用上限を設けていますか？

たとえば、一部の開発者がすべての処理でトークンを消費している場合、常に最適なモデルを使用するにはどうすればよいでしょうか。

たとえば、何か戦略を見つけたのか、それとも、実験が素晴らしい結果につながるため、自由にやらせた方がいいのか？

昨年は試験運用の年だったと言えます。

すべての操作を行います。

今年の最初の半年は、合理的に使用するだけだったかもしれません。

そして 9 月以降、トークン制限が導入されました。

そのため、デベロッパーのトークン使用量には制限が設けられています。

また、インストルメンテーションにより、セッションが良好で健全かどうかを把握できます。

セッションが正常であるとはどういうことですか？

1 セッションあたりのターン数はこれほど多くなっていますか？

ターンとは

そのため、Google はツールを使用してデベロッパーを教育することにも取り組んでいます。

これは最初のステップにすぎないと思います。

問題を解決するには、まず問題があることを認識する必要があります。

そして、少なくともこれが無料ではないことを確認しています。

以前は、AI は無料であるように感じられていました。

そして、人々はそれを使っていました。

「ブランチを変更して」と頼むと、「わかりました、Annyce さん。5 ドルでブランチを変更します」と言われるようなものです。

「コマンドラインに移動して、自分で実行すればいいのでは？」と思うかもしれません。

そのため、エンジニアが実際の費用について教育を受けるようになると思います。

ECS インスタンスを起動して、そのまま放置するようなことはしません。

AWS が最初に登場したとき、私たちは「自分のインスタンスを使える」と思ったかもしれません。

会社に多大な費用をかけていました。

トークンでも同じことが起きていると思います。

実用的な制限は、非常に興味深い機会も提供すると思います。

LLM を使い始めた当初は、あらゆるものを LLM に投入していました。

コードをイントロスペクトして、問題を把握し、魔法のように解決してくれます。

しかし、それにはコストがかかりました。

そして、私たちは実際に、業界がそれを認識していることを知っています。

そのため、開発者や組織は、どのように最適化できるかを考える必要があります。

なぜかというと、たとえば、ユーザー インターフェース コンポーネントを生成するジェネレーターがあり、それらが特定の構造や単体テストなどに準拠する必要がある場合、モデルにその場で生成させるのではなく、決定論的なツールを生成させて、それを使って作成してもらう方がよいからです。

つまり、トークンと使用量の制限を有効に活用して、実際に効果を高める機会はたくさんあります。

そうですね。そのテーマに沿って、少なくとも Instacart では制限を導入しています。

しかし、目標は必ずしも AI の使用量を制限することではなく、ある種の衛生管理、またはあなたが言うような内省をもたらすことだと思います。

たとえば、特定のモデルを他のモデルよりも優先して使用すべきなのはどのような場合か、

Fable や Astra に時間を尋ねたり、Git ブランチを変更させたりする必要はないでしょう。

必要があります

スクリプトの作成に時間をかければ、ずっと無料で利用できます。

トークンが無駄になることはありません。

必要があります

そのため、制約は必ずしも使用を制限するためのものではなく、すべてを投げ出すような考え方から脱却するためのものであるということを付け加えるとよいと思います。

必要があります

おっしゃるとおり、昨年は実験の年だったように感じます。

今年は、このツールをどのように効果的に使用するかという段階に入ったように感じます。

うん

ここにあるストーリーは、私たちも大いに共感できるものです。

特に、より多くのテストから、効率性と説明責任のバランスの取れたセットへの移行です。

これは、さまざまな投資によるものです。

デベロッパー向けの教育や可視性などがあります。

Annyce がアクティビティ セッションの費用と情報について話していたように、

安全なデフォルト設定などへの投資は、無駄なやり取りを回避し、使用しているスキルが回帰などを効率的に探すのに役立ちます。

また、支出している費用に対する説明責任を果たすことができます。

トークン数には上限があります。

開発者がその上限に達すると、ボタンを 1 回クリックして理由を入力し、マネージャーが承認できます。

素晴らしい取り組みが行われている場合は、その取り組みを経験してほしいと考えています。

しかし、無駄なことや実験的なことをしている場合、なぜそのことにお金を使うべきなのかをマネージャーに説明できないため、そのようなことを抑制するのにも役立ちます。

その結果、作業を行わないだけでなく、これが適切なモデルの選択かどうかを確認することになります。

この重さは適切ですか？

ご存じのとおり、これらのトークンのコストは、競合他社との競争圧力により下がり始めています。

しかし、一般的に、エンジニアがそのことを考えることは、私たちが彼らに与えているお金の優れた管理者であること、それがリアルタイム、正しい健全なアプローチだと思います。

そして長期的には、その判断を完全に不要にすることです。

必要があります

自動モデル ルーティングなど、ユーザーが意識する必要のない機能が求められています。

ただし、それまでの間は、この状態が正常です。

うん

Google の取り組みの多くは、モデル ルーティングなどの開発に重点を置いてきました。これにより、デベロッパーが判断する必要をなくし、タスクを適切なモデルにマッピングしようとしています。

しかし、適切なトリップワイヤーを設置することも重要です。

そのため、トークン制限についてはいくつかの方法で考えています。

デベロッパーをブロックすることは決して望ましくありません。

しかし、適切な分野に適切な方法で予算が使われていることを確認するために、立ち止まって確認する機会を設ける必要があります。

たとえば、1 日の利用時間の上限は、デベロッパーが自分でブロックを解除できるトリップワイヤーとしてのみ機能します。

彼らがしなければならないのは、ポータルに行ってボタンをクリックし、「ねえ、私は何も驚くべきことは起こらなかった」と言うだけです。

自分で操作する」

必要があります

これは 1 つの簡単なレバーにすぎません。誰もがループを実行しており、これらのループは一晩中実行される可能性があるため、コストが増加しないようにする必要があります。

これは非常に合理的です。

一方で、デベロッパーが最適なモデルを利用できるようにすることも重要です。

しかし、このカテゴリのモデルについては、フロンティア予算を作成しました。

そのため、1 か月の予算が設定されています。

十分な高さだ。

ブロックされていません。

ブロックを解除する必要がある場合は、例外プロセスがあります。

マネージャーに送信されます。

何をしているかを説明する瞬間です。

プラットフォーム チームは意思決定者ではありません。意思決定は、作業が行われている場所の近くで行われるべきだからです。

フロンティア モデルの使用に関しては、上限付きで完全な柔軟性が提供されます。

これが機能する理由は、最終的にプロセスに予測可能性がもたらされるからです。

必要があります

トークン支出の予算を立てる際に、計画していたことを考慮に入れたいと考えています。これは誰にとっても課題ですが、これらのレバーを使用することでそれが可能になります。

こうした会話で興味深いのは、

それは、私たちが全員、企業で働いているからだと思います。

そして、企業。

そのため、トークンごとに料金を支払う必要があります。

必要があります

しかし、インターネットには、サブスクリプション料金を支払っているユーザーが多数存在します。

そのため、彼らにとってはまったく異なる計算になります。

必要があります

しかし、誰もが同じプールにいて、すべてのトークンについて考え始めなければならないのは時間の問題だと思います。

そのとき、企業が今行わなければならないように、もう少し責任を持つという点で、もう一方の靴が落ちるのではないかと思います。

または、予算が無制限の最先端のラボで働いている場合です。

そして、運用を続け、Twitter で話題になっているような、AI ネイティブな働き方を数多く生み出していくのです。

すべての企業がそれを真似したいと考えていますが、トークンを消費したくないと考えています。

Google で働く人がここにいます。

とても興味があります。

どうすれば使えますか？

Google からの予算はいくらですか？

ルイス、答えてくれる？

その経済性について話すのに、私は適任ではないと思います。

Google は非常に大きな企業であり、多くの異なる組織が存在します。

ちょうど時間になりましたので、これで終了とさせていただきます。

便利だった。

Saved by the bell.

これは A+ のモデレーションです。

PR 担当者は…

パネリストの皆さん、ありがとうございました。そして、ADS にご参加いただきありがとうございました。