Claude 不是编译器--它比编译器更好

在2025年初，我写了《Claude 是编译器吗？》：https://commaok.xyz/ai/is-claude-a-compiler/? 当时，我的答案是：我不知道。

我现在很确定答案是“不，那是类别错误，它比编译器更强大。”但这需要一些说明。

计算机程序以复杂和易出错而著称。程序的操作需要极高的精确度。没有“挥手”的CPU指令。与此同时，高级目标往往严重缺乏规范。

在一种高度程式化的世界观中，软件是分层构建的，每一层都增加规范并隐藏“非必要”的细节。愿景变成战略，产品计划变成编码计划，代码变成二进制。每个步骤由不同的角色处理：高管、副总裁、产品经理、架构师、工程师、编译器。

关键是，每一步都涉及大量决策。这就是提高规范程度的意义所在。（这也是我评估工程师的两个关键指标之一是判断力，另一个是礼让。）

最底层，从源代码到二进制，是编译器的工作。编译器做很多决策！如内联、寄存器分配、是否发出警告或直接拒绝程序。这些决策很重要：它们驱动性能、系统稳定性、可预测性以及故障模式。编译器工程师的工作是确保编译器持续做出良好决策。

一个好的、值得信赖的编译器让软件工程师无需自己做这些决策。大多数工程师对编译器的工作原理了解不多；他们不需要了解也能高效工作。

在2025年，我们生活在一个使用大语言模型生成小块代码的世界。在这个思维模型中，编码代理可能作为软件工程师与传统编译器之间的新一层存在。它将自然语言“编译”成代码，做出决策，让工程师无需操心。它的价值与其可靠性及能够做出决策的规模成正比。

问题是，这种高度程式化的世界观是错误的。抽象会泄漏，层与层之间会摩擦：https://www.dbreunig.com/2026/07/03/ai-ecosytem-pace-layers.html。即使没有，我们也会挑出它们的漏洞。

跨层工作极具价值；对机械特性的理解很重要。

帝国大厦建设的一部分方式：https://www.construction-physics.com/p/building-fast-and-slow-the-empire 在不到一年的时间内并且低于预算（!!）完成，是通过系统地跨层工作实现的。例如，在决定外部铬镍钢外壳时：

建筑师、施工方和分包商都觉得自己在没有充分咨询的情况下无法胜任处理这个复杂的施工技术问题。因此，在充分的初步讨论之后，召开了一次全体会议，出席会议的有业主代表、建筑师和施工方、负责滚制材料的分包商、负责制造和安装的金属工人，以及在各个准备阶段对所有钢板进行检测的检查员。

当你大声说出来时，这听起来真是显而易见。

然而，我们在实践中却系统性地未能做到这一点。我只能想象那些金属工人的高兴，他们有机会将设计引导向不慢且不痛苦的工作方式。

我们失败的部分原因是对值得询问的内容一无所知。最顶尖的高管在自己的行业中有深厚知识，这绝非偶然：https://daringfireball.net/linked/2022/10/11/ceos-as-nerds。我也怀疑，部分原因是轻视（“一名普通金属工能告诉我什么？”）。但很大一部分原因还是沟通和组织开销。层级存在是有原因的——信息隐藏使组织可以扩展。

Claude 比编译器更优，因为它可以在堆栈上下垂直工作。大语言模型现在可以讨论策略、产品、架构、代码和机器码。它（还？）不能像有经验、专注的人工一样出色完成大多数具体任务，但它可以完成所有这些任务，而且无需安排会议或征求许可。

exe.dev：http://exe.dev 虚拟机有很好的域名：vm-name.exe.xyz：http://vm-name.exe.xyz。当我们启动新虚拟机时，会添加一条或三条 CNAME 记录。很简单，对吗？

但我们的虚拟机启动非常快，即使在创建虚拟机之前创建了 DNS 记录，用户仍然不得不等待 DNS 传播，有时传播需要几分钟，而不是几秒钟。

我们做了最显而易见的事情：我们写了自己的 DNS 服务器，这样 DNS 总是能立即与信源保持一致。生活因此变得美好。

但延迟很重要：https://blog.exe.dev/regions，所以我们增加了区域。就这样，DNS 又成为了瓶颈，因为所有 DNS 都由俄勒冈提供服务。此外，部署会导致小规模的 DNS 中断。为了解决这个问题，我们现在需要的是一个地理分布但完全一致的 DNS 服务器。

面对困难问题时，我们采取了一个理智工程师会做的选择：作弊。我们根据自身特定需求精心设计了一个分布式 DNS 服务器。

