随着代码生产成本因AI工具而大幅下降，约一半的传统工程管理规则已失效。作者指出，虽然AI使产出代码更便宜，但工程组织是否因此显著提速尚未证实，代码审查、文档等环节并未过时。

好的，作为一名专业的中文编辑，我将对原文进行中文重述，保留核心细节，并删减与主题无关的内容。

---

当代码成本崩溃后的工程管理

我担任工程总监已超过三年，但仍常听到一些“旧规则”，例如：总监不应花时间写代码、好工作需要时间、保护团队免受业务干扰、在承诺前需达成共识等。

我曾以为这些规则已经过时。但当我们引入大语言模型（LLM），代码生产成本骤降后，我开始审视每条规则背后的假设。一个惊人的发现是：大约一半的旧规则基于已失效的假设，而另一半则不然，其中一些甚至比以往更重要。

我们真正知道什么

生产“看似合理”代码的成本已经崩溃，且不会回升。除此之外，大多数说法要么未经证实，要么是错误的。

• AI工具是否让工程组织显著提速？未经证实。
• 代码审查、文档和入职培训是否过时？错误。
• 能否用一半的人完成同样的路线图？这是一个赌注，而非事实。

如果你基于这个狭窄的论断重建管理实践，你会是正确的。但若基于那些宽泛的说法，你就是在拿别人的职业生涯赌博。

聚焦于审计假设

每项管理实践都基于特定假设。例如，速度追踪假设产出是努力的有效指标；六个月的入职培训假设语法学习缓慢；共识驱动的架构假设变更成本高昂；人员规划假设产出与人数成正比。

问题不在于实践有多古老，而在于它究竟基于什么。如果一项实践基于编写代码的成本，那就需要重新审视，因为成本变了。如果它基于人类如何协调、建立信任、分配注意力或验证正确性，那么无论其形式多么陈旧，本质并未改变。

这听起来显而易见，但许多人凭感觉行事：看似现代的就保留，看似过时的就抛弃。这会导致团队放弃了有用的“摩擦”，却保留了无用的流程，因为实践的新旧与其有效性是无关变量。

证据小于噪音

要警惕任何只报告巨大提速的人。我所知的收益主要体现在新项目、样板代码和不熟悉的领域。在工程师已熟悉的系统上进行深度工作时，这些收益会减弱甚至逆转。我期待2025年第四季度之后的数据和研究，届时新模型的能力将完全超越旧报告所依据的模型。

然而，感觉速度与测量速度之间的差距本身就是一个管理问题。如果你的工程师感觉更快，但交付量相同且缺陷更多，你将错误地配置人员、制定计划，并向业务方设定无法实现的期望。在采用AI的组织中，首要任务是进行足够诚实的测量，以判断你是否真的加速了。

廉价事物的弱代理指标

速度、拉取请求数量和关闭工单数从来都不是完美的指标。它们之所以存在，是因为它们所近似的事物——编写代码的努力——是真正稀缺的，因此噪音在可容忍范围内。

现在，这个被近似的事物变得廉价了。这使得这些指标不仅不完美，而且具有误导性，因为提高它们最廉价的方式是生成数量，而数量正是你的组织不再缺乏的东西。

AI特定的指标（如接受率、提示次数）解决了错误的问题。持久的做法更古老也更困难：衡量业务成果和系统健康度，并将代码量视为需要证明其合理性的成本，而非值得赞扬的产出。优秀的工程师在LLM出现之前就说过这些。那时是对的，现在则因代码编写不再是难点而变得可强制执行。

“正确”仍然需要时间（目前如此）

“好工作需要时间”这条规则可以清晰地一分为二。

管道时间已经崩溃。搭建服务、生成测试、在框架间转换、编写迁移初稿——所有这些现在都很快。基于这些成本制定的时间表理应被压缩。

正确性时间也一分为二。

AI系统现在检查和纠正代码的速度比任何人类审查者都快。机械验证正在崩溃。任何“正确”可以被表达为机器可检查的产物（如类型、测试、契约、lint规则、不变量、金丝雀指标）的地方，AI都能以人类无法匹敌的速度运行测试循环、读取失败、修复差异并再次运行。如果你的正确性存在于这一层，你的检查时间确实在下降，并将持续下降。

