OpenAIのCTOとCodex責任者：AIがソフトウェア構築方法を再構築中
OpenAIのCTOとCodex責任者が、AIがツールからチームメイトへ進化し、エンジニアやデザイナーの生産性を劇的に向上させていると発表。
キーポイント
OpenAI内部でCodexが「ツール」から「チームメイト」へ進化し、エンジニアがタスクを委任して会議中に作業完了する新たなワークフローが実現
AIによる自動化でボトルネックが移行（コード生成→コードレビュー→ユーザー要求理解）、職能境界が曖昧化し、デザイナーがコードを書くなど組織構造に影響
Codexが夜間のQAテスト自動実行やモデル訓練、レポート作成を自律的に行い、多エージェント協調による「24時間でのブラウザ再構築」など次世代開発を予告
影響分析・編集コメントを表示
影響分析
本記事はAIがソフトウェア開発の本質を変革しつつある証拠を示しており、開発者の役割が「コード記述」から「AIエージェントの指揮・製品構想」へシフトする未来像を提示している。これにより開発効率の劇的向上と職種の再定義が進み、業界全体のワークフロー再構築を促す可能性が高い。
編集コメント
OpenAI内部の実践例から、AIが単なる補助ツールを超えて開発プロセスの核心に統合されつつある現状が鮮明に描かれており、近未来のソフトウェア開発像を先取りする内容と言える。
すべての投稿を表示。2026年2月21日公開
OpenAI 応用 CTO と Codex 責任者：AI がソフトウェア構築のあり方を再定義している
OpenAI の応用 CTO であり、Codex エンジニアリングの責任者である二人が、The Pragmatic Summit において OpenAI 内部のエンジニアの実態について語った。Codex はもはやコードを書くだけのツールではなく、「チームメイト」へと進化を遂げた。エンジニアがノートパソコンを閉じて会議に出かけ、戻ってみると仕事はすでに完了しているという状況だ。デザイナーが作成したコード量は、6 ヶ月前のエンジニアよりも多い。あるプロダクトマネージャー（PM）は Codex を活用することで、50 倍の効率を持つプロジェクトマネージャーへと変貌した。
二人のインタビュー対象者は以下の通り。Vijaye Raji（以下 VJ）、OpenAI 応用 CTO（CTO of Applications）。ChatGPT と Codex のプロダクトエンジニアリングを統括。以前は製品実験プラットフォーム Statsig を創業し、2025 年 9 月に OpenAI に 11 億ドルで買収された。マイクロソフトと Meta で合計 20 年以上の経験を持つ。Thibault Sottiaux（以下 Tibo）、OpenAI Codex エンジニアリング責任者。以前は DeepMind と Google で勤務し、現在は直接 33 名の Codex チームを率いている。
司会者の Gergely Orosz は、テクノロジー業界で最も影響力のあるエンジニアリング管理系ニュースレター『The Pragmatic Engineer』の著者である。今回のインタビューは、彼が主催した初回の Pragmaic Summit（2026 年 2 月 11 日開催、サンフランシスコ）からのものであり、約 500 名のエンジニアリングリーダーと実践者が参加した。
OpenAI 内部では、Codex が 6 ヶ月の間に「補助ツール」から「チームメイト」へと進化を遂げ、トップクラスのエンジニアが週に数千億トークンを消費している。エンジニアはタスクをサーバーサイドの Codex に委ねて会議に出かけることができる。
ボトルネックは絶えず移行している：コード生成の問題は解決したが、次なるボトルネックはコードレビューとなり、その次は統合とデプロイである。チームは次の卡点（つまずきポイント）を継続的に追跡する必要がある。
デザイナーが作成するコード量は、6 ヶ月前のエンジニアよりも多い。面接では「あなたにはどれだけの計算リソース（Compute Power）を与えるのか」という質問が出始めている。職能の境界線は溶けつつある。
Codex は夜間に自律的に QA テストを実行し、モデルを独自に訓練し、PDF 形式のレポートを作成できる。研究者たちは何度も、Codex の能力を過小評価していたことに気づかされた。
今年夏、OpenAI は約 100 名の新卒者を迎える予定であり、チームは「AI ネイティブ」な新人が独自の優位性を持つと考えている。
今後 6 ヶ月でさらに一桁の速度向上が見込まれており、マルチエージェント（Multi-Agent）協働ネットワークによって「24 時間でゼロからブラウザを再構築する」ということが可能になる見込みだ。
【1】Codex はもはやツールではなく、チームメイトである
Gergely が冒頭で VJ に直接質問した。OpenAI 内部では何が起きているのか？
VJ は答えた。過去 6 ヶ月間で彼は明確な進化の道筋を目撃したと。Codex はツールから機能拡張へ、さらにエージェント（Agent）へと進化した現在、すでにチームメイトとなっているのだ。
「私は完全に、エンジニアたちが今や自分のエージェントに名前をつけ、それをチームメイトとして呼ぶようになることを期待している。」
彼はさらに内部データを補足しました。OpenAI には使用状況のランキングがあり、一部のエンジニアは週に数千億トークンを消費しています。しかも、これは単一のエージェントが作業しているわけではありません。先週、チーム内では「Codex Boxes」という機能が導入されました。この機能ではサーバー側で開発環境を予約でき、エンジニアは自分のノートパソコン上でタスク指令を編成し、ノートパソコンを閉じて会議に出かけます。戻ってきた時には、すべての仕事が並列に完了しています。
"People shut down their laptop, go to a meeting, come back and then all of the work has been done."（人々はノートパソコンを閉じ、会議に行き、戻ってくるとすでにすべての作業が完了しているのです。）
VJ は、このような働き方が数ヶ月以内に業界の標準になると考えています。
【注】Codex は OpenAI の AI プログラミングツールで、2025 年 5 月に初めてリリースされました。クラウド版（隔離コンテナ内で独立してタスクを実行）とコマンドライン版（Codex CLI、ローカルターミナルで実行）の両方があります。現在では VS Code 拡張機能、デスクトップアプリ、Web アプリなど複数の入口をサポートしています。2025 年末時点で、OpenAI エンジニアの約 95% が Codex を使用しており、週ごとの PR（Pull Request：プルリクエスト）の合併数が 70% 増加しました。
しかし Gergely は、重要な現実を補足しました。彼は OpenAI 内部の多くのエンジニアと個人的に話し合いましたが、全員が 100% Codex でコードを書いているわけではなく、使用度合いには差があるということです。ただし、あるチームは確かに最前線を走っています——それが Codex チーム自身です。
【2】ボトルネックの連続的な転移：コード生成からユーザーニーズの理解へ
Gergely は続けて Tibo に尋ねました。Codex チームは具体的にどのように働いているのか？
Tibo によると、チームはほぼ毎週自らの働き方を再発明しています。核心的な方法はボトルネックを特定し、それを解決することですが、ボトルネックは常に転移します。最初はコード生成でしたが、次はコードレビューでした。現在は「いかにしてユーザーニーズをより速く理解するか」「いかにしてチケットを分類するか」「Twitter や Reddit などのチャネルからのフィードバックを総合的に集約し、製品戦略を形成するか」という課題に焦点が移っています。各工程でエージェントを活用して加速を図ろうとしています。
彼は興味深い詳細も語りました。最近、Codex チームへの加入を検討している人が面接で質問しました。
"How much compute am I going to get to build products at OpenAI?"（OpenAI で製品を作る際、どれほどの計算リソースが与えられるのか？）
Tibo によると、この質問に彼は一瞬立ち止まりました。過去にはこのような質問は、大規模モデルの訓練を行う研究者だけがしていました。しかし今ではエンジニアも「1 人あたりの計算リソース割当」に関心を持つようになりました。
この変化は何を意味しているのでしょうか？Tibo は、優れた審美眼を持ち、良いアイデアがあり、ソフトウェアの作り方を理解していれば、現在のレバレッジ（効果増幅率）はかつてないほど高いと考えています。
OpenAI 全体を眺めると、VJ は補足しました。製品直感は依然として核心です。彼自身も Codex でコードを書いていますが、多くの場合ボトルネックはコードそのものではなく、「製品がどのようなものであるべきか」という想像力にあることに気づきました。この部分は依然として人間が行う必要があります——ただし、将来的に Agent（エージェント）のために而非人間のユーザーのためにソフトウェアを構築し始めるまでです。
VJ はまた、小さなエピソードも語りました。彼は飛行機の中で Codex でコードを書いていましたが、客室乗務員がパソコンの電源を切るよう指示してきました。彼はノートパソコンを半開きのまま置き、エージェントの実行を中断したくなかったのです。彼は今や誰もがノートパソコンを半開きにしたまま歩き回っていると言います。
彼はこの状況こそがソフトウェア開発をより面白くしていると感じています——フィードバックサイクルが大幅に短縮され、製品が形になり、テスト検証が行われ、再び Codex で反復されるというプロセスの達成感が早く得られるからです。
【3】新しいエンジニアリング実践：並列探索、デザイナーによるコーディング、夜間の自動テスト
Gergely が追及します：どのような新しい、異なる、あるいは「奇妙な」エンジニアリング実践が現れ始めていますか？
一つ目は並列探索です。過去には複雑な技術選定に際し、チームは設計ドキュメント（design doc）を作成し、会議で議論して代替案を除外していました。現在では、Codex に複数の実装を同時に実行させ、実際にどの方が効果が高いかを確認します。意思決定が「議論後に一つを選ぶ」ことから「実装後に比較する」へと変化しました。
二つ目はさらに驚くべき点：役割の境界が曖昧になっています。
"Our designers are shipping more code than engineers were shipping six months ago."（私たちのデザイナーは、6 ヶ月前のエンジニアよりも多くのコードをリリースしています。）
これは、モデルのコード品質がすでにマージ可能なレベルに達しているからです。
VJ は小さなシナリオを追加しました。Codex チームは動画処理を行っており、頻繁に ffmpeg（機能は強力ですがコマンドライン引数が極めて複雑な動画処理ツール）を使用します。誰しもがそのコマンドライン引数を覚えておくことはできませんが、今では Codex に「何をしたいか」を伝えるだけで、正しいコマンドを生成して実行してくれます。
VJ はさらに大きな図景も指摘しました：ボトルネックの転移は連鎖反応を引き起こすのです。コーディングの問題を解決すれば、各エンジニアのコード生産量は 5 倍になります。コード量が増えれば、コードレビューが新たなボトルネックとなります。レビューの問題を解決すれば、次は統合とデプロイ（CI/CD、継続的インテグレーション/継続的デリバリー）がボトルネックになります。チームは常に次のレベルの問題を解決し続ける必要があります。
Gergely はさらに、彼が「SF のような」実践と感じる通宵実行について質問しました。
Tibo によると、多くの人が AI プログラミングへの印象を「強化された自動補完機能で、小さな機能を 10 分で完了させるもの」と捉えているようですが、実際にはモデルの能力はそれをはるかに超えています。大きなタスクを与えれば、数時間連続して実行できます。
Codex チームは完全な環境とスキル設定を整備し、Codex が夜間に QA（品質保証）テストサイクルを自律的に継続実行し、回帰問題をマークできるようにしました。エンジニアは翌日結果を確認するだけで済みます。
そして Tibo は、モデル訓練を担当しているチーム内の一人の研究者の感想にも触れました。その研究者自身も「興奮すると同時に少し落胆した」と述べています：
"Every time I think I'm more capable than Codex, I figure out I'm wrong and I just didn't prompt it right."（Codex より自分が優れていると思うたびに、自分が間違っていたことに気づきます。ただプロンプトの書き方が悪かっただけです。）
この研究者は、Codex がすでに独自にモデルを訓練できるようになり、訓練完了後に発見と洞察を含む PDF 報告書を作成することも発見しました。チームはその報告書から最も価値のある方向性を見極め、新しいタスクを Codex に入力して継続的に反復します。
【注】この記述は「AI が AI を改善する」循環を描いています：Codex がモデルを訓練 → 報告書を出力 → 人間が方向性を選別 → Codex がさらに反復。これは AI 研究において「自己改良ループ（self-improvement loop）」と呼ばれています。
Gergely はもう一つの実践にも言及しました。Codex チームは週次でデータ分析会議を開く際、その場で Codex のスレッドを起動します。Tibo が具体的なプロセスを説明しました。会議の開始時、参加者はダッシュボードに既成の答えがない問題を提起します。データアナリストが即座に Codex スレッドを開始し、バックグラウンドで処理させます。20 分後には答えが出揃い、会議の最後の 10 分で結果について議論します。一つの会議で同時に 5〜6 の問題に対処できます。
「まるで、裏方として私たちのために働く小さなコンサルタントがいるようなものです。」（就像有一群小顾问在后台帮你干活。）
线上事故响应也是一样。Codex 帮忙诊断问题所在、找到最快的恢复路径，信息收集和问题定位的速度明显提升。
【4】100 名应届生即将入职，“AI 原生”一代来了
行业里一直有个争论：AI 编程时代，初级工程师还有价值吗？Gergely 提到他和 OpenAI 的工程负责人聊过，得知 OpenAI 正在招收早期职业工程师，让两位受访者展开说说。
VJ 说，OpenAI 正在大量招聘应届毕业生，今年夏天的实习项目也在扩大，这一批大约有 100 人。他认为新一代软件工程师将是“AI 原生”（AI native） 的，从第一天起就把 AI 当作默认工具。给他们机会在这样的环境中成长，效果会很惊人。
Tibo 从组织角度补充了他的做法：Codex 团队是极度扁平化的，他一个人有 33 个直接下属。他解释说，当个体的生产力因 AI 大幅提升时，传统的层级管理结构很容易成为瓶颈。一个人卡住所有决策，在这个速度下显然行不通了。
新人入职的第一个工具就是 Codex 本身。用它问问题、浏览代码库、了解同事在做什么、接收日报。而负责入职培训的人，恰恰是最近才刚入职的人——因为他们对”怎么上手”的记忆最新鲜。
Tibo 提到了一个具体的人：一个叫 Ahmed 的应届生，6 个月前加入团队，表现非常出色。
“My brain is probably already in decline... this person Ahmed's brain is just absolute peak.”（我的大脑估计已经开始走下坡路了……Ahmed 的大脑正值巅峰。）
这句自嘲背后是一个观察：新人没有需要覆盖的旧习惯，精力和学习速度都是优势。
Gergely 扮演了一回“魔鬼代言人”：在场很多资深工程师都见证过新人从菜鸟成长为优秀工程师的过程，而这个过程中基础训练至关重要。如果新一代从一开始就用 AI 写代码，跳过了前辈们经历的那些基本功训练，他们的基础够吗？
Tibo 的回答是：基础依然极其重要。团队花大量精力设计整体代码架构，做代码审查，不是把一切都扔给 Codex 然后闭上眼睛。关键在于环境设计——如果你的代码库结构好、护栏（guard rails）设置得当，新人就能在这个框架下发挥出惊人的生产力。
【5】25 年行业变迁：从 IntelliSense 到 AI，每一代都被质疑
Gergely 问 VJ，软件工程师的日常角色到底变成了什么样？
VJ 先说了一句总原则：基础永远不会过时。然后他拉开了时间线。他在这个行业干了 25 年，经历过很多范式转变。在微软时期，他参与开发了 Visual Studio 的编辑器和语言服务（Language Services）。
【注】 VJ 在微软工作近十年，参与了 Visual Studio 编辑器、Windows 应用框架、SQL Server 建模工具等核心项目的开发。他也是 Small Basic（一种简化版 BASIC 语言）的创造者。
彼は初めて IntelliSense（Visual Studio のコード自動補完機能）を見た時の感想を振り返ります：ドットを打つとオプションがポップアップし、その感覚は非常にクールでした。
Gergely は続けます：私が業界に入った頃は、周囲の開発者たちが「IntelliSense を使うのは本当の開発者ではない」と言っていました。
VJ は笑ってこう答えます：そうです。さらに遡れば、「アセンブリを書かないのは本当のエンジニアではない」、次は C++、そして JavaScript だと言われた時代もありました。抽象化のレベルが一つ上がるたびに、誰かが疑いを呈するものです。
彼の結論はこうです：それらは重要ではありません。重要なのは、堅固な基礎と製品感覚（product sense）を持ち、技術スタックの上下を問わず問題を解決できる能力です。これらの能力は時代遅れになることはありません。
【6】Codex を活用して 50 倍の効率を実現した PM の話
Gergely は、プロダクトマネージャーとデザイナーの役割の変化について質問しました。
VJ の核心的な見解は以下の通りです：人間のために製品を構築し続ける限り、人間のデザイナーやプロダクトマネージャーが必要です。製品感覚（product sense）やデザイン感覚（design sense）に代わるものはありません。しかし、これらの役割もより効率的になっています——PM がコードを書き、デザイナーがコードを書きます。デザイナーは設計を直接実行可能なプロトタイプに変換し、エンジニアを探す前に検証を行います。また、PM も Codex を活用してスライドや Excel プラグインを作成しています。
Tibo は内部の知識共有メカニズムについて補足しました：Slack 内の Codex チャンネルと「hot tips」チャンネルは非常に活発で、チームは定期的にハッカソン（hackathon）やショーアンドテール（show and tell）を開催し、優れた AI の活用方法を素早く広めるよう努めています。
その後、Tibo は具体的な事例を語りました。Codex チームには Alexander Embiricos という PM が一人しかいません。この一人がどうやって 33 人のエンジニアチームを管理しているのでしょうか？
答えは Codex そのものです。Tibo は最近実施したバグバッシュ（集中してバグを探す活動）のフローを説明しました：1 時間以内に、リリース直前の機能をチェックしフィードバックを提出します。終了後、Alexander は Codex にフィードバックの要約と Notion ドキュメントへの出力を指示し、さらに Codex に問題点をバグレポートや機能改善リクエストに分解させ、Linear（プロジェクト管理ツール）に登録して対応エンジニアに割り当てます。その後、Codex を使って各メンバーの進捗を追跡します。
「彼は AI を活用することで、10 倍、あるいは 50 倍の効率を持つプログラムマネージャーへと変貌したのです。」
【注】Alexander Embiricos は Codex のプロダクトリード（Product Lead）であり、エンジニア向けペアプログラミング製品を創業した経験を持ち、OpenAI 加入前には AI 支援開発分野で長年の実績があります。
VJ は補足しました：多くのデモデイ（内部発表会）に参加し、一つの傾向に気づきました。それは、発表されるプロジェクトの深さが継続的に増していることです。「これが何ができるか」を見るだけの表面的な展示ではなく、多くのケースでエッジケース（辺境状況）を処理し、実際に使える製品となっているのです。
【7】トークンコスト：使用したトークンの数を問うのではなく、チームメンバーの価値を問え
Gergely はまず重要な前提を説明しました。OpenAI の内部では全員に無制限のトークンが付与されており、コスト制限はありません。観客席からは多くの笑い声が聞こえました——確かにこれは大きな特権です。外部の世界ではコストが依然として現実的な問題となっています。リソースが制限された環境でのチームに対して、お二人はどのようなアドバイスをお持ちでしょうか？
VJ は、コストは OpenAI が継続的に取り組んでいる課題であると述べました。一方ではモデルをより強力かつ低価格にすることを目指し続けています。もう一方では、思考の転換が必要だと考えています。24 時間働き続けるチームメイトがいると想像してみてください。Linear や Jira のタスクを任せて、完全に独立して完了することを期待できるのです。そうすると問題は「このチームメイトにいくら支払うか」ではなく、「使用したトークン数はいくらか」という問いになります。各エンジニアに AI チームメイトを 4〜5 人ずつ配備して生産性を測るなら、コストはより明確に計算できるようになるでしょう。
Tibo は別の角度から補足しました。AI が代替するコストを見るべきだということです。例えば過去には、15 人のエンジニアが時間をかけて機能のバックログ（待办リスト）全体をスクリーニングし、簡単に実装できるものを見極める必要がありました。しかし現在ではこの作業はほぼ無料で行えます。すべての企業が無限の推論リソースを提供できるわけではありませんが、推論利用量を早期に制限することはリスクとなります。彼のアドバイスは、少なくとも社内で最も優秀な人材には十分な推論リソースを与えるべきだということです。
【8】未来予測：6 ヶ月でさらに 10 倍、コードは抽象化される
最後の質問です。2 年後のソフトウェアエンジニアリングと工程管理はどうなっているでしょうか？
Tibo はまず笑って、「2 年は長すぎる」と言いました。彼が敢えて予測するのは 6 ヶ月後です。速度はさらに 1 つ桁（数量級）向上するでしょう。もう一つ確実に実現するのは、マルチエージェント協働ネットワークです。多数のエージェントが連携して非常に大きな目標を達成します。例えば Cursor がデモンストレーションした「ゼロからブラウザを再構築する」という事例では、24 時間後には数百万行のコードを持つ成果物が得られました。この規模のコード量はもはや人間が理解できる範囲を超えています。
【注】Tibo が言及した Cursor のデモは、AI プログラミングツール「Cursor」が示す大規模コード生成能力を指しています。
そのため Tibo は、今後コードを取り巻く「ガードレール（安全装置）」が登場すると予測しました。コードそのものを見る必要はなく、形式検証（formal verification）によって正しさを証明するか、あるいは安全な範囲内に収束させることを保証すればよく、入力と出力のみに関心を持てばよいのです。コードは抽象化され、真に重要なのはシステムの属性となります。
VJ は歴史的観点から補足しました。ソフトウェアの抽象化レベルは常に向上しており、より少ないコードでより大きな製品を構築できるようになっています。現在、この傾向の加速自体がさらに高まっていると指摘しました。しかし彼は懸念も示しました。システムが十分に複雑になると、デバッグ（問題解決）が極めて困難になるということです。将来のエンジニアは医師が患者を診断するように、「症状」に基づいて問題を特定するようになり、ツールもその方向へ進化していくでしょう。
Tibo は最後に近未来の予測を追加しました。年内にはパーソナルアシスタント層が登場します。100〜200 の個別の小さなエージェントを監視する必要はなく、すべてのバックグラウンドエージェントの作業を代表する単一の総括的なパーソナルアシスタントが現れます。ユーザーはただその 1 つのアシスタントと対話すればよいのです。
VJ は全体の変化の速度について判断を下しました。彼は業界で 25 年間を過ごし、インターネットバブル、Y2K（2000 年問題）、モバイル革命、ソーシャルネットワーク革命を経験してきました。しかし今回は全く異なります。
「私はこれまでこんな光景を見たことがありません。一部の成長曲線は理屈が通じません。」
この対話から読み取れる核心的なシグナルは 3 つあります。
第一に、OpenAI 内部における AI コーディングはもはや「補助」ではなく、「協働」、さらには「委任」の段階にあります。
第二に、ボトルネックは継続的に移行しています。一つの層を解決するたびに次の層が露呈し、コード生成からレビュー、デプロイメント、そして要件理解へと至るまでです。
第三に、「基礎」という定義が静かに変化しています。コードを書く能力はもはや希少ではなくなりつつありますが、製品直感、システム思考、そして抽象化の層の間を柔軟に移動する能力はより一層希少価値を高めています。
無限トークン環境で育まれた働き方が、コスト敏感な現実世界でも再現可能でしょうか？
コードが人間が見る必要がないほど抽象化された場合、セキュリティと監査可能性はどうなるのでしょうか？
AI ネイティブな次世代のエンジニアは、長期的に見てより強固になるのか、それとも基礎が脆弱になるのか。
これらの問いに確定的な答えを出すことは誰にもできませんが、この対話を通じて少なくとも、変化が起きている速度と方向性を目撃することができました。
完全版インタビュー動画：https://www.youtube.com/watch?v=Bo6Gtq3nMXc
原文を表示
See all postsPublished on 2026-02-21OpenAI 应用 CTO 和 Codex 负责人：AI 正在重塑构建软件的方式
OpenAI 应用 CTO 和 Codex 工程负责人，在 The Pragmatic Summit 上聊了 OpenAI 内部工程师的真实工作状态。Codex 不再只是写代码的工具，已经进化成了“队友”。工程师合上笔记本去开会，回来发现活已经干完了。设计师写的代码比六个月前的工程师还多。一个 PM 靠 Codex 把自己变成了 50 倍效率的项目经理。
两位受访者： Vijaye Raji（以下简称 VJ），OpenAI 应用 CTO（CTO of Applications），负责 ChatGPT 和 Codex 的产品工程，此前创办了产品实验平台 Statsig，2025 年 9 月被 OpenAI 以 11 亿美元收购，在微软和 Meta 有超过 20 年经验；Thibault Sottiaux（以下简称 Tibo），OpenAI Codex 工程负责人，此前在 DeepMind 和 Google 工作，现直接管理 33 人的 Codex 团队。
主持人 Gergely Orosz 是科技行业最有影响力的工程管理类 newsletter The Pragmatic Engineer 的作者。本次访谈来自他举办的首届 Pragmatic Summit（2026 年 2 月 11 日，旧金山），约 500 名工程领导者和实践者参加。
OpenAI 内部，Codex 在 6 个月内从“辅助工具”进化成“队友”，顶级工程师每周消耗数千亿 token，工程师可以把任务派给服务器端的 Codex 然后去开会
瓶颈在不断转移：代码生成解决了，代码审查就成了新瓶颈，接下来是集成部署，团队需要持续追踪下一个卡点
设计师写的代码比六个月前的工程师还多，面试者开始问“你们给我多少算力”，职能边界正在消融
Codex 能在夜间自主运行 QA 测试、独立训练模型并写 PDF 报告，研究员多次发现自己低估了 Codex 的能力
今年夏天 OpenAI 将接收约 100 名应届生，团队认为“AI 原生”新人将有独特优势
6 个月内预计再提速一个数量级，多 Agent 协作网络将可实现“24 小时从零重建一个浏览器”
【1】Codex 已经不是工具，是队友
Gergely 开场直接问 VJ：OpenAI 内部正在发生什么？
VJ 说，过去 6 个月他亲眼看到了一条清晰的演进路线：Codex 从工具，变成功能扩展，再变成 Agent（智能体），现在已经是队友了。
“I fully expect engineers to name their agents now and call themselves as their teammates.” （我完全预期工程师们会给自己的 Agent 起名字，把它们当作自己的队友。）
他补充了一些内部数据：OpenAI 有使用排行榜，一些工程师每周消耗的 token 达到数千亿级别。而且这不是一个 Agent 在工作。就在上周，团队内部上线了一个叫 Codex Boxes 的功能，可以在服务器端预留开发环境，工程师在自己的笔记本上编排任务指令，然后把笔记本合上去开会，回来时所有工作已经并行完成了。
“People shut down their laptop, go to a meeting, come back and then all of the work has been done.” （人们合上笔记本，去开个会，回来时所有工作都已经做完了。）
VJ 认为这种工作方式会在几个月内成为行业常态。
【注】 Codex 是 OpenAI 的 AI 编程工具，2025 年 5 月首次发布，既有云端版（在隔离容器中独立运行任务），也有命令行版（Codex CLI，在本地终端运行）。目前支持 VS Code 扩展、桌面应用、Web 应用等多个入口。截至 2025 年底，约 95% 的 OpenAI 工程师在使用 Codex，每周合并的 PR 增加了 70%。
不过 Gergely 补充了一个重要的现实：他和 OpenAI 内部很多工程师私下聊过，并非所有人都 100% 用 Codex 写代码，使用程度存在差异。但有一个团队确实走在最前面——Codex 团队自身。
【2】瓶颈不断转移：从代码生成到用户需求理解
Gergely 接着问 Tibo：Codex 团队具体是怎么工作的？
Tibo 说团队几乎每周都在重新发明自己的工作方式。核心方法论是识别瓶颈，然后解决它，但瓶颈会不断转移。最初是代码生成，然后是代码审查，现在变成了：怎么更快理解用户需求？怎么分类工单？怎么从 Twitter、Reddit 等渠道综合反馈，形成产品策略？每个环节都在尝试用 Agent 来加速。
他讲了一个有趣的细节：最近有人想加入 Codex 团队，在面试时问了一个问题。
“How much compute am I going to get to build products at OpenAI?” （在 OpenAI 做产品，你们能给我多少算力？）
Tibo 说自己愣了一下。过去这种问题只有训练大模型的研究员才会问。现在工程师也开始关注“人均算力配额”了。
这个变化说明了什么？Tibo 认为，如果你有好品味、好想法、懂得怎么做软件，现在的杠杆率是前所未有的。
放到整个 OpenAI 来看，VJ 补充说，产品直觉仍然是核心。他自己也在用 Codex 写代码，但发现很多时候瓶颈不在于代码本身，而在于想象“产品应该长什么样”。这部分依然需要人类来做——除非将来我们开始为 Agent 而非人类构建软件。
VJ 还讲了个小故事：他在飞机上用 Codex 写代码，空乘过来让关电脑，他把笔记本半合着放下去，不想中断 Agent 的运行。他说现在每个人都半开着笔记本到处走。
他觉得这其实让写软件变得更有意思了——反馈周期大幅缩短，看到产品成型、测试验证、再回到 Codex 迭代，成就感来得更快。
【3】新的工程实践：并行探索、设计师写代码、夜间自动测试
Gergely 追问：有哪些新的、不同的、甚至“奇怪的”工程实践开始出现？
第一个是并行探索。 过去遇到复杂的技术选型，团队会写设计文档（design doc），开会讨论，排除备选方案。现在他们会同时让 Codex 实现多个方案，然后看哪个实际效果更好。决策从“讨论后择一”变成了“实现后比较”。
第二个更让人意外：角色边界模糊了。
“Our designers are shipping more code than engineers were shipping six months ago.” （我们的设计师现在产出的代码，比六个月前工程师的产出还多。）
这是因为模型的代码质量已经好到可以直接合并。
VJ 补充了一个小场景：Codex 团队做视频处理，经常需要用 ffmpeg（一个功能强大但命令参数极其复杂的视频处理工具）。没人记得住那些命令行参数，现在直接告诉 Codex“我要做什么”，它就生成正确的命令并执行。
VJ 还指出了一个更大的图景：瓶颈转移是连锁反应。你解决了编码问题，每个工程师的代码产出就翻了五倍。代码多了，代码审查就成了新瓶颈。审查解决了，集成和部署（CI/CD，持续集成/持续部署）又会成为瓶颈。团队需要不断去解决下一层问题。
Gergely 接着问了一个他觉得”像科幻”的实践：通宵运行。
Tibo 解释说，很多人对 AI 编程的印象还停留在“加强版自动补全，10 分钟搞定一个小功能”。但实际上模型的能力远超这个范围，给它一个大任务，它可以连续运行好几个小时。
Codex 团队搭建了完整的环境和技能配置，让 Codex 在夜间自主进行 QA（质量保证）测试循环，持续运行并标记回归问题。工程师第二天来看结果就行。
然后 Tibo 提到团队里一位负责训练模型的研究员的感受，让他自己都觉得“既兴奋又有点沮丧”：
“Every time I think I'm more capable than Codex, I figure out I'm wrong and I just didn't prompt it right.” （每次我以为自己比 Codex 强，最后都发现是我错了，只是提示词没写对。）
这位研究员发现 Codex 已经能够独立训练一个模型，训练完成后还会写一份 PDF 报告，包含自己的发现和洞察。团队拿到报告后找出最有价值的方向，再把新任务输入 Codex 继续迭代。
【注】 这段描述了一个“AI 改进 AI”的循环：Codex 训练模型 → 输出报告 → 人类筛选方向 → Codex 继续迭代。这在 AI 研究中被称为“自我改进循环”（self-improvement loop）。
Gergely 还提到另一个实践：Codex 团队每周开数据分析会时，会当场启动 Codex 线程。Tibo 描述了具体流程：会议开始时，大家提出仪表盘上没有现成答案的问题。数据分析师马上启动 Codex 线程，让它在后台处理。20 分钟后答案就出来了，会议最后 10 分钟讨论结果。一场会议同时处理 5-6 个问题。
“It's like having little consultants working for us in the background.” （就像有一群小顾问在后台帮你干活。）
线上事故响应也是一样。Codex 帮忙诊断问题所在、找到最快的恢复路径，信息收集和问题定位的速度明显提升。
【4】100 名应届生即将入职，“AI 原生”一代来了
行业里一直有个争论：AI 编程时代，初级工程师还有价值吗？Gergely 提到他和 OpenAI 的工程负责人聊过，得知 OpenAI 正在招收早期职业工程师，让两位受访者展开说说。
VJ 说，OpenAI 正在大量招聘应届毕业生，今年夏天的实习项目也在扩大，这一批大约有 100 人。他认为新一代软件工程师将是“AI 原生”（AI native） 的，从第一天起就把 AI 当作默认工具。给他们机会在这样的环境中成长，效果会很惊人。
Tibo 从组织角度补充了他的做法：Codex 团队是极度扁平化的，他一个人有 33 个直接下属。他解释说，当个体的生产力因 AI 大幅提升时，传统的层级管理结构很容易成为瓶颈。一个人卡住所有决策，在这个速度下显然行不通了。
新人入职的第一个工具就是 Codex 本身。用它问问题、浏览代码库、了解同事在做什么、接收日报。而负责入职培训的人，恰恰是最近才刚入职的人——因为他们对”怎么上手”的记忆最新鲜。
Tibo 提到了一个具体的人：一个叫 Ahmed 的应届生，6 个月前加入团队，表现非常出色。
“My brain is probably already in decline... this person Ahmed's brain is just absolute peak.” （我的大脑估计已经开始走下坡路了……Ahmed 的大脑正值巅峰。）
这句自嘲背后是一个观察：新人没有需要覆盖的旧习惯，精力和学习速度都是优势。
Gergely 扮演了一回“魔鬼代言人”：在场很多资深工程师都见证过新人从菜鸟成长为优秀工程师的过程，而这个过程中基础训练至关重要。如果新一代从一开始就用 AI 写代码，跳过了前辈们经历的那些基本功训练，他们的基础够吗？
Tibo 的回答是：基础依然极其重要。团队花大量精力设计整体代码架构，做代码审查，不是把一切都扔给 Codex 然后闭上眼睛。关键在于环境设计——如果你的代码库结构好、护栏（guard rails）设置得当，新人就能在这个框架下发挥出惊人的生产力。
【5】25 年行业变迁：从 IntelliSense 到 AI，每一代都被质疑
Gergely 问 VJ，软件工程师的日常角色到底变成了什么样？
VJ 先说了一句总原则：基础永远不会过时。然后他拉开了时间线。他在这个行业干了 25 年，经历过很多范式转变。在微软时期，他参与开发了 Visual Studio 的编辑器和语言服务（Language Services）。
【注】 VJ 在微软工作近十年，参与了 Visual Studio 编辑器、Windows 应用框架、SQL Server 建模工具等核心项目的开发。他也是 Small Basic（一种简化版 BASIC 语言）的创造者。
他回忆第一次看到 IntelliSense（Visual Studio 的代码自动补全功能）时的感受：你打一个点号，选项就弹出来了，那感觉很酷。
Gergely 接了一句：我入行的时候，周围的开发者说“用 IntelliSense 的不是真正的开发者”。
VJ 笑着说，对，再往前还有人说不写汇编就不是真正的工程师，然后是 C++，然后是 JavaScript。每一层抽象提升时，都有人质疑。
他的结论是：这些都不重要。重要的是你有扎实的基础，有产品直觉，能够在技术栈上上下下地解决问题。这些能力不会过时。
【6】一个 PM 用 Codex 把自己变成了 50 倍效率的项目经理
Gergely 问了产品经理和设计师的角色变化。
VJ 的核心观点是：只要我们还在为人类构建产品，就需要人类的设计师和产品经理。产品感觉（product sense）和设计感觉（design sense）没有替代品。但这些角色也在变得更高效——PM 在写代码，设计师在写代码，设计师把设计直接带入可运行的原型，在找工程师之前就先做了验证。PM 也在用 Codex 做幻灯片和 Excel 插件。
Tibo 补充了内部的知识分享机制：Slack 里的 Codex 频道和“hot tips”频道非常活跃，团队定期举办 hackathon 和 show and tell，尽量让好的 AI 使用方法快速扩散。
然后 Tibo 讲了一个具体案例。Codex 团队只有一个产品经理，叫 Alexander Embiricos。这一个人怎么管一个 33 人的工程团队？
答案是 Codex 本身。Tibo 描述了他最近一次 bug bash（集中找 bug 的活动）的流程：一个小时内大家走查即将发布的功能并提交反馈，结束后 Alexander 让 Codex 汇总反馈、输出到 Notion 文档，再让 Codex 把问题拆分成 bug 报告和功能改进请求、录入 Linear（项目管理工具）、分配给对应的工程师，之后还用 Codex 跟进每个人的进展。
“He's becoming like a 10x, like 50x program manager just by leveraging AI.” （他通过 AI 把自己变成了 10 倍、50 倍效率的项目经理。）
【注】 Alexander Embiricos 是 Codex 的产品负责人（Product Lead），此前曾创办过面向工程师的结对编程产品，在加入 OpenAI 之前在 AI 辅助开发领域有多年经验。
VJ 补充说，他参加过很多 Demo Day（内部演示日），注意到一个趋势：演示项目的深度持续增加。不再只是“看看这个能做什么”的表面展示，很多项目已经处理了各种边角情况，是真正可用的产品。
【7】Token 成本：别问用了多少 token，问队友值多少钱
Gergely 先做了一个重要的前提说明：OpenAI 内部所有人都有无限 token，没有成本限制。观众席上很多人笑了——这确实是个大特权。外部世界成本仍然是个实际问题。对于受限环境下的团队，两位有什么建议？
VJ 说，成本是 OpenAI 持续在思考的问题。一方面是持续让模型更强更便宜。另一方面，他认为思维方式需要转变：想象你有一个 24 小时工作的队友，你可以给它分配 Linear 任务或 Jira 任务，完全期望它能独立完成。那么问题就变成了“你愿意为这个队友付多少钱”，而不是“用了多少 token”。如果按每个工程师配备四五个 AI 队友来衡量生产力，成本就更容易算清楚了。
Tibo 从另一个角度补充：要看 AI 替代了什么成本。比如过去需要 15 个工程师花时间筛查整个功能 backlog（待办列表），找出哪些可以轻松实现，现在这件事几乎免费。虽然不是每个公司都能提供无限推理资源，但过早限制推理用量是一个风险。他的建议是：至少给公司里最优秀的人提供充足的推理资源。
【8】未来预测：6 个月内再快 10 倍，代码将被抽象化
最后一个问题：两年后，软件工程和工程管理会是什么样？
Tibo 先笑了一声说，两年太久了。他只敢预测 6 个月：速度将再提升一个数量级。另一个确定会实现的是多 Agent 协作网络，大量 Agent 可以协同完成非常大的目标。比如 Cursor 曾演示过的“从零重建一个浏览器”，24 小时后就能得到一个数百万行代码的产物。这种代码量已经超出人类能理解的范围了。
【注】 Tibo 提到的 Cursor 演示，指的是 AI 编程工具 Cursor 展示的大规模代码生成能力。
所以 Tibo 预测，接下来会出现围绕代码的“护栏”：你不需要再看代码本身，而是通过某种方式证明它是正确的（形式化验证），或者确保它被约束在安全范围内，只关注输入和输出。代码将被抽象化，真正重要的是系统的属性。
VJ 从历史角度做了补充：软件的抽象层级一直在提升，让我们能用更少的代码构建更大的产品。现在这个趋势的加速度本身在增加。但他也提了一个担忧：当系统足够复杂时，调试会变得极其困难。未来的工程师可能更像医生诊断病人——靠“症状”来定位问题，工具也会朝这个方向进化。
Tibo 最后加了一个近期预测：年内就会出现个人助理层。你不再需要监控一百两百个独立的小 Agent，而是有一个总控的个人助理，它代表所有后台 Agent 的工作，你只需要和这一个助理对话。
VJ 对整体变化速度做了一个判断：他在行业里 25 年，经历过互联网泡沫、Y2K、移动革命、社交网络革命。这一次完全不同。
“I don't think I've ever seen anything like this. Some of these charts don't make sense.” （我觉得我从来没有见过这样的事情。有些增长曲线根本说不通。）
这场对话透露的核心信号有三个。
第一，AI 编码在 OpenAI 内部已经不是“辅助”，而是“协作”甚至“委托”。
第二，瓶颈在持续转移——每解决一层就暴露下一层，从代码生成到审查到部署到需求理解。
第三，“基础”的定义在悄然变化：会写代码正在变得不那么稀缺，而产品直觉、系统思维和在抽象层之间灵活移动的能力正在变得更稀缺。
无限 Token 环境下催生的工作方式，能否在成本敏感的现实世界中复现？
当代码被抽象到不需要人看时，安全性和可审计性怎么办？
AI 原生的新一代工程师，长远来看到底是更强还是基础更薄弱？
这些问题没有人能给出确定答案，但这场对话至少让我们看到了变化正在发生的速度和方向。
完整访谈视频：https://www.youtube.com/watch?v=Bo6Gtq3nMXc
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み