Codex 責任者：「すべての人がビルダーである」というのは非常に悪い考えです。

Andrew AmbrosinoはOpenAI Codexチームのリーダーです。デザイナー出身で、エンジニア、プロダクトマネージャー、起業も経験し、現在担当するCodexの週間アクティブユーザーは500万人を超えています。彼は、おそらく今最も「AI時代のプロダクト開発のあり方」を語るのにふさわしい人物の一人でしょう。

彼の見方では、会社のほぼ誰もがすぐに機能プロトタイプを作れるようになった今、本当の課題は「作れるかどうか」ではなく、「作るべきかどうか」に移っています。

Lennyとの対談で、Andrew AmbrosinoはOpenAI内部の開発プロセスを詳しく紹介しました。実装コストがAIによって大幅に圧縮された後、プロダクト開発のあらゆる局面――企画、ドキュメント、プロトタイプ、デザイン、役割分担、チームコラボレーション、プロダクト計画――が変化しています。どの古いルールが無効になりつつあるのか？どの新しい基準が形成されつつあるのか？実装が希少ではなくなったとき、本当に希少なリソースとは何か？

いくつかの核となる見解：

90人がそれぞれリリースできそうなプロトタイプを90個作れるとき、最も貴重なのは「 taste（センス）」です。

Codexチームの採用基準の一つは「 taste（センス）」であり、膨大な情報からシグナルとノイズを区別できることです。「無限のトークン」がある世界で、彼らはゴミコンテンツを生み出したくないのです。

もしCodexが3ヶ月早くリリースされていたら完全に失敗していたでしょう。唯一の変数はモデルの進歩でした。機能が悪いと簡単に判断せず、単にタイミングが悪かった可能性を考慮すべきです。

機能が最終的に十分に優れているかどうかは、機能の形態そのものではなく、モデルがどれだけ賢いかに依存します。

CodexがかつてChatGPTを覆したように、Codex自身も新しい試みによって覆される可能性があります。ボトムアップの探求文化を維持する必要があり、同じチームに細部の磨き上げと自己破壊的な革新の両方を期待することはできません。

以下は対談のエッセンスです。

実装コストが下がれば taste がより重要になる

Lenny：あなたは、AIがプロダクトワークの形を変えていると話しましたね。今、あなたはおそらく世界最先端のAIプロダクトチームで働いています。具体的に、プロダクトチームの働き方は2年前と比べてどう変わりましたか？

Andrew Ambrosino：今、チームリーダーとして最も難しいのは、プロセスが逆転したことです。

昔のプロダクト開発の進め方は誰もがよく知っています。まず調査、アイデア出し、プロトタイプ作成。ウォーターフォール開発の時代をとっくに過ぎていても、根本的なロジックは同じで、実装は高コストでした。そのため、実装前に文書、調査、プロトタイプを通じてすべてのリスクを事前に排除する必要がありました。プロトタイプとデザインは開発よりもコストが低い、これが過去の基本的な前提でした。

今ではその前提は完全に変わりました。誰でも何でも作れるようになりました。私は本当にそう信じています。ゼロからこれらのモデルと対話するだけで、私たちのモデルであれ他社のモデルであれ、あなたが望むどんな機能でも構築できます。これはソフトウェア開発の中で最も難しい部分ではないかもしれませんが、確かにクールなことです。

無限のトークンを人々に与えると、OpenAIの誰もが自発的で良いアイデアを持っています。だから誰もがあらゆる種類のものを作っています。今、会社には緊急に必要な機能があり、私は確信しています。90の異なる、調整されていない小さなチームがそれぞれ実装と試行を進めています。その90の試行の中で、どれが良いのか？どの部分を他の側面に折り畳むべきか？どのように定義すべきか？別の機能の一部であるべきか？スイッチの中にいくつのオプションがあるべきか？そういうことです。

つまり、短い答えは「逆転した」です。人々が根本的に異なる役割を担っているわけでも、スキルが消えたわけでも、役割が存在しなくなったわけでもありません。実装が最もコストのかかる部分ではなくなりました。あえて言えば、最もコストがかかるのは taste（センス）です。