但请注意这一层之所以快的原因：它之所以快，是因为已经有人写下了“正确”的含义，并以机器可评估的形式呈现。 规范完成了工作，检查器只是读取它。

语义验证则是另一回事。代码是否实现了业务真正需要的策略？这个权衡是否符合你的监管要求？在这里，“正确”存在于人脑和机构历史中。AI检查AI存在结构性问题：检查器与生成器共享训练数据、偏见和盲点。两者会在相同的地方因相同的原因而失败。自我审查能发现错别字，但发现不了共同的理解偏差。

我认为由此产生三个后果，这也是本文的核心：

• 单位成本下降，总工作量上升。 廉价的检查会引发更多的生成，而更多的生成需要更多的检查。即使每次检查变得更便宜，验证工作量也会随数量增长。净日历时间变得模糊，事故特征也发生转变：愚蠢的错误减少，系统性问题增多，因为大量看似合理的输出现在通过了大量看似合理的审查。
• 边界是一个战略变量。 你的正确性有多少是机器可检查的，这并非固定不变，而是取决于你的规范、契约和不变量。拥有强大规范的团队能充分受益于廉价的检查。 规范薄弱的团队则会让生成的代码由生成它的同一台机器来审查。投资于机器可检查的正确性，现在是一个组织能资助的最高杠杆的基础设施工作之一，因为它决定了你能多大程度利用这波浪潮。
• 验证中最慢的部分从来不是检查，而是问责。 有人签字，有人承担错误的后果。签字时间不会压缩，因为它不是信息处理，而是风险接受，法律和信任体系将其分配给具体的人。

因此，验证仍然设定着吞吐量。变化的是约束的位置：从检查速度转移到规范质量，以及特定人类愿意为结果承担责任的意愿。

初级工程师的培养管道是一个未解决的问题

没有人知道如何在这种环境下培养工程师。

你期望高级工程师拥有的判断力，历史上是通过AI现在吸收的那些工作来建立的：修复小错误、编写样板代码、遇到困难然后解决困难——这些不仅仅是任务，更是产生判断力的实践。如果机器拿走了实践，培养高级工程师的管道就会断裂，而且这种断裂会有延迟，所以你在三到五年内不会注意到。

有一些看似合理的应对措施：对生成代码进行结构化审查、有意的无辅助练习、轮岗测试和验证工作、在资深监督下更早接触真实系统。我正在运行其中一些版本。但我无法告诉你它们是否有效，因为结果变量是五年后一名高级工程师的质量。

我能告诉你的是，任何声称已经解决了这个问题的人，无论是供应商、博主还是会议演讲者，都是在推销东西。请将培养管道视为一个你个人需要面对的开放性问题。它的行动与证据之间的延迟最长，纠正错误的机会也最少。

我对旧规则的看法

• “总监不应该写代码。” 那种浅尝辄止、通过审查拉取请求来寻找存在感、并成为瓶颈的总监是真实存在的。同样真实的是，那种对工作的心智模型落后五年、无法区分团队是真正变快了还是在大量生成自信但错误的输出（“废话大炮”）的总监。解决方法是校准。你不需要交付代码，但需要足够直接地接触工具和产出，这样你就不会被炒作或贬低所愚弄。
• “保护团队免受业务干扰。” 这条规则背后的假设是注意力有限，上下文切换成本高昂。这个假设依然成立。但让团队缺乏业务背景信息的成本变了。工程师在没有业务背景的情况下提示AI工具，只会大规模地产生流畅、看似合理但错误的工作。修正方案不是向所有人灌输一切，而是停止默认过滤，开始有选择地决定：哪些背景信息、给谁、以何种详细程度。
• “我们需要在承诺前达成共识。” 共识始终关乎承诺和协调，以及应对廉价转向的成本。廉价转向改变的是哪些决策需要共识。可逆的决策（双向门）应由尽可能小的群体快速做出，因为错误的可逆决策现在很容易撤销。不可逆的决策仍然需要缓慢的过程。真正的技能是分类，而大多数组织经常错误分类，将可逆的技术选择视为永久性的，将永久性的组织选择视为随意性的。
• “我们需要更多人手。” 产出的单位经济学变了，因此每个请求都需要比三年前更严格的问题：这项工作中哪部分是判断，哪部分是我们继续雇佣人类来做的生产？但不要矫枉过正。向一个已经延迟的项目加人仍然会让它更延迟。协调成本、入职拖累和沟通开销并没有随着语法的价格而改变。审视人员需求是因为人均产出变了，而不是因为人不再是昂贵的部分。

