AIエージェントの実行環境としてBashが広く使われているが、これは理想的な解決策ではなく過渡期の技術である。モデルにコードベース全体を渡すのではなく、必要な情報だけを取得させることでトークン数を削減し精度を向上させる手法が確立されてきた。しかしBashには標準化の欠如、破壊的操作の判別困難、承認フローの煩雑さなど根本的な課題がある。TypeScriptベースの実行環境は型付け、ポータビリティ、軽量な仮想化といった利点を持ち、次世代のエージェント実行レイヤーとして有望視されている。CloudflareのCode ModeやVercelのJust Bash、そしてJust JSといったプロジェクトが、仮想化されたJavaScript実行環境でエージェントを安全かつ効率的に動作させる未来を示している。
かつてのAIコーディングとその限界
昔は、子供たちがChatGPTにコードベースで何を実行すべきか尋ね、そのコマンドをコピーして自分のターミナルに貼り付けていたものです。モデルにコードベースについて知らせたい場合、あらゆる種類の奇妙で粗悪なツールを使ってコードベース全体を圧縮しようとし、それを巨大なプロンプトとしてモデルに渡していましたが、そういったものは本当に何もうまく機能しませんでした。
明らかに、それは今日私たちがAIを使う方法ではありません。誰もがCursorやClaude Code、Codex CLI、T3 Codeなどのツールを使っており、そこではモデルが実際にあなたのシステムを使用できます。そしてあなたのシステムとは、通常はBashを意味します。これらのモデルには、マシン上でBashコマンドを呼び出すことを可能にするツールへのアクセスが与えられており、コードを読んだり、理想的には少量だけで全部ではなくコンテキストを溢れさせないように適切なことを行ったり、実際にコードベースに変更を適用したり、コマンドを実行したり、パッケージを取得したり、その他必要なあらゆることを行います。
なぜなら私たち全員が知っているように、Bashを使えばコンピューター上で必要なことは基本的に何でもできるからです。あるいは、できるのでしょうか。私はここでかなり大胆な主張をしに来ました。Bashでは不十分です。驚くべきことに、これらのモデルはコマンドを実行することで私たちのマシン上で非常に強力なことができますが、それはこれらのエージェントを実行する理想的な方法ではありません。
それは本当に重要な踏み台です。しかし今日、私はそれがいかに踏み台に過ぎないかを強調したいと思います。それは、私たちが愛するAIツールが今日私たちができること以上のことをシステムで行える未来に到達するために、私たちが行わなければならない多くのことの一つに過ぎません。これは少し技術的な深掘りになります。これらのモデルがどのように機能するか、エージェントとハーネスの実行方法が時間とともにどのように変化してきたか、そして最も重要なのは、将来の解決策はどのようなものかということについて掘り下げていきます。
私はこれに飛び込むことにとても興奮しています。特に最近、T3 Codeでこれらのことについて細部まで考えてきたからです。しかし皆さんもご存知の通り、T3 Codeはオープンソースです。つまり私たちはそれで全くお金を稼いでいません。ですので、私にお金を払ってくれる何かから少し休憩を取ります。今日のスポンサーです。
今日のスポンサーはBrowser Baseです。エージェントがウェブを使用するための最良の方法です。歴史的に、私はこのようなものにあまり興味がありませんでしたが、GPT-5.4が登場した今、私の考えは完全に変わりました。以前は全く不可能だったことの簡単なデモをお見せしますが、今では絶対に可能です。これはBenがテストのために構築したアプリで、エージェントがブラウザを使用するBrowser Useメソッドと、GPT-5.4に存在するこの新しいJavaScriptベースのメソッドの違いを比較するためのものです。なぜならこのタイプのパターンで特別にトレーニングされたからです。
これが意味するのは、エージェントがコードを書いてブラウザ自体で実行できるということです。何かを手動で選択してクリックする代わりに、代わりにそれを行うコード行を書くことができます。そしてそれははるかに効率的です。現在、デモアプリはGoogle Flightsを使用してフライトオプションを見つけようとしていますが、私はこれを完全に変更します。
ここで、Wordleのページに行ってプレイするように指示しています。どうなるか見てみましょう。ありがたいことに、Browser Baseではセッションを実際に開いて、それが起こっているのを見たり、後でリプレイを見たりすることができます。そしてここでモデルがゲームをプレイしているのを見ることができます。ターミナルに戻ると、ここで書いているコードで何をしているかを見ることができます。
そして今、推測を始めています。そしてそれは、ページ上のコードを読んでどのように機能するかを理解した後、実行するJavaScriptコードを書くことで、Wordleインスタンスの単語を変更することによって行っています。同じ推測を2回実行したところで、完璧には程遠いですが、まだ成功する良いチャンスがあると思います。
指を交差させましょう。エージェントがどうするか見てみましょう。そして見てください。最後の推測で、成功しました。ですので、Wordleでカンニングするのを手伝ってほしい場合や、その種の複雑なウェブインタラクションである他のことを行う場合は、Browser Baseをぜひご覧ください。
Bashでは不十分である理由
Bashでは不十分といった太字のテキストを書き留める時、私は間違いなくそれを正当化する必要があります。しかしそれを行うためには、少し早い段階から始めなければなりません。LLMが実際に何ができるかについて少し考える必要があります。まあ、LLMができることを私たち全員が知っていることが一つあります。それはテキストを生成できることです。
そして物事が始まった当初、これらのモデルをより有能にしようとした時の方法は、特にコードタイプのテキストを生成する際、モデルが適切な判断を下すのに十分なコードについて知る方法が必要でした。モデルにはコンテキストウィンドウと呼ばれるものがあります。それは何らかの応答を得ようとする際にモデルに収まることができるトークンの数です。
結局のところ、これらのモデルは本当に効果的なオートコンプリートに過ぎません。これまでのチャット履歴で言われたことに基づいて、トレーニングされたすべての情報、その後に行われたすべての強化学習、その他すべてのことに基づいて、次に来る可能性が最も高いと考えるものは何かということです。
モデル内のパラメータは、過去に来たものに基づいて、さまざまなものへ、そしてさまざまなものから指し示す効果的にはベクトルに過ぎません。したがって、これまでに送信したすべてのデータを適用し、それを使用して次に来る可能性が最も高いテキストのチャンクが何であるかについて別の方向を指し示します。そしてこれを繰り返し続け、最終的に終了信号に達するまで続けます。そこで完了したと判断し、これがあなたの結果です。
モデルがこのタイプのオートコンプリート生成を行えるようにするためには、既存のテキストを分解してパラメータ化し、モデルに渡して次のトークンを取得する方法が必要です。トークンは、1つの単語や3〜5文字のような小さな文字数の通常はテキストのグループです。
たとえば、OpenAIのトークン化デモでこの一節をコピーして貼り付けると、このテキストは280文字で52トークンであることが以下に表示されます。最初の単語OpenAIのアポストロフィsには3つのトークンがあります。Open、AI、そしてアポストロフィsです。次の単語のlargeは単語だけでなく、スペースが含まれており、languageもスペースを含んでいます。
さらに興味深いのは、これらのトークン化プロセスが時間とともにどのように変化したかです。GPT-3のトークナイザーに戻ると、非常に興味深いことに、この段落では古いトークナイザーから新しいトークナイザーへの切り替えは何もしないようです。
しかし、コードに飛び込んでみましょう。ここで、私のコードベースからこのセクションを取り出すと、コードの場合、これは306トークンにトークン化されていることがわかります。そしてトークンはすべて、開始タグが独自のトークンのような意味のあるものです。Classは独自のトークンです。等号とクラス名の開始は独自のトークンです。そしてここの最後のコロン引用符は、これらのものの終わりを示すための独自のトークンです。
これをGPT-3でのトークン化の動作と比較すると理にかなっています。これははるかに細かく分割されています。ここの開始時の各スペースが独自のトークンであることを含みます。そしてこれらの各トークンが効果的にパスを作成していることを覚えておいてください。これらは、どこかに車を運転するためにモデルに与えている方向です。これは、このように分割されている場合、10フィート前進し、次に10フィート前進し、次に10フィート前進すると何度も繰り返し言っているようなものです。
本当にやりたいことは、クラスに達するまで運転すると言うことです。そして新しいトークン化方法はこれを行い、モデルへのデータ取得をはるかに良くし、トークンが少なくなるようにして、行きたい場所へのパスを見つけようとしています。これらはすべて、研究所が多大な努力を注いできたものです。
しかし理解すべき重要なことは、チャット履歴がこれらのトークンでいっぱいであるということです。そして履歴内のトークンは、次に来る可能性が最も高いトークンを決定するものです。したがって、トークンがスペイン語であれば、次のトークンもスペイン語である可能性が最も高いです。トークンがJavaScriptであれば、JavaScriptを生成する可能性が最も高いです。
チャットの履歴は、出力が何であるかを決定する上で非常に重要です。したがって、コードベース内のコードのようなコードをモデルに出力させたい場合、コードベース全体をコンテキストに投げ込むべきですよね。そうでしょうか。いいえ。
問題は、プロンプトが「この新機能を動作させるのを手伝ってください」のようなものであれば、これはわずか8トークンで、コードベースに貼り付けると、この155行のファイルを取ってみましょう。非常に小さいです。それはすでに1,200トークンです。したがって、私のプロンプトは8トークンで、コードベース内の1つのファイルは1,200トークンです。コードベース全体を入れると、おそらくモデルが処理できるトークン数の制限に近づくでしょう。
ほとんどは10万から25万の間ですが、すべてのトークンが次を予測する数学を行うのを悪化させるため、終わりに近づくにつれてはるかに頭が悪くなります。これが、私がRepopackのようなツールを心から嫌悪する理由です。このツールは、おそらく私の会社に6桁以上のコストをかけています。このツールのせいで少なくとも10万ドルの無駄な支出が発生しています。
なぜなら、メッセージの数に基づいてT3 Chatの価格を設定していた頃、メッセージがどれだけ高価かではなく、人々はコードベースを取得し、全体を10万以上のトークンファイルにダンプし、それをエディタ、またはこの場合はT3 Chatに貼り付けて、Cursorの代替としてT3 Chatを使用して安くコードを生成しようとしていました。いいえ。悪い、愚かです。これをしないでください。
これはより多くのコストがかかるだけでなく、入出力するトークンの数に基づいて課金されるため、履歴が実際には望んでいないもので満たされるため、はるかに悪い応答を得ることになります。モノリポのTypeScriptパッケージ内の1つのファイルで小さな変更を行おうとしている時、コードベース内のRustのすべてのコード行について知る必要はありません。
このようにモデルにコンテキストを取得する方法は、悪いだけでなく、高価で、遅く、破壊的で、出力の質を損ないます。もし私がRepopackを運営していたら、ページの上部に小さな警告を入れて、「ねえ、私たちは業界として、これがAIでコーディングするための最悪の方法であることを学びました。文字通り他のことをすることをお勧めします。なぜなら、これは機能しません。これは悪いです」と言うでしょう。
Bashが機能する理由
では、何が機能するのでしょうか。Bashは機能します。矛盾していることは分かっています。このビデオはBashでは不十分ですが、聞いてください。問題がモデルが何を変更する必要があるかを知る必要があることであり、モデルにコードベース内のすべてのコード行を与えることが意味をなさない場合、私たちは少し考え直す必要があります。私たちがどのように働くかに戻ります。
実際にコードベース内のすべてがどこにあるか知っていますか。もしそうなら、おめでとうございます。すぐに本当の仕事を得られることを願っています。実際のコードベースで実際の同僚と働く私たちにとって、誰もすべてがどこにあるかを知りません。それは現実的でも実行可能でも正気でもありません。コードベース内のすべてがどこにあるかを知ることはできません。
では、変更を加える必要がある時、何をしますか。おそらく、あなたが望む場所に到達する方法についていくつかの信号やシステムを頭の中に持っているでしょう。サイト上のボタンが間違った色である場合、コピーを取得してコードベース内でCommand+Fで検索できます。あるいは、ボタンが使用するクラス名を調べて、それらを見つけようとすることができます。または、ウェブアプリから直接ファイルに移動できる開発ツールを導入することができます。
しかし、コードベース全体を1行ずつ読むことは生産的な解決方法ではないため、正しい場所に到達する方法が必要です。また、これらのモデルは、私たちのような記憶を持っていないため、新しいチャットを作成するたびにゼロから始める必要があることも注目に値します。コードベース内のどこに物があるかを覚えていません。
そしてたとえ覚えていたとしても、おそらく悪いでしょう。なぜなら、それらが変更された場合、混乱して間違ったことをするからです。では、モデルでこれをどのように再現するのでしょうか。モデルが他のすべてではなく、知る必要があるものだけを持ち込めるようにするにはどうすればよいでしょうか。
現実には、私たちにはできません。モデルがチャット履歴内にある程度無駄なコンテキストを持たないことを保証する方法はありません。しかし、彼らができることを使用させれば、その可能性を低くすることができます。それはテキストを生成して、実際に必要なテキスト、つまり関連するコードの部分を見つけることです。
そして、Primagenのストリームや他のターミナルウィザードで、Vimの大ファンでRip Grepを本当にうまく使う人たちを見てきた私たち全員が見てきたように、ターミナルを使ってコンピューター上で多くのことができます。ターミナルを使用してコンピューター上で必要なことはほぼすべて行うことができます。
したがって、Claude Codeのようなツールが登場し始め、モデルがコマンドを書いて、知らないことや使用できないことを見つけることができるようになりました。したがって、モデルにコードベース全体を与えて、この巨大な山から正しいファイルを見つけて変更を加えるように指示する代わりに、非決定論的マシンを覚えておいてください。
したがって、これらのパラメータはすべて、さまざまなフレーズ、さまざまなキーワード、さまざまなパラメータに非決定論的に指し示しています。正しい方向に導く可能性は本質的に低下します。しかし、コンテキストがコードベースに存在し、それを見つけるためにgrepコマンドを書く場合、grepは決定論的です。
毎回同じものを見つけます。したがって、モデルが正しいコンテキストを取得するための正しい5〜15トークンのコマンドを書くことができる限り、それは効果的に決定論的です。これを決定論的動作の範囲として考える方法があります。一方に完全に決定論的、もう一方に完全にランダムがあります。
そしてこれはある種、AIの問題です。AIは非常に非決定論的です。モデルで生成をヒットすると、尋ねられたことを満たす何かを生成するために最善を尽くしますが、毎回同じ方法で行うわけではありません。同じモデルに同じ質問を3回尋ねると、3つのほぼ似た答えが得られる可能性が高いですが、意味のある違いがあります。
したがって、これをスペクトルで表すと、math.random、JavaScriptの関数は完全にランダムではありませんが、かなりランダムに近いです。そしてconsole.log、log hello worldは決定論的です。なぜなら、これを実行するたびに、ほぼ同じ時間で実行され、hello worldの同じ答えが得られるからです。AIは実際にはこの決定論的な側にあまり入りません。
しかし、それを別の方向に非常に速く動かすものを知っていますか。より多くのトークンです。より多くのトークンは効果的により多くのランダムに等しくなります。モデルに与えられるコンテキストのトークンが多くなり、モデルによって生成されるトークンが多くなり、回避しなければならないことが多くなるにつれて、正しく取得する可能性は低下します。
これを人間の働き方に例えると、机に3つのものがあり、私があなたに3つのものがどこにあるかを説明するように頼んだ場合、あなたがそれを見て、それから私があなたに質問をして、あなたが戻って見ることができない場合、あなたはかなりまともな仕事をするでしょう。机にあるものはどこにあるか、記憶だけから答える場合です。あなたはそれを正しく理解する可能性がはるかに高いです。
しかし、机に300のものがある場合、そのうちの3つさえ覚えている可能性はどれくらいでしょうか。おそらくあまり高くありません。モデルは効果的に同じように働いています。そして、モデルがメッセージを送信すると、それは今や履歴の一部になります。それは今や横断しなければならないトークンの山の一部になります。そして、望む答えを得る可能性を高めるために、その山を小さく保ちたいのです。
では、トークンの山をより小さく保つにはどうすればよいでしょうか。以前のソリューションがコードベース全体をダンプすることだった場合、それは何も小さく保つことにはなりません。コードベースをダンプする代わりに、わずか7トークンの単純なgrepコマンドを書き、1つのファイルから8行のコードを取得するとしましょう。それはさらに30トークンです。モデルが必要とする情報を取得するために40トークン未満を使用しました。10万トークンを渡して必要な情報を見つけることを期待する代わりにです。
これは魔法のような改善であり、モデルがコーディングでこれほど良くなった理由の大きな部分です。そして、モデルが必要なコンテキストを見つける方法を知る方が、すでに履歴にあるコンテキストをモデルが横断するよりも良いという現実にまだ追いついていない特定の研究所があります。
これはGoogleモデルがまだそれほど悪い理由の一部です。なぜなら、Googleは大量のコンテキストからデータを取得するのが本当に得意なモデルを作ったからです。OpenAIとAnthropicおよびすべての中国の研究所は、必要な時に必要な情報を取得できるようにするツール呼び出し特性により焦点を当てています。最初からすべてを提供してさらに混乱させるのではなく。
Bashの限界とTypeScriptベースの解決策
それでは、ビデオのトピックに入る必要があります。前に述べたように、Bashがモデルがこのコンテキストを収集するために使用できるものとして素晴らしいのと同じくらい、テキストでBashを操作でき、モデルがテキストを生成でき、モデルをトレーニングしてこれを行い、モデルは仕事を行うために必要な情報を取得できるようになります。
では、これについて十分でないものは何でしょうか。ブラウザでボタンをクリックするようなUIをコマンドしようとすることから、誤って削除すべきでないものを削除したり、望まないことをシステム上で行ったりしないように、Bashコードを実行するための安全な場所を持つこと、すべての単一のエージェントが物事を行うための専用マシンを必要としないようにこれを行う方法を見つけようとすることまで、ここには多くのレイヤーがあります。
これをより仮想化する方法、またはクラウドに配置する方法、またはブラウザに配置する方法はどうでしょうか。これらの作業を完了させる方法を、すべてのボックスに専用VMを持つことなく、よりアクセスしやすくするにはどうすればよいでしょうか。また、Bashは必ずしもプログラミング言語ではありません。つまり、機能します。良いです。それで本当に強力なスクリプトをたくさん書くことができますが、Bashでできること以上のことができる必要があります。
そして、これをある時点で見たことがあると確信しています。GPT-5.3 Codecsのテストで早い段階で気づいたことの1つは、モデルが私のコンピューター上のファイルを編集するためにPerlスクリプトを書くのが本当に好きだったことです。編集ツールを手動で呼び出したり、他の方法で編集を行ったりする代わりに、小さなPerlスクリプトを書いて、それをコマンドとして実行してこれらの変更を加えました。
では、もっと良くできることは何でしょうか。いくつかの解決策が頭にありますが、まず別の解決策をお見せしたいと思います。今日のスポンサー、今日の広告を少し違った方法で行います。これを見せたいだけです。これが見えますか。これは失敗したCIで、なぜ失敗したと思うかを教えてくれます。それについて少し考えてください。
GitHub体験からどれだけ離れているか理解していますか。GitHubを使用してアクションが失敗すると、20分から数日間、GitHubでは機能しないのに私のマシンでは完全に正常に動作する理由を解明しようとしてモグラ叩きをしなければならないという奇妙なうずうず感が内側にあります。
おそらく数秒前にこれを言うべきでしたが、今日のスポンサーはDepotです。彼らはあなたのGitHub ActionsとDockerビルドをはるかに高速にします。しかし、今では、ご存知のように、GitHub Actionsがかなり悪いことが判明しているため、GitHub Actionsを使用する必要はもうありません。そのため、彼らは独自の代替品を作ることにしました。
そしてすごい、それは信じられないほどです。小さなチームとして独自のものを構築し、あらゆる面で単にそれらを圧倒することができたという事実は、GitHub Actionsがいかに悪いかを示しています。また、これらすべてがエージェント対応であることにも注目に値します。そして、私は信頼性の低い粗悪なMCPサーバーを意味しているわけではありません。
実行中の実際のアクションに関するすべての情報を取得できるCLI、および直接実行する機能を意味します。つまり、ジョブを適切にデバッグおよび監視し、必要なすべての情報を取得し、物事が起こっている時にボックスにSSH接続する機能さえあります。コミットせずにローカルファイルでアクションを実行することさえできます。
ループ内のエージェントにとってこれがどれほど役立つか分かりますか。モデルがFSコマンドを書いてこのライブラリで実行でき、RAMを離れることがありません。このインスタンスを離れることがありません。それ自体の小さなボックスに住んでいて安全です。それはとてもクールです。そして私たちは今後、このようなものをますます目にすることになると思います。
GitHubよりも多く請求できるかもしれませんが、そうしていません。実際、実行時間1秒あたり0.01セント、つまり0.0001セントという滑稽なほど少ない料金を請求しています。まだGitHub Actionsを使用している場合、時間を無駄にしています。soyb.link/depotで今すぐそれを修正してください。
Bashが十分でない理由について話すためには、Bashがどこで発生するかについて話す必要があります。それは実行レイヤーです。モデルがツール呼び出しを行い、決定を下し、情報を探し、物事を行い、物事を収集している時です。Bashはコンテキストの収集だけでなく、変更の適用、変更の確認、出荷、その他多くのことにも使用されます。
そして、それらのことを行う実行レイヤーは、現在最も争奪戦が繰り広げられている領域の1つです。なぜなら、理想的には、私たち全員が無期限にこれらをコンピューター上で実行するだけではないからです。Reeseはこの実行レイヤーについて小さな記事を書きました。ここから始めるのに本当に良い場所だと思います。
LLMは、ツール呼び出しを実行するために彼ら用に作られた実行レイヤーを切実に必要としています。1年前、LLMはツールへの直接呼び出しを行っていました。それが彼らのコンテキストを無関係な情報で溢れさせ、非常に貧弱なパフォーマンスを見つけたことが分かりました。
次に、コーディングエージェントで、より少ないツールを与えると、はるかに優れたパフォーマンスを発揮することを発見しました。そして今、すべてのエージェントにはBashツールがあります。なぜなら、Bashツールは1つのツールに過ぎないからです。そして繰り返しますが、コンテキストを溢れさせることは最悪のことです。
数日前、料理か何かについてT3 ChatでGemini 3 Flashに質問した時に奇妙なことに気づいた誰かからDMを受け取りました。そして応答は「あなたが開発者であることを知っているので、これがあなたにとって最も興味深いでしょう」で終わりました。そしてそれは応答の半分のようでした。
そして彼らは混乱して私に連絡しました。「これはT3 Chatの問題ですか。料理について尋ねた時になぜ私が開発者であることについて話しているのですか」と。まあ、理由はこの開発者がT3 Chatのカスタマイズに自分自身に関する情報を持っており、彼らの仕事が何であるかを含み、エンジニアと答えたからです。
そして、それが今コンテキストにあるので、Geminiモデルがそれを使用することに間違いありません。あなたがやっていることに関連していなくても関係ありません。コンテキストに存在する場合、モデルはそれを認識します。そしてGeminiはこれについて本当に悪いです。Geminiに情報を与えると、完了しようとしているタスクにまったく関連していなくても、その情報を使用します。
したがって、Geminiモデルに1,000のツールを渡すと、それらがまったく役に立たなくても、めちゃくちゃに使用します。しかし、少数のツール、特にBashツールを与えると、そのBashツールを使用して必要なことを何でも行うことができます。そして、これがBashツールが非常に強力な理由の大きな部分です。なぜなら、モデルにBashを与えると、それ以外のものをあまり多く与える必要がないからです。
そして、代替案が編集ツール、更新ツール、名前変更ツール、移動ツール、ファイルチェックツール、ディレクトリ作成ツール、その他すべてのものを与えることである場合、それらすべてを使用しますが、どこにも到達しません。ここでのReeseのこのフレーミングが好きです。Bashは単なるツールではありませんでした。それは最初の実行レイヤーの導入でした。
LLMは今や、ツールを段階的に発見し、コマンドを連鎖させ、長くなりすぎた時に出力をgrepできるようになりました。それは通常のツールとして滑り込んだ最初の実行レイヤーでした。しかしBashは不完全です。今日のエージェントで抱えている次の問題について考えてください。
CursorとOpencodeとOpenclawの間でサインイン状態を共有して、これらのエージェントが作業中のWebアプリのようなものにアクセスできるようにしたいとします。承認方法を共有したいとします。したがって、何かで承認した場合、毎回手動で承認する必要なく、他のものでそれを共有してアクセスできるようにする必要があります。
そして、これらの承認はそれ自体で危険です。直感に反するように思えますが、モデルとエージェントとハーネスに、何かを承認または不承認にするかを常に尋ねさせることで、危険性が大幅に増加します。なぜなら、それは私たちを何度も何度もyesを押すことに慣れさせてしまったからです。
私を含む私たちのほとんどが、危険にスキップ許可モードで実行するだけです。なぜなら、そこに座ってyes、grepできます、yes、catできます、yes、gitステータスをチェックできますと何度も何度も押したくないからです。だから、ただそれに任せます。ここには他にも多くの楽しい問題があります。
一部のエージェントに一部のツールへのアクセスを許可したいとします。何かのために同時に2つの異なるアカウントにサインインしたいとします。ツールによって実行できるすべての可能な操作を知りたいとします。読み取り専用を自動承認したいが、書き込みおよび破壊的アクションには承認が必要だとします。
特定の関数にワイルドカード承認を適用したいとします。AIアクションが破壊的かどうかを知る必要があります。そしてチームの場合、営業チームがSalesforceを呼び出せるようにしたいが、エンジニアはできないようにしたいとします。
企業と実際のシステムがどのように機能するかにおいて意味のあることすべてですが、Bashではそれを理解することはできません。主な理由は標準がないことです。Bashは単にコマンドを実行させるだけで、これらのコマンドはあらゆるクレイジーな方法でフォーマットできます。どのアクションが破壊的でどれがそうでないか、ユーザーからの入力を引き出そうとすること、利用可能なすべてを知ること、ワイルドカード承認を行うこと、これらのタイプのことすべての周りに標準が欠如しています。
Bashにはそれができません。Bashコマンドが破壊的であるかどうかを知るための標準はありません。特定のコマンドを実行する許可があるかどうかを知るための標準はありません。モデルがこれを行う方法はありません。そして、使用するすべての単一のツール、すべての単一のCLI、使用するすべての単一のものには独自のソリューションがあります。つまり、これらのツールがこれらのことをチェックする方法と、それに何を期待するかを説明するコンテキストの肥大化に戻らなければなりません。
あるいは、より良い方法を見つけようとすることができます。そして、私たちはすでに最悪のこと、つまりBashが残ると仮定する代替案を見ています。Data DogのPop、Google Workspaces CLI、Poly Market CLIのようなもののためにCLIを作成しているこれらすべての企業に行き着きます。くそっ。Poly MarketがCLIを作るかどうかのポリマーケットがあるかどうか疑問に思います。
Poly Market CLIが古くなって壊れるまでにどれくらいかかるかのポリマーケットがあるでしょう。言っておきますが、ちなみに広告ではありません。私はこれらのギャンブルのものすべてが本当に大嫌いです。ギャンブルしないでください。お金を失います。ギャンブルをしているような気分になりたい場合は、Geminiで何度も何度も生成するだけです。
基本的にギャンブルですが、少し安いです。自分自身に、まあ、ここでの解決策は任意のAPIを呼び出せるCLIを作ることだと考えているかもしれません。それは小さく考えすぎです。世界中のすべての人がサービスとやり取りできるようにするものを構築しているわけではありません。そしてBashはその解決策ではありません。
では、何ができるでしょうか。入力と出力を持つ型付き環境が必要で、安く実行でき、ポータブルで、よく分離され、その他すべてのことができる呼び出しをプロキシする能力が必要です。ああ、TypeScriptがすぐそこにあります。これをすでに読んでいませんでした。私たちがこの方向に進むだろうという感じがありましたが、それを見るのは楽しいです。
文脈として、私が世界で最も嫌いなものの1つはMCPです。それはいくつかのことに対して時々役立つことができるポイントにほとんど達していますが、それでもようやくそこに到達しつつあるだけです。あなたのものに統合できるMCPサーバーの大多数は悪く、AIを使用する体験を悪化させるだけです。大多数です。
そして、ここでの問題の1つは、これらのMCPサーバーがそれらで実行できるさまざまなコマンドで山積みになっており、それらをどのように使用するかを知るために必要なコンテキストがあることです。そして、MCPサーバーがコンテキストとして追加されると、コンテキストウィンドウの非常に多くを占めます。完全に同じではありませんが、比較的似ています。
Anthropicは、常にコンテキストに追加するのではなく、ツールを検索することを実装しました。そして、ここで彼らが持っていたこのMCPサーバーの例では、そのスペースのほぼ40%がMCP情報で占められていたことがわかります。72,000トークンのMCPサーバーに関する情報。それは狂気です。なぜなら、これらの仕様は悪く、肥大化し、ひどいからです。
Code Modeは、MCPサーバーとそれらを呼び出す方法についてのすべてのコンテキストをモデルに与えようとする代わりに、それらをTypeScript SDKに変換し、使用されるコンテキストをはるかに少なくして、モデルが使用し、コードを書くことができる検出可能なものとしてコードベースに含めたらどうなるかというCloudflareの興味深い代替案でした。
すべてについて知る必要はありません。代わりにコードやMCPのものを検索する方法で検索できます。これについて詳しく説明した複数のビデオがあります。まだ見ていない場合はチェックすることをお勧めします。それらは私のMCPビデオです。
しかし、ここで私があなたに与えるTLDRは、モデルに代わりにこれらのものを呼び出すコードを書かせると、多くのものがより良くなったということです。すべてのユーザーを取得するクエリを実行し、それをすべてコンテキストに入れてから、特定のフィールドを持つものを見つける代わりに、コードを使用してフィルタリングできました。すべてのユーザーを取得してから、必要なものをドットフィルターで取得し、気にする2行だけを返すことができました。コードベースまたはデータベースに存在する10万行ではなく。
次のステップを行うためにモデルに戻らなければならないすべての単一のMCP呼び出しまたはツール呼び出しの代わりに、コードは実行して必要なフィルタリングおよび他のツール呼び出しを行うことができます。そして完了したら、結果をモデルに送り返し、無駄になっているコンテキストを減らすのに役立ちます。そして、モデルはこれが本当に得意であることが判明しました。
多くの例で応答を行うために必要なトークンの量がはるかに少なくなりました。答えを得る速度がはるかに速くなりました。そして、モデルに10万のものを与えて必要なものをフィルタリングするように指示すると、60〜70%の確率でそれを行いますが、コードに尋ねると、決定論的に100%の確率でそれを行うため、信頼性が向上しました。
彼らの例でのこの方法は、使用される平均トークン数を43,500から27,000に減らすのに役立ちました。これはほぼ40%の削減です。また、レイテンシーが大幅に向上し、いくつかのベンチマークで25.6から28.5への3ポイントの上昇で精度が向上しました。それはナッツです。
コードを書くようにトレーニングされたモデルがコードを書くのがかなり得意であることが判明しました。そして、実際の言語にはBashよりも利点があることが判明しました。Reeseが言っていることに戻ると、TypeScriptはここで非常に興味深い解決策です。TypeScriptが言語でBashがBashであるというだけでなく、TypeScriptはさまざまな環境でさまざまな方法で実行できるためです。
V8やNodeやCloudflareのworkersのようなものでのJavaScriptランタイムのアイソレート内、あるいは独自のブラウザ内でさえ、JavaScriptプロセスを分離して、互いに隣接して安全に実行でき、互いに影響を与えないようにするさまざまな方法があります。つまり、すべてをDockerで仮想化して上記のすべてを仮想化する必要なく、同時に何百ものユーザーのリクエストを実行している1つのLinuxカーネルを持つことができます。それは巨大です。
それは魔法です。それはとても強力です。そしてTypeScriptは言語としてここでかなり有用です。なぜなら、JavaScriptになると、コンパイルする必要がないからです。この仮想環境に投げ込むだけで、それは本当の仮想環境ではないため良いです。分離されません。
面白いことに、これがVercelがJust Bashを作った理由です。彼らによると、モデルはBashを使用するのが本当に得意ですが、各モデルにBashを使用するための完全なコンピューターへのアクセスを与えることは理想的ではありません。正しいファイルを見つけたり、コードを編集したり、その他必要なことを行ったりするようなことをするためにBashをモデルに与えることができたらどうでしょうか。しかし、実際にファイルシステムに触れない偽のBashを与えることによって完全に仮想的に。
それは、NodeまたはV8または他の場所で実行されるTypeScriptで書かれた引用符付きのBashの仮想インスタンスに過ぎません。これは非常にクールです。非常にクールで、数日前にカバーしたCloudflareとVercel間の巨大なドラマを引き起こしました。それは非常にクールなプロジェクトです。
しかし、私たちが今確立しているように、Bashはここでの究極の解決策ではないかもしれません。なぜなら、重要な多くのものが欠けているからです。だからこそMaltaはJust JSを導入しました。半分冗談です。彼らはJust BashにJavaScriptとTypeScriptの実行を追加しました。それは少しクレイジーに聞こえます。なぜなら、ある種そうだからです。しかし、これがどれほど強力かについても考えてみてください。
1つのインスタンスでNodeを実行している1つのサーバーがあり、何百人もの人々がエージェントを実行してコードを編集できるようにしたい場合、何百人ものユーザーがアクセスしているこのサーバー上のBashにこれらのエージェントへのアクセスを与えることはできません。
そして、彼らが抜け出して他のユーザーのものに触れる能力を持つことは絶対に望んでいません。ユーザーAがユーザーBのファイルにアクセスして編集できる場合、すべてが崩壊します。Just Bashは役立ちますが、それでもBashです。モデルにTypeScriptを書かせて、ファイルシステム内のすべてのファイルに対して実行し、どれが重要かを把握したり、分類したり、ファイルシステム内のデータで実際のことを行ったりできるようにしたい場合はどうでしょうか。
すべてがこのサーバー上にあるため、ファイルシステムへのアクセスを与えることはできません。人々が他の人のファイルにアクセスできるようにしたくありません。しかし、各アイソレートが安全だったらどうでしょうか。各インスタンスが、そのデータだけがその中でアクセスできることを知っていて、他の人がそのデータにアクセスできず、他の人のデータにアクセスできなかったらどうでしょう。彼らがJust Bashで設定したように。それがJust JSです。
これは、モデルがFSコマンドを書いてこのライブラリで実行でき、RAMを離れることがないことを意味します。このインスタンスを離れることはありません。それ自体の小さな安全なボックスに住んでいます。それは本当にクールです。そして、私たちは今後、このようなものをますます目にすることになると思います。
あるいは、エージェントが効果的に嘘をつかれて、実際のカーネル上の実際のBashを持つ実際のコンピューターを使用していると信じさせ、それ以上のことを知らず、それに応じて行動し、理論的には同じ方法でTypeScriptを書くこともできれば、コマンドを実行する前に、何ができて何ができないかについてより有用な情報を得ることができるソリューションです。
Reeseが言ったことに戻りましょう。LLMがツールを呼び出すためのTypeScript環境を作成することで、チームと共有できるポータブル環境を作成できます。実行が非常に軽量です。その周りに強力なエコシステムがあり、強く型付けされているため、承認ルールで非常にクリエイティブになることができます。
興味深いです。チームと共有できるポータブル環境というアイデアが本当に好きです。すべての人に対して適切に機能するDockerイメージを作成しようとする代わりに、必要なすべてを行い、APIなどを呼び出して、エージェントの適切な環境を作成するTypeScriptファイルを持っていたり、他のすべての人が好きなツールに対して使用できるようにこれをホストしたりするだけです。
それは実際に本当にエキサイティングです。エージェントが動作する環境を構成するTypeScriptファイルというアイデア。それは非常に魅力的です。これがどこに向かっているのかが好きです。ここには無限の可能性があります。彼は正当な理由でこれを書きました。彼は、このものが設定されると、GitHubリポジトリに基づいて仮想ファイルシステムとストアを与えるようなクレイジーなことができる本当にエキサイティングな未来を見ています。
モデルに、独自のプロセスで生成を行い、コードのスニペットを共有するためにAI SDKのようなものを呼び出させます。そして、ここでできる非常にクールなことがたくさんあります。そして、これまでに行ってきたすべては、Bashがこれらのどれのためにも構築されていないという事実を回避しようとするハックのように感じられました。
だからこそReeseはExecutorを構築しました。これは、AIモデルが物事を安全に実行するために使用できる環境を作成する方法を理解しようとする彼の試みです。だからこそDaxはOpencode内のBashツールを完全に取り除く実験をしています。これらのエージェントはJSをうまく書きます。
したがって、過去にBashが行っていたことを行うためにJSを書くだけだったらどうでしょう。そして、安全な実行レイヤーであるRivetやSandboxのようなツールで作業できます。これらのサンドボックス企業がますます増えており、その多くは本当にクールです。
明らかに、Daytonaはスポンサーです。私は彼らがとても好きです。彼らは今現在最高のソリューションの1つだと思いますが、このようなものを探している場合は、間違いなく周りを見てください。それでも、Just Bashが宇宙で私のお気に入りのものだと思います。たとえBashが理想的でなくても。
仮想化のためのこのレイヤーは私にとって非常に理にかなっており、それはエージェントが物事を実行できる場所であり、私の頭の中でクリックします。私たちがこれらすべてを理解するのはまだ初期段階にあることは非常に明確です。エージェントがどこで実行され、何を編集して実行する許可を持つかという質問は、まだ答えがないすべてのオープンな質問です。
しかし、業界としてどこに行き着くかを見るのが楽しみです。エージェントでコーディングする方法のUIがまだ解明されていないのと同様に、環境もまだ解明されていません。私たちは、使用するAIエージェントが今日使用するツールにうまく適合しないため、日々使用するすべてのものがAIの一般的な動作方法のために変わる意味のある可能性がある奇妙な空間に本当にいます。
彼らがBashでうまく機能したのは楽しい偶然でしたが、彼らにとって最良のものがまだ何であるかわかりません。そして、それを見つけるには時間がかかります。そして、それを見つけるのはあなたかもしれません。皆さんがこれらのビデオを見て、私が提示しようとしている機会を理解してくれることを願っています。
今、どれだけのことが変わる可能性があるか、そして私たち一人一人がそれを変えた人になれることを、皆さんに理解してもらおうとしています。私がよく考えるスティーブ・ジョブズの古い言葉があります。私たちの周りのすべての単一のものは、世界の理解に基づいて、あなたや私のような人によって作られました。
世界自体が今変化しており、私たち全員がそれがどこに向かうかを形作るのを助ける機会があります。だから、これらの機会を利用して興味深いことをしてください。これらのツールで構築してください。これらの問題に遭遇してください。自分で解決しようとしてください。
他の人がそれらをどのように解決するかを見て、これらのソリューションで遊んでください。それらを変更してください。変えてください。フォークしてください。遊んでください。T3 Codeをダウンロードして、それを粉々にしてください。自分自身またはチームのために使用する独自の内部フォークを構築してください。
これらすべてのものを壊して再構築してください。なぜなら、未来は今日の姿とは大きく異なるからです。ここには非常に楽しい機会があり、より多くの皆さんがそれを利用することを願っています。使用するインターフェースについての私の以前のビデオに基づいて構築している皆さんのUIを見るのは非常にクールでした。そして、このようなもので皆さんがどこまで行くかを見るのが待ちきれません。
皆さんがどう感じているか、そして皆さんの心の中での未来のサンドボックスが何であるかを教えてください。そして次回まで、peace nerds。
コメント