人工智能让你快速获得一个工作的草稿（比如说四分之三的进展），而且这个速度非常真实。问题在于剩下的五分之一包含了什么，以及谁曾经培养处理它的能力。在上一篇文章的最后，我承认有一个相关的痛点我留下来单独讨论：工具以急速方式将你带到80%的程度，而最后的20%总是工程师真正待过的地方。这就是本文主题。先从一个老笑话开始，这个笑话通常归于贝尔实验室的汤姆·卡吉尔，并由乔恩·本特利的《程序设计宝典》专栏名声大噪：代码的前90%需要耗费90%的时间，而剩下的10%则需要耗费其他90%的时间。这是一个有趣的说法，因为算术是荒谬的，而经验却是确切的。系统的可见部分，演示的部分，快速组装在一起。然后项目遇到了没人预算的部分：边缘情况、故障模式、仅在负载下才出现的条件、一页半的操作现实，这决定了该产品是否能在实际应用中幸存。1 那个尾部并不是时间表上的一个四舍五入误差，而是整个时间表。生成性人工智能并没有废除这个规则。它只是将其重新定位，并在移动过程中创造了一个值得仔细命名的问题。让编码模型构建一个功能，它会以惊人的速度和流畅性产生前80%的内容：快乐路径逻辑、通过基本测试的结构、在演示中运行的脚手架。有一个警告：只有当模型是在类似于你的问题上训练的，并且能够对其进行泛化时，那个80%才是真实的。把它指向训练数据几乎没有触及的地方，流畅性就不会流畅，而正确性却会降低，你会得到相同自信的脚手架，现在是虚构的。2 流畅输出和可用工作是两回事，模型已经足够优秀，可以得到前者，但却错过了后者。当80%是真的时候，它悄悄跳过的是那20%，而跳过的并不是随机的。它们集中在工程中需要持续操作经验的部分，防止两次竞争请求破坏状态的幂等性键，保持重试不变成踩踏的回退和抖动，规避长表锁的迁移，速率限制器，电路断路器，使最终故障在凌晨3点可诊断的结构化日志。每一个在开发过程中都是不可见的，因为开发环境从未测试能够暴露它的条件。代码编译成功，测试通过，演示正常工作，工件看起来完成。然后它遇到并发、流量激增、部分网络故障或任何普通的生产残酷，而事情根本还没完成。最后20%是工程师曾经生活的地方。它从来不是有趣的部分，但却是具有形成性的部分，因为它是强制与基础接触的部分，建立了接触所产生的判断。你通过追逐一个无法解释的段错误、平行程序中令人作呕的随机损坏、偶尔的堆栈崩溃而了解内存。3 你通过调试一个仅在星期二出现的竞争条件来了解并发。你通过观看一个在一千行上运行流畅的查询在一千万行上崩溃来了解数据形状。所有这一切都不是温柔或高效的教育，但却是教育，因为系统在你理解之前根本无法工作。模型现在生成的80%基本上是最能抵抗的部分。而它跳过的20%则是教授的部分。这当中有一个值得大声说出来的要点，和这个故事焦虑的版本相对：经验现在更有价值，而不是更少。当打字部分有一部分被处理时，决定性的技能变成了与打字相关的一切，知道哪个算法真正合适，看到组件相遇以及在压力下如何表现，脑中保持系统真正应该做什么的清晰。这是最后20%曾经建立的判断，而正是这一部分模型无法传达给你。一个我承认的偏见：我仍然比自己的大语言模型更善于优化大多数时候，尽管有可能我只是比它更挑剔。4 好的计划，暴力执行这里有一个相关的推论，正好与此相反，我第一次在不同的军装中学习了这一点。美国军队教导一种规划版的相同比例，通常围绕着归于巴顿的名言：现在暴力执行的好计划比未来在某个不确定的时间执行的完美计划更好。乔治·S·巴顿将军这并不是无计划或坏计划冲进来的许可。它是对相反失败的警告，即由规划导致的瘫痪。等着完美计划，你还是会输：你的力量静止不前和未部署，而一个有粗略计划的竞争对手则会行动，包围你。