Lenny：以前は皆がPRDや戦略ドキュメントを書いていましたが、今では直接プロトタイプを作ります。会社の多くの人が似たようなアイデアを持っていて、90の異なるものが出てきて、そこから方向を選ぶのですね？

Andrew Ambrosino：はい、そういうことが大量に起こっています。OpenAIだけでなく、すでに多くのプロダクトリーダーが「PRDは死んだ、プロトタイプが主流だ」と言っていますが、私は実際には全く同意しません。

なぜなら、実装があらゆるメディアで安価になったため、考えずにプロトタイプに飛びつくことが非常に魅力的になったからです。特にあなたがエンジニアでなく、コードを書いたことがなく、興味も時間もない場合、「PRDは死んだ、私が欲しいものを直接見せてあげる」と言いたくなるでしょう。

しかし、私は逆の現象も見ています。エンジニアにとっては、大量の文書を書くことが魅力的になり、読む価値のない文書が大量に生まれています。これは文書を書く人が悪いという意味ではなく、実装が豊富になったとき、自分の意見を表現する適切なフォーマットを選ぶことが本当に重要になるという話です。

もしあなたが表現したいのが曖昧な領域におけるプロダクトの明確さなら、確かに文書を書くべきでしょう。もし人々に実際に使ってもらい、インタラクションパターンをストレステストさせたいなら、プロトタイプを作るべきです。重要なのは適切なメディアを選ぶことです。

Lenny：「primal mark（最初の痕跡）」という概念があります。画家がキャンバスに最初に置く一筆で、その後のすべてがそこから派生します。あなたの言うことは、プロトタイプが間違った最初の一筆になることがあるということですか？なぜなら、皆がそれにアンカーされ、より大きな方案を考えなくなるからですか？

Andrew Ambrosino：そうです。過去には暗黙のシグナルがありました。何かがどのように見えるかが、プロセスのどの段階にあるかを示していました。もし何かが正式にリリースされたプロダクトのように見えたら、それは既に後期段階であり、リスクは排除され、デザインは確認され、ビジネス目標は合理的であることを意味していました。

今ではこれらは切り離されました。その理由は、過去に構築のためのリソースを得るには、まずリスクを十分に低減する必要がありましたが、今ではそのハードルがなくなったからです。したがって、本来は探求段階のものだけが、すでにリリース可能に見え、視覚的にも準備ができています。しかし、それは正しい方向ではないかもしれません。調査結果に合わず、ユーザーが本当に必要としているものでもなく、ビジネスに最適な選択でもないかもしれません。

taste（センス）を過度に強調するつもりはありません。しかし繰り返しますが、何をすべきか、どのように提示するか、どのように目標を達成するか、どのメディアを使うかを知ることは、今やあらゆる分野で最も重要な能力になりつつあります。

Lenny：「taste（センス）」という言葉は今流行語ですね。具体的に、あなたが言う「良いセンス」とは何ですか？

Andrew Ambrosino：taste（センス）は分解して考える必要があります。

確かに美的な部分もありますが、システム思考の部分もあります。このものをシステム全体にどのように配置するか。方向性の部分：私たちはどこへ行くのか、これはどのテーマの一部か。表現の部分：この情報をどう提示するか。さらに、tasteの一部はインタラクションのレイヤーにあります。このアニメーションは伝えようとする意味に合っていない、速すぎる、表現しようとする意図と一致していない。

これらは確かに非常に重要ですが、本当のtasteの問題は、もし何でもできるなら、目標は何か？どうやってそこに到達するか？ということです。

Lenny：AIがますます強力になり、多くのことを行うようになったとき、人間の脳はどの領域で価値を発揮し続けるのでしょうか？tasteはその一つに思えます。しかし、AIのデザイン出力はまだあまり良くありません。なぜトップモデルはデザインをうまくできないのですか？

Andrew Ambrosino：実用的な理由もいくつかあり、解決が難しい問題もあります。デザインはソフトウェアよりも評価が難しいです。デザインの良さについてモデルを訓練するフィードバックループを作ることは、コードがコンパイルできるかどうかを訓練するよりもはるかに面倒です。なぜなら、人間のtasteがフィードバックメカニズムの一部だからです。

