而这是一次阶跃式的变化。它其实是逐渐发生的，但我认为，外部市场真正感知到这个变化的时间点，是GPT5.2 Codex发布的时候。那一刻，模型突然在长时间运行、端到端处理任务、管理上下文以及遵循指令方面都变得好得多。于是我们看到了这个拐点，而这也正是我们构建这个app的部分原因。
所以，整体来看，在GPT5.2 Codex之前，我们用来写代码的AI功能更多像是自动补全，或者你是在和模型做结对编程。在我看来，那时你仍然需要坐在电脑前、手放在键盘上，模型也许会出去做一点小活，但你仍然需要在场、主导整个过程。它只是帮你处理一些小事情。
而到了2023年12月GPT5.2 Codex的时候，我们基本上切换到了另一种模式："我会把这个任务完全委托出去。"不是马上让它写，而是：先和它一起制定一个plan，确认我们认可它将要执行的spec（规格说明），然后我就让它自己去"慢慢煮"。这是一种完全不同的工作方式。
而且这件事真的就在我们对话的当下还在变化。所以，我们上周发布这个Codex app的部分原因，就是我们想构建一种产品形态或用户体验，让"委托"这件事比"结对"更加自然、更加符合人体工学。也就是：你可以同时把任务委托给多个agents。
所以即便是在OpenAI内部，这件事也正在发生巨大的变化。我没法给你一个精确的百分比，但我会说：绝大多数代码都是由AI写的。而且现在，大多数人甚至都不会再打开IDEs（集成开发环境）。如果他们真的打开IDE，可能只是因为你想"掌控接口"，对吧？比如你会帮忙把两个模块之间的接口梳理清楚，然后让AI把剩下的部分补全。或者你想和AI一起协作制定一个计划，然后再让AI去填充实现。但代码本身，已经不再是由人类来写了。
Harry Stebbings：那在24个月后，IDE还会是技术栈的一部分吗？
Alexander Embiricos：好，那从形式定义上来说--集成开发环境，这个词本身就非常模糊，几乎任何东西都可以被称作 IDE，对吧？所以我觉得这个定义本身并没有太大意义。
如果你这么定义，那你甚至可以说Codex app也是一个IDE。但我个人并不这么看。在我看来，IDE是一个非常强大的编辑器。而我们在Codex app里刻意没有加入文本编辑功能，因为我们希望非常清楚地传达：你应该如何使用这个工具。它有大量用于管理多个agents、进行委托、审查变更的能力。它还有非常显眼的技能--这是一个开放标准，非常适合用来做非编程工作，比如调试任务、监控部署之类的事情。但它不提供文本编辑。
Harry Stebbings：如果我们假设，大部分代码都是由Codex生成的，那你们是如何做代码审查的？AI会负责内部的代码审查吗？
Alexander Embiricos：这里有几个层面。首先，你要做什么的spec（规格说明）或plan（计划），变得前所未有地重要。也就是说，要从架构层面思考：这段代码应该如何运作？
我们最近上线了一个非常显眼的plan mode，它和其他工具有点不一样：你会让agent先出去，提出它打算如何完成这件事。这是一个相当长的计划，然后它会问你：你是否同意它的执行方式？或者你是否想提供一些输入？
这非常类似于：如果你新招了一个工程师，他刚加入你的代码库，在真正开始干活之前，需要先向团队提交一份RFC（请求评审文档）。所以，尽管这并不算是传统意义上的code review，但我认为，对"计划"的审查正变得越来越重要，因为我们正在进入一个以"委托"为核心的agent协作阶段。这是一个被严重低估的点。
