AI写代码越快，程序员越危险？Codex负责人摊牌：真正难的是"删代码"

AI能快速生成代码，但真正考验开发者的，是判断何时删减与优化。先说几个核心判断：现在的AI工具在“生成”上确实很强，但随之而来的问题是代码臃肿和后续的维护压力。

“如果有任何研究团队在听，拜托让模型更擅长删代码吧。”

OpenAI Codex应用负责人Andrew在播客里笑着说出了这句话。

但有过项目经验的人都清楚，这根本不是玩笑。

现在的AI太能加东西了。让它修一个bug，它可能顺手改出几层无关的代码；让它做一个小功能，它能拉出一堆新文件；让它补一个边界条件，它有时会把原本清晰的逻辑绕得更复杂。

AI写东西确实快。但与此同时，代码库也更容易变臃肿。

它把一个关键问题摆到了所有开发者面前：

当AI越来越会写代码，谁来负责删代码？

Andrew提到，OpenAI内部90%的人都在用Codex。不是90%的工程师，是整个公司90%的人。

这意味着Codex已经不仅仅局限在纯工程场景了。文档、数据、邮件和各种工作流，它都开始接手。

AI工具越深入工作流，开发者要处理的任务就越不止是“让它写出来”这么简单。

你还需要判断：任务有没有拆对？能不能上线、能不能维护？哪些该删掉？

代码写得更快，麻烦也来得更快

Andrew说，写代码这件事已经不是最重要的部分了。最珍贵的是判断和筛选。

别误会，这绝不是说写代码不重要。代码依然要能跑、能维护、能上线。过去团队最怕的是“想法没人实现”，现在这个门槛被AI大幅降低了。

以前要开发一个新功能，通常先写PRD、排期、拉设计、找工程。大家在真正开工前反复讨论，是因为成本高，试错一次的代价太昂贵了。

现在，很多想法可以先丢给AI跑一下。甚至同一个方向，可能同时冒出几十个原型。

Andrew谈到，公司里可能有90个没怎么协调的小团队，都在试同一个功能的不同做法。

效率确实提升了，但另一个问题也冒出来了：东西太多了。

哪个原型该继续推进？哪个需求压根就没想清楚？哪段AI生成的代码只是看起来能跑，但未来会坑了维护的人？

Andrew提到的“品味”和“筛选”，放到工程语境里，不是什么审美鸡汤，而是实实在在的判断力。AI能把第一个版本做出来，但它不知道这个版本值不值得保留。

以前程序员的稀缺性，常常体现在“我能不能把东西写出来”。接下来，会更像“我能不能判断这个东西该不该存在”。

PRD没死，别被一个能跑的Demo骗了

访谈里还有个挺反常识的观点。现在很多人喜欢说，PRD死了，原型才是新的沟通方式。但Andrew没那么极端。他的观点更接近：实现成本低了以后，做原型确实更容易，但文档仍然有它独特的位置。

要澄清一个模糊的方向，文档可能更合适。

要让团队感受一个交互，原型更合适。

要验证一个技术风险，那就先做实验。

Claude Code、Codex、Cursor都能很快拉起一个页面、一个API、一个脚本。很多团队会不自觉地把“有东西跑起来”当成“问题已经想明白了”。

开发者都知道，最麻烦的bug通常不是少写了一个if。

而是一开始需求就错了。

AI会让文档、原型、代码、实验都变得便宜，但它不会替团队决定现在该用哪一种表达方式。这里判断错了，后面生成得越快，返工也越快。

未来最缺的，可能是会收拾残局的人

Boris Cherny也发过一条相关的推文。他从Claude Code团队的视角，把未来产品团队分成了五类角色：原型师、构建者、收尾者、增长者和维护者。

最值得开发者注意的是“收尾者”。

收尾者不是打杂的人，而是把AI做出来的半成品收拾到真正能用状态的人。