さらに、研究所は歴史的に、AI研究を加速できるモデルを優先してきました。モデルが正しいコードを書けることは明らかに研究を加速しますが、デザインについては同じ論証ができません。デザインが重要でないという意味ではなく、それがフィードバックループに含まれていないだけです。

これらは実用的な理由で、いずれは解消されるでしょう。モデルはデザインにおいてかなり優れたものになるでしょう。しかし、より解決が難しいものもあります。

第一に、デザインには文化的な側面があります。昨年、すべての新しいウェブサイトがLinearのデザインをコピーしていたのを覚えていますか？もしモデルが毎回Linearのウェブサイトを出力するなら、それは課題ではありません。デザインにおける斬新さの重要性は、ソフトウェアエンジニアリングよりもはるかに高いです。ソフトウェアエンジニアリングではモデルが既知のパターンに完全に従うことを望みますが、デザインにはある程度のランダム性と斬新さが必要です。

第二に、ビジュアルデザインとコードの間の相互作用です。もし明日会社がブランドを変更した場合、浅いアプローチは263のコンポーネントを一つずつ更新することです。深いアプローチは、この2つが異なって見えても実際には同じリストスタイルに属し、同じインタラクションパターンを伝えていることを理解することです。この抽象化レイヤーは、現在の技術ではまだ手が届きません。

Lenny：Jenny Wen（Anthropic Claude Codeのデザイン責任者）は「デザインプロセスは死んだ、直接構築すべきだ」と言っていますが、あなたはどう思いますか？

Andrew Ambrosino：Jennyと私は多くのことで一致しているかもしれません。正式なデザインプロセスについては、彼女の言う通りだと思います。それは死にました。そして私はAI以前からそのプロセスのファンではありませんでした。

何年も前に私がスタートアップをしていたとき、「Case Study Factory」という記事がありました。それは、デザイナーが一定のプロセスに従うように訓練され、次第にそのプロセスそのものを結果よりも重要視するようになるという話です。もし何かがこのプロセスを経れば、自動的に2つの結論が導き出されると想定されます。第一に、それは良いものになる。プロセスが品質を保証する。第二に、たとえ誰も使わなくても、それは良いものだ。なぜならプロセスを経たからだ。

ユーザー調査、発散、収束。フレームワークは正しいですが、常に少し学術的でした。そのプロセスの前提は、実装が高コストであり、一度しか作れないため、作る前にすべての問題空間と解決策空間を網羅する必要があるというものでした。

その後、FigmaとOrigamiが登場し、インタラクションプロトタイプをプロセスに取り込みました。今の問題は、実装全体をプロセスの最前面に持ってくることができることです。完全に洗練されたプロトタイプは、直接リリース可能に見えます。会社の十分な数の人がそれを見て、「今リリースできますか？」と尋ねます。しかし実際には、まだ初期のデザイン探求段階にあり、誰もそれを明言していないだけです。

だからと言って、デザインプロセスが死んだというのは、正しくもあり正しくもありません。もし特定のツールや特定の日常業務に縛られているなら、確かに死んでいます。しかし、「私たちは今プロセスのどの段階にいるのか」という認識は、これまで以上に重要です。

デザインプロセスを特定のメディアに縛ることが、危険なところなのです。デザイナーには今、より多くのツールがあります。既存のプロダクトに直接物を入れたり、A/Bテストを行ったりできます。多くの企業はプロダクトのベビーバージョン、ベビーCursor、ベビーCodexを持っています。大幅に簡略化されたコードベースで、正式なプロダクトのすべてのインタラクションをシミュレートできます。それを使ってvibe code（雰囲気プログラミング）ができます。「もしサイドバーがこうなったら？もしパネルがポップアップしたら？」これはデザイナーにとっての新しいツールですが、古い認識と組み合わせる必要があります：今、プロセスのどこにいるのか。

職種と役割は融合しつつあるが、PMはなくならない

Lenny：多くの企業が「役割の消滅」について話しています。PM、エンジニア、デザイナーの役割分担は完全になくなると思いますか？

