Andrej Karpathy、Techmeme LLMsは新たな創造時代を示すと語るも、監査のギャップは残る

Andrej Karpathyは、LLMには依然として根本的な弱点があるにもかかわらず、注目すべき閾値を越えたと語る。それは、自ら構築したものを確実に検査できないという弱点だ。最新のtechmeme llmsの議論は、短い指示からカスタマイズされたインタラクティブな世界を作り出すシステムに焦点を当てている。しかし、そうしたシステムは物理演算の破綻、誤った位置に置かれたオブジェクト、視覚的な不具合、欠落したインタラクションを人間が見つけることにしばしば依存している。

Karpathyは、この変化を以前のモデルテストとの比較で説明した。LLMに「自転車に乗るペリカン」のSVGを生成させる問いは、かつてコード、幾何学、物体間の関係に対する理解を明らかにした。新しい課題ははるかに大きい。現在のモデルは、アニメーション、カメラ、照明、シミュレートされた挙動を備え、探索可能なシーンを支えるソフトウェアまで生成できる。

この規模は、成功の定義を変える。もっともらしいコードを数千行生成することは、一貫性のある世界を生成することと同じではない。中心的な競争は、いまや生成と検証の間にある。モデルは、完成した体験を知覚、テスト、修復するよりも速く、成果物を拡張できる。

Techmeme LLMsはペリカンテストの先へ進む

Karpathyの投稿は、個別の出力を評価する段階から、完全な体験を評価する段階への移行を示している。

元の投稿でKarpathyは、この分野が「自転車に乗ったペリカン」のSVGを作るようなテストの領域を離れつつあると述べた。LLMは、求めに応じて生成される超カスタムな世界へ向かっていると説明した。

この投稿は、2026年8月2日にTechmemeの議論を通じて広まった。付随する素材では、架空のシーンをアニメーション付きの3次元で解釈したものが示された。そこには、生成されたコード、キャラクター、環境要素、動き、カメラの挙動が組み合わされているように見えた。

公開されている素材は、管理されたベンチマークを示すものではない。そこには、使用されたすべてのプロンプト、介入、再試行、手動修正が明らかにされているわけでもない。したがって、このデモは自律的な世界生成の証明ではなく、可能なワークフローの証拠として扱うべきだ。

その留保を踏まえても、この変化は重要である。SVGは比較的小さな表面積を持つ、範囲の限定された成果物だ。ブラウザベースの世界には、多数の相互作用するシステムが含まれ、それぞれが別々に失敗し得る。

モデルは、オブジェクトの位置、スケール、色、素材、移動経路を選ばなければならない。レンダリングコード、タイミング、カメラ配置、アニメーション状態、ユーザー操作も管理する必要がある。また、曖昧な文章を具体的な視覚的判断へと変換しなければならない。

だからこそ、ペリカンテストはそもそも有用だった。自転車には、認識可能な機械的関係がある。モデルは自転車らしく見えるものを生成できても、フレーム、チェーン、ペダル、操舵部を誤って接続することがある。

ソフトウェアでは、より大きな見栄えの裏に同じ問題が隠れる可能性がある。生成されたシーンは短い録画では印象的に見えても、別のカメラアングルでは破綻するかもしれない。ユーザーが移動した際に、オブジェクトが浮く、消える、壁をすり抜ける、あるいはサイズが変わることもある。

こうした失敗は、崩れた図よりも要約しにくい。単一の静止フレームではなく、時間をまたぐ相互作用から生じるためだ。レビュアーは世界を探索し、以前の状態を記憶し、どの結果が意図した設計に反するのかを理解しなければならない。

Simon Willisonが更新を続けるペリカンコレクションは、視覚テストが注目を集めた理由を示している。異なるモデルは有効なSVGコードを書けても、同じ依頼に対して視覚的には大きく異なる解釈を生成し得た。その出力は、通常のコーディングベンチマークが見落としがちなギャップを露呈させた。

