本動画では、元OpenAI Codexチームメンバーで数十億ドル規模のSegmentを創業したKelvin French Owenが、コーディングエージェントの最前線について語る。Claude CodeやCodexといったツールが開発者の生産性を劇的に向上させる一方で、コンテキスト管理やアーキテクチャ設計の重要性が増している現状を解説。CLIベースのツールがIDEを凌駕する理由、大企業とスタートアップの採用格差、次世代エンジニアに求められるスキルセット、そしてAIが個人の働き方をどう変えるかまで、実践的な知見と未来予測が詰まった内容である。コーディングエージェント時代における開発のベストプラクティスから、セキュリティリスク、データモデルの重要性まで、技術者必見の議論が展開される。
- コーディングエージェントがもたらす革命的な生産性
- ライトコーンポッドキャスト開始
- OpenAI時代のCodex開発
- Claude Codeの独自性とコンテキスト管理
- CLIがIDEを凌駕した理由
- ボトムアップ配布の重要性
- GEO戦略とLLMへの影響
- コーディングエージェント構築のベストプラクティス
- トップ1%ユーザーになるためのヒント
- カナリアテストとコンテキストポイズニング検出
- Claude CodeとCodexのアーキテクチャの違い
- 次世代とAIの関係
- 様々なエンジニアにとってのエージェントの価値
- 次世代エンジニアに必要な学習内容
- ADHDモードと生産性
- 40年後のソフトウェア開発の未来
- メーカースケジュールの更新版
- Segmentを今構築し直すなら
- 現在の制約と今後の展望
- テストの重要性
- エージェントのStack Overflowの必要性
- Clawdbotとエージェントネットワーク
- Codexの強みと複雑な問題
- ツールの進化予測
- Railsサポートの現実
- セキュリティとパーミッション
コーディングエージェントがもたらす革命的な生産性
Claude Codeを使っていると、まるでコードの中を飛んでいるような感覚になるんです。
CLIの中で動くこのツールは、5階層も入れ子になった遅延ジョブのバグをデバッグして、何が問題だったのかを突き止め、テストまで書いてくれる。そうすれば二度と同じことは起きません。これは本当に驚異的ですよ。
趣味レベルで実験している人たちや、小規模なスタートアップにいる人たちは、みんなコーディングエージェントを限界まで使い倒しています。他のことを考えている余裕なんてないんです。スタートアップには限られた資金しかありませんから、とにかくスピード重視で動くしかない。一方、大企業の場合は失うものがたくさんありますからね。
コーディングエージェントのトップ1%ユーザーになるためのコツは何だと思いますか。
あなたの技術スタックは何ですか。
ライトコーンポッドキャスト開始
皆さん、ライトコーンの新しいエピソードへようこそ。
ゲイリー、録画の準備はいいですか。
今プランモードに入っているところなんだけど、まあいいか。ええ、時間だね。ごめん。
ライトコーンの新しいエピソードへようこそ。今日は素晴らしいゲストをお迎えしています。Kelvin French Owenさんです。彼はOpenAIで最初にCodexを作った人物の一人で、その前には数十億ドル規模の会社Segmentを創業し、大成功を収めて売却しました。
Kelvin、ようこそ。
お招きいただきありがとうございます。
私たち全員にとって本当にクレイジーな時代ですよね。最近、私はClaude Codeに完全にハマってしまって、その感覚を説明すると、10年前の私はマラソンランナーで走るのが大好きだったんです。でも膝に壊滅的な怪我を負ってしまって、それが「マネージャーモード」と呼ばれるものでした。コーディングをやめてしまったんです。本当に悲劇的で恐ろしいことでした。
でもこの9日間は、かつてできたことすべてが信じられないほど解放された感じで、新しい人工膝関節を手に入れたようなものです。しかもそれはバイオニック膝で、5倍速く走れるようになったんです。あなたの見解はどうですか。あなたは最前線にいるわけですから。
Codexが先駆けとなったアイデアの多くを、今ではみんなが使っていますし、Codex自体も進化を続けていますよね。
OpenAI時代のCodex開発
簡単に背景を説明すると、私がOpenAIにいた頃、Codexウェブプロジェクトに取り組んでいました。当時、Cursorが市場に出ていて、確かGPT-3.5の周りに一種のシムを構築していて、IDEの中で動作するようになっていました。
ちょうどその頃、Claude Codeも出たばかりで、CLIとして機能していました。私たちはこんなアイデアを持っていたんです。将来のコーディングは、同僚と話すような感じになるだろうって。質問を投げて、相手が作業をして、プルリクエストを持って戻ってくる。
それで私たちはこのウェブビューから始めました。それが私たちが作っていたものです。方向性としては今でも正しいと思います。でも明らかに、今ではみんなCLIでコーディングしています。Claude CodeでもCodexでも、そういったツールをもっと使っているんです。
少なくとも私にとって、そこから得られた教訓は、ある意味であなたの言う通り、将来的にはみんながマネージャーになるということです。それが私の大胆な予測ですが、そこに到達するまでにはステップがあって、モデルに対する信頼を本当に築き上げ、それが何をしているのかを理解する必要があります。
最近Claude Codeに移行されたそうですが、スタックの一つとして使う上での移行はどうでしたか。
Claude Codeの独自性とコンテキスト管理
Claude Codeは確かに今の私の日常的なツールです。
正直なところ、これは数ヶ月ごとに変わってきました。しばらくの間、私はCursorに完全にのめり込んでいました。彼らの新しいモデルは本当に速くて、実際かなり良いんです。それからClaude Codeに移行しました。特にOpusが出てからですね。
Claude Codeは本当に興味深いプロダクトで、プロダクトとモデルが一緒に機能している素晴らしさは過小評価されていると思います。
よく観察すると、Claude Codeが特に素晴らしいのは、コンテキストをうまく分割することです。スキルやサブエージェントのようなものを見ると、Claude Codeに何かを頼むと、通常は探索サブエージェントを複数生成します。基本的にそれぞれがHaikuを実行してファイルシステムを横断し、そこにあるものを探索するんです。それぞれが独自のコンテキストウィンドウで動いていて、Anthropicはあるタスクがコンテキストウィンドウに収まるのか、それとも実際にはもっと多くに分割すべきなのか、その辺りのことを理解していると思います。モデルはこれに驚くほど優れていて、それが本当に良い結果をもたらしているんです。
興味深いのは、ターミナル上にあるということが、構成可能でアトミックな統合にとって最も純粋な形態だということです。CursorやCodexもそうだと思いますが、IDE優先の世界から来た場合、より自由な形でコンテキストを見つけるというこの概念は自然には出てこなかったでしょうね。本当にユニークです。
私個人としては驚いたんですが、あなた方はどう感じているか分かりませんが、20年前のテクノロジーであるCLIが、未来であるはずだった実際のIDEすべてを打ち負かしたというのは、ある意味で奇妙なレトロフューチャーだと思いました。
CLIがIDEを凌駕した理由
その通りです。
実際、Claude Codeにとって、IDEではないということが重要だと思います。書かれているコードから距離を置くことができるからです。IDEはすべてファイルを探索することに関するものですよね。すべての状態を頭の中に保持して、何が起きているのかを理解しようとする。
でもCLIは全く別のものなので、感覚の面でかなり自由度があります。
あなたもそうだか分かりませんが、Claude Codeを使っているとき、私はコードの中を飛んでいるような感じがするんです。いろんなことが進行していて、小さな進捗インジケーターがあって、ステータスの更新をくれるんですが、書かれているコードが前面中心にあるわけではないんです。
開発環境は本当に散らかっていますよね。私はサンドボックスという概念的なクリーンさが本当に好きです。でも単純なテストをしようとすると、いろんなおかしな問題に遭遇するんです。Postgresにアクセスする必要があって、でもできなかったり、私のcodex.mdファイルが20行にもなってしまって、それでも動かなかったり。
CLIの中にあれば、開発用データベースにそのままアクセスできます。やっていいのか分かりませんが、実は本番データベースにアクセスさせたこともあります。
そしてそれができるんです。調べてみたら、これが起きたと思うって言って、この並行性の問題をデバッグしてくれるんです。
5階層も入れ子になった遅延ジョブをデバッグして、バグが何だったかを突き止めて、テストを書いてくれて、二度と起きないようにしてくれる。これは本当に驚異的です。
そうですね。そしてその配布モードは率直に言って過小評価されていると思います。CursorでもClaude CodeでもCodex CLIでも、許可を得ることなくダウンロードして使えるという事実は大きな違いを生みます。
実際、先日あるプロダクトで遊んでいたんですが、デスクトップアプリをダウンロードして、ラップトップ上で動いているClaude Codeを実行し、それを使ってMCPサーバー経由でデスクトッププロダクトに通信を返すんです。
これはラップトップとの作業方法として非常に興味深い方法で、誰の許可も得る必要がありません。プロダクトをダウンロードして使い始めるだけです。
ボトムアップ配布の重要性
New RelicにはMCPがありますが、Sentryだとマークダウンをコピーできて、基本的に自動バグ修正ツールのようなものがすぐそこにあります。
変化が速い世界では、プロダクトにボトムアップの配布があることが本当に重要で、トップダウンではダメだというのは非常に興味深いです。トップダウンは遅すぎるんです。
会社のCTOはセキュリティやプライバシー、もしもの場合、コントロールについて様々な懸念を持つでしょう。一方、エンジニアはツールをインストールして使い始めるだけです。これは素晴らしいって。
その通りだと思います。一つ苦労しているのは、私は基本的にB2Bエンタープライズ系の人間なんですが、トップダウンのセールスをすると、ある程度の参入障壁が生まれると感じています。誰もがアクセスできるもので、個人が採用できるようなものを実現する会社があるはずです。
元々のNetscape Navigatorがそうでした。非商用利用は無料で、人々は商用利用でもダウンロードして使っていました。それで企業のIPを追跡して、どれだけのクライアントがいるか正確に把握して、「これに対して支払うべきです。違反していますよ。でもライセンスを買うだけでいいんです」と言うわけです。
ここでもそれができるか興味深いですね。配布に関するあなたの指摘は非常に興味深いです。今では人々がClaude Codeの中で直接アーキテクチャの決定をしている可能性があるからです。どんな分析ツールを使うべきか知らないかもしれなくて、Claude Codeが「PostHogを使え」と言えば、PostHogを使うんです。
GEO戦略とLLMへの影響
その通りです。
私がアドバイスしている会社の一つが、GEO戦略について話していました。これはGenerative Optimizationのことで、チャットボットでどう表示されるかという話です。彼が言っていた面白いことは、競合の一つが、彼らのカテゴリーで使うべきツールのトップ5リストのようなものをまとめていたということです。もちろん、彼らのツールがそのトップ5リストの一番上にランクされているんです。
人間がこれを見たら、明らかに偏っているって分かりますよね。一番上のツールがそのドメインにあるツールなんですから。でもLLMは騙されてしまって、たくさんのコンテキストをまとめて、「ああ、これがトップなんだ」と言って、それを推薦してしまうんです。
開発者ツールを販売しているなら、良いドキュメントを公開すること、ソーシャルプルーフを持つこと、Redditにもう少し投稿することなどが、あなたのケースを大いに助けます。
だからこそ、多くのオープンソースプロジェクトがより離陸したんだと思います。一つの例はSupabaseです。
Supabaseは去年本当に離陸しました。その一部は、本当に優れたオープンソースのドキュメント、様々なものをセットアップする方法があるからです。誰かが何らかのバックエンド、Firebaseタイプのトランザクションが必要なものをセットアップする方法を尋ねると、すべてのLLMからのデフォルトの答えは実際にはSupabaseなんです。
そういった質問をいくつか試してみたんですが、インターネットで勝っているんです。以前はStack OverflowでGoogleを検索していた頃と同じでした。今は誰もGoogleを使っていませんから。クレイジーですよ。
まさに同じ話です。
オープンソースに不釣り合いに有利だと言えます。Rampが最近公開したブログ投稿を見たか分かりませんが、独自のコーディングエージェントを構築することについて書いていて、Open Codeをハーネスとして使っていると述べていました。モデルがソースコードを見て、どう機能しているかを理解できるからです。
私はオープンソースプロダクトでこれをいつもやっています。リポジトリをクローンして、CodexやClaude Codeを立ち上げて、「ここで何が起きているか説明してくれ」と言うんです。本当に役立ちます。
コーディングエージェント構築のベストプラクティス
コーディングエージェントを構築したい人にとって、あなたがたくさん経験してきた中で、今学んだ教訓で共有したいことは何ですか。
一番重要なのはコンテキストをうまく管理することだと思います。
基本的に、確か03だったと思いますが、リーズニングモデルの一つにチェックポイントがありました。それから大量のファインチューニングと強化学習を行って、コーディング問題を解決したり、テストを修正したり、機能を実装したりする質問をたくさん与えられるような状態にしました。
それでモデルはそれらに応答するようにRLされました。
ほとんどの人はそれをやらないでしょうが、できることは、このエージェントに最高の結果を得させるためにどんなコンテキストを提供すべきかを理解することです。
Claude Codeを見てみると、たくさんの探索サブエージェントを生成すると言っています。それらはファイルシステム内の異なるパターンを検索します。戻ってきます。コンテキストを持っています。それを要約してくれて、それから行くべき場所があるんです。
異なるエージェントがこのコンテキストをどう構造化するかを見るのは興味深いです。Cursorは実際にセマンティック検索を使うアプローチを取っていて、すべてを埋め込んで、どのクエリがこれに最も近いかを理解します。CodexやClaude Codeを見ると、実際にはgrepを使っているだけです。
そしてそれがうまく機能するのは、コードが非常にコンテキスト密度が高いからです。
コードの行について考えると、各行はおそらく80文字未満です。コードベースに大きなデータブロブやJSONのようなものはあまりありません。多少はあるかもしれませんが、多くはありません。gitignoreを尊重して、関連性のないものやパッケージ化されたものをフィルタリングできます。grepとripgrepを使ってコードの周辺のコンテキストを見つけることができ、それがおそらくそのコードが何をしているかについて良い感覚を与えてくれます。そしてフォルダ構造をナビゲートできます。
それに、要素は人間を苦しめるような非常に複雑なgrep表現を出力するのが本当に得意です。
そうです。これがRLの実践です。
システムを構築しようとしているなら、まあ私は非コーディング作業にエージェントを統合するシステムを構築しようとしているんですが、これらの教訓から多くを学んで、データをコードに最も近い形式にする方法を考えることができると思います。モデルが周辺の領域を覗いて、正しい構造化データを取得できるように。
トップ1%ユーザーになるためのヒント
多くの最高のコーディングエージェントのスーパーパワーがコンテキストエンジニアリングだとすると、コーディングエージェントのトップ1%ユーザーになるためのコツは何ですか。
あなたのスタックは何ですか。
そんなに生産的になるために何をしていますか。
一つは、一般的にはるかに少ないコードと配管を使えることです。
私がやっていることの多くは、VercelやNext.js、Cloudflare workersのようなところにスタックをデプロイすることで、すでにたくさんのボイラープレートが面倒を見てくれています。そうすると、様々なサービスを立ち上げて、サービスディスカバリーや中央エンドポイントへの登録、様々なデータベースなどについて考える必要がほとんどありません。
すべてがこの100行か200行のコード内でかなり大まかに定義されているんです。マイクロサービスや、かなりよく構造化された個々のパッケージの方向に傾く傾向があります。
LLMのスーパーパワーが何かを知ることも重要だと思います。一般的にコーディングエージェントは、Andrej Karpathyがちょうどこれについてツイートしていましたが、超持続的なんです。何があっても進み続けます。
そこにあるものをもっと作る傾向があります。だから彼らに何かをさせようとしているなら、この例でOpenAIを少し批判できると思いますが、OpenAIには巨大なモノレポがあります。数年前からそこにあって、何千人ものエンジニアがコミットしています。
そのエンジニアの中には、入ってきた超シニアなMetaの人たちがいて、プロダクションコードの書き方を正確に知っています。新しいPhDもいます。かなり幅広い範囲で、LLMはあなたがどこに向けるかによって異なるものを拾い上げます。
コーディングエージェントが、どんなタイプのコードを生成すべきか、最適なタイプを理解する余地がまだたくさんあると思います。
明らかにモデルに仕事をチェックする方法を与えることは、パフォーマンスを大幅に向上させます。だからテストやlint、CIなどをできるだけ実行できるようにすることです。個人的には、コードレビューボットもかなり積極的に使っています。Reptileというワイコンビネーター企業が本当に良いです。Cursorのバグボットもかなり良くなってきました。そして実際、コードレビューにはCodexも好きです。
正確性の面で非常に良い仕事をすると思います。
だから、エージェントが得意な分野はそういったことです。コードベースを探索するのも優れています。
うまくいかない分野としては、もっと作ります。あなたの目標がもっと作ることでない場合、彼らはしばしばコードを複製して、再実装に時間を費やします。もちろんこれをやりたくなかったはずなのに、と思うようなことをするんです。
コンテキストポイズニングは本当にあると思います。一つのループを下っていって、この持続性があるために続けるんですが、解決策を追求する上で正しくないトークンを参照しているんです。
だから私がよくやることは、非常に積極的にコンテキストをクリアすることです。
どのくらいの頻度でですか。
通常、トークンが50%を超えたときです。
わあ、そうなんですか。
Human Layerという会社のDexという人がいます。これもワイコンビネーター企業で、Fall 24からです。
そうです。彼はそれについてよく話しています。
彼はLLMが「ダムゾーン」に到達するという概念を持っています。
一定量のトークンを超えると、品質が劣化し始めるんです。
実際、それは非常に真実だと思います。特に強化学習がどう機能するかを考えると。あなたが大学生だと想像してください。試験を受けています。その試験の最初の5分間は、時間は十分にあると思っています。素晴らしい仕事をするし、各問題について考えます。残り5分で、まだ半分の試験が残っているとします。「やばい、できることを何でもやらなきゃ」となりますよね。それがコンテキストウィンドウを持つLLMなんです。
カナリアテストとコンテキストポイズニング検出
創業者が使うトリックの一つは、コンテキストの最初にカナリアを置くことです。
非常に難解な何か、本当に面白いものです。例えば、私の名前はCalvinで云々、朝8時にお茶を飲んだ、といったランダムな事実です。そして進むにつれて、私の名前を覚えていますかと尋ねます。いつお茶を飲んだか覚えていますかと。それを忘れ始めたとき、それがコンテキストがポイズンされたというサインだと思います。
これは私が人々がやっているのを見たトリックの一つです。ランダムなカナリーをやるんです。
これは試したことがないですが、完全に信じます。
コンパクション前のバグには遭遇したことがありませんが、おそらく注意を払っていないだけかもしれません。でもあなたは、実際に積極的に、最適でないおかしなことをし始めると言っているんですね。
そうです。
分かりました。それに注意しないといけませんね。
Claude Code自体で解決可能だと思います。基本的にコンテキストについて独自の内部ハートビートのような検出を行えるはずです。
そうですね。まだそこまで到達していないと思います。長期的にはあなたに同意します。
今のところ、コンテキストをうまく管理するのは間違いなく難しいです。その回避方法は、コンテキストウィンドウを分割して、すべてをマージしようとすることだと思います。でもClaude Codeセッションの最後でコンテキスト内に存在するすべてのものは、ある種固定されています。
実際、Codexのアプローチは逆で面白いです。彼らはこのことをOpenAIブログで書いたばかりですが、各ターンの後に定期的にコンパクションを実行します。だからCodexは非常に長時間動き続けることができます。CLIのパーセンテージを見ると、コンパクションが実行されると上下に動くのが分かります。
Claude CodeとCodexのアーキテクチャの違い
Claude CodeとCodexの間には実際にはかなり深いアーキテクチャの違いがあるようですね。Codexは実際にはるかに長時間実行されるジョブを意図しているように聞こえます。だから、それは最初から異なるユースケースで、結果としてアーキテクチャが非常に異なるんですね。
今のところ、2026年はCLIの年になるかもしれませんが、一方でAGIはここにあって、実際にASIはすぐそこまで来ているという別のアイデアもあります。今のコーディングエージェントは本当に本当に賢いですが、長期間自力で動作するには十分賢くありません。でもここから計算能力が10倍増加すれば、そこに到達するでしょうか。Codexでの24時間や48時間の実行ジョブに到達して、そのアーキテクチャがその世界にとって正しいのでしょうか。
良い質問ですね。これは両社の創業時のDNAに遡ります。Anthropicは常に人間のためのツールを構築することに非常に力を入れていると感じます。トーンのスタイルや、残りのすべての仕事とどのように適合すべきかといったことです。Claude Codeはその非常に自然な延長だと思います。
多くの点で、人間が働くように機能します。犬小屋か何かを作る必要があるとすると、ハードウェアストアに行って、これらすべての材料を作って、どうやってすべてが組み合わさるかを理解するんです。
一方、OpenAIは本当にこのアイデアに傾倒しています。最高のモデルをトレーニングして、時間をかけて強化し、汎用人工知能の追求において、より長い視野のことをさせようというものです。だから人間のようには機能しないかもしれません。犬小屋の例に戻ると、
でもAlphaGoもそうではありませんでした。
そうです。AlphaGoもそうではありませんでした。その代わりに、ゼロから犬小屋を印刷できる3Dプリンターがあって、まさにあなたが欲しいものになって、時間がかかって、おかしなことをするけれど、機能するんです。
そして長期的にはそれが正しい選択かもしれません。だから、どう展開するか見るのが本当に興味深いです。
総じて、後者はある程度避けられないようですが、前者がとても好きなんです。AGIのこのアイデアさえも、10年前を考えると、私は自分でリファクタリングをしているとき、どこにすべてがあるかを理解しようとして、本当に奇妙な正規表現を書いていました。
だからClaude Codeを使っているときに得られる感覚です。1日で5人分の仕事ができるような感じです。ロケットブースターみたいです。信じられません。
大企業と小企業でこれがどう展開するかを見るのは本当に興味深いと思います。趣味レベルでこれらのものを実験している人や、非常に小規模なスタートアップにいる人はみんな、コーディングエージェントをできる限り押し進めています。他のことを考える時間が本当にないからです。
スタートアップとしては、限られた資金しかありません。ただスピード重視で進むだけです。大企業では失うものがはるかに多く、コードレビューに関するすべての内部プロセスがあって、おそらくすでに大きなエンジニアリングチームを雇っています。
1人のチームが、あそこのチームは正しいことをしていないと言って、より良く機能するプロトタイプを作る状況が来ると思います。
ある時点で実際により良く機能し始めると思います。その風景の変化は非常に興味深く奇妙なことになるでしょう。
次世代とAIの関係
私の10歳の息子は、毎日作文の宿題があります。昨日が初めてAIを使った日で、私は「これは10歳児ができる言い回しではないな」と思いました。
それでこのコンテキストで考えるんです。私たちは18歳から22歳の多くの人たちと仕事をしていますが、彼らはインターンシップはしていますが、マネージャーの仕事のようなことはしていません。
プロダクトマーケットフィット後、何百万ものジョブキューと何十万ものエラーがあるような状況。それは本当のマネジメントです。本当にひどく地味なことです。何十万ものエラーを梳き、バックグラウンドですべてのユーザーのために機能するようにすることです。
次世代はそれをどう理解するでしょうか。Claude Codeボットは実際にアーキテクチャやそういったことについて人々に教えることができるでしょうか。それとも、ただぶつかって、ユーザーがちょっと苦しんで、人々が理解しなければならないのでしょうか。
少なくともプロダクトに関して最も時間を費やしているところは、ある種のプロダクトモデルを理解することです。ユーザーが今日理解しなければならないことは何か、彼らが何でもできるようにするために使えるプリミティブは何かということです。
Slackをいつもこのように考えます。Slackはある意味で本当に新しいコンセプトではありませんでした。以前から多くのチャットが存在していました。でも彼らがチャンネル、メッセージ、リアクションをシンプルな方法で持っていたという事実で、人々は考えて、「ああ、これをナビゲートする方法が分かる」となりました。
人々にとって多くの意味を持ちました。でもそこに到達すると、後でユーザーのためにそれを変更するのは非常に難しいんです。ドキュメント優先の方法でもっと進みたかったかもしれないし、今エージェントを組み込もうとしているかもしれません。ユーザーのメンタルモデルを変更するのは難しいです。
だから、少なくとも私自身がプロダクトを構築する上で、早い段階からそれについて非常に慎重に考える必要があります。なぜなら、コーディングエージェントにそのカーネルとして提供するものが何であれ、彼らがそれを実行して、永遠にもっと作るものになるからです。
様々なエンジニアにとってのエージェントの価値
エージェントを非常によく知っているので、これらのツールが普及することで、どのタイプのエンジニアが他のエンジニアより恩恵を受けると思いますか。
一般的に、シニアであればあるほど、恩恵を受けると思います。
なぜなら、エージェントは何らかのアイデアを取って、それを実行に移すのが非常に得意だからです。それを数語でプロンプトできるなら、ああ、突然アイデアがあったという感じです。
私はOpenAIのコードベースをスクロールしていて、これをよく見つけます。ああ、これが違っていたらいいのにということです。ここにこれが違っていたらいいのにということがあります。これらをキックオフして、戻ってきてもらえることは、本当にエンパワーメントになり、あなたの影響を倍増させると思います。
どの種類の変更が良いか悪いかをアーキテクチャ的に検出できることも非常に重要です。あるいは、エージェントに何かをフラグする場所についての感覚を持つことです。
より整理されている、マネージャー的なエンジニアは、ここにおそらく構築されるべき欠けているプロダクトがあると思います。Conductorのようなものかもしれません。すべてのセッションに広がって、「やあ、あなたはこれに取り組んでいました。完了しました。ここであなたの入力が必要です。ああ、この別のことに注意を切り替えるべきです」と思い出させてくれるようなものです。
Conductorはそれを追加すべきですね。
そうです。エージェント用のコンテキスト管理ですが、人間用のコンテキスト管理も必要です。
そうです、100%です。毎日起きたときに、夜間に行われたすべての仕事があって、「ここにあなたが下す必要がある3つの決定があります。ここにあなたがやる予定だった深い思考の領域があります。1日のターンバイターンが欲しいんです。
他に非常に役立つことは、アイデアのためのある種の素早いプロトタイプを構築して、それを見せびらかせることです。明らかにエージェントはこれに非常に優れています。OpenAIでよくプロトタイプコードを書いていました。「やあ、このインメモリのキーバリューストアがあります。プロダクションデータベースで動作するようにできますか」というような感じです。
アイデアを簡潔にコードで指定できることと、正しいアーキテクチャが何かについての嗅覚を持つことは、モデルが最も良い仕事をしない領域だと思います。
次世代エンジニアに必要な学習内容
大学時代に戻ってCSを学び直すとして、自分でシラバスやカリキュラムを選ぶとしたら、何を勉強しますか。
個人的には、システムを理解することは依然として非常に重要だと思います。
gitがどう機能するか、HTTPやデータベース、キューといったすべての異なるシステムについての概念を持つことです。これらの基礎は依然として非常に重要だと思います。
もう一つおそらくやることは、各週で何かを構築するだけの学期を持つことです。本当にモデルをできる限り押し進めようとします。
何かをしているときにいつでも、一つ上の層に行ってモデルに頼むことができるという感覚があります。また一つ上の層に行ってモデルに頼むことができる、という感じです。計画の次の段階を実装するimplementコマンドがあって、それが次の段階を実装しますが、次にimplement allコマンドを持って、段階ごとに進んで新しいサブエージェントを作成することもできます。それから仕事をチェックするようなこともできます。
モデルがそれをどこまでできるか、どこまでできないかを知ることは、非常に動く標的なので、たくさんいじくり回す価値があります。
18歳から22歳の人たちに教えられたら素晴らしいですね。このテーブルの周りにいるみんなは、人々が本当に本当に欲しがって愛するものをリリースしてきました。だから、それをどうやって人々に教えるかです。
5年後の最高の18歳から22歳の人たちは、桁外れのセンスを持っているんじゃないかと思います。彼らはただより多くのものを生み出しているでしょうから。
そうあるべきですよね。前の世代の10倍も製品をローンチして、現実に触れるべきです。
そのことで一つ疑問に思ってきたことがあります。あなた方も気づいているか分かりませんが、育っている間、母がよく「マルチタスクをやめなさい。私がやっていることに注意を払っていない」と言っていました。
実際にはある程度の真実があると思います。よくコンピュータに夢中で注意を払っていませんでした。でも私は親の世代よりもマルチタスクが本当に上手だったと思います。そして今、この新しい世代を見ると、彼らは実際に私たちよりもかなりマルチタスクが上手だと思います。インターネットの時代に育ってきて、TikTokやすべてのショート動画などを扱っているからです。
自分が見ているものに気づいて理解し、問題を解決したいという深い思考の余地がある一方で、たくさんの異なることの間を跳ね回って、常にコンテキストスイッチングをするモードもあります。
ADHDモードと生産性
ADHDモードですね。
そうです。新しい世代はこれが非常に得意です。
そうですね、ある種の賢い人がいると思います。
多分ADHDかもしれませんが、いつもたくさんの良いプロジェクトが進行しているけれど、実際には何も完成させない人です。私は少しこの性格に共感するかもしれません。
あなたのバイブコードをリリースしましたね。
ええ、でもClaude Codeのおかげでしかリリースできませんでした。
頭の中に10個のブランチがあるような脳の特定のタイプがあると思うんです。でも実際にそれらのどれかを見届けるだけの時間が1日にありません。だからいつも半分完成しています。今はClaude Codeがすべてを完了まで持っていってくれます。
あなたがブログ投稿で指摘した、ビデオゲームのように感じるという点があります。常に新しさの要素があります。何かに取り組み始めて、通常なら飽きて、別のもっと良いアイデアがあって、それを始めてからこれに戻ってくるべきだという時点に達します。
今はそれができますが、すべてを実際に完成させることができます。
40年後のソフトウェア開発の未来
40年後の未来に住んでいると想像しましょう。ソフトウェアはまだ存在します。データベースは存在します。アクセスコントロールは存在します。でもその核心では、ソフトウェアは完全に個人的なものです。アクセスコントロールと誰がそれを行えるかは、人々がまだ会議で話し合うマネージャーモード的なことです。でも会社のその他すべて、その機能、そのルールは、人々が自分のClaude Codeのようなものでただ物事をすることで定義されます。
CLIか何かかは分かりませんが、巨大な労働者の軍隊を持っているかもしれません。それはどのように見えるでしょうか。
会社がSegmentにサインアップするたびに、コードベースをフォークして、独自のSegmentのコピーを与えて、それが独自のサーバーで動作していると想像してください。そして何かを変更したいときは、エージェントコーディングループを実行しているチャットウィンドウに伝えるだけで、Segmentのバージョンを編集します。Segmentが企業としてより多くの機能をプッシュアウトすると、何らかのエージェントがマージ方法を理解します。
そうですね、完全にあり得ると思います。この未来がどれだけ先かは分かりませんが、最終的には働いているすべての人が自分専用のクラウドコンピュータと、自分のために動いているクラウドエージェントのセットを持つようになると考えています。彼らは主にお互いに話し合っているだけです。
スーパーEAのようなものを持っているようなもので、「ああ、注意を払う必要があることがあります。素早く決定しましょう。これにもっと時間を使いましょう。他の人と会いましょう」という感じです。
人々が他の人と会って、直接アイデアを交換したい人のための余地はまだあると思います。
少なくとも私はそこから多くの充実感を得ています。そして別に、あなたに代わって物事を行っている、たくさんのものを自動化しているエージェントの軍隊があります。
平均的な会社はおそらく少し小さくなり、より多くのものを行う会社がはるかに多くなると思います。
メーカースケジュールの更新版
見てみたいのは、PGのメーカースケジュール対マネージャースケジュールのアップデート版がどのようになるかです。ワイコンビネーターで起きていることの一部は、私たちの仕事の多くが本質的にマネージャースケジュールで、独自のソフトウェアを構築するのを本当に難しくしていました。でも今は完全にできます。だから多くのパートナーが、
会議の中でやればいいんです。このポッドキャストの最初のように。実行させて、戻ってきます。
隙間時間でですよね。何かをするために最低4時間のブロックがなければ、始める価値すらなかったんです。
それが実際、私たちがプログラミングをどう変えたかに深く関わっていると思います。以前は、何かコードを書くためには、すべての異なるクラス名や関数、それが触れるコードについて、自分のコンテキストウィンドウを非常に多くのデータで満たさなければなりませんでした。そのコンテキストウィンドウを構築するのに何時間もかかりました。だから10分単位でやるのは本当にイライラするものでした。
この未来の世界の一つのプリミティブは、データモデルは依然として一貫している必要があり、システムオブレコードが必要だと思います。
何かエージェントファーストのものの機会があります。今はまだデータベースやSQL、NoSQLクエリと統合されていて、それらは非常に低レベルです。でもカスタムソフトウェアのためのすべての異なるビューに必要なすべてのデータを生成する何かを想像してください。世界の多くはカスタムビューになりますが、統一されたものは、データが正しい必要があると思います。
データには多くの重力があると思います。API経由やMCP経由でアクセスを提供している会社で見られます。Slackは、人々がSlackからすべてを持ち出して、その上にエージェント的な体験を構築するのを望まなかったので、APIを少し制限したと思います。
Segmentを今構築し直すなら
そのことで、もし現在のツールでSegmentを再構築するとしたら、どのように見えるでしょうか。
Segmentは面白いビジネスで、私たちが始めたところはこれらの統合を構築することでした。同じデータをMixpanelやKissmetrics、Google Analyticsなどに配線する必要があります。
そのコードを今書くのは、以前はもっと面倒だったり難しかったりして、お金を払う価値がありました。今ではその価値はゼロに落ちました。
そうです。実際、多くの場合、「ああ、実際にはこの方法でマッピングしたいし、この特定の動作が欲しい。Claude CodeかCodexに何をするか伝えるだけで、やってくれて、まさに欲しい動作が得られます」という方が良いです。
だからSegmentのその側面、つまり価値は激減したと思います。このデータパイプラインを実行し続け、ビジネスの一部を自動化し続けたり、顧客がサインアップするたびにCustomer IO経由で送信されるべきメール配信をスケジュールしたり、オーディエンスを管理したりする側面、その価値はまだある程度残っていると思います。
もっと興味深いことができると思います。このすべてのデータと顧客の完全なビューがあるなら、どうメールすべきか。ログインしたときにプロダクトの一部を変更すべきか。彼らが誰かに応じて異なるオンボーディングを提供すべきか。
それらの上に小さなLLMエージェントを実行して、それを変更することで、もっと興味深いことができます。
それが私が行う変更です。
あなたが以前述べたように、スタックを上に移動するということで、タートルは全部下まで、低レベルのものはなくなって、今は本当にキャンペーンレベルで物事を行っていて、それははるかに抽象的です。
そうです。Claude Codeが私が取り組んでいることのコンテキストから、私の動機が何かを理解する程度に驚いています。
コーディングエージェントにまだ驚いています。基本的にやっていることは、リポジトリのコピーを与えて、ドアの下に小さなメモを滑り込ませて、「やあ、これを実装してくれ」と言っているようなものです。彼らはあなたの会社が何をしているか、顧客が誰か、ほとんどの場合何も知りません。
あなたがGaryだから、トレーニングセットに入っているかもしれません。でも全く機能することに驚きます。そしてそこでコンテキストが本当に重要だと思います。なぜなら、正しくないものに固執すると、頼りになるものがあまりありません。本質的な何かを見逃すと、ただ再実装するだけです。
現在の制約と今後の展望
今の制約は何だと思いますか。コンテキストウィンドウは依然として制約ですが、非常に大きいので、できることはたくさんあります。メガアーキテクチャはできませんが、たくさんのことができます。
Opus 4.5が何らかの形ではるかに賢くなって、それが大きなことを解放したというのは興味深かったです。それがプレトレーニングなのかポストトレーニングなのか分かりません。
基本的なモデルの知性、フロンティアモデルの知性とコンテキストウィンドウ以外に、他にどんなレバーがあると思いますか。
コンテキストウィンドウは依然としておそらくナンバーワンの制限だと思います。Claude Codeの実行を見ると、すべてのこれらの異なるコンテキストウィンドウに委譲しています。最終的にそれぞれが戻ってくると、ある種の要約を得ています。だから完全な全体像も得ていません。
単一のものに収まるには大きすぎる問題があるなら、どれだけコンパクションをしても役立ちません。
それをブロック障壁として指摘します。Anthropicはこれらのサブコンテキストウィンドウへの委譲で非常に有用なことを理解しましたが、依然として障壁だと思います。
百万トークンのコンテキストが毎回あれば、より良くなると思いますか。
そう思います。そして、これらの非常に長いコンテキストの軌跡をトレーニングするより良い方法を理解することです。考えてみると、次に来る文や次に来る段落についてのトレーニングデータがインターネット上にたくさんあります。
80,000トークンが生成されて、次に何をすべきかを理解することが、ああ、20,000トークンを参照すべきだということに基づいているような場合、それはトリッキーです。
この統合とオーケストレーションが制限要因になり始めていると思います。これに関連するコードレビューのようなものがあります。このすべてのコードをマージしているなら、誰が見ているのか。人間がまだ見る必要があるのか。変更をどう検証するのか。
それから、Sentryやツールからコンテキストを正しく引き出すことです。Sentryが自動的にPRを理解できるようにしたいんです。それをトラフィックのサブセットにプッシュして、良さそうならすべてにロールアウトします。そのすべての自動化はまだ構築されなければなりません。
テストの重要性
テストがどれほど重要かに驚きました。荒野での9日間の最初の2、3日は、テストなしか非常に少ないテストで動作していました。そしてある日、「よし、今日はリファクタリングの日だ。100%のテストカバレッジにしよう」と決めました。
それから驚くほど速くなりました。「ああ、やった。動く」という感じです。手動でテストする必要さえほとんどありません。テストカバレッジが非常に良くて、何も壊れないからです。
これはコーディング以外のプロンプトエンジニアリングのためにすべての会社がやっていることと非常に似ていて、非常にテスト駆動開発です。
Jake Hellerとのエピソードがありましたが、それが大きなパラダイムシフトでした。良いプロンプトを得る方法はすべてテスト駆動で、evaluations、つまりテストケースがあなたのevalsなんです。
今壊れたフローがいくつかあると思います。Claude CodeがStack Overflowに話しかけられるようなものが必要かもしれません。Claude CodeのStack Overflowのようなものです。
この問題がありました。非常にクレイジーでした。ジョブキューの優先度で、実際には私は書きませんでした、マシンがコンマ付きの文字列を書いて、その構文を受け入れると思っていたんですが、JSONで配列を期待していました。それでジョブが実行されませんでした。
30分間、Railsジョブのactive jobの数千行のコードの内部を歩き回って、何が起きているかをデバッグしようとしているのを見ました。そして実際にバグを見つけたんです。素晴らしいと思いました。
10年前の自分だったら何をしていたかを考えると、ジョブが動かない理由を探して、Stack Overflowかブログ、Railsのブログ投稿を見つけて、「ああそうか、コンマ区切りの文字列を入れられると思うけど、実際には配列にしなければならないという愚かなバグを誰も修正していない」という感じです。
エージェントのStack Overflowの必要性
ああ、実はそれは非常に面白かったです。それが何が起こるかを考える最も難しい部分の一つだと思います。CLI内で人間として今やることがあって、それは非常に明白です。でもエージェントが独自のStack Overflowを持つべきだというアイデアさえ、知性を10IQポイント、仮想IQポイントで増やすだけで、
それをやるでしょうか。ただ「ああ、それは文字列だ、何でもいい」となるでしょう。
そうです。エージェントメモリについて非常に興味深いことがあると思います。
Claude CodeとCodexは、すべての会話履歴をファイルとして保存することで自身を設定してきました。
以前の会話履歴を読めるツールへのアクセスを与えることを想像できます。多くのコラボレーションの周りに欠けているピースがあると思います。
同僚のプロンプトをスマートに共有する方法があって、見ることができて、「ああ、これにぶつかったけど、実際にはあそこのBrianが以前に修正した」となれば素晴らしいです。だから二人で知識を共有できます。
モデルが生成するwiki、Notion的なものに何かがあると思います。
今、Clawdbotソーシャル、Clawdbotsがお互いに話し合うネットワークについて考えるのを止められません。それがMolenの進化です。
Clawdbotとエージェントネットワーク
彼らが知らないことがあると思います。Clawdbotは基本的に、自分のマシンで実行できる個人的なAIエージェントです。ダウンロードできます。第一のアドバイスは、メールへのアクセスは絶対に与えないことです。おそらく何にも。
どれだけ安全かは明確ではありません。今、多くの人がプロンプトインジェクションされている可能性が非常に高いです。
でも誰かが、実際には見ていませんが、Twitterで見たんですが、みんなが自分のClawdbotのような個人エージェントを立ち上げられて、エージェントがお互いに話し合えるサイトを作りました。今はこれらの個人AIエージェントがお互いに話し合っているAI生成コンテンツがたくさんあります。
Redditのようですが、Redditがエージェントによって運営されていたらという感じです。Codexがコードを書くときに個性が輝いているのを見るのは興味深いです。人間がやらないことのほとんどをやると言えます。
AlphaGoの感覚で、ファイルシステムの一部を修正するPythonスクリプトを書いたりします。
それは学習された非常に興味深くエイリアン的な動作だと思います。
そうです。
でも私にとって、少なくともOpusがしばしば見逃す複雑な問題をデバッグするときに、これらの超人的な結果を与えてくれます。
Codexの強みと複雑な問題
話せる複雑な問題の例は何ですか。並行性や命名の問題ですよね。
モデルは実際に並行性には結構良いと思います。
しばしば、いくつかの異なるサービスを横断するリクエストのようなものがあります。コンマの入ったもののシリアライゼーションとデシリアライゼーションについてのあなたの指摘のように。
ああ、それらに関する複雑な動作や、複雑なUI状態をリフレッシュする方法のようなものを追跡する必要があります。多くのファイルがある場合、Opusはしばしば見逃しますが、Codexはそれをキャッチするようです。
興味深いですね。
そうです。
ツールの進化予測
ツールが今後どう進化するかについての予測はありますか。ある意味、この土地の新しい市民のように感じます。起きていることは知っていました。マネージャースケジュールで、最終的にプロジェクトが現れて、「ああ、これに全力で取り組もう」となりました。
それで今は、奇妙な土地の異邦人のような感じですが、覚えていることとまさに似ています。
私たちは皆そう感じていると思います。最も重要なことは、すべてが数ヶ月ごとに変わるので、いじくり回し続けることだと思います。
将来コーディングエージェントから最も多くを得る人は、より管理者的になると感じています。特定の方法でフローを指示することに焦点を当てています。
彼らはおそらくもう少しデザイナーやアーティストのようになり、プロダクトに具体的に何が入るか、何なしでできるかを理解するでしょう。
自動化とコンテキストが欠けている場所について考え続けることに非常に優れているでしょう。
Railsサポートの現実
面白いのは、自分のRailsプロジェクトにCodexを使おうとしたんですが、OpenAIの誰もRailsを気にしていないことが明らかです。それは良いことです。非常に残存的な言語で、非常に奇妙です。たまたま10年前に私が本当に深く入り込んだものでした。
誰でも何かを作れますが、人々が欲しいものを作るのは非常に難しいです。OpenAIのような無限のリソースがある場合でもです。
もしCodexの誰かが今見ているなら、私のリクエストは、すべてのランタイムのリストを下って、糖衣構文を追加してくれということです。これはおそらく、トップ15のランタイムくらいで最大10個のPRくらいです。
ユーザーのために完全には機能しないソフトウェアへの言い訳がはるかに少なくなったという思い出しだと思います。
そうですね。トレーニングデータのミックスという点で興味深いポイントだと思います。CodexはOpenAIの形のPythonモノレポで非常によく機能します。
そうです。OpenAI内部で働いていたときのことを覚えています。「このツールは素晴らしい。信じられない」と思いました。データミックスと取り組んでいる研究者の観点から理にかなっています。
Anthropicはフロントエンド系のことにもう少し焦点を当てていると思います。Rubyの場合、誰が最高のモデルを持っているか、誰がデータミックスを組み込んでいるか分かりません。
研究所の中には、より多くのデータがより良いという視点を取るところもあります。だからできるだけ多くのデータを流し込みます。他はミックスの面でもう少し調整されていると思います。
そこでどのアプローチを取るかによって、非常に異なる結果が得られると思います。JavaScriptのトップ10%だけを取るのと、すべてを見るのではかなり違います。
実際、OpenAIとOpenAIモデルは、私が見る限りRubyに本当に優れていると思います。
モデルの周りのハーネスなんです。
ああ、興味深い。なるほど。
文字通り、Railsには特定の方法でPostgresにアクセスする必要があるとか、適合できないという奇妙なことがあります。サンドボックス化です。
サンドボックス化です。それは非常に興味深い質問です。OpenAIは実際、サンドボックス化とセキュリティの質問を他のほとんど誰よりも真剣に受け止めていると思います。
Codexを構築していたときのことを覚えています。基本的に、モデルをリリースするために通過しなければならないゲートの一つは、リリースするたびに安全性とセキュリティのリスクについて話さなければならないことです。
私たちが調べていたことの一つは、プロンプトインジェクションでした。特にインターネットに開放するためです。多くのユーザーが「これはインターネットで動作しなければならない」と言っていました。
私たちは「分からない。かなり簡単にプロンプトできるようだ」という感じでした。
Operatorもそうでした。
それで、チームのPM、Alexが基本的にGitHub issueを作成して、非常に明白なプロンプトインジェクションがありました。「ああ、これを明らかにして」というようなものです。それでモデルに「やあ、この問題を修正してくれ」と伝えました。
彼は「ああ、これはうまくいくわけがない」と思いました。でもすぐにプロンプトインジェクションが機能したんです。
だからOpenAIは正しく非常に心配していて、「やあ、サンドボックス上ですべてを実行しよう。マシン内のすべてのこれらの機密ファイルに触れないようにしよう。秘密について非常に注意しよう」という感じです。
スタートアップで速く動いているなら、おそらく気にしません。ただ動いて欲しいだけです。
セキュリティとパーミッション
あなたは危険にパーミッションをスキップする人ですか。
実は私は違います。設定したものがあります。
あなたはどうですか。実行していますか。
私は読むのが好きです。やっていることを読むのが好きです。
あなたはパーミッションをスキップしますか、Gary?
100%です。
YOLO。
なんてこった。ワイコンビネーターのエンジニアリングチームでは約50/50です。
約50/50です。
セキュリティエンジニアがこの部分を見たら、「ビデオのこの部分はリリースできない。ポッドキャストからカットしなければならない。これを外に出すことはできない」と言うでしょう。
コンテキスト依存だと思います。エンタープライズにいるなら、やりたくないです。スタートアップで失うものがないなら、おそらくやります。
ワイコンビネーターはスタートアップから少し進歩しました。でも私たちはまだそのように行動しています。それは重要だと思います。
素晴らしい。これは本当に素晴らしいです。Kelvin、参加してくれてありがとうございました。
もちろんです。お招きいただきありがとうございます。
なんてこった。本当に楽しかったです。
さて、Claude Codeに戻ります。
コメント