Andrew Ambrosino：一部の企業はトレンドに乗るのが好きで、極端に走ります。役割の概念を排除する危険性は、同時に「これらの分野には学ぶべきベストプラクティスがある専門職である」という認識を排除することにあります。

私は多くの企業が「プロダクトの役割を廃止する」と言うのを聞きますが、それは非常に悪いアイデアだと思います。そして「誰もがビルダーだ」と言うのです。結果として、プロダクトマネジメントという、真のベストプラクティスが蓄積され、実際に失敗から学んできた分野が、直接捨てられてしまいます。誰かが数行のコードを書いただけで、万事うまくいくと思うのは、良い状態ではありません。

「これはあなたの領域ではない、触ってはいけない」という境界が消えるのは歓迎しますが、バランスが必要です。誰もがすべてのことができるわけではありません。広さと深さの両方においてです。だからこそマネージャーもなくなりません。

そして、それぞれの分野にはスキル要素があります。多くのエンジニアはそれを認めず、エンジニアリングにはスキルがあり、他の職種は「雰囲気」だと思っています。そうではありません。Excelが使えるからといって、財務チームで働けるわけではないのです。

今起こっているのは、人々が役割を超えたコラボレーションがより容易になり、他の分野のベストプラクティスを学ぶことも容易になったことです。特定の役割における効率を、特定のツールを使う能力に結びつける必要がなくなったのです。

私は長い間、自分はソフトウェアエンジニアになるべきではないと思っていました。なぜなら、アセンブリ言語に関心がなく、TypeScriptの型システムを覚えたくなかったからです。これらの役割には常に一定のハードルがあり、「この役割をうまくこなす＝このツールを熟練して使う」という感じでした。それが解消され始めていると思いますが、人々はそれを誇張しています。

Lenny：あなたのCodexチームでは確かに役割の融合が進んでいますね、具体的にはどのような感じですか？

Andrew Ambrosino：Codexチームでは、確かに社内の他のチームや業界の他の企業よりも、役割の融合が進んでいます。その理由の一部は、これがエンジニア向けの技術プロダクトだからです。そのため、私たちのデザイナーはエンジニアの言語を話し、プロダクトマネージャーは技術言語を話し、コードを書くことができます。

私たちはチーム内でコラボレーションのスタイルを説明する方法として、今では役割間の重複が以前よりもはるかに大きいと言います。人を定義するのは、「デザインはどこで終わり、エンジニアリングはどこから始まるか」といった責任範囲ではなく、彼らが行うすべての仕事の平均的な分布です。

もしデザインチームの誰かが行うすべてのことを広げてみると、そこには大量のコードを書く作業や、大量のプロダクト関連の作業が含まれているかもしれません。しかし、これらの仕事の「平均」を取ると、結局彼または彼女はよりデザイン寄りの領域に位置することになります。

Lenny：あなたはプロダクトマネージャーの仕事はzone defense（ゾーンディフェンス）のようなものだと話しましたが、具体的にはどういう意味ですか？

Andrew Ambrosino：もし二人のプロダクトマネージャーが非常に密接に協力しすぎている場合、通常それは良い兆候ではありません。むしろ、フォース指向レイアウトのようにチームを広げて見て、どこに空白があるか、まだ誰もカバーしていない領域はどこかを確認すべきです。

今日の世界では、キュレーション、ガイダンス、アライメントが最も重要な仕事になっています。誰もが絶えずアイデアを投げ出し、環境全体がノイズに満ちています。過去のようなトップダウンで年度計画を立てるやり方はもう通用しません。tasteのゲートキーパーとして、コンセプトからプロダクトへと導く人が必要です。そのためには、会社のあらゆる場所をカバーしなければなりません。

したがって、チームを広げて見て、誰が何が得意か、お互いに一定の距離を保ち、カバレッジが十分に広いことを確認する必要があります。そして、ギャップを埋めます。「プロダクト思考の強いエンジニアを採用したい」といった具合に。私たちは、あるグループが大量のコードを書き、最終的にプロダクトチーム全体がプロダクトの一貫性をレビューして調整するような状況を避けたいのです。私たちは全員がこれらの能力を持ち、それぞれが専門とする方向性が変わっていくことを望んでいます。

