OpenAI Codex应用负责人Andrew播客里笑着说出这句话。
但写过项目的人都懂，这一点也不好笑。
现在的AI太能加东西了。让它修一个bug，它可能顺手改出几层别的代码；让它做一个小功能，它能拉出一堆新文件；让它补一个边界条件，它有时会把原本清楚的逻辑绕得更远。
AI写东西确实快。但是代码库也更容易变臃肿。
它把一个问题摆到了开发者面前：
当AI越来越会写代码，谁来负责删代码？
Andrew：OpenAI内部90%的人都在用Codex。不是90%的工程师，是整个公司90%的人。
这意味着Codex已经不仅限于纯工程场景。它开始接手文档、数据、邮件和各种工作流。
AI工具越来越深入工作流，开发者要处理的就越不只是“让它写出来”。
你还要判断任务有没有拆对，能不能上线、能不能维护、该不该删掉。
代码写得更快，麻烦也来得更快
Andrew：写代码这方面已经不是最重要的部分了。最珍贵是判断和筛选
别误会，这不是说写代码不重要。代码还是要能跑、能维护、能上线。过去团队最怕“想法没人实现”，现在这个门槛被AI降低了。
以前要开发一个新功能，通常先写PRD、排期、拉设计、找工程。大家在真正开工前反复讨论，是因为成本高，错一次的代价太昂贵了。
现在很多想法可以先丢给AI跑一下。甚至同一个方向，可能同时冒出几十个原型。
Andrew：公司里可能有90个没怎么协调的小团队，都在试同一个功能的不同做法。
Andrew谈“实现变便宜，贵的是判断和筛选”
虽然效率提升了，但是另一个问题又出现了：东西太多了。
哪个原型该继续？
哪个需求压根没想清楚？
哪段AI生成的代码只是看起来能跑，但是会坑了后期维护的工作人员？
Andrew提到的taste和curation，放到工程语境里，不是什么审美鸡汤，更像是判断力。AI能把第一个版本做出来，但它不知道这个版本值不值得留。
以前程序员的稀缺性，常常体现在“我能不能把东西写出来”。接下来会更像“我能不能判断这个东西该不该存在”。
PRD没死，别被一个能跑的Demo骗了
访谈里还有个挺反常识的观点。
Andrew：现在很多人喜欢说，PRD死了，原型才是新的沟通方式。Andrew没有这么极端。他的意思更接近：实现成本低了以后，做原型确实更容易，但文档仍然有自己的位置。
要澄清一个模糊方向，文档可能更合适。
要让团队感受一个交互，原型更合适。
要验证一个技术风险，那就先做实验。
Andrew谈PRD和原型的关系
Claude Code、Codex、Cursor都能很快拉起一个页面、一个API、一个脚本。很多团队会不自觉地把“有东西跑起来”当成“问题已经想明白”。
开发者都知道，最麻烦的bug通常不是少写了一个if。
是一开始需求就错了。
AI会让文档、原型、代码、实验都变便宜，但它不会替团队决定现在该用哪一种表达方式。这里判断错了，后面生成得越快，返工也越快。
未来最缺的，可能是会修改Demo的人
Boris Cherny最近也发了一条相关的推文。他从Claude Code团队的视角，把未来产品团队分成五类人：Prototyper（原型师）、Builder（构建者）、Sweeper（收尾者）、Grower（增长者）和Maintainer（维护者）。
Boris Cherny关于AI时代产品团队五类角色的X帖截图
最值得开发者注意的是Sweeper（维护者）。
Sweeper不是打杂的人，是把AI做出来的半成品收拾到能用的人。
AI现在特别擅长做Demo，也特别擅长留下烂摊子：重复逻辑、奇怪抽象、没处理的边界条件、风格不统一的UI、没有测试的功能，还有一堆“现在能跑，但没人敢改”的代码。
Andrew：模型现在通常会增加复杂度。他甚至开玩笑说，希望模型能更擅长删除代码。
Andrew谈模型会增加复杂度，开发者要学会收尾
未来团队里可能不缺会用AI快速做Demo的人，缺的是能把Demo变成产品的人。
这个人要能看懂AI写出来的东西，敢删，敢合并，敢重构，也能判断哪些功能根本不该上线。
有些代码不是要优化，是该扔。
有些功能不是没做完，是一开始就不该做。
有些Agent跑出来的结果，看着很努力，实际只是在制造维护债。
AI越会生成，越需要有人负责收拾。对开发者来说，这个能力不会写在简历第一行，但会决定一个项目能不能活到第二个月。
岗位会混在一起，但别把专业能力扔了
Andrew还聊到OpenAI内部的角色变化。Codex团队里，设计师开始懂工程，产品经理会写代码，工程师也参与产品判断。
Andrew谈Codex团队里的角色边界变化
当然，这并不意味着以后人人都是“Builder”。
Andrew：如果公司简单宣布“不要产品经理了，大家都去做Builder”，很可能把产品这门专业里积累下来的方法和教训一起丢掉。
这话对技术团队也适用。
AI会让岗位边界变模糊，但不会让专业能力消失。会写代码的产品经理更有用，懂产品目标的工程师更有用，会用AI做原型的设计师也更有用。但这不等于所有人都可以无差别替代所有人。
开发者不用焦虑成“全能选手”，但也不能只守着编辑器那一亩三分地。
你得知道业务目标是什么，也得看得懂设计约束；你要会给Agent派活，也要能判断它交上来的东西有没有价值；你要能写代码，也要能从代码里抬头看用户。
Codex这种工具已经把角色边界往前推了一截。
Codex以后可能不是IDE，而是工作入口
访谈后半段，Andrew讲了一个OpenAI内部的视频案例。非工程岗位也在用Codex处理工作流。
Andrew：OpenAI内部有位视频同事Brent，要剪Codex发布用的视频。他一开始只是试试Codex能不能编辑视频。结果Codex发现他用的是PremierePro，先通过编辑背后的文件做了一部分操作；遇到做不到的地方，又给自己写了一个PremierePro扩展，用扩展去控制Premiere里的标记。
Andrew讲Codex接入PremierePro完成视频编辑的案例
Andrew：Codex不一定要替代Premiere、Excel、浏览器、Linear、Slack这些专业工具。它更像一个入口，负责理解任务、调用工具、交接结果。
也就是说，Codex以后可能不是开发者一直盯着的IDE，而是很多工作的起点。
你想剪视频，它去接PremierePro；你想处理表格，它去接Excel；你想查资料，它去接浏览器；你想推进一个研发任务，它去接代码库、Issue、PR和CI系统。
这对开发者的影响很大。
过去我们做应用，默认是人来点按钮、填表单、看页面。但接下来，越来越多应用还要被Agent调用。
所以Codex这类工具真正要改=改进的，不只是写代码这一步。
它在把“打开一个工具干活”，变成“先把任务交给一个入口，再让入口去调度工具”。这也是为什么它会从IDE往外走，进入视频、文档、数据、邮件和更多工作流。
程序员不会消失，但工作重心会后移
值得开发者警惕的是：AI把工作的前半段推得太快了。
以前很多问题可以往后拖。需求不清，等产品再补；体验粗糙，等设计再磨；代码脏了，先上线以后再重构；线上出事，再拉测试和运维兜底。
现在Demo一天能做十个，Agent一晚能改几千行，工具还能接PremierePro和Excel。速度上去了，判断、审查、权限、复杂度、维护成本都会更早冒出来。
Boris说的Sweeper，放在这里就不只是一个新岗位名。
它更像开发者接下来必须掌握的一项能力：把AI生成的东西收回来，拆开看，删掉不该要的，留下能维护的。
代码越容易生成，越需要有人负责收尾。
