Codex 責任者：「誰もが builder だ」というのは非常に悪いアイデアだ
TechFlow厳選深潮セレクト
Codex 責任者：「誰もが builder だ」というのは非常に悪いアイデアだ
AI プロダクトを作るにはまだ PM が必要ですか？必要であれば、AI 時代の PM は何をする必要がありますか？
Web3業界の深掘り報道に専念し潮流を洞察作者：Founder Park
アンドリュー・アンブロシーノは OpenAI Codex チームの負責人です。デザイナー出身で、エンジニアやプロダクト担当も経験し、起業もしました。現在担当する Codex の週間アクティブユーザーは 500 万を超えています。彼はおそらく現在、「AI 時代のプロダクトをどう作るべきか」に答えるのに最も適した人物の一人でしょう。
彼によると、会社内のほぼ誰もが迅速に機能のプロトタイプを構築できるようになった今、真の課題は「作れるかどうか」ではなく、「これを作るべきかどうか」です。
Lenny との対談において、アンドリュー・アンブロシーノは OpenAI 内部の開発プロセスを詳細に説明しました。実装コストが AI によって大幅に圧縮された後、立项、ドキュメント、プロトタイプ、デザインから役割分担、チームコラボレーション、プロダクト計画に至るまで、プロダクト開発のあらゆる环节が変化しています。どの旧来のルールが失效し、どの新しい標準が形成されつつあるのか。実装が希少ではなくなった今、真に希少なリソースは何なのか。
いくつかの核心的な观点：
- 90 人が 90 個のリリース可能なプロダクトプロトタイプを作れるようになった時、最も貴重なのは taste です。
- Codex チームの採用におけるハードル基準の一つは品味であり、海量のコンテンツからシグナルとノイズを見分ける能力です。「無限の tokens を持つ」世界において、彼らはゴミコンテンツを生産したくありません。
- Codex がもし 3 ヶ月早くリリースされていれば完全に失敗していたでしょう。唯一の変数はモデルが進歩したことです。機能を轻易に不好と判定しないでください。それは単に時期尚早だった可能性もあります。
- 機能が最終的に十分良いかどうかの前提は、多くの場合機能そのものの形態ではなく、モデルが十分に賢いかどうかです。
- Codex がかつて ChatGPT を颠覆したように、Codex も新しい試みによって颠覆される可能性があります。ボトムアップの探索カルチャーを維持する必要があり、同じチームにディテールを磨きつつ自らを颠覆することを期待してはいけません。
以下は対談のエッセンス内容です。
実装のコストが低下し、taste がより重要になった
Lenny：AI がプロダクトワークの形態を変えているとおっしゃいました。你现在はおそらく世界で最も最先端の AI プロダクトチームで働いています。具体的に、プロダクトチームの働き方は 2 年前と比べてどのように変化しましたか？
アンドリュー・アンブロシーノ：現在チームリーダーとして、最も難しいことはプロセスが逆転したことです。
過去のプロダクトの作り方は、大家都熟悉しています：まず調査、アイデア出し、プロトタイプ作成。ウォーターフォール開発時代は既に過ぎ去っていますが、底层ロジックは同じで、実装は高価でした。そのため、実装の前にドキュメント、調査、プロトタイプですべてのリスクを事前に排除する必要がありました。プロトタイプやデザインは開発よりも安価である、これが過去の基本仮説でした。
現在この仮説は完全に変わりました。誰でも任何东西を作ることができます。本当に信じていますが、ゼロからこれらのモデルと対話すれば、私たちのモデルであれ他社のモデルであれ、你想要的任何機能を構築できます。これはソフトウェア開発で最も難しい部分ではないかもしれませんが、確かにクールです。
人々に無限の tokens を与えると、OpenAI の誰もが主体性を持ち、良いアイデアを持っています。そのため、誰もが様々なものを作っています。現在会社内に緊急に必要な機能がある場合、同時に 90 の異なる、調整されていない小チームが各自で実装と試行を行っていることは確実です。その 90 の試行の中で、どれが良いのか？どの部分を他の方面に折叠すべきか？それをどう定義すべきか？それは別の機能の一部であるべきか？スイッチの中にいくつのオプションがあるべきか？そういうことです。
したがって简短な答えは：逆転したということです。人々が根本的に異なる役割を行っているわけでも、スキルが消失し役割が存在しなくなったわけでもありません。実装が最も高価な部分ではなくなったのです。あえて言わせていただければ、最も高価なのは品味（taste）です。
Lenny：つまり以前は大家都 PRD や戦略ドキュメントを書いていましたが、現在大家は直接プロトタイプを作ります。会社内の多くの人々が類似のアイデアを持っていれば、90 の異なるものが出現し、その後从中方向を選ぶのですか？
アンドリュー・アンブロシーノ：はい、このようなことは大量に発生しています。OpenAI だけでなく、多くのプロダクト負責人が「PRD は死んだ、プロトタイプが王道だ」と言っているのを目にしていますが、私は実際にはこの观点に完全に同意しません。
実装があらゆるメディアにおいて安価になったため、思考を跳过して直接プロトタイプを作ることが非常に誘惑的になります。特にあなたがエンジニアではなく、コードを書いたことがなく、興味も時間もない場合、「PRD は死んだ、私が欲しいものを直接見せよう」と忍不住に言ってしまいます。
しかし、私は逆に現象にも気づきました。エンジニアにとって、大量のドキュメントを書くことが逆に非常に誘惑的になります。読む価値のない大量のドキュメントです。ドキュメントを書く人が悪いと言っているのではなく、実装が豊富になった時、观点を表現するフォーマットを正しく選ぶことが、真に重要になるということです。
表現したいのが模糊領域のプロダクトの明確さであれば、確かにドキュメントを書くべきでしょう。人々に試用させ、インタラクションパターンをストレステストしたいのであれば、プロトタイプを作ります。鍵はメディアを正しく選ぶことです。
Lenny：primal mark（原始标记）という概念があります。画家がキャンバスに落とす最初の一笔で、後のすべてのものはその一笔から延伸されます。あなたの意味は、有时プロトタイプが間違った最初の一笔になるということですか？因为大家はそれにアンカーしてしまい、より大きな方案を考えなくなるからです？
アンドリュー・アンブロシーノ：そうです。過去には暗黙のシグナルがありました。ものがどのように見えるかは、それがプロセスのどの段階にあるかを意味していました。もしものが正式上线プロダクトのように見えれば、それは既に後期であり、リスクは排除され、デザインは確認され、商業目標は合理的であることを意味していました。
現在これらのものは脱钩しました。理由は、過去に構築するためのリソースを得るには、まず十分にリスクを低減する必要がありましたが、現在この閾値はなくなったからです。したがって、本来は探索段階にあるものが、既にリリース可能なように見え、視覚的には準備が整っています。しかし、それは正しい方向ではなく、調査結論に適合せず、ユーザーが真に必要としているものではなく、ビジネスにとって最適な選択ではない可能性があります。
品味这件事を過度に強調するつもりはありません。しかし繰り返しになりますが、何をすべきか、どう提示するか、どう目標を達成するか、どのメディアを使うかを知ることが、あらゆる領域において最も重要な能力になりつつあります。
Lenny：品味という言葉は現在流行語です。具体的に、あなたの言う「良い品味」とは到底是什么？
アンドリュー・アンブロシーノ：品味は分解して見る必要があります。
確かに審美的な部分もありますが、システム思考の部分もあります。このものがシステム全体の中でどう配置されるか。方向性の部分もあります。どこへ行くのか、この事はあるテーマの一部なのか。表現の部分もあります。この情報をどう提示するか。そしてもう一つの品味はインタラクションレベルです。このアニメーションは伝えたいセマンティクスに適合せず、急ぎすぎており、伝えたい意味とマッチしていません。
これらは確かに非常に重要ですが、真の品味の問題は、もし何でもできるなら、目標は何か？どうそこに到達するか？です。
Lenny：AI が越来越強くなり、越来越多的事を行うようになった時、人間の脳はどの場所で価値を持ち続けるのでしょうか？品味は感觉はその其中之一です。しかし AI のデザイン出力はまだあまり良くありません。なぜトップモデルはデザインをうまくできないのでしょうか？
アンドリュー・アンブロシーノ：いくつかの実際的な理由と、いくつかのより難しい問題があります。デザインはソフトウェアよりも評価が難しく、モデルに何が良いデザインかを訓練するためのフィードバックループを作成することは、コードがコンパイルできるかを訓練するよりもはるかに煩雑です。なぜなら人の品味はフィードバックメカニズムの一部だからです。
また、実験室は歴史的に、AI 研究を加速できるものをモデルが得意とするよう優先してきました。モデルが正しいコードを書けることは明らかに研究を加速しますが、デザインでは同じ论证ができません。デザインが重要でないと言っているのではなく、そのフライホイールの中にいないということです。
これらは実際的な理由であり、它们は消失するでしょう。モデルはデザインにおいて相当上手くなるでしょうが、いくつかのより扱いにくいものがあります。
第一に、デザインには文化的属性があります。昨年すべての新しいウェブサイトが Linear のデザインをコピーしていたのを覚えていますか？もしモデルが毎回 Linear のウェブサイトを出力するなら、それは挑戦ではありません。デザインにおける新規性の重要度は、ソフトウェアエンジニアリングよりもはるかに高いです。ソフトウェアエンジニアリングではモデルが既知のパターンに完全に従うことを望みますが、デザインにはある程度のランダム性と新規性が必要です。
第二に、ビジュアルデザインとコード間の相互作用です。もし明日会社がブランドを変更した場合、浅い做法は 263 個のコンポーネントを逐个更新することです。深い做法は、これら二つは看起来違いますが、実は一つのリストスタイルに属し、同じインタラクションパターンを伝えていることを理解することです。この抽象レイヤーは、現在の技術ではまだ届きません。
Lenny：Jenny Wen（Anthropic Claude Code デザイン負責人）はデザインプロセスは既に死んだ、直接構築すれば良いと言っていますが、你怎么看？
アンドリュー・アンブロシーノ：私は Jenny と多くの事において一致しているかもしれません。正規のデザインプロセスについて、彼女が言うことに同意します。それは死んだのです。そして私は AI 以前からそのプロセスのファンではありませんでした。
多年前私がスタートアップをしていた時、「ケーススタディ工場」という記事がありました。デザイナーが固定されたプロセス一套に従うように訓練され、徐々にそのプロセス自体を結果よりも重要視するようになるという内容です。もしものがこのプロセスを経れば、默认で二つの結論が得られます：第一に、それは良いものであり、プロセスが品質を保証する。第二に、誰も使わなくても、それは良いものである。なぜならプロセスを経たからです。
ユーザー調査、发散、収束。フレームワークは正しいですが、常に少し学術的でした。そのプロセスの前提は実装が高価であり、一度しか作れないため、行う前にすべての問題空間と解決策空間を窮尽する必要があったということです。
後に Figma と Origami が出現し、私たちはインタラクションプロトタイプをプロセスに引き込みました。現在の問題は、すべての実装をプロセスの最前面に引き込めることです。完全に精致なプロトタイプは、直接リリース可能なように見えます。会社内の十分に多くの人々がそれを見た後、「現在リリースできますか？」と尋ねます。しかし実際には、你们は早期デザイン探索段階にあり、誰も明言していないだけです。
したがってデザインプロセスが死んだと言うのは、既に対でもあり錯でもありません。もし特定ツールと特定日常業務に绑定されているなら、確かに死んだのです。しかし「我们现在プロセスのどの段階にいるか」という認識は、これまで以上に重要になっています。
デザインプロセスを特定メディアに绑定すること、それが危険な場所です。デザイナーは現在より多くのツールを持っています。ものを直接既存プロダクトに入れることも、A/B テストを行うこともできます。多くの会社にはプロダクトのベビーバージョンがあります。ベビー Cursor、ベビー Codex。大幅に簡素化されたコードベースで、正式プロダクトのすべてのインタラクションをシミュレートできます。それを使って vibe code できます。「もしサイドバーがこうなったら？もしパネルがポップアップしたら？」これはデザイナーの新しいツールですが、古い認識と配合する必要があります：你现在プロセスのどの位置にいるか。
岗位と役割が融合しているが、PM は消失しない
Lenny：多くの会社が「役割消亡」と言っています。PM、エンジニア、デザイナーの分業は完全に消失すると思いますか？
アンドリュー・アンブロシーノ：一部の会社は潮流に乗り、極端に行くことを好みます。役割概念を消滅させる危険性は、同時に「これらの領域には学習可能なベストプラクティスがある専門職である」という認識を消滅させる可能性があることです。
多くの会社が「私たちはプロダクト役割をキャンセルする」と言うのを聞きますが、これは非常に悪いアイデアだと思います。そして「誰もが builder だ」と言います。結果として、真のベストプラクティス积累了あり、真に陷阱を踏んだことのある学科であるプロダクトマネジメントが、直接抛弃されます。誰かが数行のコードを書いただけで、万事 OK だと思うのは、良い状態ではありません。
「これはあなたの領域ではない、触れてはいけない」という境界の消失は歓迎しますが、バランスが必要です。誰もがすべての事を行えるわけではありません。広さからも深さからもそうです。这也是なぜ管理者が消失しない理由です。
しかもあらゆる学科にはスキル成分があります。多くのエンジニアはこの点を認めず、エンジニアリングにはスキルがあるが、他の岗位役割はすべて「雰囲気」だと思っています。そうではありません。Excel を使えるからといって財務チームで働けるわけではありません。
現在起こっているのは、人々が跨役割コラボレーションしやすくなり、他の領域のベストプラクティスを学びやすくなったことです。ある役割での効率を特定ツールを使用する能力に绑定する必要がなくなりました。
私は很长时间觉得自己ソフトウェアエンジニアを行うべきではないと感じていました。なぜならアセンブリ言語に関心もなく、TypeScript のタイプシステムを記憶したくなかったからです。これらの役割には常にいくつかの閾値が存在し、「この役割をうまく行う等于このツールを熟練 mastered すること」であるかのように見えていました。これは正に解消され始めていますが、人々はそれを誇張しています。
Lenny：你们 Codex チーム内には確かに多くの役割融合がありますが、具体的にはどのようなものですか？
アンドリュー・アンブロシーノ：私たちは Codex チーム内で、確かに会社の他のチームや他の業界よりも多くの役割融合を見ています。部分的な理由は、これがエンジニア向けの技術プロダクトだからです。したがって私たちのデザイナーはエンジニアの言語を話し、私たちのプロダクトマネージャーは技術言語を話し、コードを書きます。
私たち内部にはコラボレーション方法を記述する言い方があります：現在役割間のオーバーラップは過去よりもはるかに大きいです。人を定義する際、「デザインがどこで終わり、エンジニアリングがどこから始まるか」といった責任境界を見るのではなく、彼のすべての仕事内容の平均分布を見ます。
もしデザインチームのある人物が行ったすべてのことを展開して見れば、その中には大量のコードを書く仕事も含まれ、大量のプロダクト関連の仕事も含まれます。しかしこれらの仕事に「平均値」を取れば、彼は最終的によりデザイン寄りの領域に落在ことになります。
Lenny：あなたはプロダクトマネージャーの仕事がより zone defense（区域防守）に似ていると提到了が、具体的にはどういう意味ですか？
アンドリュー・アンブロシーノ：もし二人のプロダクトマネージャーが過度に緊密にコラボレーションすれば、通常は良いシグナルではありません。力指向レイアウトのようにチームを展開して見るべきです。どこに隙間があるか？どこまだ誰もカバーしていないか？
今日の世界では、キュレーション、ガイダンス、アライメントが最も重要な仕事になりました。誰もが絶えずアイデアを投げ出し、環境全体がノイズに満ちています。過去のようなトップダウンで年間計画を立てる方式はもう機能しません。我们需要有人作为品味のゲートキーパーとなり、一件事をコンセプトからプロダクトへと導く必要があります。そしてこれは、あなたが会社の隅々までカバーする必要があることを意味します。
したがって、チームを展開して見る必要があります。誰が何が得意か？彼此を一定の距離に保ち、カバレッジが十分に全面的であることを確保します。その後ギャップを埋めます。例えば：「プロダクト思考が強いエンジニアを募集したい。」私たちはこのような状況を望みません。一群人がまず大量のコードを書き、最後にプロダクトチーム全体にプロダクトの一貫性を審査およびキャリブレーションさせる必要がある状況です。私たちは誰もがこれらの能力を持つことを望みます。ただ各自深く钻研する方向が変化する必要があるだけです。
Lenny：したがって現在最も価値のある人は、アイデアから完成まで全程を推進でき、かつ品味を持って「これは素晴らしい」と知道できる人ですか？
アンドリュー・アンブロシーノ：はい、我觉得これが当下最も核心的な変化です。これはまた、私が IC（個人貢献者）と管理者の関係について理解していることも反映しています。管理が消失するわけでも、誰もが単なる IC であるわけでもありません。現在每个人はある程度同時にこれら二つの役割を担っています。
もしあなたが IC なら、你已经不再一文字ずつコードを敲いているわけではありません。你実はあるものを管理しています。agents を管理し、組織されて共同でタスクを完了する仕事を管理しています。もしあなたがチーム管理者なら、本質的に行っているのは同じ事です。ただ管理の粒度が異なるだけです。
私が通常探す人は、扎实な専門能力を備えている除此之外、必ず品味を持っていなければなりません。なぜなら「無限の tokens を持つ」世界において、私たちはゴミコンテンツを生産できないからです。你必须海量のコンテンツからシグナルとノイズを見分ける能力を備えていなければなりません。
毎回有人 Codex チームに何人いるか尋ねると、私の答えは：「およそ 10 人から数千人の間です。」これは冗談のように聞こえますが、実際にはすべての人の仕事がこのプロダクトに汇聚します。モデル研究、ブラウザ使用、モデル人格、フロントエンドインフラ、ユーザーエクスペリエンス。これらすべてがプロダクトの一部を構成しています。
しかし同時に、私たちは毎日数千人から提出された PR（コード提出リクエスト）を受け取っているわけではありません。チームには两位数規模のエンジニアがおり、デザイナーの数はエンジニアの約半分です。再加上数人のプロダクトマネージャー。绝大多数は IC です。チームの影響範囲は大きいですが、管理階層は厚くありません。ここにはかつて会社を創業した人も多く、また大手企業内で「創業者マインドセット」で仕事をする人も多く、さらに品味が極めて良い人も多くいます。
全体の Codex アプリはすべて dogfooding のループによって形作られました。私たち全員に共通の願いがあります。可能な限り多くの仕事をアプリ内で完了すること。たとえそれが暫時最高のツールでなくても。なぜなら只有这样、它最終的に最高のツールになる機会があるからです。私たちは經常刻意に某些内部プロセスを改善せず、プロダクト自体をより良くし、从而これらのプロセスをサポートできるようにします。これは実際には非常に不舒服な状態です。しかし週ごとに、它確かに持続的に変化しています。
Codex は 3 ヶ月早くリリースすれば死んでいた。唯一の違いはモデルが進歩したこと
Lenny：物事がこれほど速いペースで変化する中で、你们はどう計画していますか？どのくらい先を見ていますか？
アンドリュー・アンブロシーノ：私たちは計画において革命的な做法はありません。基本原則は、当下に近ければ近いほど、計画はより具体的である必要があるということです。9 ヶ月の計画を行わないわけではありません。しかしその計画は非常に模糊でなければなりません。なぜなら你现在 9 ヶ月の計画に加える任何の精度は、虚假精度であり、時間を浪費するだけだからです。
アプリプロダクト側では、11 月に計画できることは、12 月にはまだ正しいかもしれませんが、2 月には完全に別の事になっています。
私の前の会社では、モデル能力に基づいて機能開発を駆動し始めた時、原有のプロダクトプロセスは基本的に崩壊しました。後に興味のある方向をすべてリストアップし、それらのプロトタイプを作成し、哪些が現在実行可能かを判断し、他のものは暫時搁置するようになりました。モデル能力に新しい飛躍が現れるたびに、那些搁置されたものを再び取り出して試します。なぜなら機能が最終的に十分良いかどうかの前提は、多くの場合機能そのものの形態ではなく、モデルが十分に賢いかどうかだからです。多くの人々が私の計画方法に不満を持っています。しかしこの事は確かに非常に難しいです。
Lenny：タイミングがどれほど重要かを示す具体的な例はありますか？
アンドリュー・アンブロシーノ：Codex については良い故事があります。我非常確信しています。私たちが 2 月にリリースした Codex アプリは、もし 11 月に準備が整ってリリースされていれば、市場で完全に失敗していたでしょう。唯一の違いは 11 月から 2 月の間にモデルが進歩したことです。同一プロダクト、完全に同じ形態。結果は完全に異なります。只差数ヶ月。
Lenny：したがって現在不行なものは以後行けるようになる可能性がありますか？より大きな野心を維持する必要がありますか？
アンドリュー・アンブロシーノ：はい。人々に「このものは現在不行なので、それは悪い機能だ」と轻易に認定しないよう推奨します。それは単に時期尚早なだけかもしれません。
Codex の最初のリリースに戻ります。Codex web。基本的にモデルにタスクを与え、它が行い、完了して結果を返します。過激に聞こえませんが、問題は它が十分うまく行えず、その形態が超前すぎたことです。
その後 Claude Code が出現しました。完全にローカル化され、クラウドに接続せず、自分がどれだけ AGI かも偽装しません。它はあなたに質問し、そこで待ちます。人生全体を它に委託することはできません。它ははるかに使いやすくなりました。なぜなら当時のモデルの能力レベルにマッチしたからです。
私たちは当時あまりにも「AGI でした」。我经常この教訓を考えます。過去、プロダクトが市場で失敗した場合、それは多くの場合プロダクト形態やコミュニケーション方法に関する問題を教えてくれました。現在異なります。あなたは同じものを六回リリースする必要があるかもしれません。直到它成功するまで。形態は完全に変わらないかもしれません。
アプリ内ブラウザもこのような状況です。私たちはかつて動作するバージョンを持っていました。Atlas 時期に戻れば、私たちは既に agent をブラウザ内でタスクを実行させていました。さらに前は ChatGPT 内の Operator。それは成功しませんでした。しかし Operator、Atlas、Codex、ChatGPT を串にして見れば、它们間に実際に連続した進化の道筋を描けることに気づきます。本質的には同一機能です。ただ知能レベルの変化に伴い、絶えず再リリースされ、結果もこれにより完全に変わりました。
一度プロダクトや機能が存在すれば、人々は容易に各種詳細問題や微最適化に注意を向けます。そして彼らは確かにそうすべきです。しかし這也是なぜ私たちが常にボトムアップの探索カルチャーを維持する理由です。因为有时、Codex アプリがかつて某种方式で ChatGPT を颠覆したように、Codex 自身も未来に新しい試みによって颠覆される可能性があります。同じチームに継続的に颠覆的なイノベーションを生み出させつつ、常にプロダクト品質とディテールの磨きに専念させることは期待できません。ある段階で、あなたはこれらの二つの能力が同時に存在できるメカニズムを設計する必要があります。
Lenny：Codex のビジョンは何ですか？你要把它带到哪里？
アンドリュー・アンブロシーノ：今年 1 月と 2 月、私たちは内部自用テストの過程で、エンジニアリングと研究ワークフローにおいて非常に明確な PMF が形成されていることを発見しました。同時に、市場、広報、財務、法務の人々も Codex を使用しています。たとえこのアプリが彼らにとって友好的でなくても。它は彼らにコードを示し、コマンドライン検索ツールの実行を承認させます。
私たちは Codex の能力を他のプロダクトに追加しようと試みました。ChatGPT デスクトップアプリ、Atlas ブラウザ。結果最も面倒な事が発生しました。誰も Codex アプリを離れ、那些据说专门为彼ら打造されたプロダクトを使おうとしません。
これは私たちに啓発を与えました。開発者ツールと汎用ナレッジワークツールの間には、実際には多くの微妙な共通点が存在します。私たちは確かに信じています。私たちが構築しているこのプロダクト形態は、各種深度垂直シナリオを承载する正しい形態です。簡単から始め、必要に応じて徐々に複雑さを増加させます。
それは「画面上に矩形を描き、その後すべての事必须在里面完成する」ようなプロダクトではありません。よりベースキャンプに似ています。ここで仕事を開始し、終了し、自動化プロセスを管理します。そして它は你需要するすべてのツールを呼び出します。有人はこの形態を「super app」と呼んでいます。本当に彼らが当時そう呼ばなければ良かったと思います。なぜなら現在私はほぼ毎日この言葉を聞かなければならないからです。
Dan Shipper には非常に面白いアイデアがあります。彼は未来に私たちは Codex 内で「内から外へ」SaaS ツールを使用するだろうと考えています。Notion、Linear、Salesforce はあなたがブラウザで開くものではなく、agent が Codex 内で帮你操作するものです。我们也確かにこれを行っています。アプリ内ブラウザ、Chrome 拡張、computer use。これらすべては Codex が外部ツールと交互できる方法です。
最も良い例の一つ。私たち内部の動画制作人 Brent は Codex を使用して Codex のリリース動画を編集しました。Codex は動画エディタではありません。那些 UI もありません。しかし它は Brent が Premiere Pro を使用していることを理解し、Premiere Pro 背後のファイルを編集して一些修改を行うことができます。它がすべての事を行えないことを発見した時、它は自ら Premiere Pro 拡張プラグインを書き、Premiere Pro にインストールし、その後このプラグインを通じて Premiere Pro と対話しました。これを見た時私たちは 모두震惊しました。
これは良いパターンです。専門ツールが専門の事を行います。Codex はより良い動画エディタになる必要はありません。它能无缝に専門ツールと交互できれば十分です。
コードを書くことは重要ではなくなった。コードを削除することこそ重要
Lenny：手書きコードから AI が 100% のコードを書くへ。そして現在の agents とループへ。最前線のチームは現在到底どう働いていますか？
アンドリュー・アンブロシーノ：Loops（ループ）？それは先週の事です。
私たちは常に「プロダクトのどの割合が AI によって書かれたコードか」という問題を議論しています。昨年の基準で見れば、現在私たちの 100% のコードは AI によって書かれています。したがって問題はもはや「どのくらいが AI によって書かれたか」ではなく、「コードは監督の下で書かれたか無監督で書かれたか」です。これは完全に異なる次元です。私はこの基準が絶えず更新されることを歓迎します。なぜならこれは私たちがプロダクト進展を遂げていることを意味するからです。
私たちは自律開発ソフトウェアにおいて多くの探索を行いました。例えば大量の harness engineering。例えば「もしモデルが夜間に自動的にコードベースのガベージコレクションとクリーンアップを行ったら？」
しかし現在すべてのモデルには問題があります。它们は常に複雑さを増加させています。もし研究を行っている人が聞いているなら：お願いです、モデルにコードを削除することを学ばせてください。開発を完全に自動運転に任せようとする時、これは人的レベルにおいてもコードベースレベルにおいても深刻な問題になります。
Feature requests（機能リクエスト）も同様です。どのようにモデルに哪些機能を行う価値があるか、哪些を無視すべきか、哪些をマージ後再定義すべきかを判断するよう教えるべきか？またどのようにモデルに正しい抽象化を構築するよう教えるべきか？
これらの能力は継続的に進歩しています。しかし私は私たちが既にこのような段階に発展したとは思いません。ループを設定し、モデルに自動的に「アプリを改善」させ、Twitter、Slack、メールを継続的にリスニングし、その後自律的にイテレーションを完了させる段階です。ただし、私たちは確かにこの事を実現しようとしています。
Lenny：あなたは私たちがその段階に至ると思いますか？つまり目標を設定する：「勝つ」？
アンドリュー・アンブロシーノ：「/goal 私に 10 億ドル稼がせて。」我不知道。私は決してないまたは永遠にどうとは言いません。
Lenny：あなたはプロダクトおよびエンジニアリング負責人として、自分自身はどのように AI を使用して働いていますか？
アンドリュー・アンブロシーノ：我觉得我现在おそらく世界上最高の仕事を持っていると思います。
最初に Codex を行った時、私の個人の目標は它を私がそれを使用して Codex のコードを書けるほど良くすることでした。それはスーパー緊密な自用プロダクトループでした。私はある事を行えません。ならばそれを修復します。その後我能できます。その後より多くの事を行えます。
後に私の役割は変わりました。私はより多くのプロダクトディスカバリーを行う必要がありました。チームが何を行っているかを理解し、方向から逸れたものを修正します。于是 Codex は私がこれらの事を行うツールになりました。「このデータを整理するスプレッドシートを構築してください。」「この方向で過去に哪些探索が行われたか、内部深層調査を行ってください。」
5 月の一連のリリース。アプリ内ブラウザ、computer use、artifact creation。那是我們第一次使用 vibe coordination（氛围式協調）でリリースを管理しました。私にはすべての ToDo を記録する Notion ドキュメントがあります。その後 Codex を使用して自動的に PR、Slack チャンネルから進展を収集し、ステータストラッカーを更新します。当時これはプロダクトリリース方法を管理する最前線だと感じていました。
現在私は毎日朝起きると、Codex が帮我生成した日報を見ます。私が参加した 3000 個の Slack チャンネルから私が注目する必要がある事を篩い分けます。私は「私に 5 つの質問をください。私が回答します」と返信できます。它は自己調整します。私は「次回実行時、このワークフローへの注目を減らしてください」または「この事が発生したが日報に現れませんでした。以後確実に捕捉できるようにしてください」と言います。它は通知方法を更新し、注目重点を調整します。
Lenny：これはどう設定しますか？ワークフローは何ですか？
アンドリュー・アンブロシーノ：現在まだ発見段階です。スケジュールタスクを作成します：「私の Slack チャンネルを一遍し、これらは私が関心のある事です。これらにより分類整理し、ここにいくつかのコンテキストがあります。」最初の数回実行にはガイダンスが必要かもしれません。幸い私はどう指示を編集するかを探す必要はありません。私は直接対話して「次回これを帮我変更してください」と言います。它就更新します。
しかし我觉得这也是チャットボット形態の核心的な問題です。私はどう設定するか知道ています。なぜなら私にとってこれはプロダクトディスカバリーだからです。しかしもしあなたが OpenAI で働いておらず、これを開発していないなら、あなたはこれらの事を搞清楚したくはないでしょう。我们需要どうしてこれらの事が普通人にも使用可能な形態になるかを考える必要があります。
Lenny：私自身も Codex を使用してスパムメールをフィルターする自動化を作成しました。その中の一段階は Google Cloud コンソールで一堆の API トリガーを設定する必要があります。那个インターフェースは特に煩わしいです。そこで私は Codex に帮我行うよう頼みました。它は直接私のコンピュータを接管し、computer use 機能を使用して操作しました。
アンドリュー・アンブロシーノ：它就是：「コネクタがあるかないか関知しない。兄貴、私は直接クリックを開始する。」
どうコネクタ、アプリ内ブラウザ、Chrome 拡張および computer use 間の境界を划分するかは、非常に面白い事です。多くの場合、これらの境界は実際にはすべて感觉で摸索されたものです。
我觉得これらの個人ワークフローは特に面白いと思います。大家都様々なものを試しています。每个人は完全に異なるシステムを構築します。しかし徐々に、いくつかの共通パターンが浮上します。その後私たちは意识到します：「これはプロダクト内のファーストクラスエクスペリエンスになるべきだ。」
例えばメモリ（memory）。多くの人が Obsidian ナレッジベースや Notion スペースを設定して自分のマインドパレスを構築しています。あなたは自分で行う必要はありません。十分に汎用的なメモリ機能が替わり行うべきです。私たちは常に篩い分けています。什么对个人有効だが個人レベルに留めるべきか、什么应该進入プロダクトして基盤コンポーネントになるべきか。
Lenny：外の人々が見ているのはあなたが勝っていることだけです。しかし確かに事が成功しなかった時がありますか？
アンドリュー・アンブロシーノ：あなたがこのように描述するのは面白いと思います。これは実は私が初めて自分が失敗していないと感じた時です。
私は之前起業して多くの年を行いました。最後は基本的に会社を拆解して売却しました。高度な規制業界で行いました。プロセス全体は継続的な失敗のようでした。後に別のスタートアップに行きました。別の閉鎖された規制業界で AI ツールを行いました。これも一次又一次に不行でした。私は実際には多く失敗しました。有时只是一个时间点。スキル、情熱、市場窓がちょうどアライメントしました。
たとえ現在この Codex と ChatGPT を結合するプロジェクト内でも、数えきれないほどの小さな失敗があります。私たちは「このようにあるべきだ」と言い、Slack にリリースします。下には 2000 件のメッセージがあり、私たちがどれだけ愚蠢かと言います。これは私が OpenAI を好きな場所です。人々は直接告诉我们。内部プロダクトの失敗に対して容赦ありません。這也是なぜ外部プロダクトがうまくいっている理由です。私が現在この位置に到達する前に、私はおよそ 10 から 15 年失敗しました。したがって私は毎日まだ少し驚きを感じます。事が竟然順調に進んでいることに。
Lenny：読者に対して最後に何かアドバイスはありますか？
アンドリュー・アンブロシーノ：你现在のワークフローと「生涯绑定」しないでください。真に堅持すべきは、那些只有你が独特にデリバリーできる成果です。その後、継続的にあなたのプロセスを変更することを試みてください。もしあなたが最も引以为豪とするスキルが「私は Figma の auto layout（自動レイアウト）を最も理解している」なら、你在干什么？AI もあなたよりも上手くなるでしょう。行う価値のある事を見つけ、その後那些事を行う方法を見つけてください。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