目标很明确：降低远离俄勒冈的用户的延迟，并提高正常运行时间的韧性。但其他方面并不明确。我们必须弄清楚从我们想要的具体行为（尤其是在各种故障情况下）、它如何融入公司整体计划，到能够最好实现这些目标的架构，一直到具体实现的细节。

我们当面讨论了最高层的战略和架构决策。我们准备制作一个相当通用的 DNS 服务器，并在其上叠加我们特定的行为调整，采用辐射型模型，使用只追加复制策略，并在边缘进行持久化。

剩下的就是实际构建它。

我让大型语言模型研究分布式 DNS 系统的标准设计，讲解 DNS 的内部工作和怪癖，指出历史上的安全漏洞，探索替代实现策略（AXFR/IXFR？不，谢谢），研究开源方案，模拟故障模式，并制定测试策略。

一旦我有了一个看起来有希望的初步设计草图，我就让多个并行的代理循环去构建整个系统，包括测试和对抗性代码审查。他们提出了许多问题——从主要结构方法到代码行级的细节层面。当我回答这些问题（或撤回那些让我后悔的答案）时，我慢慢将所学转化为非常简洁的书面指导，将被证明重要的决策进行编码。

然后我让新的代理比较已完成的实现，并寻找有趣的偏差。令人震惊的是，有多少重要的决策是代理从未询问过的，而是直接做出——而且做法各不相同。

这里有一个例子。复制使用了相当明显的方法：通过请求自上次已知条目以来的所有内容来赶上进度，然后长轮询以获取新条目。有一个棘手的问题：数据库回滚。虽然罕见，但确实会发生，而且会破坏“只追加”合同。

代理注意到了这一点，并以截然不同的方式解决了它。我最终采用的设计是给每一行一个“时间线”字段，意思是“你生活在哪条时间线上？”这些时间线是随机生成的，每个“自第 N 行以来的条目”同步请求都包括边缘服务器的第 N 行时间线值。如果时间线不匹配，我们就知道历史已被更改，并回退到完全干净的重新同步。

不同代理构建的系统之间也存在明显的风格差异。Claude 和 Codex 都认为 Claude 创建的系统更优雅，但 Codex 更彻底。

我梳理了主要发现的分歧列表，进行了实验，然后添加了更多书面指导。

然后我重复了整个差异规范分析：https://commaok.xyz/ai/differential-spec/ 过程，两次。我了解我的格言：https://en.wikipedia.org/wiki/Second_system_effect。

计划放弃一个，你无论如何都会放弃。

如果你计划放弃一个，你将放弃两个。

等我准备构建一个正式系统时，我已经积累了一份疤痕文档，从经验上足以指导代理完成大多数重要决策，在每一层次上，从高层目标到架构，再到偶尔的低级细节，比如承载并发缓存的数据类型的确切形状。

最终系统包括单元测试、端到端测试、用于降低生产风险的影子模式，以及简明的为代理编写的文档套件。

这一切总共花了我大约一周的时间。我阅读了极少量的实际代码。

在那之后，我向团队展示了解决方案。我计划上线服务器，然后去度假。当同事们向我提问——“X 是怎么工作的？在 Y 条件下会发生什么？”——我发现自己能够自信地回答所有问题。（而我确实去度假了。一个月后的 DNS 事件数量：0。）

Claude 在这里不仅仅是一个编译器。我从未把任务交给一个代理，让它做一堆决策以付诸实践。那是氛围编码（vibe-coding）。

相反，Claude 是一个垂直整合的资源，一个多编译器。它跨堆栈工作的能力加速并增强了我在不同层次上做出一系列决策的能力，包括哪些决策重要的判断。（大多数单独的代码行达不到那个标准。）那是氛围工程（vibe-engineering）。

我想说，在所有重要方面，我理解这段代码。当然，如果我现在不得不手动编辑它，会有一个严重的学习曲线。但我不必那样做。更重要的是，我可以推理系统，与同事分享观点，并指导代理进行未来的工作。而且还有一个持久的产物，它概括了设计中重要到值得记录的核心意图要素，覆盖所有层，因而应该能够在修复 bug 和代码变动中存续。

这个时代的一个问题是：软件工程师需要理解他们所工作的系统的哪些内容？

精心选择的层次提供理解。基本物理定律看似无所不包，但在解释为什么在事故中坐公交比开车更好时，它们不如经典力学。

有些软件层正在消亡，因为它们提供便利，但没有额外洞察力。（抱歉，Tailwind。我曾爱过你。）但能够让我们以可理解的方式表达重要决策的软件层？那些会留下。