ただし、ベンチマークでの成功は飽和し得る。モデルがよく知られたテストパターンを再現できるようになると、そのプロンプトは広範な能力と、特定の訓練や記憶された慣例とを区別できなくなる。より大きく予測しにくい環境は、誤りを明らかにする余地を増やす。

したがって、最新のtechmeme llmsをめぐる議論は、主として表示された世界が芸術的な称賛に値するかどうかを問うものではない。AIによる創造の単位が拡張したかどうかを問うものだ。証拠は、それが拡張したことを示唆している。

ユーザーはもはや、画像、段落、コンポーネント、スクリプトだけを依頼する必要はない。一人の人のために調整された一時的な体験を記述できる。モデルは、ユーザーが待つ間にコードからその体験を組み立てられる。

これは従来のゲーム開発とは異なる。スタジオは幅広い利用者に向けた共有製品を作り、リリース前にテストする。一方、オンデマンド生成では、ソフトウェアを一時的で、個人的で、安価に依頼できるものとして扱う。

教師は、歴史的な場面をインタラクティブに表現するものを依頼できる。子どもは就寝前の物語に基づく小さな世界を求められる。プロダクトチームは、本番開発に取りかかる前に、文章で書かれたシナリオをナビゲート可能なプロトタイプへ変換できる。

こうした成果が重要であるために、映画のようなリアリズムは必要ない。低忠実度の生成世界でも、空間的な関係、インタラクションのアイデア、物語の展開を伝えられる。その価値は、磨き上げられた完成度ではなく、具体性と速度から生まれ得る。

その結果、このデモは問いを変える。もはや単に「LLMは依頼されたオブジェクトを描けるか」ではない。より難しい問いは、「探索される間、そのシステムの一貫性を維持できるか」だ。

オンデマンドの世界はクリエイティブソフトウェアに圧力をかける

直近で圧力を受けるのは、あらゆるインタラクティブ体験に長期の手作業による制作工程が必要だと想定するツールだ。

従来のクリエイティブソフトウェアは、執筆、イラスト、モデリング、アニメーション、プログラミング、テストを分離している。専門家はファイル、エディター、レビュープロセスを使い、それらの段階をまたいで作業を進める。生成システムは、複数の段階を一つの会話型インターフェースへと圧縮する。

この圧縮は、プロトタイプの経済性を変える。かつて文書の中にとどまっていたコンセプトが、動作するシーンになり得る。チームは、完成したアセットへ投資する前に、タイミング、スケール、インタラクションを評価できる。

短期的に最も有力な用途は、完成された商用ゲームを置き換えることではない。使い捨てのシミュレーション、視覚的な説明、物語のスケッチ、インターフェース実験を生成することだ。これらの出力は、焦点を絞った問いに答えるのに十分な期間だけ存続すればよい。

ゲームデザイナーは、あるメカニクスが理解しやすく感じられるかをテストできる。映画制作者は、シーンのおおまかなブロッキングを検討できる。教育者は、一人の学習者の興味に合わせた探索可能な教材を作れる。

ナレッジワーカーも、ノートをインタラクティブな表現へ変換できる。AIナレッジベースは、こうした依頼の基となるソース資料を保持できる。生成された体験に追跡可能性が必要となるとき、その文脈は重要になる。

より大きな機会はパーソナライゼーションにある。従来のメディアは通常、すべての視聴者に同じ成果物を提供する。生成ソフトウェアなら、各セッションに合わせてキャラクター、複雑さ、テンポ、言語、題材を変えられる。

カスタマイズされた世界は、ほんの数分前に提供された情報に応答できる。ユーザーのプロジェクト、架空のキャラクター、学習目標、好みの視覚スタイルを取り込むこともある。そのため出力は、静的なメディア作品よりも生成されたアプリケーションに近くなる。