Lenny：つまり、今最も価値のある人は、アイデアから完成まで全体を推進でき、さらに「これは素晴らしい」と判断するtasteを持っている人ですね？

Andrew Ambrosino：そうです。それが今の最も中心的な変化だと思います。これは私のIC（個人貢献者）とマネージャーの関係についての理解にも反映されています。マネジメントが消えるとか、誰もが単なるICになるという意味ではありません。今や誰もがある程度、両方の役割を同時に担っています。

もしあなたがICなら、もう一文字一文字コードをタイプしているわけではありません。実際には、何かをマネジメントしています。エージェントを、組織化されて共同でタスクを実行する仕事をマネジメントしています。もしチームマネージャーなら、本質的には同じことをしていますが、マネジメントの粒度が異なるだけです。

私が通常求める人は、しっかりとした専門能力に加えて、tasteを持たなければなりません。なぜなら、「無限のトークン」がある世界では、ゴミコンテンツを生み出すわけにはいかないからです。膨大なコンテンツからシグナルとノイズを区別する能力が必要です。

誰かがCodexチームの人数を尋ねるたびに、私の答えはこうです。「だいたい 10 人から 数千人の間くらいです。」冗談のように聞こえますが、実際には、全員の仕事がこのプロダクトに集約されます。モデル研究、ブラウザ使用、モデルの人格、フロントエンド基盤、ユーザー体験、これらすべてがプロダクトの一部を構成しています。

しかし同時に、毎日数千人が提出したPRを受け取っているわけでもありません。チームは二桁のエンジニア、デザイナーはその約半数、それに数人のプロダクトマネージャーで構成され、大多数はICです。チームの影響範囲は大きいですが、マネジメント層は厚くありません。ここにはかつて会社を創業した人が多く、大企業で「創業者マインドセット」で働く人も多く、非常に優れたtasteを持つ人もたくさんいます。

Codexアプリ全体は、dogfoodingのサイクルによって形成されてきました。私たち全員に共通の願いがあります。できるだけ多くの仕事をアプリ内で完了させることです。たとえそれが一時的に最高のツールでなくても、そうすることで最終的に最高のツールになるチャンスが生まれるからです。私たちはあえて内部プロセスを改善せず、代わりにプロダクト自体を改善してそれらのプロセスを支えられるようにすることがよくあります。これは非常に居心地の悪い状態です。しかし、週を追うごとに、確かに変化し続けています。

Codexが3ヶ月早くリリースされていたら死んでいた、唯一の違いはモデルの進歩

Lenny：こんなに速い変化のペースの中で、あなたたちはどのように計画を立てていますか？どのくらい先を見ていますか？

Andrew Ambrosino：計画に関して、私たちは革新的なことをしているわけではありません。基本原則は、現在に近いことほど、計画は具体的でなければならないということです。9ヶ月の計画を立てないというわけではなく、その計画は非常に曖昧に保たなければならないということです。なぜなら、今9ヶ月計画に追加するどんな精度も虚偽の精度であり、時間の無駄だからです。

アプリケーションプロダクトの側では、11月に計画できることは、12月にはまだ正しいかもしれませんが、2月には全く違うものになっています。

私の前の会社では、モデル能力に基づいて機能開発を推進し始めたとき、既存のプロダクトプロセスはほぼ崩壊しました。その後、興味のある方向性をすべてリストアップし、プロトタイプを作り、どれが今実現可能かを判断し、残りは一時的に保留するようになりました。モデル能力に新しい飛躍があるたびに、保留していたものを再び取り出して試してみます。なぜなら、機能が最終的に十分に優れているかどうかは、機能の形態そのものではなく、モデルがどれだけ賢いかに依存するからです。多くの人が私の計画のやり方に不満を持っていました。しかし、これは確かに非常に難しいことです。

Lenny：タイミングの重要性を示す具体的な例はありますか？