我们正在将更多注意力转向堆栈上层，但并没有完全放弃下层。代理并不是让我们放弃对系统更深层理解的免费通行证。Go 标准库的大部分是用 Go 写的，但少数关键例程是用汇编写的。在那里你不能依赖编译器。

软件工程师正被拉得很紧。这既令人振奋又令人筋疲力尽。不过，越来越明显的是，在不久的将来，‘氛围工程’只是……工程。

In early 2025, I wrote Is Claude a Compiler：https://commaok.xyz/ai/is-claude-a-compiler/? At the time, my answer was: I don’t know.

I’m now pretty sure the answer is “no, that’s a category error, it’s better than a compiler.” But this requires a bit of unpacking.

Computer programs are notoriously intricate and finicky. A program operates at an extreme level of precision. There is no “wave hands” CPU instruction. High-level goals, meanwhile, are deeply underspecified.

In a highly stylized view of the world, software gets built in layers, each one adding specification and hiding “unnecessary” detail. Vision becomes strategy, product plans become coding plans, code becomes binaries. Each step is handled by a different role: executive, VP, PM, architect, engineer, compiler.

Critically, every step involves making lots of decisions. That’s what it means to increase the level of specification. (This is why one of my two key metrics for hiring engineers is judgment. The other is comity.)

The bottom layer, from source code to binary, is what a compiler does. Compilers make lots of decisions! Inlining, register allocation, whether to emit warnings or reject a program outright. And these decisions matter: They drive performance, system stability, predictability, and failure modes. A compiler engineer’s job is to arrange for the compiler to make consistently good decisions.

A good, trusted compiler frees a software engineer from having to make these decisions. Most engineers have little idea how compilers work; they don’t need to in order to be effective.

In 2025, we operated in a world where we used LLMs to generate smallish chunks of code. In this mental model, a coding agent might slot in as a new layer between a software engineer and a traditional compiler. It “compiles” natural language to code, making decisions so the engineer doesn’t have to. Its value is proportional to its reliability and the scale of the decisions it can make.

The thing is, this highly stylized view of the world is false. Abstractions leak and layers rub：https://www.dbreunig.com/2026/07/03/ai-ecosytem-pace-layers.html. And even if they didn’t, we’d poke holes in them anyway.

Working across layers is extremely valuable; mechanical sympathy matters.

Part of how the Empire State Building was constructed：https://www.construction-physics.com/p/building-fast-and-slow-the-empire in under a year and under budget (!!) was by systematically working across layers. For example, when deciding about the exterior chrome-nickel steel cladding:

Neither architects, builders nor subcontractors felt competent to deal with this complicated technical problem of construction without full consultation. Accordingly, after full preliminary discussion, an all-inclusive meeting was called which was attended by representatives of the owner, the architects and builders, the subcontractors rolling the material, the metal workers who were to fabricate and those who were to erect it, and the inspectors who were to test all sheets at the several stages of preparation.

This sounds really obvious when you say it out loud.

And yet we systematically fail at this in practice. I can only imagine the delight of the metal workers who had an opportunity to guide the design toward something that wasn’t slow and miserable to work on.

Part of the reason we fail is ignorance of what is even worth asking about. There’s a reason that the best executives have deep knowledge of their industry：https://daringfireball.net/linked/2022/10/11/ceos-as-nerds. I also suspect that some of it is dismissiveness (“What could a line metalworker have to tell me ?”). But a big chunk is also communication and organizational overhead. Layers exist for a reason—information hiding enables organizational scaling.

Claude is better than a compiler because it can work vertically across the stack. LLMs now talk strategy, product, architecture, code, and machine code. It can’t (yet?) do most individual tasks as well as an experienced, dedicated human, but it can do all of them, without having to schedule meetings or ask permission.

exe.dev：http://exe.dev VMs have nice domain names: vm-name.exe.xyz：http://vm-name.exe.xyz. When we start a new VM, we add a CNAME entry or three. Easy, right?

But our VMs start fast, so fast that even if we created the DNS entries before creating the VM, our users still had to sit around waiting for DNS to propagate, which occasionally took minutes, not seconds.

We did the obvious thing: We wrote our own DNS server, so that DNS always immediately matched the source of truth. And life was good.

But latency matters：https://blog.exe.dev/regions, so we added regions. And just like that, DNS became the long pole again, because all DNS was served out of Oregon. Also, deployments caused tiny DNS outages. To fix this, all we needed now was a geographically distributed but fully consistent DNS server.

We did what a sensible engineer does when faced with a hard problem: cheat. We vibe-engineered a distributed DNS server tuned to our specific needs.

