AI 正在消灭软件工程的中产阶级？
文章摘要
Florian Herrengt 2026 年 8 月 11 日的博客文章。全文以一段对比开场：
2020 年，你是团队里最资深的人，负责代码质量与架构，建立了良好的工程实践，认真审阅经验不如你的人提交的 PR，努力维护一个健康的代码库。某次你休假回来，代码库一团糟——大家互相随手合并 PR，有人为了图方便往数据库里加了一堆表做反范式化，还有人没有任何扎实证据就把 serverless 或 Kafka 塞进了技术栈。没关系，你能修好。
快进到 2026 年。你没休假，只是一个普通的周一早上。你泡好咖啡打开电脑，发现有 7 个 PR 等着 review。你打开第一个：+24506 / -3938 行，附带一段 AI 生成的说明。你的团队从周五到现在做的改动，比过去你休假几周期间还多。
AI 移除了速度上限。作者的核心论点是：AI 让工程文化薄弱的项目失败得快得多。以前人们会坐下来讨论怎么做，现在可以直接让智能体跑几个小时然后开个 PR。最悲剧的地方在于，在外行看来它是有效的——你把分支拉下来测一测，多半能跑。于是他们继续，一遍又一遍，直到项目到了没人知道任何东西是怎么运作的地步。他打了个比方：就像有人刷信用卡买豪车，你看不见债务，只看见那辆好看的车。
接着是那段被 HN 反复引用的对话：用户报了个奇怪的 bug，团队第 4 次尝试修（准确说是第 4 次让 AI 修），连 Fable 也搞不定。你去问做这个功能的人：「这数据是从哪来的？」「嗯……我其实不知道。我问一下 Claude。」两个人并排坐着看满屏文字滚过，谁也不知道其中有几分是真的，但 Claude 看起来非常自信。「要不打开 ultracode 让它再检查一遍？」这要跑一会儿，你们开始聊 X 上最新的瓜。答案出来了：「这个你看得懂吗？」「不太确定。」「这不是你上周才写的吗？」沉默。
项目已经复杂到没有人可能理解它在干什么。修的话工作量大到根本没法向管理层开口；而且就算修了，几个月后还会回到同样的状态。「那就让 Claude 修吧。」「行，我建个循环和目标，让它一直跑到确认都能工作为止。」「好。」「不过我今天 Fable 额度用完了，明天再跑。」你再倒一杯咖啡回到电脑前，还有 13 个 PR 要 review。你看到一处不明白的地方，去问作者「为什么这里要这么做？」对方发来一个链接——是一段 Claude 对话。设计决策就埋在里面某处，夹在 Claude 自信地推荐某个架构、道歉、改主意、同事让它再考虑一遍、以及另外 15 轮改动之间。「我该看哪部分？」「大概全部吧。」
对「反正大型系统本来也没人完全理解」这个常见反驳，作者承认属实，但指出关键差别：你从来没被要求理解每个服务和每个数据库，但至少有某个人理解，并且会讲给你听；现在他们去问 LLM，因为他们自己也不知道。
你再也养不起差的工程师。每个团队里都有让项目成为可能的能干的人，也有让所有人更困难的人。现在任何人一天写出的代码量能超过过去一年。在前面那个故事里所有人都失职了：开 25000 行 PR 的人早就该叫停智能体，理解它在干什么，拆成小块，质疑它引入的每一个抽象；review 的人应该拒绝审这么大的东西而不是屈服；加 Kafka 的人应该能确切说明为什么需要它；做功能的人应该能不靠甩 Claude 对话链接就说清数据来源。
作者强调技术债并非永远是坏事，重点是你知道自己在走捷径。但撤销一个坏决定非常难：让 LLM 加一堆表和列要多久，10 分钟？可一旦开始往里存数据，你就不能直接删了——你得做迁移方案、保证不影响每天付费使用的用户、想好迁移失败怎么办、别留下孤儿外键。而在你修的同时，PR 还在源源不断进来：一个人一下午能生成 2 万行代码，但你仍然得坐在那里理解这些行到底做了什么。等你理清一个坏决定，另外五个已经合并了。
新的 AI 经济。差的工程师一直是负债，这在 OpenAI 和 Anthropic 出现之前几十年就是如此，区别只是过去有速度上限。今天实现（implementation）很便宜，你拿钱是为了做出好决定、构建可扩展且能管住复杂度的软件。作者反问：为什么公司一开始要给伦敦或旧金山的工程师付六位数？如果他们要的只是把规格翻译成可运行代码的人，为什么不早就便宜地在别处解决？为什么那些声称「软件已被解决」的科技公司还在开顶薪抢最好的人？
他的判断是：AI 会把薪资进一步拉开。要具备可雇佣性，你得越过一条门槛，而这条门槛就是当下最好的模型能做到的水平。好工程师变得更有价值，因为 AI 让他们跑得更快，他们不再需要那么多人在旁边纯做实现工作；同时差工程师变得贵得多。他把这与自己此前那篇《vibe coder 的职业道路是死路》联系起来：你必须贡献超出「任何人给智能体一个 prompt 就能得到」的东西；如果你缺乏评估 LLM 建议所需的判断力，再向它要判断也解决不了问题。最终，总得有人知道到底发生了什么，而那个人是团队里最有价值的人。做不到的人会变得便宜很多或干脆被替换，钱则流向越来越少的一批真正可被信任的人。他认为这不限于软件工程，而会发生在大多数知识工作上。
文章后半是对常见反驳的逐条回应，这部分本身就很像一场预演的 HN 辩论：
- 「差工程师一直存在」——区别是速度。这是 30 km/h 撞车和 200 km/h 撞车的区别。AI 之前，差工程师连编译通过都费劲，产出慢、爆炸半径有限，损害被打字速度所限；现在他一顿午饭前就能生成 1 万行能跑的代码。坏决定复合的速度彻底变了，而修复的速度没变。
- 「改进你的流程就行」——我们本来就有测试、CI、代码评审、架构评审，它们也没消失。问题是这些流程是为「产生大量改动不可能」的世界设计的。当有人一天开 10 个带 AI 生成描述的 PR 时，代码评审就不管用了；测试覆盖的是你想到要测的行为，抓不到没人想到的行为。你有多少次 CI 全绿、覆盖率满格却仍然上线了 bug？「写代码的难度本身就是一个限流器。」如果理解改动、守护质量的人现在成了瓶颈，你只有三个选择：少生成、找到真正更好的验证方式、或者接受更低的质量。
- 「你就是反 AI」——他说自己每天重度使用 AI，无意回到全手写。关键点是我们让产生大改动变得极其便宜快速，而理解这些改动仍然缓慢困难，我们没有构建正确心智模型的捷径。也许将来会有，今天没有。
- 「产出更多就是更高产」——一天 10 个 PR 数字很好看，但所谓 10x 工程师可能只是从周围所有人那里偷走生产力。如果我一天生成 10 个 PR，导致三个工程师接下来两天都在 review、弄清我改了什么、纠正错误假设、调试回归、解释为什么一半要重做，我并没有 10 倍高产，我只是把工作转移给了别人——而且消耗的是团队里最难被替代、注意力最稀缺的那批人的时间。PR 数、改动行数、「完成」的功能数都是糟糕的生产力度量。他也承认有人指出根因是组织激励错乱：如果公司奖励关单量而不是质量，那谨慎的工程师看起来像差员工，草率的那个反而升职。
- 「坚持质量会让你被当成 toxic」——他宁愿要一个交付少但工作可信的人，也不要一个快得多但让他担心以后会炸出什么问题的人。要灵活、要在业务权衡合理时妥协，但也要有脊梁；而且线上出事时（一定会出事），他需要做改动的人真的理解到能帮忙修，而不是一脸茫然。
- 「AI 输出就像编译器产生汇编」——编译器是把代码翻译成另一种表示并保持语义，它是确定性的，它不决定你的系统该做什么。LLM 在做决策：选架构、挑抽象、决定东西放哪。你让 Claude 做一个功能，它不是在翻译你的意图，而是在代你做几十个设计决定。如果五年后能给智能体一份完整规格并可靠地对着规格验证产出，那审代码就过时了，他乐意不再做；现在还不到那一步。
- 「我们 99% 代码是 AI 生成的，运行良好」——他自己也是。但你仍然要花功夫理解结果。「AI 能写代码」≠「我不再需要理解它」。
- 「用户不在乎，就是个 CRUD 应用，发布拿钱」——这种视角通常来自相对小或隔离的项目。大系统里客户今天满意还不够，你需要其他工程师能理解这个系统。你有没有被半夜叫起来修一个不是你写的系统的线上事故？没人会为一个简单 CRUD 付大钱，公司付钱给有经验的工程师，是因为那个「简单 CRUD」坐落在一个有多年业务规则、约束和集成的混乱真实系统里，坏决定在那里是有后果的。
- 「初级开发者怎么办」——他最近合作的两位初级开发者非常好，恰恰因为他们努力理解自己在做什么而不是只产出代码：用 AI 探索不懂的东西、提问澄清推理、复核假设，用工具增进理解。而他也见过基本放弃、不再试图理解代码的资深开发者，结果变成了差得多的工程师。「问题不在 AI，问题在于把 AI 当作理解的替代品而不是建立理解的工具。」对「不该教 AI 能做得更好的技能」的说法，他反驳：我们仍然教算术和代数尽管计算机算得好得多，仍然教拼写、语法和写作，甚至在人人口袋里都有能秒查事实的设备时仍然教历史地理——否则你要靠什么发展出理解、质疑和验证所需的心智模型？
- 「用 AI 就是委派，跟经理一样」——经理通常不是决定软件该如何架构或实现的人，他们的工作是优先级、人、协调和资源分配。你还是工程师，只是把技术判断委派给了 LLM，也就是不再做你工作中最重要的那部分。
- 「不招初级了，以后哪来资深」——通过削减入门级岗位，行业在破坏自己的未来，这没错。但行业并不真的欠人机会，就算你认为它应该，公司也不会这么行事。他补充：维护才是软件行业的本质，LLM 无法修改数十万行规模的项目，划分架构所需的技能仍然完全属于人类，去学这个。这也正是有经验的工程师变得更值钱而不是更不值钱的原因。
- 「真的会有人在乎吗」——等到什么都不工作、没人修得好、加新功能要等很久、每次改动都在别处弄坏东西时，他们就会在乎了。这在 AI 之前就已经在发生，只是现在更多本来要花很多年才会烂到不可维护的公司，几个月就能到那儿。
HN 评论精华
993 分、907 条评论。这篇的讨论比原文更分散：赞同「AI 放大了坏工程师的破坏力」的一派人数最多，但反对声音也很有组织，主要围绕三点：（1）文章其实描述的是管理和文化问题，不是 AI 问题；（2）「资深工程师免疫」是自我安慰，技能退化对所有人一视同仁；（3）「必须逐行审查代码」本身可能是过时的建议。另有一大块讨论跑偏到了就业市场、H-1B、初级岗位消失和更宏观的经济议题上。
赞同并补充实战细节的
- alpha_squared 提供了最贴合原文的一手经验：上一份工作里他经常要 review 中级/初级开发者提交的 2 万行以上的 PR，最后只能直接关掉 PR 要求拆分，有时还得升级到对方的管理链去谈。更常见的是，他们一旦花时间琢磨怎么拆，就会发现改动集其实小得多，他回头收到的是一个 400、500 行的 PR。有一次他的一位资深同事额外花力气去弄清改动的真实意图，替那位初级开发者重开了一个 PR——把 14000 行变成了 5 行配置改动。「这完全不可持续，某个地方总会先崩。」
- ryandvm：如果你不幸在一个工程链条高层坐着「LinkedIn thought leader」的地方工作，你的组织很可能正陷在「所有人必须对所有事使用 AI」的狂热梦里。而且确实像原文说的那样灾难：工程经理让 Claude 写整个 initiative，然后把这些含糊的 AI slop 宣言丢给团队，需求岗的人再让 Claude 拉出一堆表面看似合理的 Jira 工单；最后落到某个倒霉工程师手上时，这些工单在技术上相当于《芬尼根的守灵夜》，于是他只好让 Claude 开 ultracode 把这坨读完、起个 PR；接着由另一个用 Claude 的人来评审。「我真希望我是在夸张。」
- Syntaf：最扎心的一句是「差工程师一直是负债」。有了 AI，「差」工程可以在组织里被放大 10 倍。他见过最恶劣的情形是长期在职、但已经对手艺失去兴趣的工程师——有足够的资历能把东西发出去，却没有足够的兴趣把它做好，这个组合很危险。不过他仍然相信 garbage in → garbage out：AI 的好坏取决于你给它的抽象和契约，他不认为 AI 生成的代码本质上就差，只是今天人们还缺少驾驭智能体写出好代码的技能。
- tantalor 一句话点评被高赞：「坏消息：当你把思考委派给别人（Claude）时，你已经变成了管理层。」
- mjr0 描述了机制变化：过去你不得不招一些你明知不太行的人来做「暖身体」，拼组件、修小 bug；你仍然要一个称职的开发者去 review，很烦，但总比自己全做省时间。现在称职的开发者可以直接跑智能体走同样的评审流程，而且成本相对人力薪水几乎免费（哪怕是外包人力）。于是形成双峰分布：底部 X% 的开发者基本变得毫无价值，顶部 Y% 的开发者比以往更值钱。
- scronkfinkle 给了一个精准的说法：这是「Stack Overflow 工程师的自动化」。企业软件里一直有非谈判性的大量代码要写，传统做法是资深的人做完难的思考、蒸馏成 Jira 工单，交给一个边写边把每个磕绊丢进 Google 的工程师。这个交接不再必要，同一个资深的人可以直接启动智能体。他提到有人称之为行业的「nature is healing」时刻：如果你只是为了高薪来、从不打算对工作做批判性思考，这会很痛苦，因为那个手工流程被自动化了，「有价值」的门槛被抬高了。
- GrayHerring：与其说 AI 在消灭中产，不如说 AI 在以前所未有的速度暴露差工程师。以前他们把所有思考外包给别人，现在他们看到巨大的「进展」，从而产生对自己能力的幻觉。
- tvbusy 补充了一个原文没讲的成本：你还要花巨大的力气向管理层解释，为什么 PR 数和改动行数暴涨（在他们眼里等于生产力爆炸），实际上却有一个工程师在摧毁团队的节奏。
- wojciii 讲了一个残酷的实例：暑假前他促成团队里一个人被解雇——他并不想这样，但对方交付的质量达不到「一个会思考、有工程学位的人」应有的水平；加上 AI 之后事情更糟，他至今还在代码库和文档里发现需要审查、测试和修复的问题。接替者正在培训中，他明确要求：可以用 LLM 辅助开发，但你要对自己的贡献负责。
质疑与反驳
- whywhywhywhy 挑了原文标题句的逻辑：「AI 让工程文化薄弱的项目失败得更快」——这难道不是恰恰相反吗？它让那些本来在头几个坎就会放弃的人得以深陷其中，然后抱着「能靠 prompt 脱身」的虚假希望，结果是越来越深的意大利面。
- pelagicAustral 直接质疑那个 20000 行 PR 的前提：不知道什么样的公司会有大型代码库还接受 2 万行的 PR 并指望它可持续。他自己是 AI-first 工作方式，PR 最多触及 12 到 15 个文件，最激进的也就 30 个，仍然是人类可评审的，仍然是可以回滚而不搞坏其他部分的那种改动。「有办法做好这件事的，各位卢德分子。」
- aabdi 反对文章的怀旧：「你从来不被要求理解一切，但至少有人理解并且会讲给你听」——这里戴了玫瑰色眼镜。AI 之前的日子同样糟：根本没人给你讲任何东西！要么人已经走了，要么在忙别的。没人写测试（按我的标准），运维工作大多被跳过，文档就是没有，没人好好配 lint。就是烂。
- oceanplexira 提出最有代表性的反面立场：这里很多论证都是「汽车不过是更快的马」。「必须逐行审查代码」这一派，等到 Claude/Grok 开始直接写机器码的那天会非常难受——它们一定会——那时你看起来就会像 1970 年代那些说不能信任编译器的人。把代码拆成小块评审是遗留软件工程的过时建议，我们大概会转向评审 prompt 或功能性仿真。「五年后的资深工程师，跟 2019 年的资深工程师会长得完全不一样。」
- maerF0x0 认为原文漏掉了一个失职者：那个手里堆着 13 个 PR 要审的人自己也在失职。他还提出许多旧的软件工程做法本身只是局部最优，我们仍在寻找新的最优，而这段旅程可能会经过比旧局部最优更低的地带。
- TiccyRobby：这个前提根本不成立，这是技术文化问题，需要你去强制执行。放任它当然会比以往更野，但这是个相对不难解决的问题。
- jplusequalt 的反驳获得很多共鸣，直指原文的核心假设：这篇博客混淆了生产力与专业能力。LLM 是否给有经验的开发者带来大量生产力提升？是。LLM 是否在削弱他们理解代码的专业能力？也是。文章隐含假设顶部四分之一的工程师对技能衰退免疫——他们不免疫。如果你越来越多地把规划、编写和分析代码外包给 LLM，你就在失去规划、编写和分析代码的能力。「全面拥抱 AI 工具的资深工程师是在给自己吹彩虹屁，以躲避自己也正在被淘汰的现实……看这段话的你——对，就是你——别自我感觉太好，你的技能也在贬值。」
- i_idiot 从劳资角度反问：现在要怪工程师了？他们多半是被经理逼着更快地推 PR，否则就上 PIP。
- zug_zug 把问题重新框定为管理问题：文章说招差工程师危险，这一直是对的，尤其那类「糙一个原型、赢得总监掌声、留给别人维护」的人。但管理层通常选择留下这些人，因为纸面上好看（看他关了多少工单）。真正的问题是管理/业主问题：经理和总监会停止招 yolo 工程师吗？会授权工程师仅凭复杂度和体量就关掉 PR 吗？会把重构和简化作为一等公民来投入吗？如果不会，那就有麻烦，他不羡慕在这种公司里当粘合剂的工程师。
- crnkofe 觉得这类「社会崩塌、岗位毁灭」的哀叹已经听腻了。他承认 LLM 让恶化更快更有效，但另一方面问题也能更快被分诊和重写。他加入过的几乎每家创业公司核心都是学生和过劳技术人员写的灾难代码，他完全能想象这种烂底子会成为未来所有创业公司的底子——那大概需要一支智能体或开发者大军来理解所有正在被写出来的意大利面。「等第一代意大利面西部片代码『成熟』之后，开发者需求暴涨我一点也不会意外。」
- adamtaylor_13 质疑标题概念：「中产阶级」在这里到底指什么并不清楚。所有工程师都落在「好」和「差」的某个连续谱上，划精确刻度没意义，但我们都认识好工程师和差工程师。AI 无非是给两边都发了更锋利的工具。那我们还是照旧设定期望、淘汰达不到期望的人——一直都是这样。「那 AI 到底是哪里的问题？」
- thraway3837 部分同意但补充：好代码从来没有过诚实的质量度量，从终端用户视角看产品要么能用要么不能用。AI 改变的是「写代码」这一段；实际输出的代码行等同于甚至优于最好的程序员，而系统设计、架构、QA、与既有遗留系统的集成才是强项与技能所在。要成为好工程师你必须是系统思考者，有没有 AI 都一样。他认为这会淘汰绝大多数不能或不愿思考系统的工程师——不再是戴上耳机输出代码，而是必须与人、系统、架构、组织打交道，API 或 MCP 帮不了你。他特别为两类人难过：年纪较大而不擅长的工程师，以及应届生——很多人入学时被告知 CS 是好职业，毕业时 AI 编码已在几乎每个工作场所全面使用。
关于初级岗位、就业市场与更宏观的走向（讨论中占比很大的一支）
- declan_roberts：在 AI 和与全世界竞争的 H-1B 之间，找入门或中级软件工程工作从来没有这么难过，这意味着通往资深工程师的通道彻底断了。
- xvilka 把这变成一个真问题：没有人生下来就是好工程师，那通常是无数不眠之夜、日复一日的苦练、失败一百万次、一路犯蠢错误换来的「经验」。那么下一代好工程师的成长路径现在是什么？不会再有做同样事的机会和预算了。
- petcat 认为影响的与其说是初级/中级工程师，不如说是那类「流水线、Jira 工单执行型」的开发工作，并指出这尤其冲击在美国的印度技术工人——这类岗位常由 Infosys 等外包咨询公司填充，而 H-1B 新增的 10 万美元赞助费用让「反正他们大部分时间也是在用美国的 LLM 干活」的雇佣变得难以justify。
- fl4regun 认为这种下行压力本来就会出现：经济规律下，公司要么用 AI 替代所需工程师数量，要么用低薪离岸人力。
- rayiner 把它放到更大的「K 型经济」叙事里：技术已经这样做了几十年，很多相关讨论其实是关于中上层的分化制造出向下流动的受教育年轻人。他举法律行业为例——如果你父亲是区域性律所的合伙人，那条路对你多半已经关闭了；技术推动了整合与规模化，你不再需要美国每个城市都有律师去处理当地法律事务。服务华尔街客户的全国性律所的律师赚得比以往任何时候都多，但往下的落差变得非常陡峭。全国的小企业与 Amazon 竞争也是同样的故事，对小资产阶级冲击巨大。「当然，这在经济上是有效率的。没人会为了让某个本地小业主的孩子过得比中位数好，而放弃 Amazon 当日达。」
- markstos 把范围扩展到 AI 之外：也许更广泛地说，AI 会掏空「中等智力」。最终形成的鸿沟是：把 AI 用于认知探究的人（「帮我理解这个」，从而加速学习）vs. 把理解和分析思考整个让渡给 AI 去完成工作的人。
- tarkin2 提出依赖性视角：它移除的主要是通过实际练习获得的技能，取而代之的是「你必须订阅 OpenAI 才能做你的工作」的要求；而且更是你公司必须订阅——但也不是你公司了，因为你多半会被一个工程师（加一份 AI 订阅）取代，那个人还在同时干另外四五个人的活。这一个工程师会越来越依赖 AI 公司，而 AI 公司在掏空了工程市场里原有的所有技能之后，会直取咽喉。
- zackmorris 走得最远，把话题引向宏观经济与政治：等我们意识到根本没人在买我们 vibe code 出来的软件时就晚了。他类比互联网泡沫和 9/11 后的寒冬（那次持续约 5 年，直到 2007 年 iPhone 和 Facebook 兴起），认为这次的冬天不会结束，或者更准确说，这就是终局。他建议不要再争论我们是否处于危机，而是去看 5–10 年的奇点终局：价格越来越低但没人有钱买任何东西。他说自己已经把注意力从「用 AI 玩求职游戏」转开，转向思考在资本主义无法再提供时间/金钱/资源之后，如何为中产提供这些，并（半开玩笑地）建议大家一起读一遍《共产党宣言》，还引用了 Mark Fisher 的名言「想象世界末日比想象资本主义的终结更容易」。
- deadbabe 提了一个务实但有争议的模式：一个熟练的资深工程师带着 AI 写全部代码，效果远好于一大群人。AI 时代拥有大团队没有意义，只会拖慢速度并把责任摊得太薄。一个人做很多事时，大量东西活在他脑子里，他知道该在自己的 PR 里找什么；而且人们倾向于喜欢自己的 AI slop、讨厌别人的。代价是你必须把巨大的信任押在单个个体身上，但如果押对了人，你能把组织推得比一群平庸工程师或受限的资深工程师团队远得多。
- dmezzetti 从开源维护者角度提供了少见的正面数据：他维护的 txtai 收到的 PR 大幅增加。虽然 Claude 提交信息和 commit 的极度啰嗦、以及它不停为自己是不是 bug 辩护很烦人，但他认为「更多人被赋能」是好事。这确实要求真的去 review：他曾合并过一个会彻底搞坏搜索的 PR——不过人也会犯这种错。从开源角度他认为越多越好，你只需要愿意做评审的工作，而且不能只是让 AI 智能体去评审 AI 智能体提交的东西；如果你在乎质量，人必须在环路里。
- eshack94 分享了自己的纪律：绝不把批判性思考或决策外包给 LLM，绝不在学习上抄近路。用 LLM 做工作相关和开发任务时，他从不用全自动模式，也从不批准自己不理解的东西；遇到不懂的，他会先去开支线任务学明白再回来，这多花时间，但能让他从更知情的位置去批准/否决/改向，而不是盲飞。他还提到原文之外的三个风险：技能萎缩、因自满而停滞（「既然智能体能做，我为什么要成长和学习」）、以及认知懒惰。
- devdude1337 提出一个理论性更强的辩护：编程不是负债，编程本身就是通过书写来创造细节知识的过程。你拿到一个任务，它如何与其他所有不变量交互？对数据流、处理和用户工作流有什么影响？这些问题你事先很难回答，是在编程过程中撞上的，因为形式语言迟早逼你把它们考虑进去。如果把这个知识建构外包出去，出事时你就失去了掌舵能力，也失去了在代码里导航、定位 bug 或不变量破坏的能力。LLM 天生做局部优化，而不变量往往隐式散布在整个代码库里，把它们解释给 LLM 比一开始就自己写代码还费劲。
- 若干精炼短评：mikert89「AI 给杰出的人更多杠杆，它是放大器不是延伸器」；xyst「AI 生成的代码是中层管理新的『代码行数』指标」；danielovichdk「『你再也养不起差工程师』——你从来就养不起」；game_the0ry「写代码从来不是工作，创造价值才是，写代码只是实现手段」；brap「一个人怎么能在不知道自己 PR 大致怎么工作、为什么这么做的情况下就把它发出来？如果你连这个基本问题都答不上来，那我们到底为什么还需要你？」；theflyinghorse 的心智模型是「LLM 就是一个自动化的印度外包开发商店：代码考虑不周、实现潦草、不考虑性能，但它能跑，而且便宜」；parkersweb 提出一个有趣的假说——「Claude 会回归到复杂性」，因为它被训练来模仿既有模式，所以哪怕一丁点过度设计或意面代码都像是心智病毒，会逐渐感染并自我放大所有后续输出。
- jadar 提出了这场讨论里少有人回答的问题：我很欣赏作者点出了问题，也认为他是对的，但我希望有更多乐观或解决思路。作为工程师我该怎么对抗它？或者，我怎么才能成为一个「好」工程师？「感觉有时候人们唯一的解法就是『别用它』。」