Andrew Ambrosino：Codexについて良い話があります。私は確信しています。私たちが2月にリリースしたCodexアプリは、もし11月に準備ができてリリースされていたら、市場で完全に失敗していたでしょう。唯一の違いは、11月から2月の間にモデルが進歩したことです。同じプロダクトで、全く同じ形態でありながら、結果が全く異なりました。たった数ヶ月の差です。

Lenny：つまり、今ダメなものも将来は通用する可能性がある？より大きな野心を持つべきですか？

Andrew Ambrosino：そうです。私は人々に「これは今ダメだから、悪い機能だ」と簡単に決めつけないことを勧めます。単に時期が来ていないだけかもしれません。

Codexの最初のリリース、Codex webに戻りましょう。基本的にはモデルにタスクを与え、それを実行し、完了したら結果を返すというものです。過激には聞こえませんが、問題はそれが十分にうまく機能しなかったことです。その形態はあまりに先進的すぎました。

その後、Claude Codeが登場しました。完全にローカルで、クラウドに接続せず、自分がAGIであるかのように振る舞いません。質問をしてきて、待っていて、人生全体を委任することはできません。はるかに使いやすかったです。なぜなら、当時のモデルの能力レベルにマッチしていたからです。

当時、私たちはあまりに「AGI的」すぎました。私はこの教訓をよく考えます。過去には、プロダクトが市場で失敗すると、プロダクトの形態やコミュニケーション方法について多くを教えてくれました。今は違います。同じものを成功するまで6回リリースする必要があるかもしれません。形態は全く変わらないかもしれません。

アプリ内ブラウザも同様の状況です。私たちには以前、動作するバージョンがありました。Atlasの時代に遡ると、すでにエージェントがブラウザ内でタスクを実行していました。さらに遡るとChatGPTのOperatorがありますが、それは成功しませんでした。しかし、Operator、Atlas、Codex、ChatGPTを結びつけてみると、それらの間に連続的な進化の線を引くことができることがわかります。本質的には同じ機能であり、インテリジェンスレベルが変化するにつれて再リリースされ、結果が根本的に変わったのです。

一度プロダクトや機能が存在すると、人々は様々な細かい問題やマイクロ最適化に注意を払いやすくなります。そして実際そうすべきです。しかし、だからこそ私たちは常にボトムアップの探求文化を維持しています。なぜなら、時には、Codexアプリがある方法でChatGPTを覆したように、Codex自身も将来新しい試みによって覆される可能性があるからです。同じチームに継続的に破壊的なイノベーションを生み出させ、同時にプロダクトの品質と細部の磨き上げに常に集中させることは期待できません。ある段階で、これら二つの能力が同時に存在できるようなメカニズムを設計しなければなりません。

Lenny：Codexのビジョンは何ですか？どこに連れて行こうとしていますか？

Andrew Ambrosino：今年の1月と2月、社内での自社利用テストの過程で、エンジニアリングと研究のワークフローにおいて明確なPMF（プロダクト・マーケット・フィット）が形成されていることがわかりました。しかし同時に、マーケティング、コミュニケーション、財務、法務の人々もCodexを使っていました。たとえそのアプリが彼らにとって使いやすいものではなく、コードを表示したり、コマンドライン検索ツールの実行を承認させたりするものだったとしてもです。

私たちはCodexの機能を他のプロダクト（ChatGPTデスクトップアプリ、Atlasブラウザ）に追加しようと試みました。結果、最も厄介なことが起こりました。誰もCodexアプリを離れて、自分たちのために特別に作られたはずのプロダクトを使おうとしなかったのです。

このことから得た教訓は、開発者ツールと一般的な知識ワーカーツールの間には、多くの微妙な共通点があるということです。私たちは確かに、現在構築しているこのプロダクト形態が、様々な深い垂直領域を支える正しい形態であると信じています。シンプルなものから始め、必要に応じて徐々に複雑さを追加していくのです。

それは「画面に四角形を描いて、その中ですべてを完結させる」ようなプロダクトではありません。どちらかと言えば、基地のようなものです。ここで仕事を始め、終え、自動化プロセスを管理し、必要なすべてのツールを呼び出します。この形態を誰かが「スーパーアプリ」と呼びましたが、本当にそう呼ばなければよかったと思います。なぜなら今、私はほぼ毎日この言葉を耳にしなければならないからです。