The goals were clear: Reduce latency for users far from Oregon and increase uptime resiliency. But the rest was not. We had to figure out everything from the exact behavior we wanted (particularly under various failure conditions), to how it fit into our overall company plans, to the architecture that could best achieve those goals, straight through down to the fine implementation details.

We hashed out the highest level strategic and architectural decisions in person. We’d make a fairly general-purpose DNS server and layer on our particular behavioral tweaks, use a hub-and-spoke model, use an append-only replication strategy, and have persistence at the edges.

All that was left was to actually build it.

I had LLMs research standard designs for distributed DNS systems, teach me about the guts and quirks of DNS, point out historic security failings, explore alternative implementation strategies (AXFR/IXFR? no thanks), research open source offerings, game out failure modes, and plan testing strategies.

Once I had an initial sketch of a design that seemed promising, I prompted multiple concurrent agent loops into building the entire thing , including tests and adversarial code review. They raised a bunch of questions—at every level of detail, from major structural approaches down to line-level code concerns. As I answered them (or reverted answers that generated regret), I slowly converted what I had learned into very terse written guidance, codifying decisions that proved to be important.

Then I asked new agents to compare the completed implementations and look for interesting deviations. It was shocking how many important decisions the agents never asked about but simply made—and made differently.

Here’s an example. Replication uses the fairly obvious approach: Catch up by asking for everything since the last known entry, and then long poll for new entries. There’s one ugly twist: database rollbacks. Rare, but they do happen, and they break the “append-only” contract.

The agents noticed this, and they solved it in wildly different ways. The design I ultimately settled on was to give every row a “timeline” field, as in “which timeline are you living in?” These are randomly generated, and every sync request for “entries since row N” includes the edge server’s timeline value for row N. If there’s a timeline mismatch, we know that history has been altered and fall back to a full clean re-sync.

There were also obvious style differences between the systems built by different agents. Claude and Codex both agreed that Claude created a more elegant system but that Codex was more thorough.

I worked through the list of major identified divergences, experimented, and then added more written guidance.

Then I repeated that entire differential spec analysis：https://commaok.xyz/ai/differential-spec/ process, twice. I know my aphorisms：https://en.wikipedia.org/wiki/Second-system_effect.

Plan to throw one away; you will, anyhow.

If you plan to throw one away, you will throw away two.

By the time I was ready to build a keeper, I had accumulated a scar-tissue document that was empirically sufficient to guide an agent through most of the important decisions, at every layer, ranging from high level goals through architecture down to the occasional low level detail, such as the exact shape of the data type for load-bearing concurrent caches.

The final system included unit tests, end-to-end tests, a shadow-mode for de-risking prod rollout, and a terse written-by-and-for-agents doc suite.

This cumulatively took about a week of my attention. I read a vanishingly small amount of the actual code.

At the end of that, I presented the solution to the team. I planned to launch the server and then go on vacation. As my colleagues peppered me with questions—"How does X work? What happens in condition Y?"—I found I could answer all of them confidently. (And I did go on that vacation. Number of DNS incidents a month later: 0.)

Claude wasn’t just a compiler here. I never handed off a task and let an agent make a bunch of decisions in order to reduce it to practice. That’s vibe-coding.

Rather, Claude was a vertically integrated resource, a multi-compiler. Its ability to work across the stack accelerated and augmented my ability to make a bunch of decisions at different levels, including about which decisions were important. (Most individual lines of code don’t make that cut.) That’s vibe-engineering.

I’d say that, in all the ways that matter, I understand the code. Sure, if I had to hand-edit it now, there’d be a serious learning curve. But I won't have to. And more importantly, I can reason about the system, share perspectives with my colleagues, and guide agents on future work. And there’s an enduring artifact that encapsulates the central, intentional aspects of the design that were important enough to record, across all layers, and should thus survive bug fixes and code churn.

One of the questions of this era is: What do software engineers need to understand about the systems they work on?

Well-chosen layers provide understanding . Fundamental laws of physics appear all-encompassing, but they’re inferior to classical mechanics for explaining why it’s better to be in a bus than a car in an accident.

Some software layers are dying, because they provide convenience, but not extra insight. (Sorry, Tailwind. I loved you.) But software layers that enable us to express important decisions in a comprehensible way? Those will stay.

We are shifting more of our attention up the stack, but without fully relinquishing the lower layers. Agents are not a free pass to hand off all understanding of the deeper layers of a system. Most of the Go standard library is written in Go, but a few key routines are written in assembly. You can’t rely on the compiler there.

Software engineers are being stretched. It’s exhilarating and exhausting. What’s becoming clear, though, is that in the near future, vibe-engineering is just…engineering.