克劳德不是一个编译器
在2025年初,我写了《克劳德是一个编译器吗?》。当时,我的答案是:我不知道。现在我相当确定答案是“不是,这是一个类别错误,它比编译器更好。”但这需要一些 unpacking。计算机程序因其复杂和挑剔而闻名。程序在极高的精度水平上运行。没有“挥舞手”这样的 CPU 指令。与此同时,高级目标深深地定义不清。在高度程式化的世界观中,软件分层构建,每一层都增加规范并隐藏“不必要”的细节。愿景变成战略,产品计划变成编码计划,代码变成二进制。每一步都有不同的角色处理:高管、副总裁、项目经理、架构师、工程师、编译器。关键是,每一步都涉及大量的决策。这就是提高规范化水平的意义所在。(这就是我为雇用工程师设置的两个关键指标之一的原因,判断力。另一个是和谐。)最底层的从源代码到二进制就是编译器所做的。编译器做了很多决策!内联、寄存器分配、是否发出警告或直接拒绝程序。这些决策很重要:它们影响性能、系统稳定性、可预测性和故障模式。编译器工程师的工作是确保编译器做出始终良好的决策。一个好的、值得信赖的编译器使软件工程师不必做这些决策。大多数工程师对编译器的工作原理知之甚少;为了有效,他们不需要了解。到2025年,我们生活在一个使用大型语言模型(LLMs)生成小块代码的世界。在这个思维模型中,编码代理可能作为软件工程师与传统编译器之间的新层。它将自然语言“编译”成代码,做出决策,让工程师不必这样做。它的价值与其可靠性和它可以做出的决策的规模成正比。问题是,这个高度程式化的世界观是错误的。抽象会泄漏,层之间会摩擦。即使没有,我们也会戳破它们。跨层工作是极其有价值的;机械同情至关重要。帝国大厦在不到一年的时间内在预算内建成的部分原因是通过系统地跨层工作。例如,在决定外部铬镍钢外墙时:建筑师、建造者和分包商都觉得自己在没有充分咨询的情况下不能处理这个复杂的技术问题。因此,在全面初步讨论后,召开了一次包含所有相关代表的会议,参加者包括业主、建筑师和建造者、负责材料施工的分包商、负责制造和安装的金属工人以及负责在各种准备阶段测试所有材料的检查员。当你把这说出来时,这听起来确实很明显。然而,我们在实践中系统性地失败于此。我只能想象负责金属工作的工人有机会引导设计走向一个不那么缓慢和痛苦的方向的喜悦。我们失败的部分原因是对值得询问的事情的无知。最好的高管之所以有深厚的行业知识是有原因的。我还怀疑其中一些原因是轻蔑(“一个普通金属工人能告诉我什么?”)。但很大一部分也归结为沟通和组织成本。层次的存在是有原因的——信息隐藏使组织扩展成为可能。克劳德比编译器更好,因为它可以在堆栈中垂直工作。LLMs 现在谈论战略、产品、架构、代码和机器代码。它(还)无法像一个经验丰富、专注的人那样好地完成大多数个体任务,但它可以完成所有任务,而不必安排会议或请求批准。这里有一个具体的例子。exe.dev 的虚拟机有很好的域名:vm-name.exe.xyz。当我们启动一个新的虚拟机时,会添加一个或三个 CNAME 记录。很简单,对吧?但是我们的虚拟机启动很快,因此即使我们在创建虚拟机之前创建DNS记录,我们的用户仍然不得不等待DNS传播,这有时需要几分钟,而不是几秒钟。我们做了显而易见的事情:我们写了自己的 DNS 服务器,使 DNS 始终与事实相符。而且生活很美好。但是延迟很重要,因此我们增加了区域。就这样,DNS 再次成为了长杆,因为所有 DNS 都是在俄勒冈州服务的。此外,部署会导致微小的 DNS 中断。要解决这个问题,现在我们需要的只是在地理上分布而完全一致的 DNS 服务器。当面对一个难题时,一个明智的工程师一般会采取的方式是:作弊。我们调试设计了一个分布式 DNS 服务器,以满足我们的具体需求。目标很明确:减少远离俄勒冈的用户的延迟,增加正常运行时间的弹性。但是其余的则不然。我们必须弄清楚我们想要的确切行为(特别是在各种故障条件下)
本站免费、广告极少。如果觉得有帮助,可以请我们喝杯咖啡 —— 任何金额都对持续运营有实际帮助。
☕请我喝杯咖啡