代码是一种负担（而不是资产）。科技老板们不理解这一点。他们认为AI很棒，因为它生成的代码是程序员的10,000倍，但这仅仅意味着它产生了10,000倍的负担。 1/

如果您想要一个格式化为论文的版本来阅读或分享，这里有一个链接到我的无监控、无广告、无追踪的博客： 2/

AI 是我们正在填入高科技社会墙壁中的石棉： 代码是一种负担。代码的 *能力* 是资产。 3/

技术商店的目标是拥有能够产生比维持这些代码运行所需成本更多收入的代码。 4/

长期以来，企业一直抱有一个错误的信念：代码的运行成本随着时间的推移而降低：在初始的调整期内，代码中的错误被发现并解决后，代码就不再需要进行有意义的维护。 5/

毕竟，代码是一种没有活动部件的机器——它不会磨损；甚至不会磨损。 这是保罗·梅森2015年书籍《后资本主义》的论点，这本书的陈旧程度令人惊讶（尽管可能没有梅森自己的政治信誉那么糟糕）。 6/

代码并不是一种无限可复制的机器，不需要任何劳动。相反，它是一种脆弱的机器，需要越来越多的英雄措施来保持其良好的工作状态，并最终会“磨损”（在需要全面重构的意义上）。 7/

要理解为什么代码是一种负担，您必须理解“编写代码”和“软件工程”之间的区别。 “编写代码”是一项非常有用、有趣且引人入胜的消遣。 8/

它涉及将复杂任务分解为离散步骤，这些步骤描述得非常精确，以至于计算机可以可靠地执行它们，通过找到巧妙的方法来优化性能，最小化代码对计算机资源（如RAM和处理器周期）的需求。 9/

与此同时，"软件工程"是一个包含"编写代码"的学科，但更关注于代码所组成的*系统*的长期运作。 10/

软件工程关注的是生成系统接收的数据的上游过程。它关注的是系统向外发出处理信息的下游过程。 11/

它关注的是从相同的上游过程接收数据和/或向系统正在发出的相同下游过程发出数据的相邻系统。 12/

"编写代码"是关于编写*运行良好的*代码。"软件工程"是关于编写*失败良好的*代码。它是关于编写可读的代码——其功能可以被可能被要求维护它的第三方理解。 13/

这些第三方可能会被要求调整与系统相关的下游、上游或相邻的流程，以防止系统崩溃。 14/

这就是问题所在：任何非平凡的代码都必须与外部世界互动，而外部世界并不是静态的，它是*动态*的。外部世界*总是*打破软件作者所做的假设，每次发生这种情况时，软件都需要修复。 16/

还记得Y2K吗？那是一个完美运行的代码在完美运行的硬件上停止工作的日子——不是因为代码发生了变化，而是因为*时间在推移*。 17/

我们距离Y2038问题还有12年，当32位版本的Unix将全部停止工作，因为它们也将耗尽可计算的秒数。 18/

“世界”的存在是一个不可避免的因素，它使软件逐渐磨损，并需要重建，通常代价巨大。代码运行的时间越长，它遇到“世界”的可能性就越大。 20/

获取设备用于报告其物理位置的代码。最初，这用于诸如计费之类的事情 - 确定您使用的是哪个运营商或提供商的网络，以及您是否在漫游。 21/

然后，我们的移动设备使用这段代码来帮助确定您的位置，以便在导航应用中为您提供逐步指引。然后，这段代码再次被重新利用，帮助我们找到丢失的设备。 22/

这成为了定位*被盗*设备的一种方式，这一用例与寻找丢失设备有很大不同。当定位丢失设备时，你不必考虑恶意行为者禁用了“查找我的丢失设备”功能的可能性。 23/

这些额外的用例——上游、下游和相邻——暴露了原始代码中的错误，这些错误在早期的应用中从未显现出来。 24/

例如，所有位置服务必须在（非常常见的）不确定自己位置的情况下具有某种默认行为。 25/

也许他们有一个通用的修复方法——例如，他们知道自己连接到哪个手机信号塔，或者他们知道上一次获得准确位置修复时的位置——或者他们可能完全迷路了。 26/

事实证明，在许多情况下，定位应用程序在所有可能的位置周围画了一个圆圈，然后将它们的位置设置在那个圆圈的中心。 27/

如果圆的直径只有几英尺，或者应用程序很快用更精确的位置替换这个近似值，那就没问题。但如果位置跨越数英里，并且位置修正*从未*改善呢？ 28/

如果任何没有定义位置的IP地址的位置被给定为*美国大陆的中心*，而任何不知道它在哪里的应用程序报告它在堪萨斯州的一所房子里，会怎么样？ 29/