为什么这些陈词滥调会持续存在

实践之所以存在，原因总是混合的：有些过时，有些仍然有效，有些是出于政治原因。当你听到一条旧规则被重复时，你通常听到的是一个人在用一个错误的论点捍卫其有效的部分，或者用一个曾经有效的论点来捍卫其过时的部分。

将“持续存在”视为愚蠢，是每一种管理潮流的失败模式，AI潮流也不例外。五年后看起来最糟糕的领导者，不会是那些谨慎的人，而是那些用一套新口号（即使是听起来准确的口号）取代了思考，并基于未经测量的说法来运营组织的人。

工作就是分类

当一项如此重大的技术到来时，诱惑是选择一种姿态：烧掉旧剧本，或者捍卫它。这两种姿态都是懒惰。剧本从来不是单一的对象。它是一百页纸，有些关于打字成本，有些关于人的本质，它们被紧密地捆绑在一起，以至于我们忘记了它们是可以分离的。

不要让任何人，包括这篇自信的文章，说服你它们曾经是同一页。

机器会做分类工作吗

最近有人告诉我，AI很快也会做管理工作，包括分类。我思考了一个周末，认为这在一定程度上是正确的。

管理有一个信息路由功能：汇总状态、跟踪进度、将更新转化为仪表盘、预测时间表、整理绩效数据。管理层日常工作的很大一部分是在格式和人之间移动信息。LLM非常擅长这个，这部分的价值正在趋近于零。如果你的管理层靠总结Jira来维持生计，那么是的，这已经结束了。

然后是判断功能：招聘、解雇、晋升、决定哪条规则适用于这种情况和这些人、为一个糟糕的决定负责。这与验证具有相同的结构。有人根据现实检查输出，有人承担后果。

我们又回到了上面提到的生成论点，但应用于管理工作：管理产出变得丰富，因此廉价。但以上所有内容的论点是，当生成丰富时，验证就是约束。机器生成的管理仍然需要人类根据组织的实际行为来验证它，并为结果签字。所以，这或许不是管理者的终结，而是管理者降级为编辑和所有者。这与个体贡献者正在经历的转变完全相同。

将分类工作委托出去还有一个问题。分类需要一个关于你的组织实际如何运作的模型：信任关系、走廊里的知识、过去决策的后果。这些几乎都没有被记录下来。组织的书面记录是一个小而精炼的部分，而模型是基于记录进行分类的。更糟糕的是，模型从其训练中编码的是行业的平均判断。一个LLM会大致按照中位数组织的方式来分类你的剧本。如果你的策略是成为中位数组织，那没问题。差异化恰恰存在于你拒绝委托的决策中。

这是我诚实的让步：作为智力活动的分类是可以自动化的。我使用AI来压力测试了本文的部分内容，它的初稿审计还不错。但不可自动化的是政治和道德工作。

未来的走向是：管理幅度扩大，层级压缩，管理的信息路由层确实面临风险，而头衔会比功能存在得更久。幸存下来的管理工作是那些无法被写下来、无法被平均化、也无法由其他人签字的工作。

什么会幸存

工程工作的剩余是规范和所有权。管理工作的剩余是判断和所有权。相同的形状，两个层级。

在组织的每一个层级，幸存下来的工作都是必须有人签字的工作。

让我们将推论推到极限以加深理解。想象一个组织，其中代理编写代码、运行检查、路由状态、安排工作并起草计划。人类设定方向、定义“正确”的含义并签字。从签字到交付结果之间的一切都是机器。现在将时间线倒转：想象这个组织先出现，然后有人提出了你实际运行的那个组织。我们将雇佣数百名昂贵的人，以打字速度手工生产文本。我们将他们分层排列，每一层的工作是总结下一层的内容给上一层。我们将他们的日历同步到会议室，以便他们可以互相告知已经发生的事情。我们将根据他们输出了多少来衡量他们的价值。没有人会资助这个提案。它缓慢，每次交接都会丢失信息，并且将建筑中最稀缺的资源花在了机器已经完成的工作上。