Dan Shipperには面白いアイデアがあります。将来、私たちはCodexの中で「内側から外側へ」SaaSツールを使うようになるというものです。Notion、Linear、Salesforceはブラウザで開くのではなく、エージェントが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%コードを書く時代、そして現在のエージェントとループへ。最先端のチームは今、実際にどのように働いているのですか？

Andrew Ambrosino：Loops（ループ）？それは先週の話ですね。

私たちはずっと「プロダクトのコードの何％がAIによって書かれているか」という問題について議論してきました。昨年の基準で言えば、今では私たちのコードの100%がAIによって書かれています。ですから、問題はもはや「何％がAIで書かれているか」ではなく、「コードは監督下で書かれているか、それとも無監督で書かれているか」という全く異なる次元です。私はこの基準が絶えず更新されることを歓迎します。なぜなら、それはプロダクトの進捗を意味するからです。

私たちは自律的なソフトウェア開発について多くの探求を行っています。例えば、ハーネスエンジニアリングの大量導入や、「もしモデルが夜間に自動でコードベースのガベージコレクションとクリーンアップを行ったら？」などです。

しかし、現在のすべてのモデルには問題があります。それらは常に複雑性を追加します。もし研究者の方々が聞いているなら：お願いです、モデルにコードを削除することを教えてください。 あなたが開発を完全に自動運転に任せようとすると、これは深刻な問題になります。人のレベルでもコードベースのレベルでも。

機能リクエストも同様です。どの機能が価値があり、どれが無視されるべきか、どれを結合して再定義すべきかをモデルに教えるにはどうすればよいでしょうか？また、正しい抽象化を構築する方法をモデルに教えるにはどうすればよいでしょうか？

これらの能力は継続的に向上しています。しかし、私はまだ、ループを設定してモデルが自動的に「アプリを改善」し、Twitter、Slack、メールを継続的に監視し、自律的にイテレーションを完了する段階に達しているとは思いません。ただし、私たちは確かにそれを現実のものにしようと試みています。

Lenny：私たちはそこに到達すると思いますか？つまり、目標を設定して「勝つ」ということですか？

Andrew Ambrosino：「/goal 私に10億ドルを稼がせてください。」わかりません。絶対にないとも、絶対にあるとも言えません。

Lenny：プロダクトおよびエンジニアリング責任者として、あなた自身はどのようにAIを使って働いていますか？

Andrew Ambrosino：私は今、おそらく世界で最高の仕事を持っていると思います。

Codexに取り組み始めた当初、私個人の目標は、Codexのコードを書くのに十分なほど優れたものにすることでした。それは非常に密接なドッグフーディングの製品ループでした。私は何かができず、それを修正し、そしてできるようになり、さらに多くのことができるようになりました。

その後、私の役割は変わりました。より多くのプロダクト発見、チームが何をしているかの把握、方向性のずれの修正が必要になりました。するとCodexは、これらを行うためのツールになりました。「これらのデータを整理したスプレッドシートを作って」「この方向で過去にどんな探求が行われたか、社内の深い調査をして」など。

5月の一連のリリース（アプリ内ブラウザ、computer use、artifact creation）は、初めてvibe coordination（雰囲気調整）でリリースを管理したものでした。私はNotionドキュメントですべてのToDoを記録し、Codexに自動的にPRやSlackチャンネルから進捗を収集させ、ステータストラッカーを更新させました。その時は、これがプロダクトリリース管理の最先端だと思っていました。

今、私は毎朝、Codexが生成してくれる日報をチェックします。それは私が参加している3000のSlackチャンネルから、私の注意を必要とする事項をフィルタリングします。「5つの質問をくれ、答えるから」と返信できます。そして、それは自己調整します。「次回実行するときは、このワークフローに注意を向けすぎないで」とか、「このことが起きたけど日報に載っていなかった、今後は確実にキャッチできるようにして」と言うと、通知方法を更新し、注目するポイントを調整します。