AI现在特别擅长做Demo，也特别擅长留下烂摊子：重复逻辑、奇怪的抽象、没处理的边界条件、风格不统一的UI、没有测试的功能，还有一堆“现在能跑，但没人敢改”的代码。

Andrew谈到，模型现在通常会增加复杂度。他甚至开玩笑说，希望模型能更擅长删除代码。

未来团队里可能不缺会用AI快速做Demo的人，缺的是能把Demo变成产品的人。

这个人要能看懂AI写出来的东西，敢删，敢合并，敢重构，也能判断哪些功能根本不该上线。

有些代码不是要优化，是该直接扔掉。

有些功能不是没做完，是一开始就不该做。

有些Agent跑出来的结果，看着很努力，实际上只是在制造维护债。

AI越会生成，越需要有人负责收拾。对开发者来说，这个能力不会写在简历第一行，但会决定一个项目能不能活到第二个月。

岗位会混在一起，但别把专业能力扔了

Andrew还聊到了OpenAI内部的角色变化。Codex团队里，设计师开始懂工程，产品经理会写代码，工程师也参与产品判断。

当然，这并不意味着以后人人都是“全能构建者”。如果公司简单宣布“不要产品经理了，大家都去做构建者”，很可能把产品这门专业里积累下来的方法和教训一起丢掉。

这话对技术团队同样适用。

AI会让岗位边界变模糊，但不会让专业能力消失。会写代码的产品经理更有用，懂产品目标的工程师更有用，会用AI做原型的设计师也更有用。但这不等于所有人都可以无差别替代所有人。

开发者不用焦虑成“全能选手”，但也不能只守着编辑器那一亩三分地。

你得知道业务目标是什么，也得看得懂设计约束；你要会给Agent派活，也要能判断它交上来的东西有没有价值；你能写代码，也要能从代码里抬头看用户。

Codex这类工具，已经把角色边界往前推了一大截。

Codex以后可能不是IDE，而是工作入口

访谈后半段，Andrew讲了一个OpenAI内部的视频案例。非工程岗位也在用Codex处理工作流。

OpenAI内部有位视频同事Brent，要剪Codex发布用的视频。他一开始只是试试Codex能不能编辑视频。结果Codex发现他用的是Premiere Pro，先通过编辑背后的文件做了一部分操作；遇到做不到的地方，又给自己写了一个Premiere Pro扩展，用扩展去控制Premiere里的标记。

Andrew说，Codex不一定要替代Premiere、Excel、浏览器、Linear、Slack这些专业工具。它更像一个入口，负责理解任务、调用工具、交接结果。

也就是说，Codex以后可能不是开发者一直盯着的IDE，而是很多工作的起点。

你想剪视频，它去接Premiere Pro；你想处理表格，它去接Excel；你想查资料，它去接浏览器；你想推进一个研发任务，它去接代码库、Issue、PR和CI系统。

这对开发者的影响很大。

过去我们做应用，默认是人来点按钮、填表单、看页面。但接下来，越来越多应用还要被Agent调用。

所以Codex这类工具真正要改进的，不只是写代码这一步。它在把“打开一个工具干活”，变成“先把任务交给一个入口，再让入口去调度工具”。这也是为什么它会从IDE往外走，进入视频、文档、数据、邮件和更多工作流。

程序员不会消失，但工作重心会后移

值得开发者警惕的是：AI把工作的前半段推得太快了。

以前很多问题可以往后拖。需求不清，等产品再补；体验粗糙，等设计再磨；代码脏了，先上线以后再重构；线上出事，再拉测试和运维兜底。

现在，Demo一天能做十个，Agent一晚能改几千行，工具还能接Premiere Pro和Excel。速度上去了，判断、审查、权限、复杂度、维护成本都会更早冒出来。

Boris所说的“收尾者”，放在这里就不只是一个新岗位名。它更像开发者接下来必须掌握的一项能力：把AI生成的东西收回来，拆开看，删掉不该要的，留下能维护的。

代码越容易生成，就越需要有人负责收尾。