代码成本崩塌后，工程管理的旧规则失效
Engineering management after the cost of code collapsed
作为工程总监，我发现随着 LLM 的引入，代码生产成本已彻底崩塌，许多沿用已久的管理规则正在失效。过去依赖的“好工作需要时间”或“总监不应写代码”等信条，其底层假设已不复存在。虽然生成代码变得廉价，但代码审查、文档和入职培训依然关键。真正的挑战在于区分哪些是机器可验证的机械正确性，哪些仍需人类判断的语义正确性。当验证速度被 AI 拉高，工作总量反而可能增加，而培养初级工程师的管道也面临断裂风险。管理者必须重新审视每一项实践背后的假设，从关注代码产出转向关注业务结果和系统健康度。
投资机器可验证的正确性，现在是组织能资助的最高杠杆基础设施工作之一。
HN 评论区
200- dbingham
我觉得这篇文章大部分观点都是对的，尽管它可能建立在一个错误的假设之上。
这个假设是：LLM 应该负责写代码，而人类工程师负责审查和验证 LLM 的输出。并且认为这会降低生产成本。我从根本上反对这一点。
每次我让 LLM 写代码，哪怕是使用 Opus 4.8（还没试过 Opus 5），得到的结果最终都不得不被彻底重写。LLM 依然不擅长编写可维护的代码。它们能写出看似能运行的代码吗？能。但这代码撑不过长期。那些用 LLM 写所有代码的人，是在赌 LLM 最终能进化到能自己修复代码的地步。这有可能，但我不会轻易押注。
我发现 LLM 真正巨大的价值在于代码审查。LLM 的反复审查能捕捉到惊人的潜在问题。它们在安全审查上表现尤为出色，但在任何类型的审查中都非常有效。
“LLM 写代码派”误解的另一个点是：写作从来都不是瓶颈，理解才是。而理解代码依然是瓶颈。但真正的理解是在写作循环中获得的。相比于纯阅读或代码审查，你在写作过程中获得的理解要深刻得多。
过去大部分花在写作上的时间，实际上是在更新和深化我们对正在开发的系统的理解。这种理解是无法被替代的……
- marginalia_nu
代码本身一开始就很少成为瓶颈。
如果我们真的积极优化程序员的生产力，我们就不会把程序员像沙丁鱼一样塞进温暖嘈杂的开放式办公室，那里 CO2 浓度高达 2000 ppm，然后整天用邮件、Slack 通知和会议不断打断他们；Jira 的繁琐流程也不会占据他们工作的很大一部分；程序员本该大部分时间都在思考和编程。
我们一直有能力让每个可怜虫的产出提升 2 倍，甚至 10 倍。我们之所以陷入这种编程炼狱，并不是因为这是生产力的最优解——这显然不是——而是因为这是计费工时（billable hours）的最优解，或者是组织架构权力的最优解，又或者是因为杰文斯悖论（Jevons paradox）也波及到了商业管理，导致 IT 部门分到了太多的预算。
- baron3dl
在 AI 编程的当下，什么样的软件组织才是正确且最好的？这个问题至关重要，但目前还没有像《Accelerate》（2018 年，Forsgren, Humble, Kim 著）那样全面的研究来回答。
有很多（令人痛苦的）长篇大论在讨论大家正在尝试什么，但很少有关于什么失败的后续报道。关于“负面空间”（negative space，指失败或未尝试的领域）的简短文章在哪里？裁掉一半员工结果如何？扁平化组织效果怎样？那些“黑暗工厂”（dark factories）到底没产出什么？还有那些尝试过、失败了、然后悄无声息被废弃的其他方法呢？
我们需要更高效地探索和沟通这些负面空间。不要重复同样的错误，也别让我读 2653 个字，当 300 个字就能说得更好时。
- mgaunard
代码的实际成本反而增加了；技术债务积累的速度比我们清理它的速度还要快。
- georgeburdell
据我观察，管理层主要通过以下方式浪费了 AI 带来的收益：
1. 追求超出以往标准的精致度和质量。
2. 用初级工程师耗时数月、每天成本 200 美元开发的代码，去替换原本每月每席位 100 美元的 SaaS 服务。
代码成本趋近于零，但问责制和托管的成本依然不变，因此个人只需要协调那些仍然是有限资源的部分。管理层需要停止坚持要求他们的下属采用彼此那种“氛围感编码”（vibe coded）的工具。
- 650
“保护团队免受业务干扰。”这一点的底层假设是注意力是有限的，上下文切换是昂贵的。这个假设依然成立。变化的是“让团队缺乏上下文”的成本。工程师在没有业务上下文的情况下提示 AI 工具，只会大规模地生产出流畅、看似合理但完全错误的工作成果。"
太多团队和组织里的业务人员（主要是产品经理）试图在自己的知识领域发号施令，把自己当成委派者和微型 CEO，主动避免让工程师参与进来以验证自己。工程师需要承担产品经理的角色，而产品经理的角色必须达到 1:50+ 的工程师配比，否则就该滚蛋。
- chickensong
> 排序需要你对组织实际行为的模型：信任关系、走廊里的非正式知识、过去决策的后果。这些几乎都没有被写下来。
这是一个与运营卓越和政治相关的长期存在的问题。我预计随着 AI 的采用和集成，情况会有所改善。你没法让高管创建决策记录并提交到 git。管理者有动机去囤积信息。
工程团队已经拥有（也许）解决这个问题的纪律和能力。版本控制、变更控制、架构决策记录（ADRs）、日志、结构化文档等等……我们可以追踪一个入站数据包或调用贯穿整个堆栈。管理层做不到，或者不愿做接近于此的事。一对一邮件、会议纪要、过时的 Word 文档是大多数人的标准。
将 LLM 作为接口插入，和/或接入现有的接口（如邮件），将会改变这一切。最终，我们可以在不试图“教老狗新把戏”的情况下，捕捉到更多的机构知识。
- jboss10
> Gemini 4 帮助进行了编辑。
这家伙已经能用上 Gemini 4 了吗？
我猜是 Gemma 4 很乐意被误认为是 Gemini，而且没发现这个错误。