当写代码的成本崩塌之后，工程管理该怎么做
文章摘要
作者 Karim Jedda 做工程总监三年多，写这篇是因为他反复听到那些「老规矩」：总监不该写代码、好东西需要时间、把团队与业务隔离、提交前先达成共识……在他的组织引入 LLM、代码生产成本下降之后，他开始逐条检查每条规矩底下的假设。结论出乎他意料：大约一半规矩所依赖的假设已经破了，另一半的假设完全没变，而且其中几条现在比以前更重要。
他坚持的唯一「已知事实」是一条非常窄的判断：生产貌似可用的代码，其成本已经崩塌，且不会回去了。 除此之外几乎所有说法要么未经证实，要么是错的。「AI 工具让工程组织快得多」——未经证实；「代码评审、文档、新人培养已经过时」——错的；「同样的路线图可以用一半的人跑」——那是一个赌注，不是事实。如果你只把管理实践重建在那条窄的主张上，你会是对的；如果建在宽泛的主张上，你就是在拿别人的职业生涯赌博，还把它叫做结论。
方法论：审计假设，而不是按新旧排序。 速度追踪依赖「产出是投入努力的可用代理指标」；六个月的新人培养期依赖「语法学得慢」；共识驱动的架构依赖「变更很贵」；人头规划依赖「产出随人数线性扩展」。对每条实践要问的不是它有多老，而是它到底立在什么上面。如果它立在写代码的成本上，就该复审，因为那个成本变了；如果它立在人如何协作、建立信任、分配注意力、验证正确性之上，那就什么也没变，不管这个仪式看起来多过时。作者认为很多人是按感觉排序——看起来现代的留下，看起来老的丢掉——结果是团队丢掉了有用的摩擦，却留下了无用的流程，因为一条实践的年龄和它的有效性是两个不相关的变量。
证据比噪音小得多。 要警惕任何只报告巨大提速、别的什么都不说的人（包括你自己的团队）。他熟悉的收益明显出现在绿地项目、样板代码和不熟悉的领域，而在工程师本就熟悉的系统上做深度工作时会衰减甚至反转。他明确表示很期待 2025 年 Q4 之后的研究数据，因为那批新模型的能力完全盖过了旧报告所基于的模型。但「感觉上的速度」与「测量出的速度」之间的落差本身就是一个管理问题：如果工程师觉得更快了、交付量没变而缺陷更多，你就会配错人、排错期、对业务许下做不到的承诺。AI 采用组织的第一要务是「诚实到足以告诉你到底有没有加速」的度量基础设施。
弱代理指标衡量一个已经变便宜的东西。 Velocity、PR 数、关闭的工单一直都不完美，它们能活下来是因为它们所近似的东西——写代码的努力——真的稀缺，噪音因此在可容忍范围内。现在被代理的东西变便宜了，这些指标不再只是「不完美」，而是主动误导，因为把它们拉高的最便宜手段就是生成体量，而体量恰恰是你的组织现在唯一不缺的东西。AI 专属指标（采纳率、prompt 数）是同一个错误换了个新形式。真正持久的做法更老也更难：衡量业务结果和系统健康，把代码体量当作需要被论证的成本，而不是值得表扬的产出。这话好的工程师在 LLM 之前就说过，那时是对的，现在则变得可执行了，因为没人还能争辩说写更多代码是难的那部分。
「做对」仍然需要时间——文章最核心的一节。 老规矩「好东西需要时间」可以干净地一分为二。管道时间崩塌了：搭一个服务的脚手架、生成测试、在框架之间翻译、写迁移的初稿，现在都很快，任何建立在这些成本上的排期都该被压缩。而正确性时间又要再分成两层：
- 机械验证正在崩塌。 任何「正确」可以表达成机器可检查产物的地方——类型、测试、契约、lint 规则、不变量、金丝雀指标——agent 跑测试循环、读失败、改 diff、再跑，速度是任何评审者比不了的。但要注意这一层为什么快：它快，是因为有人已经把「正确」是什么写了下来，写成了机器能评估的形式。规格做了那份工，检查器只是读它。
- 语义验证是另一回事。 这段代码实现的是业务真正需要的策略吗？这个取舍匹配你的监管暴露吗？这里的「正确」活在人的脑子里和机构的历史里。而 AI 检查 AI 有一个结构性问题：检查器与生成器共享训练数据、偏见和盲区，两层会因为同样的原因在同样的地方失败。自我评审能抓住错别字，抓不住共享的误解。
由此他推出三条结论，也是全文的核心：
- 单位成本下降，总工作量上升。 便宜的检查邀请更多的生成，更多的生成又要求更多的检查。验证的总工作量随体量增长，即便每一次检查都变便宜了。净的日历时间是不确定的，而事故画像会变：低级错误变少，系统性错误变多，因为高体量的貌似可用的产出，现在通过的是高体量的貌似可用的评审。
- 那条边界是一个战略变量。 你的正确性中有多少是机器可检查的，这不是固定的，它是你的规格、契约和不变量的函数。规格强的团队拿到便宜检查的全部好处；规格弱的团队拿到的是「由生成它的同一台机器来评审的生成代码」。投资于「机器可检查的正确性」，现在是一个组织能资助的杠杆率最高的基础设施工作，因为它决定了你能真正用上这波浪潮的多少。
- 验证中最慢的部分从来不是检查，而是问责。 有人签字，有人承担错了的后果：事故复盘、监管机构、客户。签字的时间无法压缩，因为它不是信息处理，它是风险承担，而法律和信任体系把这件事分配给人。所以验证仍然是吞吐量的约束，只是约束的位置变了——从检查速度，变成规格质量，以及某个具体的人是否愿意为结果负责。
初级工程师的培养管线是一个未解问题。 你希望资深工程师具备的判断力，历史上正是通过做那些 AI 现在吸收掉的工作建立起来的：修小 bug、写样板、卡住然后想办法脱困——这些不只是任务，而是产生判断力的练习。如果机器拿走了练习，产出资深工程师的管线就断了，而且它是延迟断裂的，你三到五年都不会注意到。他自己在试一些做法（对生成代码做结构化评审、刻意的无辅助练习、在测试与验证工作中轮岗、在资深密切监督下更早接触真实系统），但他坦言无法告诉你这些有没有用，因为结果变量是五年后一位资深工程师的质量；而任何声称已经解决了这个问题的人——不管是厂商、写文章的还是会议讲者——都是在卖东西。
逐条重审老规矩：「总监不该写代码」——那种为了刷存在感去评审 PR、把自己变成瓶颈的总监确实存在；但心智模型陈旧五年、分不清一个团队是真的更快了还是在高速生成自信而错误的产出（他称之为 slop cannon）的总监同样存在。解法是校准：你不需要交付，你需要与工具和产出保持足够的直接接触，使你既不会被炒作骗到，也不会被轻蔑骗到。「把团队与业务隔离」——底下的假设是注意力有限、上下文切换昂贵，这条完好无损；变的是让团队缺乏上下文的代价：工程师在没有业务上下文的情况下 prompt AI 工具，只会大规模产出流畅、貌似合理、但错误的东西。修订不是把所有信息倾泻给所有人，而是停止默认过滤，开始刻意筛选：哪些上下文、给谁、什么细节层级。「提交前要有共识」——可逆的决定（双向门）应该由尽可能小的团体快速做出，因为错的可逆决定现在撤销起来很便宜；不可逆的决定仍然值得慢流程。真正的技能是分类，而大多数组织一直在错分：把可逆的技术选择当成永久的，把永久的组织选择当成随意的。「我们需要更多人头」——产出的单位经济变了，每个人头请求都该被更严厉地拷问：这份工作里哪部分是判断，哪部分是我们还在雇人做的生产？但别矫枉过正：给一个已经延期的项目加人仍然会让它更晚，协调成本、上手拖累和沟通开销并没有随语法价格一起变。
关于「AI 会不会把管理也做了」，作者认为部分正确。管理有一个信息路由功能——汇总状态、跟踪进度、把更新翻译成仪表盘、预测排期、汇总绩效数据——LLM 极擅长这个，而这件事的价值正在归零：如果你的管理层是靠总结 Jira 挣饭吃的，那确实完了。但还有判断功能：招人、开人、晋升、决定在这个情境下对这些人适用哪条规则、为一个糟糕的决定负责。这和验证是同一个结构：有人对照现实检查产出，有人承担后果。管理产出变得充裕、因而变便宜；而全文的论点是当生成充裕时，验证成为约束。所以这不是经理的终结，而是经理降格为编辑与所有者，与个人贡献者正在经历的是同一个转变。他还补了两条「排序」难以委托的理由：排序需要一个关于你的组织实际如何运转的模型——信任关系、走廊里的知识、过往决定的后果——这些几乎都没被写下来，而模型只能基于记录去排序；更糟的是，模型从训练里学到的是行业的平均判断，LLM 会按中位数组织的方式给你的 playbook 排序，而差异化恰恰活在你拒绝委托的那些决定里。他诚实地承认：排序作为智力练习是可自动化的，他自己就用 AI 压力测试过这篇文章的部分论证，首轮审计还不错；不可自动化的是政治与道德的工作。
结尾的思想实验很有冲击力。 想象一个组织：agent 写代码、跑检查、路由状态、排期、起草计划；人类设定方向、定义什么算正确、然后签字。中间的一切都是机器。现在把时间轴倒过来：假设这个组织先存在，然后有人提议你现在实际运行的那个——我们要雇几百个昂贵的人以打字速度手工产出文本；把他们排成层，每一层的工作是为上一层总结下一层；把他们的日历同步到会议室里，好让他们互相讲述已经发生过的事；并以他们发出多少东西来衡量他们的价值。没有人会资助这份提案。你运行的组织从来不是被设计出来的，它是累积出来的：每一个角色、仪式和层级的存在，都是因为某样东西曾经很贵——打字、路由、检查、记忆。价格变了，组织架构图没变。在 agent 化的极限下，架构图不再记录谁在生产，而开始记录谁在签字；人头不再衡量产能，而开始衡量你能负担多少问责。文章最后一句：能走到那一步的组织会显得小、安静、而且基本是空的——一份简短的人名清单，挂着一份长长的决定清单，除此之外没有什么可管的了。
（文中注明「Gemini 4 协助了编辑」，这句话在评论区引发了不小的风波，见下。）
HN 评论精华
最先炸的是那句致谢。 jboss10 问：「这哥们已经有 Gemini 4 的权限了？我猜是 Gemma 4 乐于被误认成 Gemini，而且没纠正这个错误。」whinvik 和 0gs 也各发了一条同样的困惑。作者本人（用户名 ilovefood）出面承认：「是的，是 Gemma，我马上改。」trollbridge 更进一步，说 Pangram 检测这篇是 100% AI 生成；CharlesW 反驳了这个证据本身——Pangram 的营销让他想起《王牌播报员》里那句「他们做过研究，60% 的时候，它每次都管用」，并援引一篇论文指出 Pangram 的「100% AI 生成」判定只有 65% 的时候是对的。antonvs 的评论拿到高赞：「更糟的问题是写作成本崩塌之后的博客文章。不是所有东西都得写成中层管理者心目中的 TED 演讲。」但也有相当多人为内容辩护：aplummer 说他从头读完，没闻到 AI 味，而且有不少好洞见；JSR_FDED 说文章确实起步很慢，但一旦进入状态就很有思想、论证扎实。
主线辩论：「写代码从来就不是瓶颈」到底还成不成立。 dbingham 的长评是全帖最热的一支：他认为文章的前提（LLM 写代码、人类评审验证）本身可能是错的——每次他让 LLM 写代码，哪怕是 Opus 4.8，最后都要被完全重写；LLM 能写出貌似能跑的代码，但活不过长期。他的核心论点是：「写从来不是瓶颈，理解才是。而理解仍然是瓶颈。但理解真正是在写的循环里获得的——纯阅读或代码评审带来的理解，和写的时候获得的理解相比微不足道。」
这条底下的分歧几乎覆盖了整个光谱。lordnacho 说这曾经也是他两年前的立场，现在他放弃了：「结果证明写确实是瓶颈。你可以完全清楚自己想要什么，但把它写出来又长又烦，烦到你会找借口不去做。」dwayneII 说他在一个成熟的 Go 代码库里工作，90% 的情况下 LLM 能把 API/功能一次做对并配好端到端测试，他一年多没手写过代码了，而且质量更好——因为他有时间写那些回归测试。YZF 说在他的领域，Opus 4.5 之后 LLM 在定义良好的小块工作上写得和大多数工程师一样好，会重构、会写测试、排障也比多数工程师强；「他们是否比最顶尖 0.1% 的工程师手写的代码好？一般不是。但 99.9% 的真实代码也不是」。clbrmbr 提供了一个具体的流程方案：全需求捕获、规划、编写、评审、养护的循环配前沿模型效果很好，关键是人类同行评审——评审者和开发者开实时通话，开着转录拉出 PR 提问，通话结束后把转录喂回编码 agent，PR 被打磨得更自文档化，同时人类之间建立了共同理解；他用这套方式管理约 15 人的团队九个月，效果很好。反方也很坚决：luaKmua 说以他的工作和所需的严谨度，把实现交给 LLM 几乎省不下时间；lioeters 把「写不是瓶颈，理解才是」这句话推向了更大的图景——问题在于理解不是被出售的产品，商业模式是让所有人都变成那个魔法精灵产出物的消费者，而「理解」被留在模型提供方那一侧，这确保了下一代消费者要依赖别人来提供理解。bcrosby95 有个有趣的观察：LLM 越聪明，反而越不理解抽象的意义——它会一路钻进依赖包和程序集里，基于三层深的函数调用做决策，而这些细节在一个小版本升级里就可能变了。
「代码从来不贵 / 一直很贵」的短兵相接。 happytoexplain 说「代码从来就不贵」；doug_durham 反驳：「代码一直都很贵。整个设计工具产业的出现，就是为了避免写错的代码，因为它太贵了；有整本整本的期刊在讨论这件事。」mgaunard 提出了另一个方向的反例：「代码的成本其实上升了；技术债的累积速度已经超过我们清理它的速度。」1over137 一句话很扎心：「代码成本崩塌了？那程序员工资跌了吗？」chrisjj 挑了文章的措辞：「『生产貌似可用的代码的成本已经崩塌』——谁想要仅仅是貌似可用的代码？」devin 的回答很妙：「你那位烧 token 做 POC 的总监——现在你得想办法把它撑到规模化。」
支持文章框架的一侧。 marginalia_nu 的长评被顶得很高：代码本来就极少是瓶颈；如果我们真的在优化程序员生产率，就不会把程序员像沙丁鱼一样塞进温暖嘈杂、CO₂ 浓度 2000 ppm 的开放式办公室，再用邮件、Slack 提醒和会议整天打断他们，也不会让 Jira 繁文缛节占掉他们相当一部分工作——我们一直都有能力把每个人的产出提高 2 倍甚至 10 倍。siliconc0w 说这对好经理其实没什么变化：「认为软件工程师的工作是写代码的经理，本来就是坏经理。PR 数或代码行数从来不是好指标。」作者回应表示同意，并说这正是他认为「token 用量」这类代理指标不对的原因。raffraffraff 从基础设施岗位的视角说，他公司每天犯的错都不是代码错误，而是组织团队、系统设计、工作优先级这三件事上的失败；convolvatron 补了一句「别忘了『真的做决定』」。650 引用了文章中「停止默认过滤上下文」那段，并把矛头指向那些把自己当成迷你 CEO、刻意不让工程师参与验证的 PM。tiago_human 指出一个副作用：AI 让写代码更便宜，但让添加没人用的东西变得更便宜——瓶颈于是变成了决定什么值得存在，以及有纪律地删掉其余部分。
关于管理本身会不会被自动化。 OutOfHere 走得最远：「工程师不需要管理，投资人才需要。……自动化管理看起来比自动化工程更容易。至于领导力，让投资人来做。」visarga 的反驳很精炼：「你可以自动化工作，但永远无法自动化承担后果。」pillefitz 说这个视角太简化了：把经理想成一个在组织的织体上做工程的人——他大部分时间花在调试、沟通、寻找正确的抽象、配置流程上，和他以前做的工程工作非常相似。chickensong 则认为文章说的「排序需要的组织知识几乎没被写下来」这个问题会随 AI 采用而改善，因为工程本身已经有版本控制、变更控制、ADR、日志、结构化文档这些纪律和能力。
一条必须如实记录的负面爆料。 用户 ParityBear 在文章下面留言称：「什么都没变。过去一年我在一家很有问题的加密货币公司、跟着一位很有问题的 CEO 手下工作时，曾在这个人手下干过。这篇文章的作者很糟糕。纯粹的毒性。」并列举了一系列指控：把持所有信息不让下属拿到上下文、CEO 一抱怨就甩锅给下属、让两个团队在互不知情的情况下做同一个问题、他周围很多人辞职、在公开群聊中暴怒并威胁开除其他部门的人。这条指控未经核实，HN 上也没有其他人出面印证或反驳，但它出现在这篇讨论管理的文章下面，本身就是这条帖子的一部分。
最后是两条对行业「负空间」的呼吁。 baron3dl 提出了本帖最有建设性的问题：AI 编码时代什么才是正确的软件组织形态？这个问题至今没有 Accelerate（2018）那种量级的系统研究来回答。关于人们正在试的东西有大量（长得要命的）长文，但几乎没有关于失败的后续——「负空间的短文在哪？把人砍一半后来怎么样了？把组织扁平化呢？那些无人工厂，它们没造出来什么？」coffeebeqn 在同一串下的抱怨引起共鸣：「拜托别让我读 2653 个词，300 个词能说得更好。能不能把『如果我有更多时间，我会写一封更短的信』这个方法 RL 进下一代模型里？」