Lenny：それはどのように設定されているのですか？ワークフローは？

Andrew Ambrosino：今はまだ発見段階です。単に定時タスクを作るだけです：「私のSlackチャンネルを一通り見て、これらは私が関心のあることです。これらのカテゴリに整理してください。ここにいくつかのコンテキストがあります。」最初の数回はガイダンスが必要かもしれません。幸い、指示を編集する方法を探す必要はありません。直接「次回、これを変更して」と話すと、自動的に更新されます。

しかし、これこそがチャットボット形態の核心的な問題だと思います。私は設定方法を知っています。なぜなら、私にとってこれはプロダクト発見だからです。しかし、あなたがOpenAIで働いておらず、これを開発していないなら、それを理解しようとは思わないでしょう。私たちは、これが普通の人々にも使えるような形をどうやって作るかを考える必要があります。

Lenny：私自身もCodexを使ってスパムメールをフィルタリングする自動化を作りました。その過程で、Google Cloud Consoleに行って大量のAPIトリガーを設定する必要がありましたが、そのインターフェースは非常に煩わしかったです。そこで、Codexに代わりにやってもらいました。Codexは直接私のコンピューターを引き継ぎ、computer use機能で操作しました。

Andrew Ambrosino：それはまさに「コネクタがあろうがなかろうが、関係ないよ。俺はクリックを始めるぜ。」という状態です。

コネクタ、アプリ内ブラウザ、Chrome拡張機能、computer useの間の境界線をどのように区分するかは、非常に面白い問題です。多くの場合、これらの境界は感覚で探り当てられています。

これらの個人のワークフローは特に面白いと思います。誰もがあらゆる種類のものを試しており、それぞれが全く異なるシステムを構築します。しかし、徐々に共通のパターンが浮かび上がってきます。そして私たちは気づきます：「これはプロダクトのファーストクラスの体験になるべきだ」と。

例えば、memory（メモリ）。多くの人がObsidianの知識ベースやNotionスペースを設定して、自分の心の宮殿を構築しています。あなたがこれを自分で行う必要はないはずです。十分に汎用的なメモリ機能が代わりに行うべきです。私たちは常にフィルタリングしています。個人に有効だが個人レベルに留めるべきものと、プロダクトに入れて基本コンポーネントにすべきものとを。

Lenny：外の人から見ると、あなたは勝ち続けているように見えます。しかし、成功しなかったこともあるのでは？

Andrew Ambrosino：あなたがそう言うと、なんだか面白いです。実は、今初めて自分が失敗していないと感じています。

私は以前、長年スタートアップを経営していましたが、最終的には会社を解体して売却しました。高度に規制された業界で働いていて、そのプロセス全体が継続的な失敗のようなものでした。その後、別のスタートアップで、別の閉鎖的な規制産業向けのAIツールに取り組みましたが、それも何度も失敗しました。私は実際に多くの失敗を経験しています。時にはタイミングの問題で、スキル、情熱、市場の窓がたまたま合致しただけなのです。

たとえ今のCodexとChatGPTを組み合わせたプロジェクトでも、数え切れないほどの小さな失敗があります。私たちは「こんな形になるべきだ」と言い、Slackに投稿すると、下には2000件のメッセージが来て、私たちがどれほど愚かかを指摘します。これが私がOpenAIを好きな理由です。人々は率直に意見を述べ、内部プロダクトの失敗には容赦がありません。だからこそ、外部プロダクトはうまくいっているのです。私は今の地位に到達する前に、約10年から15年失敗し続けました。だから、毎日まだ少し驚いています。物事が順調に進んでいることに。

Lenny：読者に最後のアドバイスはありますか？

Andrew Ambrosino：今の仕事のフローに「一生縛られる」ことはありません。本当に固執すべきなのは、あなただけが独自に提供できる成果です。そして、常にあなたのプロセスを変え続けてください。もしあなたが最も誇りに思うスキルが「私はFigmaのオートレイアウトを最も理解している」なら、あなたは何をしているのですか？AIもあなたよりもうまくなるでしょう。やる価値のあることを見つけて、その何とかしてやり遂げてください。