Google DeepMindは、行動後に環境がどのように変化するかをシミュレートするワールドモデルを通じて、関連する方向性を追求してきた。Genie 3の研究では、テキストから720p、毎秒24フレームで生成される、ナビゲート可能な世界が説明されている。

DeepMindは、そうした環境が数分間にわたって一貫性を保てると報告した。同時に、限定的な行動空間、複数の独立したエージェントをモデル化する難しさ、不完全な地理的精度も認めている。こうした限界は、印象的な映像だけでは不十分である理由を示す。

Karpathyの例は、異なる技術的経路を示している。LLMは、ブラウザが実行する従来型のグラフィックスコードを書ける。専用のワールドモデルは、前のフレームとユーザーの行動に基づいて、将来の視覚状態をより直接的に生成する。

両方の経路は応答性のある環境を目指しているが、異なる失敗モードを露呈させる。生成コードは、検査可能なプログラム構造と決定論的な実行を提供する。それでも、幾何学、物理、物語上の意味について誤った前提を含む可能性がある。

ワールドモデルは、すべてのオブジェクトを明示的に構築せずとも、より自然な映像を生成できる。その内部状態は、開発者にとって検査しにくい場合がある。インタラクションがモデルの有効な記憶の範囲を超えて長引くと、一貫性も低下し得る。

こうしたアプローチはいずれ収束する可能性がある。エージェントがシーンロジックを書き、生成メディアモデルを呼び出し、レンダリング出力を観察し、両方を修正するかもしれない。完成したシステムは、記号的な構造と視覚生成を組み合わせることになる。

この見通しは、既存のゲームエンジン、デザインツール、クリエイティブスイートに対し、エージェントがより容易に操作できるようになることを求める圧力となる。これらのインターフェースは、キャンバスを見て微妙な視覚的フィードバックを理解できる人間のために作られてきた。

テキストを介して操作するLLMには、同じ体験が自動的に与えられるわけではない。ソースコード内のあらゆるオブジェクトを把握していても、最終的なシーンがどのように見えるかを見落とす可能性がある。ツールメーカーは、スクリーンショット、シーングラフ、テスト操作、構造化された診断情報を公開しなければならない。

コーディングエージェントは、この移行がどれほど急速に起こり得るかをすでに示している。Anthropicは、2025年10月から2026年4月にかけて実施された約40万件のClaude Codeセッションを調査した。コーディングエージェントに関する研究では、検証の測定が会話内での明示的な確認に一部依存していたことが判明した。

この点は、ソフトウェア開発を超えて重要である。成功がモデル自身によるタスク完了の宣言に依存するなら、結果は実際より信頼できるように見える可能性がある。インタラクティブな世界は、この測定上の問題を可視化する。

生成されたアプリケーションは、コンパイルして起動できても、その目的を果たせないことがある。操作は扱いにくいかもしれない。シーンはソースを誤って表現しているかもしれない。最も重要なインタラクションが、まったく機能しないこともある。

したがって、クリエイティブツールには、エージェントが実際に利用できるフィードバックを提供する圧力がかかっている。成功する統合は、モデルが単により多くのコードを生成するのではなく、挙動を検査できるよう支援しなければならない。

生成はネイティブな知覚を追い越している

中心的なトレードオフは単純だ。モデルは、自らが確実に探索・監査できる範囲を超える状態空間を作り出せる。

状態空間とは、異なる行動を通じてシステムが入り得る状態の集合である。小さなインタラクティブ世界であっても、多くの位置、カメラビュー、オブジェクトの状態、イベントの組み合わせを含み得る。すべての経路をテストすることは、すぐに非現実的になる。

コード生成LLMは、フィードバックがテキストで届く場合にうまく機能する。コンパイラは構文エラーを特定し、該当する行を指し示せる。テストは明確な合格・不合格の結果を返せる。