在我所在的伯班克镇，谷歌的定位共享服务曾告诉我们，我们当时11岁的女儿（我们无法联系到她的手机）距离我们12英里，位于洛杉矶县一个未合并的地区的高速公路匝道上。 32/

（她在附近的公园，但超出了范围，应用程序估算她的位置为最后确定的区域中心。） （这几个小时过得很艰难。） 33/

底层代码——使用某些曾经无害的默认值来模糊未知位置的代码——需要*不断*更新，因为与之相关的上游、下游和相邻过程也在*不断*变化。 34/

代码放在那里越久，其原始行为就越显得过时，而其上层的补丁则越显得繁琐、陈旧和晦涩。 35/

代码不是资产——它是负债。计算机系统运行的时间越长，它所代表的技术债务就越多。系统越重要，停机并完全重做的难度就越大。 36/

相反，新的代码层被覆盖在其上，而每当代码层相遇时，就会出现裂缝，这些系统的行为并不完全一致。 37/

更糟的是：当两家公司合并时，它们的缝合、裂缝的IT系统被强行整合在一起，因此现在存在*相邻*的技术债务来源，以及上下游的裂缝： 38/

这就是为什么大型公司如此容易受到勒索软件攻击的原因——它们充满了不兼容的系统，这些系统被迫与各种形式的数字橡皮泥、绳子和捆扎铁丝伪装成兼容的样子。 39/

它们并不是防水的，也无法做到防水。即使没有被黑客攻破，它们有时也会倒下，无法再站起来。 40/

还记得2022年圣诞周西南航空的计算机崩溃，导致数百万旅客滞留的事情吗？ 41/

航空公司尤其糟糕，因为他们早期就实现了计算机化，无法关闭旧计算机以用新计算机替换它们。这就是他们的应用程序如此糟糕的原因。 42/

这就是航空公司解雇客户服务人员并要求乘客使用应用程序处理*所有事情*的原因，这些应用程序根本无法正常工作。这些应用程序永远不会正常工作。 43/

英国航空的应用程序显示“发生未知错误”的原因并不仅仅是因为他们解雇了所有IT员工并将工作外包给海外低价竞标者。 44/

确实是这样——但也因为BA的第一台计算机是基于电机械阀运行的，而自那以后的一切都必须与一个由艾伦·图灵的门徒用他自己的前牙从一整根原木上啃出来的系统向后兼容。 45/

代码是一种负担，而不是资产（BA的新应用程序落后于计划多年）。 代码是一种负担。使迈克尔·布隆伯格成为亿万富翁的彭博终端服务器运行在RISC芯片上。 46/

这意味着它被锁定在使用越来越少的专业硬件和数据中心供应商，支付专业程序员的费用，并构建脆弱的代码链，以将这些RISC系统连接到世界上不那么奇特的等价物。代码不是资产。 47/

AI可以编写代码，但AI无法进行软件工程。软件工程完全是关于思考*上下文*——这个系统之前会发生什么？之后会发生什么？它会与什么并存？世界将如何变化？ 48/

软件工程需要非常广泛的“上下文窗口”，而AI则没有，也无法拥有。AI的上下文窗口狭窄且浅薄。要线性增加AI的上下文窗口，需要在计算需求上进行*几何*扩展： 49/

编写有效的代码而不考虑它如何失败，是灾难的配方。这是一种大规模创造技术债务的方式。这就像把石棉填入我们技术社会的墙壁中。 50/

老板们*不知道*代码是负债，而不是资产。这就是为什么他们不会停止谈论那些生成比任何人类程序员多10,000倍代码的聊天机器人。 51/

他们认为他们找到了一个以人类程序员的10,000倍速度生产*资产*的机器。实际上，他们找到了一个以任何人类程序员的10,000倍速度生产*负债*的机器。 52/

可维护性不仅仅是通过艰苦的经验教会你陷阱在哪里。 53/

这也需要培养一种"Fingerspitzengefühl" - 这种"指尖感觉"让你能够合理地猜测出以前从未见过的陷阱可能出现的位置。 54/

这是一种过程知识。它是不可避免的。即使是你可以用作训练数据的最大代码库中也没有潜在的： *男孩*，科技老板们真是不明白这一点。 55/

以微软为例。他们现在的重大赌注是"代理 AI"。他们想在你的电脑上安装间谍软件，捕捉每一个按键、每一次沟通、你看到的每一个屏幕，并将其发送到微软的云端，让一群聊天机器人可以访问这些信息。 56/

