Codex负责人摊牌真正的护城河是删代码这是为何“如果有任何研究团队在听拜托让模型更擅长删代码吧。”——OpenAI Codex 团队负责支撑 ChatGPT 等产品的底层编程能力应用负责人 Andrew AmbrosinoLenny’s Podcast笑着说出这句话的人管的正是让写代码变得几乎不要钱的那个部门。听完这期播客再去看自己手里的仓库你会发现这事一点也不好笑——AI 把写的成本打到趋近于零的同时把删的成本撬到了天花板。本文顺着 Andrew 这条线索聊三件事为什么删代码比写代码难 100 倍、AI 正在如何让代码库系统性发胖、以及程序员下一阶段的护城河到底在哪。一、Andrew 那句话背后的真问题先补齐语境。6 月底OpenAI Codex 团队的应用负责人 Andrew Ambrosino 上了 Lenny Rachitsky 的播客。他透露了一个惊人现状OpenAI 内部不仅仅是工程师约 90% 的员工都在高频使用内部 AI 工具类似 ChatGPT Enterprise来处理文档、数据乃至视频剪辑。在这种全民 AI的背景下Andrew 指出了软件开发的一个核心痛点“实现其实已经不是最昂贵的部分了。我敢说现在是品味Taste和策展Curation。”“模型现在的倾向是增加复杂度……如果研究团队在听请让模型更擅长删除代码。”这里的删除代码指的不是修复 Bug 时的删减而是为了降低熵增而进行的主动重构。Andrew 甚至直言人人都是 Builder构建者是他听过最糟糕的口号——当门槛消失缺乏专业深度的堆叠只会制造灾难。https://news.qq.com/rain/a/20260701A03YH800二、为什么删代码比写代码难 100 倍1. LLM 的基因就是加不是减Transformer 的本质是下一个 Token 预测。在训练语料中“新增功能”、“打补丁的样本远多于重构删除”。模型拿到的奖励函数是把这行续上而不是这段逻辑是否有存在的必要。因此当你让 AI 修复一个 Bug它大概率会引入三层新抽象你让它处理边界情况它会把原本清晰的逻辑绕得更远。模型的目标函数与软件工程中最小可行性原则天然互斥。2. 语义理解的鸿沟删一行代码本质上是在 AST抽象语法树和依赖图层面进行手术这个私有方法是否被反射调用了这个看似无用的配置是不是某个 A/B Test 的兜底逻辑这两个长得不一样的组件是否共享同一个业务语义Andrew 在播客中提到目前的模型仍缺乏理解代码库深层语义关联的能力。认不出等价就不敢删不敢删就只能堆。3. 破窗效应 × AI 技术债务复利人类心理学上有个破窗效应维护旧逻辑怕出错不如新增一个helper_v2()。AI 则加剧了这一过程为了让你满意AI 倾向于多写防御性代码、多引依赖、多留分支。据 GitClear 对 2.11 亿行代码的分析报告显示2024 年复制粘贴代码提交占比从 ~1.7% 飙升至 6.66%增长了近 300%。代码复用率在下降冗余度在飙升。三、实战AI 生成的棉花糖代码长什么样让我们看一个典型的 AI 生成代码案例实现一个按 Key 分组并统计的函数。 BeforeAI 生成的版本典型的 Additive 思维importlogging# AI有时会忘记导入有时又会过度防御defgroup_and_count_verbose(items,key_fn): Group items by key_fn and count per group. # AI喜欢做大量的前置校验有时显得啰嗦ifitemsisNone:return{}ifnotcallable(key_fn):raiseValueError(key_fn must be callable)result{}# AI常创建不必要的临时索引结构index_map{}group_list[]fori,iteminenumerate(items):try:keykey_fn(item)exceptExceptionase:# 注意若未导入logging此处会报错AI常犯此类遗漏错误loggerlogging.getLogger(__name__)logger.warning(fkey_fn failed at index{i}:{e})continueifkeynotinresult:result[key]{count:0,items:[]}index_map[key]len(group_list)group_list.append(result[key])result[key][count]1result[key][items].append(item)# AI有时会画蛇添足地手动清理临时变量delindex_mapdelgroup_list# 返回前再 Wrap 一层加入无用的元数据final{}fork,vinresult.items():final[k]{count:v[count],_meta:{generated_by:ai_assistant}# 纯噪声字段}final[k][items]list(v[items])# 不必要的深拷贝returnfinal After人类专家重构后的版本Subtractive 思维fromcollectionsimportdefaultdictdefgroup_and_count(items,key_fn):groupeddefaultdict(list)foriteminitemsor[]:grouped[key_fn(item)].append(item)return{k:{count:len(v),items:v}fork,vingrouped.items()}对比分析维度AI 生成版 (Additive)人工重构版 (Subtractive)逻辑行数~45 行~6 行认知负载高需理解异常处理、临时结构低defaultdict语义明确Bug 面中依赖外部日志配置、冗余状态低纯函数无副作用维护成本修改需遍历多层逻辑修改仅需调整核心逻辑AI 没有语法错误但它制造了大量维护噪音。当项目中充斥着这样的代码阅读和理解成本将彻底压倒编写成本。四、实战指南AI 时代程序员如何修炼删代码的内功Andrew 透露OpenAI 内部正在探索让模型审查整个代码库并建议删除的方向。但在模型进化完成前我们需要依靠以下内功 1. 第一性原理阅读法不要逐行阅读 AI 生成的代码而是先看输入输出和测试用例反推核心意图。然后问自己这个功能能否被现有的标准库函数替代这层抽象是否只是为了迎合 AI 的模式匹配 2. 测试覆盖率 删代码的勇气没有测试就没有重构的胆量。在 AI 时代TDD测试驱动开发不仅没过时反而更重要。利用 AI 生成单元测试的骨架但必须由人类来补全边界 Case 和业务逻辑断言。 3. 静态分析自动化善用工具发现死代码Python:vulture,flake8JavaScript/TypeScript:knip,ts-prune通用:SonarQube定期运行这些工具像打扫房间一样清理代码库。 4. 奥卡姆剃刀 Prompting在给 AI 下达指令时加入减法约束“请使用最简实现禁止引入新类或新模块除非绝对必要。优先考虑代码可读性和维护性而非过度设计。”五、结语Andrew 的那句拜托让模型更擅长删代码不仅仅是对研究员的请求更是对所有程序员的警示当 AI 把写代码变成一种廉价资源时删代码所代表的判断力、审美力和系统思维将成为你最深的护城河。下次当 AI 为你吐出一整屏代码时别急着git commit。试着删掉一半。如果你敢删并且知道为什么删你就赢了。 互动讨论你在 Review AI 代码时见过最离谱的冗余代码是什么样的欢迎在评论区晒出代码片段记得脱敏我们一起瘦身 文章标签#AI编程#OpenAI#代码重构#技术债务#软件工程#Python 参考资料Lenny’s Podcast: https://www.lennyspodcast.com/how-openai-uses-chatgpt-internally-andrew-ambrosino/GitClear Report: https://www.gitclear.com/ai_assistance_code_quality_2024OpenAI Blog: https://openai.com/blog/openai-codex
Codex负责人：真正的护城河是“删代码“，这是为何？
发布时间：2026/7/10 10:10:32
Codex负责人摊牌真正的护城河是删代码这是为何“如果有任何研究团队在听拜托让模型更擅长删代码吧。”——OpenAI Codex 团队负责支撑 ChatGPT 等产品的底层编程能力应用负责人 Andrew AmbrosinoLenny’s Podcast笑着说出这句话的人管的正是让写代码变得几乎不要钱的那个部门。听完这期播客再去看自己手里的仓库你会发现这事一点也不好笑——AI 把写的成本打到趋近于零的同时把删的成本撬到了天花板。本文顺着 Andrew 这条线索聊三件事为什么删代码比写代码难 100 倍、AI 正在如何让代码库系统性发胖、以及程序员下一阶段的护城河到底在哪。一、Andrew 那句话背后的真问题先补齐语境。6 月底OpenAI Codex 团队的应用负责人 Andrew Ambrosino 上了 Lenny Rachitsky 的播客。他透露了一个惊人现状OpenAI 内部不仅仅是工程师约 90% 的员工都在高频使用内部 AI 工具类似 ChatGPT Enterprise来处理文档、数据乃至视频剪辑。在这种全民 AI的背景下Andrew 指出了软件开发的一个核心痛点“实现其实已经不是最昂贵的部分了。我敢说现在是品味Taste和策展Curation。”“模型现在的倾向是增加复杂度……如果研究团队在听请让模型更擅长删除代码。”这里的删除代码指的不是修复 Bug 时的删减而是为了降低熵增而进行的主动重构。Andrew 甚至直言人人都是 Builder构建者是他听过最糟糕的口号——当门槛消失缺乏专业深度的堆叠只会制造灾难。https://news.qq.com/rain/a/20260701A03YH800二、为什么删代码比写代码难 100 倍1. LLM 的基因就是加不是减Transformer 的本质是下一个 Token 预测。在训练语料中“新增功能”、“打补丁的样本远多于重构删除”。模型拿到的奖励函数是把这行续上而不是这段逻辑是否有存在的必要。因此当你让 AI 修复一个 Bug它大概率会引入三层新抽象你让它处理边界情况它会把原本清晰的逻辑绕得更远。模型的目标函数与软件工程中最小可行性原则天然互斥。2. 语义理解的鸿沟删一行代码本质上是在 AST抽象语法树和依赖图层面进行手术这个私有方法是否被反射调用了这个看似无用的配置是不是某个 A/B Test 的兜底逻辑这两个长得不一样的组件是否共享同一个业务语义Andrew 在播客中提到目前的模型仍缺乏理解代码库深层语义关联的能力。认不出等价就不敢删不敢删就只能堆。3. 破窗效应 × AI 技术债务复利人类心理学上有个破窗效应维护旧逻辑怕出错不如新增一个helper_v2()。AI 则加剧了这一过程为了让你满意AI 倾向于多写防御性代码、多引依赖、多留分支。据 GitClear 对 2.11 亿行代码的分析报告显示2024 年复制粘贴代码提交占比从 ~1.7% 飙升至 6.66%增长了近 300%。代码复用率在下降冗余度在飙升。三、实战AI 生成的棉花糖代码长什么样让我们看一个典型的 AI 生成代码案例实现一个按 Key 分组并统计的函数。 BeforeAI 生成的版本典型的 Additive 思维importlogging# AI有时会忘记导入有时又会过度防御defgroup_and_count_verbose(items,key_fn): Group items by key_fn and count per group. # AI喜欢做大量的前置校验有时显得啰嗦ifitemsisNone:return{}ifnotcallable(key_fn):raiseValueError(key_fn must be callable)result{}# AI常创建不必要的临时索引结构index_map{}group_list[]fori,iteminenumerate(items):try:keykey_fn(item)exceptExceptionase:# 注意若未导入logging此处会报错AI常犯此类遗漏错误loggerlogging.getLogger(__name__)logger.warning(fkey_fn failed at index{i}:{e})continueifkeynotinresult:result[key]{count:0,items:[]}index_map[key]len(group_list)group_list.append(result[key])result[key][count]1result[key][items].append(item)# AI有时会画蛇添足地手动清理临时变量delindex_mapdelgroup_list# 返回前再 Wrap 一层加入无用的元数据final{}fork,vinresult.items():final[k]{count:v[count],_meta:{generated_by:ai_assistant}# 纯噪声字段}final[k][items]list(v[items])# 不必要的深拷贝returnfinal After人类专家重构后的版本Subtractive 思维fromcollectionsimportdefaultdictdefgroup_and_count(items,key_fn):groupeddefaultdict(list)foriteminitemsor[]:grouped[key_fn(item)].append(item)return{k:{count:len(v),items:v}fork,vingrouped.items()}对比分析维度AI 生成版 (Additive)人工重构版 (Subtractive)逻辑行数~45 行~6 行认知负载高需理解异常处理、临时结构低defaultdict语义明确Bug 面中依赖外部日志配置、冗余状态低纯函数无副作用维护成本修改需遍历多层逻辑修改仅需调整核心逻辑AI 没有语法错误但它制造了大量维护噪音。当项目中充斥着这样的代码阅读和理解成本将彻底压倒编写成本。四、实战指南AI 时代程序员如何修炼删代码的内功Andrew 透露OpenAI 内部正在探索让模型审查整个代码库并建议删除的方向。但在模型进化完成前我们需要依靠以下内功 1. 第一性原理阅读法不要逐行阅读 AI 生成的代码而是先看输入输出和测试用例反推核心意图。然后问自己这个功能能否被现有的标准库函数替代这层抽象是否只是为了迎合 AI 的模式匹配 2. 测试覆盖率 删代码的勇气没有测试就没有重构的胆量。在 AI 时代TDD测试驱动开发不仅没过时反而更重要。利用 AI 生成单元测试的骨架但必须由人类来补全边界 Case 和业务逻辑断言。 3. 静态分析自动化善用工具发现死代码Python:vulture,flake8JavaScript/TypeScript:knip,ts-prune通用:SonarQube定期运行这些工具像打扫房间一样清理代码库。 4. 奥卡姆剃刀 Prompting在给 AI 下达指令时加入减法约束“请使用最简实现禁止引入新类或新模块除非绝对必要。优先考虑代码可读性和维护性而非过度设计。”五、结语Andrew 的那句拜托让模型更擅长删代码不仅仅是对研究员的请求更是对所有程序员的警示当 AI 把写代码变成一种廉价资源时删代码所代表的判断力、审美力和系统思维将成为你最深的护城河。下次当 AI 为你吐出一整屏代码时别急着git commit。试着删掉一半。如果你敢删并且知道为什么删你就赢了。 互动讨论你在 Review AI 代码时见过最离谱的冗余代码是什么样的欢迎在评论区晒出代码片段记得脱敏我们一起瘦身 文章标签#AI编程#OpenAI#代码重构#技术债务#软件工程#Python 参考资料Lenny’s Podcast: https://www.lennyspodcast.com/how-openai-uses-chatgpt-internally-andrew-ambrosino/GitClear Report: https://www.gitclear.com/ai_assistance_code_quality_2024OpenAI Blog: https://openai.com/blog/openai-codex