視覚的な品質が、このように明確なフィードバックを提供することはめったにない。プログラムは正しく実行されていても、不可能または分かりにくいシーンを提示する可能性がある。キャラクターの足が地面を滑っていても、例外は発生しない。

モデルがその種の問題を見つけるには知覚が必要だ。レンダリング出力を取得し、オブジェクトを認識し、それらを指示内容と比較し、その関係に意味があるかを判断しなければならない。さらに、目に見える欠陥を正しいコードへ結び付ける必要がある。

現在のマルチモーダルシステムは、そのループの一部を実行できる。スクリーンショットを解釈し、多くの視覚要素について推論できる。また、ユーザーから不具合の説明を受け取った後にコードを修正することもできる。

しかし、そうした能力が信頼できる自己監査を保証するわけではない。誤ったレイアウトを生成した同じモデルが、スクリーンショットを確認する際にも同じ前提を繰り返す可能性がある。微妙なエラーを見落としたり、意図的なデザインだと合理化したりすることもある。

マルチモーダルな自己フィードバックに関する研究は、可能性と限界の両方を示している。Volcano researchでは、視覚的フィードバックがモデルの初期応答の修正を助け、ハルシネーションを減らせることが示された。ただし、そのためには単なる生成ではなく、設計されたフィードバックプロセスが必要だった。

この区別こそがKarpathyの主張の核心だ。モデルは世界を構成する要素を出力できても、その世界を継続的かつ本来的に体験しているわけではない。そのアクセスは、多くの場合、選択されたフレームを取得したり、選択された状態を記述したりするツールに依存している。

人間の開発者は、動き、タイミング、バランス、視覚的な階層を同時に見る。カメラを動かし、想定外の操作を試し、何かがおかしいと感じることができる。こうした観察は、言語による指示になる前に起きている。

LLMが受け取るのは、通常、より薄い表現だ。1枚のスクリーンショット、コンソールログ、あるいはテキストのシーングラフを調べるかもしれない。どの形式も、人間のレビュアーが利用できる情報の一部を欠いている。

スクリーンショットは時間を停止させる。ログはプログラムされたイベントを記録するが、見た目は記録しない。シーングラフはオブジェクトを記述する一方、その構図が意図した意味を伝えているかどうかは捉えられない。

動画は動きを保持できるが、動画のレビューには別の課題がある。モデルは多数のフレームから重要な瞬間を特定し、それをプログラムの状態に結び付けなければならない。長時間の録画は、大量のコンテキストと計算資源も消費する。

ここには非対称性が生じる。さらに1,000行のコードを生成することは安価かつ高速かもしれない。一方、その結果を多くの状態で慎重に動作させるには、レンダリング、知覚、推論、修正を繰り返す必要がある。

そのため、システムは確信よりも速く複雑さを拡大できる。生成されるインタラクションが増えるたびに、隠れた欠陥を含む可能性のある経路が1つ増える。出力が増えるほど、より優れた評価が必要になる。

この問題は、オートコンプリートからコーディングエージェントへの移行に似ている。オートコンプリートは、開発者がすぐに確認できる小さな変更を提案する。エージェントは、人間が結果を確認する前に、多数のファイルを変更してコマンドを実行できる。

インタラクティブな生成は、この傾向をさらに増幅する。誰かがカメラ、物理演算、操作、物語の正確性、アクセシビリティを検証する前に、モデルは完全なシーンを構築できる。出力が一見完成していることが、慎重なレビューを妨げる可能性もある。

ここでいう「本来的な知覚」という言葉には注意が必要だ。現代のマルチモーダルモデルは、画像、動画、音声、テキストを処理できる。隔たりは、知覚が自律的な制作ループにどれほど信頼性高く統合されているかに関するものだ。

ソフトウェアを監査するために、モデルが人間の意識を持つ必要はない。関連する証拠への信頼できるアクセス、適切な評価基準、そして新たな失敗を持ち込まずに修正する能力が必要だ。