你运行的组织从来不是被设计的，而是积累而成的。每一个角色、仪式和层级的存在，都是因为某些东西曾经很昂贵：打字、路由、检查、记忆。价格变了。组织架构图没有变。在代理极限下，架构图不再记录谁在生产，而是开始记录谁在签字。人员编制不再衡量容量，而是开始衡量你能负担多少问责。能够达到这一点的组织，看起来会是小、安静、几乎空荡荡的：一个简短的名单，附在一长串决策之后，除此之外，没有什么可管理的了。

以下是对评论内容的总结，涵盖主要观点、论据及不同立场，并保留关键引用（中英文）。

1. 代码成本是否真的下降？

• 支持下降：评论指出“The cost of producing plausible code has collapsed”（产生看似合理代码的成本已崩溃），但质疑“Who wants merely plausible code?”（谁只想要看似合理的代码？）（评论16）。
• 反对下降：评论4认为“The cost of code actually increased; code debt is being accumulated faster than we can clean it up”（代码成本实际上增加了；技术债务积累速度超过清理速度）。评论23反问“Have programmer salaries gone down?”（程序员薪水下降了吗？）。

2. LLM对开发效率的影响

• 正面：评论2认为LLM“allows people learn to use the tools to take on solving problems that couldn't be approached before”（让人们学会用工具解决以前无法解决的问题）。评论21指出“AI is useful and writes better code than most people”（AI有用，写的代码比大多数人好）。
• 负面：评论8强调“Code was very rarely the bottleneck in the first place”（代码从来不是瓶颈），真正的瓶颈是理解、组织和管理。评论11认为“LLMs still aren't good at writing maintainable code”（LLM仍不擅长写可维护代码），建议“humans write, LLMs review”（人类写，LLM审查）。

3. 管理、组织与团队结构

• 管理问题：评论10指出“The managers that thought the job of software engineers was to write code were bad managers”（认为软件工程师的工作就是写代码的管理者是糟糕的）。评论12批评“management is mostly pissing away the gains made by AI”（管理层大多浪费了AI带来的收益）。
• 组织变革：评论6呼吁“What is the right, best software organization in the current era of AI coding?”（当前AI编码时代，正确的最佳软件组织是什么？），并强调需要探索“negative space”（失败经验）。评论15预测“you need to get rid of them all, and replace them with the most experienced highest paid person you can find”（你需要淘汰所有人，用你能找到的最有经验、薪酬最高的人替代）。

4. 理解与上下文的重要性

• 理解是瓶颈：评论11强调“Understanding was. And understanding the code is still the bottleneck”（理解是瓶颈，理解代码仍然是瓶颈）。评论20指出“Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale”（工程师在没有业务上下文的情况下提示AI工具，只会大规模产出流畅、看似合理但错误的工作）。
• 上下文切换成本：评论14认为“the context switching is costing us a lot”（上下文切换让我们付出很大代价）。评论21警告“AI will exploit that weakness and expand the state space into regions we can't cognitively grasp”（AI会利用弱点，将状态空间扩展到我们无法认知的领域）。

5. 对AI生成代码质量的质疑

• 质量风险：评论16质疑“Who wants merely plausible code?”（谁只想要看似合理的代码？）。评论11指出“LLMs still aren't good at writing maintainable code”（LLM仍不擅长写可维护代码）。评论21承认“AI is more logical than humans is paradoxically a greater risk”（AI比人类更逻辑，这反而是一个更大的风险）。
• 潜在价值：评论21也承认“AI is at least at a PhD level of technical ability”（AI至少达到博士级技术能力），并认为“AI constructs much more logical structures”（AI构建更逻辑的结构）。

6. 对文章本身的质疑

• 事实错误：评论5、17、18指出文章提到“Gemini 4 helped with the editing”（Gemini 4帮助编辑），但“Gemini 4”可能不存在或为笔误。
• AI生成嫌疑：评论7报告“Pangram reports this post was 100% AI generated”（Pangram报告该帖子100%由AI生成）。

总结

评论围绕“代码成本是否下降”展开激烈辩论，多数观点认为成本下降有限，真正的瓶颈在于理解、管理和组织。LLM在代码审查和辅助理解方面有潜力，但直接生成可维护代码仍存疑。管理层面需适应AI时代，避免浪费收益，并重视上下文和团队结构。文章本身因事实错误和AI生成嫌疑受到质疑。