本動画では、AIツールの進化が既存の開発ツールやフレームワークに与える影響について深く考察している。OpenAIのSam Altmanへの直接の質問を通じて、AIモデルが新しい技術を学習する能力の限界と可能性を探る。現在のAIモデルは学習済みの知識に依存しており、トレーニングデータに含まれない新しいフレームワークや構文への対応が困難である。トークン化やコンテキスト管理の仕組みを詳細に解説しながら、モデルが既存の構文に最適化されているために新技術への適応が制限される技術的理由を明らかにする。Samは将来的にモデルが新しい情報を学習できるようになると楽観視しているが、筆者は現実的な懸念を持ち続けている。Reactコンパイラー、UV、Bunなど既存APIとの互換性を保つドロップイン型ツールの台頭と、ConvexやTailwind V4のような根本的な変化を要求する革新的技術との間のジレンマを提示し、開発の未来における重要な問いを投げかけている。
AIツールと既存技術の未来への懸念
最近の新しいAIツールについて、私が懸念していることの一つは、私たちが毎日使っている非AIツールに何をもたらすかということです。フレームワークから言語、そしてすべてをまとめるために使っているライブラリまで、これらすべての基礎的な構成要素があります。そして私が恐れているのは、AIが今日動作しているそれらの使い方しか知らなければ、それらが改善されることは二度とないのではないかということです。
これは私が過去に何度も提起してきた恐怖です。そして数日前、本当に幸運なことにOpenAIのオフィスでライブ配信があり、Sam Altmanが登場して私たち開発者に未来がどのようになり得るかについて話してくれました。だから当然、マイクを手にした瞬間、私は自分に問いかけなければなりませんでした。あなたはここに可能性を見ていますか?私たちは現在存在する技術から基盤を作っていて、それが将来入れ替えるのを難しくするのではないでしょうか?
私たちは正しい方向に進んでいると思います。そして、アップデートや新しいものの使用、人間よりもさらに速く新しいスキルを学ぶことが、今後数年のうちに実現することを願っています。私には懸念がありますが、Samの回答は正直なところ、私をかなり希望に満ちた、そしてワクワクした気持ちにさせました。私は彼が新しいことについて学ぶことを考えていることが好きですし、モデルが人間と同じように新しいことについて学べるようにすることを確実にしようとしていることが好きです。ちょうどあなたがこれから新しいことについて学ぼうとしているように、それが今日のスポンサーです。
G2Iによる採用革命
あなたは採用担当者ですか?創業者ですか?それとも人を雇う必要がある誰かですか?これは見てください。なぜなら、あなたは2026年のようにコーディングしているかもしれませんが、おそらくまだ80年代のように採用しているからです。なぜ私たちは、AIが生成した質の低い履歴書を回し合って、その中から一つのダイヤモンドを見つけられることを期待し、そしてもしかしたら、ほんのもしかしたら、その山のような応募が一人の優秀なエンジニアをもたらすかもしれないという賭けをしているのでしょうか。ほぼ確実に何人かのダメなエンジニアももたらすことになるでしょう。でも、サイコロを振るだけですよね?そうですよね?
私が投資している会社は違います。なぜなら、私は全員を同じ場所に向かわせているからです。G2Iです。優秀なエンジニアを雇う最良の方法です。これが以前は存在しなかったことは正直驚きですが、8,000人のエンジニアを抱えている人なら誰でも、彼らを使って自分の会社を作るか、伝統的な採用会社を運営するだろうというのは理解できます。
しかしG2Iは別の道を選びました。彼らは採用を修正したかったのであり、それがどれほど壊れているかに対して料金を請求したくなかったのです。G2Iを通じて採用を始めると、簡単な電話をします。共有のSlackチャンネルを設定します。候補者に聞きたい質問をいくつか提供します。彼らはあなたとあなたがやっていることに最も適していると思う候補者を手作業で選びます。
大勢のジュニアエンジニアでも、短期契約のための非常に経験豊富な何人かでも。あなたのニーズが何であれ、彼らは把握するのを手伝ってくれます。彼らは最良の候補者を見つけます。あなたが提供したすべての質問を彼らに尋ねます。彼らはビデオ回答を取得して、それをあなたに送ります。そしてあなたは誰が最良だと思うかを選びます。
そしてもしあなたがそれほど良い判断者でなくても、それも大丈夫です。なぜなら、7日間のトライアルがあるからです。私はこれが大好きです。なぜなら、従業員が嫌いな職場に行き着くことがなく、雇用主が嫌いな従業員を抱えることもないからです。これは特にヘルスケアなどの問題で米国での採用の仕組みによって面倒なことの一つです。
そして彼らはそれを解決しました。私は自分の従業員のために7日間のトライアルがあったら良かったと思いますし、以前話していた会社でも従業員として7日間のトライアルがあったら良かったと思います。One PasswordからWeb Flow、Automatic、Meta自身まで、全員がG2Iを採用の手助けに使っている理由があります。
それは、彼らが驚異的なネットワークを持ち、それらの人々を適切な会社と結びつけようとする驚異的に才能のあるスタッフがいるからです。私はG2Iと働いた多くの人を知っていますが、後悔した人は一人も知りません。soyv.link/g2iで2026年のように採用を始めましょう。
Sam Altmanへの完全な質問と回答
先ほど再生したのは、私が尋ねたことやSamが言ったことの非常に小さなカットでしたが、このトピックに深く入る前に全体を聞く価値があると正直思います。だからそれから始めましょう。
少し違うこと、より技術的な側面について尋ねたいのですが。私は使用する構成要素のような技術が進化することが本当に好きで、TypeScriptやTailwindなどのようなWeb世界のいくつかの狂った革命に立ち会ってきました。モデルや構築に使用するツールが良くなるにつれて私が持っている恐怖の一つは、米国の電力網が特定の方法で構築されていて、それが事態を悪化させていて、本当に変更できないように、私たちは今物事が機能している方法で立ち往生するかもしれないということです。
ここに可能性を見ていますか?私たちは現在存在する技術から基盤を作っていて、それが将来入れ替えるのを難しくするのではないでしょうか?なぜなら、現在のモデルに2年前に起こった技術のアップデートを使わせようとしても、歯を抜くような感じがすることがあるからです。
モデルを十分に操縦して新しいものを使わせることができると思いますか、それとも私たちは今構築している技術の改善を終えたのでしょうか?
私たちはモデルに新しいものを使わせるのが本当に得意になると思います。基本的に、これらのモデルを正しく使用している場合、それらは汎用的な推論エンジンのようなものです。
現在の私たちのアーキテクチャでは、それらにも莫大な量の世界知識が組み込まれています。しかし、私たちは正しい方向に進んでいると思いますし、アップデートや新しいものの使用、人間よりもさらに速く新しいスキルを学ぶことが、今後数年のうちのマイルストーンになることを願っています。私たちが非常に誇りに思うマイルストーンは、モデルが完全に新しいもの、新しい環境、新しいツール、新しい技術、何でも提示されたときです。
そして一度説明するか、つまりモデルが一度それを探索すると、それを非常に確実に使用して正しく理解できるようになります。そしてそれはそれほど遠くないように感じます。
これは本当に良い答えだと思いました。人々はOpenAIやSamを批判するのが大好きなのは知っていますが、私は彼が本当にほとんど奇妙なほど透明だと感じています。
彼の頭の中で起こっていることと彼の口から出てくることの間に多くの層があるようには感じません。それらは非常によく一致していて、彼は私が今見ているものを両方とも見ていることが明らかです。つまり、トレーニングデータにない新しいものをモデルに与えると、それは下手だということです。しかし、将来のモデルがこれを改善できれば、これは解決されることになります。
そしてこの仕事が解決されるまで、彼は自分の仕事が終わったとは考えていません。モデルが学習し、新しい情報に適応するというこのアイデアはまだ実現していません。しかし、それは彼が近い将来に起こることを期待していて、目指しているものです。しかし、私はこれよりもずっと深く掘り下げたいです。なぜなら今、これは私たちが今日使用しているモデルの最大の問題の一つだからです。
モデルは学習できない
モデルは何も学習できません。私たちがモデルを使用している時点で、それは学習能力を失っています。それは持っている知識で動作することはできますが、私たちは事実上その能力を凍結しました。これを開発者として考えようとすると、ランタイムとコンパイラの違いのようなものです。ランタイムは新しいコードを入れることで新しい機能を追加できます。
しかしコンパイラは、コードがコンパイルされると、その能力は今や固定されています。何かをコンパイルしている場合、それはコンパイルされたことしかできません。ランタイムを与えられたときは、何でも渡すことができます。モデルは今まさにコンパイラのようなもので、すべての情報が入り、すべてのトレーニング技術が入り、結果は多くの能力を持つものです。
ほぼ無限に感じられる量の能力を持っていますが、問題もあります。なぜなら、モデルを作成するプロセスに含まれていなかったものは存在しないからです。特定の方法で操縦することはできます。そしてこれがLLMを非常に奇跡的にするものの一つです。つまり、特定のコンテキストのセット、動作している対象となるトークンのセットを与えると、たとえトレーニングデータになくても、あなたが望むことに非常に近いことをさせるように特定の方法で操縦できます。
Reactの例を通じた説明
だから、あなた方全員が私のことで知っている基本的な例を使うために、Reactについて考えましょう。Reactフレームワークには、LLMにとっていくつかのユニークな利点があります。コンポーネントがカプセル化されている方法は、他のものを理解することなく一つを編集できて良いということを意味します。構文がJavaScriptとHTMLの両方に非常に似ているという事実は、意味をなす部分において、両方のトレーニングデータがある程度Reactに適用されることを意味します。そして世界中のReactコードの膨大な量と、標準の人気、そして現在何十年も構文がどれほど一貫しているかという事実。
これらすべてが、ReactがLLMにとって良いということ、そしてほとんどのLLMが多くのReact知識を事実上焼き込んでいることに加算されます。つまり、モデルにReactコードを書かせたい場合、そのすべての情報は事実上すでにモデル内に存在しています。しかし、私が何か新しいフレームワークを作ったとしましょう。TactまたはT3actと呼びましょう、私の特別な新しいフレームワークです。そしてそれは独自の構文を持っています。
このようにする代わりに、代わりにこのようにします。つまり、括弧の代わりにコロンがあるとか、そういうことです。アイデアは分かりますよね。モデルが持っているすべてのデータは異なる形式です。そしてモデルの動作方法は事実上オートコンプリートです。だから、開始タグdivとhelloという単語のトークナイザーを見てみましょう。
これが行ける場所はいろいろあります。モデルはこの後に何が来ると思うかを決定しなければなりません。worldを決定してから終了タグを決定することができます。モデルがこれすべてを評価する方法は、これらのトークンを持っているということです。だからdivの開始があり、ちょうど閉じ括弧があり、タブがあり、そしてもう一つ空のスペースとhelloがあります。
モデルは基本的に、コンテキストにあるものに応じて数学が変化するさまざまなものを指す多くのベクトルを持っています。だからこのすべての情報は、いくつかの異なるパスに向かって指し示します。一つは、次のトークンがworldという単語である可能性があります。なぜなら、誰かがhello worldと書くことが非常に一般的だからです。
最も一般的なのは次にタグを閉じることである可能性があり、実際にはそれらの二つのトークンだけで始まります。なぜなら、閉じ括弧だけがトークンで、残りは異なるからです。実際には、私がいくつかの楽しい研究で聞いたことがある興味深いことです。Openでも自ら公開しています。彼らは閉じ括弧トークンが一つのトークンとして留まることを確認するために努力を払っています。なぜなら、ここで括弧スラッシュがなければ、次のものがPタグまたはボタンタグであると誤って仮定するかもしれないからです。
だから、ここでのトークン化のグループ化には開始と何であるかが含まれ、その後閉じ括弧が切り離されることに気付くでしょう。なぜなら、実際には閉じないことが非常に一般的だからです。多分on clickイコール何かをして、これらのものを分割する方法が正しい方向に最も可能性の高い次のトークンを操縦するためであることが分かり始めます。
ボタンタグの開始は完全なトークンなので、その部分を行うとき、次にどのトークンが意味をなすかを決定する計算ができるようになります。だからonが次のトークンになっているのです。なぜなら、on clickが欲しいかもしれないし、on pressが欲しいかもしれないし、on navigateが欲しいかもしれないし、何か他のものが欲しいかもしれないからです。そしてトークン化が機能する方法と、このトークン化のライブラリが20メガバイトのクソのようなものである理由は、一貫して最も可能性の高い次のピースに最も可能性の高いピースを指し示すようにこれらのものをパラメータ化できるようにするためです。
だから彼らがこれらすべての異なるバージョンのトークン化を持っている理由でもあります。そして、GPT-5からGPT-3に切り替えたとき、これらの要素をまとめる仕事においてどこにも近くない良い仕事をしていないことに気付くでしょう。そこの違いが見えますか?GPT-5と新しいOシリーズモデルは要素の開始をまとめて保つことができます。
GPT-3はそれをバラバラにし、正しい開始点を持っていないときに正しい次のトークンを取得する可能性ははるかに低くなります。私はT3 chatで適切に設定しようとしてこのクソに深く入り込みすぎました。しかし今、私たちは新しいことについて考えなければなりません。なぜなら、これが機能する理由の一部は、トレーニングされたすべてのデータと、そのデータから、埋め込みから、ベクトル化から、起こったすべての狂ったことから知っているからです。この時点から、行ける場所は限られています。
helloの次の単語、それからworldになることができます。終了タグになることができ、終了タグの開始が見えるので、最も最近のものを閉じなければならないことを知っています。だからdivを閉じることが次のことであると非常に簡単に計算できます。これが意味をなすのは、モデルが持っているデータのため、トークンが分割されている方法のため、そして私たちがポストトレーニングを行い、RLを行って、ベクトルが私たちが望む方向を指すようにすることで、モデルが私たちが望む方法で応答する可能性を高くしたためです。
しかし、データが正しく、トークン化が正しく、エンコードしている知識が正しい場合にのみ、それを行うことができます。私たちはモデルをトレーニングするとき、基本的に多くのテキストを多くの数学と交換しています。そして、入力、出力、数学、計算、そしてすべてのその部分が正しいことを確認する必要があります。
新しい構文への対応の困難さ
では、それらが異なる場合はどうなりますか?代わりにこれを行う新しい構文をここに置いた場合はどうなりますか?最適化された構文と根本的に異なるため、完全に異なる方法でパラメータ化します。これはまた、モデルがそれを受け取ると、より困難になることを意味します。
ここでも、divがここでどのように異なって分割されているか。それは本当の課題です。それはモデルがこれよりもこれを理解するのをはるかに困難にするでしょう。これらの違いは非常に一般的で、多くの層があります。これらのものがトークン化される方法は、それのほんの小さな部分にすぎません。彼らが持っているデータもあります。
彼らがトレーニング中に持っている報酬メカニズムもあり、すでに存在し、すでにサポートされている構文のために最適化されています。モデルは正しいコードを書くように設計されていますが、モデルは今日私たちが理解しているように正しいコードを書くように設計されています。正しいコードが後で何か他のことを意味する場合、モデルが基本的なレベルで機能する方法は、その将来の書き方と一致していません。
私はSamがそれが変わるということに同意しません。しかし、モデルがこれらのことを回避するのが上手になることには同意します。モデルがより賢くなるにつれて、エキスパートの混合のようなものになります。これは概念で、モデルの異なるパラメータのセットが異なるタスクに対してトリガーされます。コンテキストを管理する方法とコンテキストが重みに影響を与える方法がより強力になるにつれて。
モデルのように想像してみてください。トレーニング時に持っていたデータと今与えられているデータに基づいて最も可能性が高いものに基づいてオートコンプリートしています。この開始時に、ここに私の新しいフレームワークのたくさんの例と、それがReactとどのように比較されるかがあると想像してください。div hello world div T3 React div hello hello world div。
これらを十分にモデルに与えると、物事が指している場所が変わります。なぜなら今、コロンは一つのことを意味し、括弧は別のことを意味するからです。しかし、モデルに十分なコンテキストを与えると、その長さを構築し始めることができます。なぜなら、すべての追加トークンは、パラメータのその狂ったマップで物事が指す場所を変えているからです。
だからこれを行うことによって、私たちは事実上、非常に微妙な方法でモデルに異なる重みを与えました。私たちは、以前よりもコロンを行う可能性が高くなるようにモデルを操縦し、互いに近いコロンを行うようにしました。なぜなら、通常モデルはコロンが互いに近くにあるべきだとは考えていないからです。空のスペースの後にコロンがあるべきだとは確実に考えていません。
ほとんどのモデルは、空のスペース、それからコロン、それから空のスペース、それから何か他のものに非常に混乱するだろうと私は疑います。なぜなら、そのためのパラメータ化は奇妙になるからです。スペースそれからコロンを見てください。それがそれを行ったのは、スペースの前のコロンだけがおそらく混乱するからです。これらがあなたがこれすべてで考慮しなければならないことです。奇妙です。
複雑です。コンテキストである程度影響を与えることはできますが、それを行うにはコンテキストが必要になります。そして、いわゆる焼き込まれたインテリジェンスが減少していることを意味します。モデルが今日持っている重みに基づいて特定のレベルのインテリジェンスを持っている場合、異なる方法で指すためにより多くのコンテキストを追加することは、そのインテリジェンスがある程度オーバーライドされていることを意味します。
そしてモデルを操縦すればするほど、見ているモデルが少なくなります。また、持っているコンテキストの量に制限されることも意味します。すべての追加トークンのコストも増加させています。実際にタスクを要求する前にコンテキストウィンドウに50,000トークンの説明を入れた場合、モデルの生活をはるかに困難にしました。なぜなら、クソを生成するためにはるかに多くを再計算しなければならないからです。そして以前に行われた努力は、以前と同じように重要ではありません。
明らかに、彼らはこれらのモデルをこれらすべてのことを処理するように設計しています。しかし時間がかかります。そして、オンザフライで作業を行っているときにこれらの重みのバランスを取るためにモデルに与える適切なもののセットをどのように見つけるかは、難しい問題です。しかし、これらのモデルの要点全体は、特定量のテキストを持っていて、それをより多く生成するように指示されたときに、トレーニングを通じて持っているデータと、与えられたコンテキストの両方によって適切に影響を受けることです。
そこでのバランスは正しく取るのが本当に難しく、私たちから来るコンテキストの量とモデルとその推論ステップから来るものが根本的に変化している今、毎日物事はより奇妙になっています。推論モデルの狂った世界の前は、人がモデルに話しているとき、平均して、おそらくユーザーが提供するトークンとモデルが提供するトークンの間に50対50の分割があったと私は主張します。
今、私たちはこれらの狂ったCLIコーディングツールで物事を行っているので、バグのスクリーンショットと一緒にそれを修正するのと同じくらい小さくシンプルに行くかもしれません。それからモデルはGPSに入って、コンテキストに追加するものを見つけます。モデルは推論し、それがコンテキストに追加されます。コードベースの特性に基づいて独自のコンテキストを構築します。
Vercelがちょうど行った興味深い研究、これも独自のビデオに値するもので、おそらく近い将来に来るでしょう。彼らはスキルがコーディングエージェントにフレームワーク固有の知識を教えるための良い解決策になることを期待していました。特に、next 16に追加した新しいものと新しいReactバージョンは、モデルでは彼らが望むほど拾われていないようです。
今日の早い時点で、私は新しいGemini 2.5モデルを使用していて、config.jsファイルを持たないTailwind v4に非常に混乱して、最終的にあきらめて、より良く理解できるようにTailwind 3まで私たち全員を戻しました。スキルは事実上、モデルが利用可能なすべてのスキルを見て、どれを引き込むかを選択し、コンテキストに追加してから操作できるプル標準であるため、常にコンテキストに強制される agents MD とは対照的です。
この違いは物事を非常に興味深くします。具体的には、彼らが構築したテストハーネスは、agent MDに埋め込まれたドキュメントを使用したときに100%の成功率を得ましたが、スキルは最良のケースでも79%に達しただけで、モデルにスキルを使用するように明示的に指示した場合でもそうでした。そしてそれらの指示なしでは、スキルは実際にはまったく利益をもたらしませんでした。
AIコーディングエージェントは古くなるトレーニングデータに依存しています。Next 16はこれらの新しいAPIを導入していますが、それらは現在のモデルトレーニングデータにはありません。エージェントがこれらのAPIについて知らないとき、彼らは不正なコードを生成するか、古いパターンに戻ります。古いnextバージョンを実行していて、モデルがプロジェクトにまだ存在しない新しいAPIを提案するとき、逆のことも真実になり得ます。
私が巨大な古いコードベースを移行していたとき、これに遭遇しました。それは大変でした。そしてこれは実際に戦略の問題のいくつかを完璧に浮き彫りにします。彼らは明示的な指示、スキルを使用することを伝えることによってスキルを使用させることができました。それによってパス率が上がりましたが、非常に異なる動作をもたらしました。たとえば、スキルを使用しなければならないと伝えたとき、それはまずスキルからドキュメントを読み、それからコードベースも読むのではなく、それらのドキュメントパターンに固定します。
プロジェクトを最初に探索してからスキルを呼び出すように伝えた場合、最初にメンタルモデルを構築し、その後参照のためにドキュメントを使用します。これらのことが重要であるという事実は少し不条理です。私は日常の使用のためだけに自分でこれについての直感を構築してきましたが、それをevalで見るのは狂っています。しかし、再び、私たちは将来のツールのところに戻る必要があります。
コンテキスト管理のジレンマ
システムプロンプトまたはコードベースの理解の前に進むagents MDに、トレーニングデータにないこれらの新しいツールやソリューションについて伝える何かを入れた場合、あなたはモデルにあなたが求めることをするのを下手にしています。そしてこれが問題です。モデルに指示するために利用できるスペースは限られています。
すべて焼き込まれているものがあり、それが付属しているすべての能力があり、それから新しいものを追加することができます。それはゲームエンジンと、あなたがその中で構築しているものの違いのようなものです。ゲームエンジンに、ゲームエンジンが付属していなかった多くのものを構築することができますが、最終的には上に非常に多くのものをハックできるだけです。
そしてそれはコンテキスト管理で私たちがやっていることのようなものです。そして、特定のツールについて入れるすべてのコンテキストのビットは、実際にやりたいことのためにある程度失っているコンテキストでもあります。そしてこれは単なるコンテキストの腐敗ではありません。これは根本的にそれよりも深く行きます。モデルがその動作と特性を持っていて、それらに外部から影響を与えるために費やす努力が多ければ多いほど、他のすべての方法で失うものが多くなります。
私はこのフレーミングがとても好きです。これを考えるよりきちんとした方法は、専門化が一般化の犠牲の上に来るということです。絶対に同意します。そしてモデルがすでに持っている一般的なスキルは非常によく確立されていて、それらの良いものを回避しようとするなら幸運を祈ります。それはこれらの問題が解決できないという意味ではありません。私が見たさまざまな戦略がたくさんあります。
最近多くの注目を集めているものの一つはbeadsで、これはあなたのエージェントにメモリを追加する方法で、情報を保存して後でアクセスできます。これはAIエージェント用のGitバックされたグラフ問題トラッカーです。モデルがどのタスクを実行する必要があるか、どの情報が必要かを追跡しやすくすることを目的としています。本当にクールに見えます。
私はまだ個人的に使用していません。非常に素晴らしいかもしれません。これをメモリと問題が実行間で共有され、追跡される方法の例として皆さんに知ってもらいたかっただけです。非常に興味深い。私が試していることは、モデルがつまずくものを追跡し続けることです。あなたの agent MD ファイルは、アプリとその中での作業方法の説明だけであるべきではありません。
モデルはそのほとんどを理解できますし、モデルがすでに知っていることでコンテキストを肥大化させている場合、コンテキストを無駄にしていて、必ずしも望まない方法でそれを操縦しています。これが私が試したことです。これには利点と欠点がありました。最終的にはそれを取り除きましたが、将来もっと操縦しようとします。
これは私の agent MD にあります。これは、物事を実行するときに常にコンテキストとして入力されるファイルです。ここに、エージェントへのメモがあります。私たちはこれを一緒に構築しています。自明でないことを学ぶとき、将来の変更がより速く進むようにここに追加してください。これはここに置く間違ったコピーです。しかし、この概念はモデルが理解していないものや何が間違っているのかを見つけるために多くの作業を行うところで非常にうまく機能するようです。
情報の一部を見つけるために15のツール呼び出しを行わなければならず、情報が期待するものではない場合、次に新しいスレッドを持つときに、まったく同じことを行わなければなりません。しかし、それが間違ったときにモデルがそれらのことを理解するのを手伝い、コンパイルしようとして失敗し、それを理解する場合。
それらのことに苦労したときにモデルに伝えさせることができますし、それを自分で行っていることに気付くこともできます。それを agent MD に追加して、モデルがコードに意味のある変更を加えることができる速度を大幅に改善できます。それは奇妙なことで、このファイルを変更するのを見たときの半分以上は、変更がクソでした。しかし実際にある程度意味をなした半分の時間は。
モデルが難しいと思ったこと、混乱していると思ったことを見て、将来それをより良く操縦するためにそれを使用するのは本当にクールでした。それは一種のメモリですが、メモリは奇妙なものです。なぜなら、モデルに大量のコンテキストを与えるだけでは、実際には助けにならないからです。私はこれについて、LLMで人々が犯す単純な間違いのビデオでたくさん話しています。
より多くのコンテキストはこの問題を解決しません。コンテキストは常にトレードオフです。モデルにより多くのトークンを与えると、より多く操縦しますが、それが知っていることの代わりにあなたが書いたものに基づいて操縦しています。それが行く場所に軽い調整を行うための最小限のもののセットを見つけることができれば、成功する可能性がはるかに高くなります。だからSamがモデルの学習について話すとき、それがまだ何を意味するのか誰も正確には知りませんが、これは事実上それの解決策だというのが私の仮定です。
モデルにどの知識を引き込むかを伝える必要がある代わりに、常に知識を与えることができ、それをいつ適用するか適用しないかを知るでしょう。それは素晴らしいでしょう。または、独自のコンテキスト管理が上手になり、使用するツールが何が混乱していて何が混乱していないかを追跡し続けるのが上手になり、使用するにつれてモデルが学習しているように感じます。
物事がこの方向で本当に良くなるのを見ることができます。ここで多くの改善を期待しますが、そうならないかもしれません。より多くのものを与えるとモデルが愚かになることが判明するかもしれません。MCPやRagなどの多くのもので、これを見ました。非常に戦略的かつ具体的に、特定の孤立した方法で助けることができます。
しかし、モデルに15のMCPと無制限のコンテキストを与えるだけなら、賢くなるのではなく、愚かになります。それは一貫したことです。しかし、ツールがそれを回避する方法を見つけることができれば、私たちは良い場所にいます。だからSamが考えていることが事実上、それの外側のツールとモデル内部の能力の両方を介して、常に正しい方法でモデルを操縦することを自動化することである場合。
それは非常に理にかなっています。しかし、もし失敗したらどうなりますか?もしこれが十分に良くないことが判明し、現在持っているツールで立ち往生したらどうなりますか?nextの新機能をモデルがはるかに良く使用できるようにできない場合、それは何を意味しますか?トレーニングデータにuse cache connectionの禁止が含まれることがない場合、または既存のパターンに完全にマッピングされない新しいフレームワークがあって、モデルがそれに適応できない場合はどうでしょうか?さて、これにどう対処しますか?私はすでに対処していると主張します。
互換性を保つツールの台頭
これらのプロジェクトのほぼすべてについて興味深いことを知っていますか?新しいAPIと標準を学ぶ必要がないことが彼らの目標です。Reactコンパイラーは、既存のReactアプリを取り、コンパイラーを実行させ、結果がはるかに高性能になることを可能にします。TypeScript GoはTypeScriptコンパイラーのGoでの書き直しで、はるかに速くタイプチェックできるようにします。
ネイティブコード経由で型を除去してJavaScriptを非常に速く生成することはすでにできますが、TSGOはTypeScriptも正しいことを確認します。それは巨大です。UVはpipのドロップイン置き換えで、Python環境の管理を滑稽なほど簡単かつ速くします。Oxlintは、すべてのプラグインのエコシステムにまだ取り組んでいるESLintのドロップイン置き換えですが、prettierのネイティブ書き直しであるOx formatと並んで非常に速く進歩しています。
それからrolldownがあります。これはroll upのRustベースの書き直しで、まったく同じAPIを持っているので、roll upを直接使用している人だけでなく、viteを使用している人にとってもドロップイン置き換えになる可能性があります。それからbunがあります。これははるかに速いnodeのすべてのAPIを持つ完全に互換性のあるNode.js代替品であることを意図しています。これらすべてのツールで興味深いのは、それらを使用するために最小限からコード変更を必要としないこと、そして大部分の時間で新しいAPIを学ぶ必要もないことです。
Reactコンパイラーは単にあなたのReactを取ってそれをより速くします。TSGOは単にあなたのコンパイル時間を取ってそれらをより速くします。UVは同じコマンド、同じフォーマット、同じすべてを使用しながら、Pythonエクスペリエンスを全体的にはるかに苦痛の少ないものにします。OxlintとOx formatは単なるフォーマッターです。同じlinkコマンドを実行し、物事は同じように機能します。
Roll downは、rollupでドロップインまたは置き換えることができます。Bunはあなたのnode app全体をより速く実行することができます。これらは今私の意見で最もクールな技術であり、また採用され成功する可能性が最も高いです。なぜなら、それらのどれも何も学ぶ必要がないからです。それは私にとって地獄のようにワクワクすることです。
同時に、私たちが構築する方法を進化させるものが欲しいです。あなた方全員がこの時点で非常によく知っているように、私はConvexのようなものが大好きです。TRPCのようなものが大好きです。Tailwind V4のオーバーホールと、それがTailwindで私が持っていた多くの問題をどのように修正したかが大好きです。人々がより良い構築方法を作るために私たちがどのように構築するかの規範に挑戦することをいとわないときが大好きです。
effectのようなものでさえ、私はそれとの愛憎がありますが、そこで起こっている多くのクールなことがあり、それをもっと使いたいです。しかし問題は、これらすべてのものがコードについて考え、推論する方法に意味のある変更を必要とすることです。これらのものはすべてあなたの既存のコードベースにドロップでき、何も変更する必要はありません。
これらのものはすべて、それらが機能するためにコードベースへの意味のある変更を必要とします。そして、これらのほとんどがモデルにとって使用が難しかった理由があります。それは良くなってきています。effectは今合理的な時点にあります。Convexは全体的にモデルではるかに良くなっています。TRPCはそれがさまざまで、特にコードベースに古いバージョンのTRPCがあるときです。
それはまったくそれを理解できません。そしてTailwind V4は地獄のようでした。ほとんどのモデルは単にV3に戻ります。これは非常に悪化しているので、effect devsのような人々への推奨は、モデルにeffectコードベース全体へのアクセスを与えて、それを探しているものを見つけるためにGPSさせることです。Ben、私のチャンネルマネージャーで仲間のYouTuber Ben Davis、あなたは彼を見たことがないでしょう。
確かに、Fazeは画面に彼の情報を表示します。彼はこれのためにBTCAと呼ばれるツールを構築しました。それはクラウド内でDaytonaを使用して仮想化されたボックスをスピンアップし、レポジトリをクローンして、知らないことを見つけるためにコードベース内のものを見つけるためにopen codeでエージェントを実行します。これがBenが彼がバイブコーディングしているすべてのものでspeltとeffectを使用できる方法です。なぜなら、モデルはspeltとeffectが下手だからです。
しかし、それらのプロジェクトのフルレポジトリをクローンして、それらを探し回って物事を見つけることができれば、それは機能します。私はこれが超クールだと思います。彼はこれらのツールでモデルを動作させる方法を見つけました。そして、それは単にコンテキストを肥大化させているだけではありません。モデルが持っていない情報を取得するためにモデルが使用できるツールです。Shioamがチャットで言っているように、それは非常に過小評価されていて本当に良いです。
それを聞くのは素晴らしいです。そしてAiden Bayも似たようなことに取り組んでいます。驚きではありません。私たちは偶然にお互いのつま先を踏むことがあります。Aidenは良い友人です。とはいえ、ボトルがほとんど理解しているツールを使用しているので、この努力が必要だと感じません。そして彼がこれを必要としているという事実は、私たち両方が行うべき仕事をキューに入れて、彼がspeltでやっていて、私がReactでやっている場合、彼はクラウド内の別のモデルをトリガーするモデルを待たなければならないことを意味します。それは理解しないまたは
知らないコードベースを監査して、モデルを正しい方法で操縦するための正しい指示と正しいコンテキストのビットを持ち帰る必要があります。モデルはすでに私のために操縦されています。私はそれのどれもする必要はありません。そしてそれが違いです。モデルが、ここの下のこのようなものに投資する価値があるほど学習が上手になるかどうかわかりません。
現在、私たちがすでに書いているコードをより速くすることによって、これらのもので得られる報酬がはるかに多いときに、コードを書く方法を変えるもの。開発者は何も新しいことを学ぶ必要はありません。私たちが書いているコードを書き直す必要はありません。物事を書く方法を変える必要はありません。それは単に起こります。
そして私たちが得るツールは改善していますが、構文は必ずしもそうではありません。これが世界ですでに起こる多くの場所があります。車を見てください。車はすべて道路に収まる特定の形式と形に適合しなければなりません。その上で あらゆる種類の狂ったことをすることができますが、最終的にはその形式に適合しなければなりません。適切に制御された環境で車がどのように機能するかを理論的に再考することができます。
レーストラックの車は非常に異なり、道路の車とは異なる要件を持つでしょうが、車の99%は道路を走ることを意図しています。車の99%は、車の底部に同じ基本形状を使用しています。その上に私たちが行う他のすべては、クールで、楽しくて、いいですが、基本をそれほど変えることはできません。
それが変わるかどうかわかりません。私は間違っているかもしれません。これらのモデルが非常に効果的に学習して調整できるようになって、これのどれも重要でないところまで到達する可能性があります。しかし、そうなるかどうかわかりません。そしてそれは私が持っている懸念です。だから私は、Reactは最後のフレームワークと呼ばれる私のビデオを永遠に前に作りました。なぜなら、私はこれらのものが改善されたり良くなったりしないことをとても懸念していたからです。
そして、今日使用しているツールの形に一致する代替ツールへのすべての投資を見てワクワクしている一方で、構築する方法を完全に変えるものについても同じくらいワクワクしています。そして今日の構築方法には非常に多くの間違ったことがあります。今は決して変わらないのではないかと恐れている、単にクソである非常に多くの基本的な部分があります。そしてそれが私が恐れていることです。
だから私はSamに尋ねた質問を尋ねました。だから彼の答えは私をワクワクさせました。しかし、Reactが最後のフレームワークではないと自信がまだありません。ここでの私の懸念がすぐに軽減されることを願っています。モデルを学習させるための狂った新しいソリューションが見られることを願っています。そうすれば、新しいスレッドを作るたびにモデルのメモリを消去しているように感じません。
しかし、もしかしたら、ほんのもしかしたら、私たちはここで立ち往生しています。確実に知るのは難しいですが、あなた方全員がどう感じているか興味があります。私はあまりにも懸念しすぎですか?私はあらゆる種類の新しいものが大好きなフレームワークオタクで、だから恐れているのでしょうか?数週間ごとに新しいフレームワークがなければ、話すことがなくなるのでしょうか、それともこれは単に解決されるものなのでしょうか?正直に言うことはできません。
私がこれを共有しているのは、わからないからです。これは私がここで物事がどのように機能するかを正確に自信を持って伝える通常のビデオではありません。私はここであなたに、どこに行くのかわからないと伝えるためにいます。すべてが非常に速く変化していて、私はそのプロセスで私のお気に入りの変更のいくつかを失うかもしれないことを恐れています。あなた方全員はどう感じますか?コメントで教えてください。
そして次まで、ピースナーズ。
コメント