こうした要件は、多くの創造的判断が主観的であるため、依然として難しい。正しいカメラアングルやアニメーション速度が1つだけとは限らない。しかし、テストできるほど客観的な問題もある。

オブジェクトが予期せず交差してはならない。操作は文書化されたアクションを起動すべきだ。必要なキャラクターが表示されるべきだ。要求されたシーケンスは正しい順序で発生すべきだ。

有用な監査システムは、こうした機械的なチェックと美的な好みを分けなければならない。衝突やイベント完了は自動テストしつつ、トーンや構図の判断は人間に委ねることができる。

将来のシステムは、複数の評価器を組み合わせる可能性が高い。静的解析はコードを検査できる。自動テストはインタラクションを実行できる。視覚モデルはフレームをレビューし、人間は曖昧な創造的選択を判断する。

そのスタックが信頼できるものになるまで、生成された世界は完成品というより野心的なプロトタイプに近い。その価値は現実のものだが、その正しさを規模から推測することはできない。

デモはまだ汎用的な世界構築ベンチマークではない

印象的な生成シーンは、モデルが物理空間、物語上の意図、あるいは自身の誤りを理解していることの証明にはならない。

公開された事例には、いくつかの検証上の空白がある。観察者はプロンプト作成プロセスの完全な記録を持っていない。また、表示された結果が現れるまでに、どれほどの選別が行われたかも判断できない。

強力なデモは、1回のリクエスト、多数の再試行、あるいは広範な人間の支援から生まれる可能性がある。どのワークフローも異なる能力を示す。この文脈がなければ、自律性について確固たる結論を出すのは早計だ。

元となる素材も、よく知られた架空のユニバースとつながっているように見える。有名な物語には、オンライン上に膨大なテキスト、画像、解説、ファン制作物がある。こうした学習上の接触は、モデルが期待されるキャラクターや設定を推測する助けになり得る。

より強力なテストでは、未知の素材を使うべきだ。評価者は、学習コーパスに含まれていない新しいシーンを提供できる。その場合、モデルは提供された説明に基づいて世界を構築する必要がある。

テストでは、完全なインタラクション履歴も保存すべきだ。研究者には、プロンプト、ツール呼び出し、生成ファイル、修正、失敗した試行が必要になる。短い動画では、出力に至った経緯を明らかにできない。

最新のAndrej Karpathy LLMs discussionには、この理由から熱意と批判の両方が含まれている。支持者は、カスタマイズされた創作のためのより大きなキャンバスを見ている。批評家は、統制された評価を欠く、視覚的には魅力的なデモだと捉える。

どちらの反応も重要な点を指摘している。一般知能を証明しなくても、出力は有用であり得る。人間のレビューを必要としても、プロトタイプは時間を節約できる。

このシステムを「world builder」と呼ぶことも、技術的な違いを曖昧にする危険がある。JavaScriptを通じて生成されたブラウザシーンは、学習済みシミュレータと同等ではない。プログラムにエンコードされたルールに従っている。

そのルールは物理的な振る舞いを近似できても、物理を理解していることを意味しない。落下するオブジェクトは単純な方程式に従って動くかもしれない。それは、モデルがシミュレートされたシステムのあらゆる結果を予測できることを意味しない。

一方で、一貫したグラフィックスコードを書くには、意味のある能力が必要だ。モデルは言語を座標、オブジェクト、変換へと対応付けなければならない。この結果を単なるオートコンプリートとして退けることは、そこに含まれる統合作業を見落としている。

正しい解釈は、その両極端の間にある。LLMによる世界生成は、より広範なソフトウェア合成を示している。しかし、完全な視覚的自己検証を示したわけではない。

このワークフローを検討するチームは、ループ全体を評価すべきだ。最初の結果がどの程度の頻度で機能するか、何回の修正が必要か、どの欠陥が自動チェックをすり抜けるかを測定すべきである。

