《开发者吐槽“AI 让大脑变钝”:效率叙事与现实返工之间的落差》
一线开发者体验指出重度依赖 AI 编码工具可能带来更多错误与返工,并削弱基本功与新人培养。
🧠 agentic reading|1️⃣ 精准输入
导语
科技公司高管喜欢用“代码中有多少比例由 AI 生成”来证明生产力革命已经到来,但一线开发者的体验更复杂:AI 生成的代码往往需要反复检查、修补和返工;更深的焦虑是,长期依赖 AI 可能削弱开发者对代码库、调试和基本工程判断的掌控。效率叙事背后,正在堆积看不见的技术债和技能退化风险。
1. 高管叙事:AI 代码比例越高,越像生产力胜利
大型科技公司正在把 AI 编码塑造成经济转型的证据。Meta、Google、Microsoft 等公司高层不断强调,AI 正生成越来越多公司内部代码,因此软件生产会更快、更便宜。这个叙事的潜台词是:如果顶级科技公司已经用 AI 提升效率、降低人力需求,那么其他行业也迟早会被同样改造。
他们最爱举的指标,是 AI 生成代码占比。Google 曾表示公司 3/4 新代码由 AI 生成;Microsoft CEO Satya Nadella 说公司最多 30% 代码由 AI 生成,CTO Kevin Scott 预计到 2030 年这一比例会达到 95%;Mark Zuckerberg 也说 AI 将在 12–18 个月内写出大部分用于改进 AI 的代码;Anthropic 则称团队多数代码有 90% 由 AI 生成。
这些数字让 AI 看起来像软件工程的自动化胜利,但它们没有回答一个更关键的问题:这些代码是否真的高质量、安全、可维护。代码生成比例越高,不等于系统质量越高;如果审查能力没有同步增长,高比例反而意味着更大面积的未知风险。
2. 一线体验:AI 不只是犯错,而是把检查成本转嫁给人
被要求使用 AI 的开发者讲的是另一个故事。在 Reddit、Hacker News 和其他开发者讨论区,越来越多人对大语言模型生成代码的承诺感到幻灭。问题不只是 AI 输出有缺陷,而是为了完成工作,开发者常常需要逐行检查、修复和解释它的错误,这会让任务变得更费时、更困难、更沮丧。
一名中型科技公司的 UX 设计师说,公司要求他们用 AI agent 在代码库中做大范围修改,但“没有办法评估那么多代码是否写得好、是否安全——尤其当公司里几百个程序员都在做同样的事”。这不是单个 pull request 的质量问题,而是大规模组织实践:每个人都在把不完全理解的生成代码推进系统。
AI 编码的真实成本常常不在生成那一刻,而在后续验证、修补和承担责任的过程中。模型能快速产出文本,不能自动保证架构一致性、边界条件、安全属性和长期可维护性。
3. 技术债:当参与本身比质量更重要
文章里最尖锐的一句话是:“The actual quality of output doesn't matter as much as our willingness to participate.” 真正被管理层奖励的,可能不是代码质量,而是团队愿意加入 AI 化流程。
这会制造一种“AI 参与率”崇拜:只要工具使用率、生成比例、token 消耗和自动化故事足够漂亮,就能被包装成组织转型。那名 UX 设计师担心,团队正在建造一个“rat's nest of tech debt”——一团以后难以解开的技术债。更讽刺的是,如果模型成本变得高昂或工具不可用,公司可能会留下大量没人真正理解、也没人愿意维护的 AI 生成代码。
高管们还把 AI 实施和裁员联系起来。AI 生产力提升并没有明显带来更好的产品、更短工时或更好的用户体验,更多时候被用来解释为什么可以减少人手。Meta、Microsoft、Snap 等公司都出现过将裁员与 AI 使用联系起来的表述或背景。
4. 技能退化:大脑变钝不是比喻,而是工作方式改变
开发者最担心的不是“AI 会不会抢工作”这个抽象问题,而是自己正在失去做工作的能力。长期让 AI 生成、补全和解释代码,可能让人忘记 API、丧失对代码库的心智模型、遇到生产故障时更难从底层推理。
这种退化尤其会影响新人培养。初级开发者过去通过读代码、写 bug、调试、重构来建立工程直觉;如果他们一开始就把问题转化为 prompt,再接受模型输出,就可能更擅长驱动工具,却更不擅长理解系统。AI 编码最危险的副作用,可能不是替代开发者,而是让开发者失去判断 AI 何时错了的能力。
这不是反技术情绪。AI 在生成样板代码、探索 API、解释陌生模块、加速小范围修改上确实有价值。但一旦它被用来做“跨代码库的大范围变更”,而人类又没有足够时间审查,效率就会变成风险放大器。
5. 真正的分水岭:能否保持人类工程判断
AI 编码工具的价值不在于让人少思考,而在于把人的注意力从机械输入移到更高层判断:需求是否清楚、架构是否合适、边界条件是否覆盖、测试是否能捕捉错误、变更是否能被团队长期维护。
如果组织只追求“用了多少 AI”“生成了多少代码”,而不投入评审、测试、可观测性和新人训练,AI 会把软件工程中最稀缺的能力——判断力——进一步耗空。相反,如果 AI 被限制在可验证、小范围、强测试覆盖的场景中,它才可能成为真正的杠杆。
结论
AI 编码的关键矛盾不是“会不会写代码”,而是“谁来理解、验证并维护这些代码”。高管看到的是生成比例和降本空间;开发者感受到的是返工、审查压力、技能退化和技术债。真正成熟的 AI 编码文化,不应把参与 AI 流程当成目标,而应把人类工程判断保留下来:模型负责加速,人负责理解;模型可以建议,人必须能否定。
思想框架
文章先对比高管的 AI 生产力叙事和开发者的一线体验,指出“AI 代码比例”无法代表真实质量。随后通过匿名开发者的担忧,把问题推进到技术债、审查成本和组织激励。最后落到技能退化:AI 的最大风险不是生成错误,而是让人逐渐失去识别错误和维护系统的能力。
Damn Interesting Curated Links · 8 分钟
✍️ think & write|2️⃣ 费曼输出
我的笔记
✍️ 写下你的想法,自由记录即可。如果没有灵感,试着回答上方的费曼输出问题。
登录后可记笔记
登录后可保存笔记、高亮、划线和批注。