他们声称你可以告诉你的电脑："帮我预定一趟去卡迪夫的火车，并找到去年科里提到的那家酒店，帮我在那儿预定一个房间"，它就会做到。 这是一个极其不可行的想法。 57/

没有任何聊天机器人能够远程完成所有这些任务，微软对此表示毫不掩饰。微软提议将这些任务分解到数十个聊天机器人中，每个聊天机器人希望达到95%的可靠性。 58/

这本身就是一个完全不可信的聊天机器人标准，但考虑这一点：概率是*乘法的*。一个包含两个以95%可靠性运行的过程的系统，其净可靠性为90.25%（0.95 * 0.95）。 59/

将一个任务分配给几十个95%准确的机器人，这个任务正确完成的机会几乎为*零*。 60/

与此同时，一位微软高管在去年十二月因在Linkedin上发布声明，宣布他打算让AI重写微软的*所有*代码而陷入麻烦。 63/

重构微软的代码库是非常有意义的。微软——就像英国航空和其他传统公司一样——拥有大量非常旧的代码，这些代码代表了不可持续的技术债务。 64/

你们中的一些人*是*软件工程师，发现聊天机器人在为你们编写代码方面非常有用。这是一个常见的AI悖论：为什么有些使用AI的人觉得它非常有帮助，而另一些人却厌恶它？ 66/

不喜欢AI的人是因为他们 "不擅长AI" 吗？AI爱好者是懒惰的，不关心他们工作的质量吗？ 67/

毫无疑问，这两者都有发生，但即使你教会每个人成为AI专家，并将所有不以工作为荣的人从样本中剔除，悖论仍然会存在。 68/

AI悖论的真正解决方案在于自动化理论，以及“半人马”和“反半人马”的概念： 69/

在自动化理论中，"半人马"是指一个受到机器协助的人。"反向半人马"是指一个被征召去*协助机器*的人。 70/

假设你是一名软件工程师，使用AI编写常规代码，而你有时间和经验来验证这些代码，运用你的直觉和流程知识来确保它们适合目的。 71/

很容易理解为什么你会觉得使用AI（在你选择的方式、你选择的时间、你选择的速度下）是有用的。 但假设你是一名软件工程师，接到命令要以你之前速度的10倍、100倍或10,000倍的速度生成代码。 72/

说唯一的办法是通过AI，而没有人类的方式可以审查那段代码并确保它在首次接触世界时不会崩溃，你会讨厌它： 73/

（如果你被变成了AI的责任承担者，亲自为AI的错误负责，你会更加厌恶它。） 软件工程师发现AI生成的代码在某种情况下非常有帮助：当这些代码是*孤立的*。 74/

如果你只是在做一个单一的项目——比如说，将一批文件转换为另一种格式，仅此一次——你不必担心下游、上游或相邻的过程。没有这些过程。 75/

你正在编写代码来做某件事情一次，而不与任何其他系统交互。很多编码都是这种实用项目。这是乏味的、没有回报的，并且非常适合自动化。 76/

许多个人项目都属于这个范畴，当然，根据定义，个人项目就是一个半人马项目。没有人强迫你在个人项目中使用AI——你总是可以选择如何以及何时使用任何工具。 77/

但软件工程师有时可以通过AI改善他们的工作这一事实，并不能否定代码是一种负担，而不是资产，AI代码代表着大规模的负担生产。 78/

在技术失业的故事中，有这样一个观点：新技术创造新工作，同时使旧工作变得过时：每一个因汽车而失业的铁匠，都会有一个作为机械师的工作在等待着。 79/

自从AI泡沫开始膨胀以来，我们听到了很多版本的说法：AI将为“提示工程师”创造工作——甚至创造我们无法想象的工作，因为这些工作在AI改变世界到不可识别的程度之前是不存在的。 80/

我不会指望在一个无法想象的奇幻行业中找到工作，因为我们的意识尚未因AI的影响而改变到能够概念化这些新工作模式的程度。 81/

但如果你*确实*在寻找一个AI肯定会创造的工作，数量以百万计，我有一个建议：数字石棉清除。 82/

AI 代码 - 以任何人类编码者的 10,000 倍速度编写，旨在良好运作，但不具备优雅失败的能力 - 是我们填充墙壁的数字石棉。我们的后代将花费几代人从墙壁中挖掘出这些石棉。 83/

我们将有很多工作来修复我们因最危险的AI精神错乱而破坏的东西——那种幻觉般的信念，即“编写代码”和“软件工程”是同一回事。 84/

按照我们现在的速度，我们将为几代石棉清除工提供充分的就业机会。 85/