また、変化への対応もテストすべきだ。ある象徴的なシーンで成功するモデルでも、キャラクター、カメラ位置、制約が変われば失敗する可能性がある。信頼できるシステムは、オンラインで共有される人気の事例の外にあるリクエストにも耐えなければならない。

セキュリティも別の懸念を生む。生成されたインタラクティブソフトウェアには、依存関係、ブラウザ権限、ネットワーク呼び出し、または安全でないコードが含まれる可能性がある。視覚的な成功は、それらのコンポーネントが適切かどうかを何も示さない。

パフォーマンスも重要だ。シーンは制作者のコンピュータでは滑らかに動作しても、モバイルハードウェアでは失敗するかもしれない。生成されたジオメトリ、テクスチャ、アニメーションループは、明白な警告なしにメモリや処理時間を消費し得る。

アクセシビリティは見落としやすい。キーボード操作、読みやすいラベル、モーション制御、代替説明は、派手なデモに自動的に現れることはほとんどない。こうした品質には、明示的な仕様とテストが必要だ。

著作権とアイデンティティに関する問題も未解決のままだ。ユーザーは、保護されたキャラクター、認識可能な人物、既存のゲームに基づく世界を要求できる。それらを生成する技術的能力は、権利や配布の問題を解決しない。

これらの弱点は、Karpathyの観察を無効にするものではない。その観察を信頼できる製品カテゴリーへ変えるために必要な作業を定義している。

信頼できるベンチマークでは、非公開のプロンプト、未知の参照資料、再現可能な採点を用いるべきだ。空間的一貫性、インタラクション完了、視覚的正確性、パフォーマンス、安全性、検出されたエラーからの回復を評価すべきである。

最も重要なのは、自己修正をテストすることだ。モデルには実行中の世界へのアクセスを与え、意図的に導入された欠陥を特定し、その原因を突き止め、詳細な人間の指示なしに修復させるべきだ。

それは制作能力以上のものを測定する。生成と知覚が1つの信頼できるループになりつつあるかどうかを明らかにする。

Techmeme LLMsの瞬間の後に何が起きるべきか

3つのシグナルが、オンデマンドの世界が信頼できるツールになりつつあるのか、それとも印象的なデモにとどまるのかを示す。

第1のシグナルは、再現可能な世界構築評価の登場だ。これらのテストでは、プロンプト、環境、採点ルール、完全なエージェントトレースを公開すべきだ。非公開のテストケースは、モデルが見慣れたバイラル事例向けに最適化される可能性を減らす。

有用な評価は、制作と監査の両方のパフォーマンスを採点する。モデルは未知の説明からシーンを構築し、その後、複数のカメラ位置からそれを検査するかもしれない。評価者は欠陥を導入し、システムがそれを見つけられるかを測定できる。

こうしたベンチマークが無関係なタスク全体で一貫した向上を示すなら、Karpathyの論点はより強くなる。この分野は、モデルが転用可能な空間的・インタラクティブなスキルを学んでいることを示せるだろう。個別のソーシャル投稿での成功の重要性は下がる。

失敗すれば、その主張は弱まる。認識可能な物語や特定のグラフィックスライブラリの外でパフォーマンスが崩壊するなら、見かけ上の移行は専門化されたコーディングの流暢さを反映している可能性がある。それはまだ、汎用的なオンデマンド世界生成を意味しない。

第2のシグナルは、コーディングエージェント内でより緊密に統合される知覚だ。開発者は、生成されたアプリケーションを自動的に起動し、インターフェースを巡回し、フレームを記録し、動きを検査し、可視的なエラーをソースコードへ結び付けるエージェントに注目すべきだ。

スクリーンショット対応だけでは十分ではない。エージェントには、時間的記憶と体系的な探索が必要だ。どの状態をテストし、どの状態が未検証のままかを把握しなければならない。

システムは証拠も保存すべきだ。レビュアーには、エージェントが何を観察し、どの基準を適用し、なぜ結果を完成と判断したのかを示すログが必要になる。この記録は、ユーザーに要約を信用させることなく、レビューを迅速化できる。

主要なエージェントが信頼できる視覚的回帰テストを導入すれば、監査の隔たりは縮まる。視覚的回帰テストは、バージョン間のレンダリング出力を比較して、意図しない変更を特定する。エージェントは、考えられる原因を説明することで、その手法を拡張できる。

進展がより精巧なコードの生成にとどまるなら、その隔たりは広がる。ユーザーは、より多くの隠れた状態を持つ大規模な成果物を受け取る一方で、確信はそれに比例して高まらない。

第3のシグナルは、コード化されたシーンと学習済み世界モデルの収束だ。Google DeepMindの取り組みは、直接的でリアルタイムな環境生成を示している。LLMベースのコーディングは、編集可能な構造と、確立されたソフトウェアツールへのアクセスを提供する。

統合されたシステムでは、コードがルール、インターフェース、永続状態を担うことができる。世界モデルは、視覚的な詳細、多様性、シミュレートされた振る舞いを提供できる。監査エージェントは、両方の出力を元の要求と照合できる。

この収束は、エンターテインメントを超えた応用を支えるだろう。トレーニングシミュレーションは学習者に適応できる。製品チームは現実的な利用シナリオを生成できる。ロボットは、物理空間に入る前に、多様な環境内で練習できる。

同時に、誤りのコストも高まる。欠陥のあるシミュレーションは、エージェントに誤った行動を学習させる可能性がある。個別化されたレッスンは、説得力のある視覚的詳細とともに、誤った関係性を提示する可能性がある。

そのため、パーソナライゼーションには来歴情報を伴わせる必要がある。ユーザーは、生成された世界がどのソース資料によって形づくられたのかを追跡できるべきだ。また、どの構成要素が取得されたものではなく推論によるものなのかも把握する必要がある。

knowledge blendingのためのツールは、生成された説明をソースの文脈に結び付けておくのに役立つ。検証に取って代わるものではないが、体験とそれを裏付ける資料の隔たりを縮めることはできる。

短期的な勝者が、必ずしも最も華々しいデモを生み出すとは限らない。勝敗を分けるのは、依頼、作成、観察、テスト、修正のループを閉じられるかどうかだ。

そのループには、合理的な停止ルールも必要となる。すでに機能しているシーンを繰り返し変更するエージェントは、わずかな視覚的改善を追うあまり、回帰を引き起こしかねない。ブロッキングな不具合と美的な好みを区別しなければならない。

特に意味やセンスに関しては、人間によるレビューが引き続き重要になる。目標はレビュアーを排除することではない。承認を求める前に、モデルが明白な失敗を発見できるようにすることだ。

したがって、より広いAndre Karpathy LLMsの論点は、最初に見えるほど祝祭的なものではない。生成の対象は成果物からシステムへと広がったが、評価は同じ速度で拡張されていない。

この不均衡は、今後数カ月にわたってプロダクト設計を左右する。より多くの企業が、即座に作れるアプリ、ゲーム、シミュレーション、インタラクティブストーリーを売り込むだろう。そこで決定的な機能となるべきなのは、それらの体験が実際に検査されたことを示す証拠だ。

techmeme llmsの瞬間は、開発者にあらゆる新しいデモへの有用な問いを与えてくれる。モデルは何を作り、そしてその結果を理解していたことを示す証拠は何か。

同じ問いを、自分のAI生成プロジェクトにも投げかけてみてほしい。エージェントに、検査した状態、見つけた不具合、完了判断の根拠を列挙するよう求める。その後、エージェントが一度も言及しなかった経路をテストする。そこでプロジェクトが失敗するなら、欠けているのは別の生成モデルではない。信頼できる監査ループだ。