2026 年 9 月，奥斯汀，Rails World 大会。Ruby on Rails 的作者 DHH（David Heinemeier Hansson）在开场演讲里问台下：谁每周还在大量手写代码？据他说，举手的大约只有五个人。

他自己已经好几个月没手写代码了。他的公司 37signals（做 Basecamp 和 HEY 邮箱的那家）刚刚决定“放下铅笔”：从此手写代码算异常情况，就像监控里冒出一条报错，要回头查哪里出了问题。

然后他说，他发现了一门比 Ruby 更好的编程语言：

他也承认，英语更含糊一点，结果也没那么确定。可他说，用英语写程序是一种纯粹的享受。

这话从 DHH 嘴里说出来，分量不一样。Rails 是靠 Ruby 的优雅起家的，他爱 Ruby 是出了名的。

再往前推四十一年。1985 年，MIT 的 Abelson 和 Sussman 出了一本书，叫《计算机程序的构造和解释》，大家简称 SICP。第一版序言里有一句很有名的话，大意是：程序首先是写给人读的，能在机器上跑只是顺带。整本书讲一件事：怎样用抽象驯服复杂。

DHH 在同一场演讲里说，到了 agent 的时代，抽象不再那么说得通了。如果他是对的，SICP 就该进博物馆了。

我的看法是：DHH 说对了一半。要分清是哪一半，得请三个角色出场：一位画家、两个钟表匠、一个巫师。

DHH 的演讲是从一幅画讲起的。

1883 年到 1886 年，丹麦画家 Laurits Tuxen 给国王克里斯蒂安九世一家画了一幅大型群像，前后画了三年。这幅画今天挂在哥本哈根的克里斯蒂安堡宫。据 DHH 说，Tuxen 是他的高祖父。

1900 年 2 月，柯达推出布朗尼相机，一台一美元。给普通人留影，突然便宜到谁都付得起。DHH 的说法是：从那以后，把人画得逼真不再是一门好生意，画家们只好另找出路。

DHH 把 2025 年 11 月一个编程模型的发布，比作程序员的布朗尼相机。从那以后 37signals 发生的事，他在台上列了一长串。下面都是据他说：

以前小团队养不起六个平台的原生代码，只好做网页版，现在养得起了。他讨厌 Rust 的长相，可代码既然不用他看，也就无所谓了。今年 8 月他“写”了 15 万行代码，大部分是他从来不看的 Rust。

Ruby 的作者松本行弘（Matz）在另一场对谈里开了个玩笑：他早就是 vibe coder 了，一当就是十五年。身为 Ruby 的掌门人，他提需求，核心提交者写代码，他来审、来合并。现在不过是把“有机智能”换成了 agent。

这些都是实打实的变化，不是噱头。下一节，我先替 DHH 把道理讲足。

程序员有很多规矩，听上去像真理，其实是价格。

小团队为什么做网页、不做原生？因为六套原生代码要六拨人维护，养不起。为什么用 Ruby、不用 Rust？因为程序员的一小时比机器的一小时贵得多，宁可机器多跑，也要人少写。软件为什么越做越臃肿？因为花工程师的时间去抠体积，不划算。

这些规矩付的都是钱账。人工贵、机器便宜，账就这么算。agent 把写代码的人工降了几个数量级，账就得重算。DHH 让 agent 写了一个做演示文稿的软件，二进制只有半兆。以前没人肯为这半兆付工钱。

还有一类规矩付的是组织账。1968 年，Melvin Conway 观察到：一个系统的结构，会照着设计它的组织的沟通结构长。后来大家管这叫康威定律。很多模块边界，其实是团队边界。团队变成一个人加一千个 agent，边界自然要重画。DHH 说，成千上万个 agent 同时改一个应用，抽象会变成卡脖子的点。按康威定律，这话说得通。

第三类付的是人脑账。人的工作记忆只装得下几样东西，所以函数要短，名字要好，一屏要看得完。对谈里 DHH 说得更狠：过去六十年的软件工程，都是在应付人类认知的局限，局限没了，这些办法也就不需要了。

这三类，我大体同意。问题出在最后一步：是不是所有规矩，付的都只是这三本账？

我想加上第四本：数学账。

数学账和前三本不一样，它约束任何会出错、算力有限的推理者。人是这样，agent 也是这样。

判断工具就一句话：听到“某某在 AI 时代过时了”，先问这条规矩付的是哪本账。付前三本账的，确实可能过时；付第四本账的，换谁来写代码都躲不掉。

拿 DHH 最激进的那句来试。他说，抽象的理由之一是不重复；现在重复几乎免费，保持同步也一样便宜。

“不重复”付的是哪本账？少打字是钱账，这一半他说对了。可重复之后还有一笔账：同一件事存在一千个地方，改的时候要改对一千次。这笔是数学账。

下面请钟表匠出场。

这一部分有五条定理，每条都附证明。证明可以跳过，看懂结论和图就够了。

1962 年，Herbert Simon 写了一篇文章，叫《复杂性的架构》。他后来拿了图灵奖，又拿了诺贝尔经济学奖。文章里有一个寓言。

两个钟表匠，Hora 和 Tempus，做的表都有一千个零件。两人手艺一样好，生意一样好，电话也一样多。每接一个电话，手里没装完的东西就散了。

Tempus 一个零件一个零件往上装，一接电话就前功尽弃。Hora 先把十个零件装成一个小组件，十个小组件装成一个大组件，十个大组件装成一只表。一接电话，他只丢掉手上那一个组件。

Simon 设每装一个零件，都有 1% 的可能被电话打断。两人的差距有多大？他自己粗估了一下，Tempus 花的时间大约是 Hora 的 4000 倍。下面用一条定理把它算准。

代进数字。Tempus 要一口气做完 1000 步，期望 T(1000) ≈ 231.6 万 步。Hora 要装 111 个组件（100 个小的、10 个大的、1 只表），每个 10 步，一共 111 × T(10) ≈ 1,174 步。Tempus 花的步数是 Hora 的 1,974 倍。比 Simon 的粗估小一半，是因为他用的是粗略的估算办法；Simon 自己也说，这个数不必太当真。差了三个数量级，这一点不变。

Simon 用这个寓言解释，为什么自然界的复杂系统几乎都是分层的：原子、分子、细胞、器官。原因不是造物主的“脑子”不够用，而是有了稳定的中间形态，复杂的东西才造得出来、留得下来。

注意，这里没有人脑什么事。Tempus 和 Hora 一样聪明，记性一样好。差别只来自一件事：会被打断，打断会丢掉进度。agent 也会出错。

这条推论正面回答了 DHH。agent 越来越可靠，p 越来越小，最优模块就越来越大：

出错率从 1% 降到 0.01%，可靠性提高 100 倍，最优模块从 14 步变成 142 步，粗了 10 倍。抽象会变粗，不会消失。要让不分层成为最优，整件活得小到只有两个模块那么大。精确地算，出错率 1% 时，只分一层就比不分层省事的分界，在 27 步左右。一个真实的软件系统，离这个条件差得远。

当然，这是玩具模型。真实的错误不独立，也不一定让人从头来过；“一步”在代码里也没有明确的单位。但它抓住了一件实在的事：稳定的中间形态值多少钱，取决于出错率和活有多长，和干活的是人还是机器无关。

DHH 自己讲过一个例子。2026 年春天，37signals 让几位设计师用 vibe coding 给 Basecamp 5 补最后几个功能。据他说，每个 PR 单看都像样，二三十个合起来，架构像一块瑞士奶酪，到处是洞。他事后的结论是：当时的判断错了，再等几个月，模型更强，就没事了。

模型更强，p 确实会变小。可瑞士奶酪的毛病不在哪一步做错了，而在二三十步之间，没有一个稳定的中间形态把它们拢在一起。Hora 的组件，就是这个中间形态。

回到 DHH 那句：重复免费了，同步也便宜了。

设想有一条规则，比如“会员价打八折”，被写在 n 个地方。每次改价，agent 要把这 n 处全改对。它很可靠，每一处改对的概率都是 r。

r = 99.9%，已经比大多数人细心了。n = 1000 时，全部改对的概率只有 36.8%；n = 5000 时，只剩 0.67%。

关键是乘积 n(1 − r)。“同步便宜”把 1 − r 变小，“重复免费”把 n 变大。只要 n 涨得比可靠性快，全对的概率照样往零掉。只存一份，这个问题就不存在了：一致性不再是靠细心维持的概率事件，而是结构保证的必然。

数据库领域五十多年前就想明白了这件事。1970 年，IBM 的 Codd 提出关系模型，后来发展出“范式”：同一个事实只存一处，免得改了这里、忘了那里。数据库里执行更新的本来就是机器，机器很可靠，数据库照样讲范式。工程上也常故意冗余存几份，换查询速度，可那是明码标价的取舍：多出来的同步，得有专门的机制负责。

DHH 说的另一半，也碰到了数学账。他说成千上万个 agent 同时改一个应用，抽象会成为卡脖子的点。卡脖子的点为什么存在？SICP 第 3 章专门讲过。

两个各 10 步的进程，就有 184,756 种交错；各 50 步，约 1.0 × 10²⁹ 种。每一种都可能算出不同的结果。SICP 3.4 节有一道习题（习题 3.38）：账户里原有 100 美元，Peter 存 10 美元，Paul 取 20 美元，Mary 取走一半。三人依次办，余额可能是 35、40、45、50；三人同时办、步骤交错，还会冒出别的数。

锁、队列、只能从一个口子进出的模块，都是把交错压回一种顺序的办法。它们确实拖慢并行，这一点 DHH 说得对。可拆掉以后，要验证的就不是一条路，而是天文数字条路。这同样不是人脑的问题，agent 也得面对这些路。

DHH 还说，Rust 他一行不看，只把它当黑箱，从外面验收，就像历史上所有花钱请程序员干活的老板。

这话没错。可是从外面验收，能验到什么程度？

先看测试。测试只能试有限个输入，而任何有限的测试，都有无穷多个程序能全部通过，它们在测试之外的行为各不相同。Dijkstra 在 1969 年说过一句很有名的话，大意是：测试能证明有 bug，不能证明没有 bug。

那就打开黑箱看代码，或者再请一个 agent 来审呢？SICP 第 4 章写完一个解释器以后，留了一道习题，让读者自己证明：不可能写出一个通用的程序，判断任意程序会不会停下来。

这个结论的源头是图灵 1936 年的论文，“停机问题”这个名字是 1950 年代才有的。SICP 把它放成第 4 章的一道习题，用 Scheme 写五行就够了。

1953 年，Henry Rice 把它推到了头。

“不会泄露用户数据”“余额永远算对”“和旧系统行为一致”，都是行为上的非平凡性质。没有哪个审查者，人也好，agent 也好，能对任意代码判定它们。这个约束对谁都一样，人脑也逃不出 Rice 定理，这不是比谁更聪明的问题。

那软件是怎么做对的？靠不让代码“任意”。我们事先放进结构：类型、接口、规格、可以对照的标准答案。具体的程序常常是查得了的，难的只是“任意”的程序。讲机器证明的那一篇说过类似的事：判定一个命题难，检查一份证明容易。结构，就是程序随身带的证明。

DHH 身边就有一个好例子。Rails 社区的 Sam Ruby 今年做了一个项目，叫 Roundhouse：把一个 Rails 应用当成规格，编译成十来种语言的版本。怎么知道翻译对了？同一个网址，在原来的 Rails 和新版本上各请求一次，返回的页面要一个节点一个节点地对上。原来的应用，就是判据。

Sam Ruby 在回应 DHH 的文章里说，有了 agent，严谨并没有消失，它搬到了上游的规格和下游的测试里。我同意。黑箱可以不看，判据不能没有。

现在可以回答标题里的问题了：英语是最好的编程语言吗？

先讲控制论里的一条定律。1956 年，Ross Ashby 提出“必要多样性定律”：要把结果控制在你想要的范围里，调节者手上的多样性，至少要抵得上外界干扰的多样性。他的说法大意是，只有多样性能对付多样性。下面这条，是它在信息论里最简单的一个版本。

一个应用里，你在乎的区别成千上万：按钮放在哪，钱怎么四舍五入，出错时提示什么，删除能不能撤销。设其中有 u 个，你没写，约定也没覆盖，模型只能凭经验猜。每猜一个，和你想的一样的概率是 a，那么全部猜中的概率是 a^u。又是一个指数。

这条定理能解释好几件事。

第一，DHH 说，Rails 的“约定优于配置”直接带来了 token 效率。约定，就是双方事先说好的那部分比特：表名怎么对应类名，网址怎么对应控制器。说好了，就不用写，也不会猜错。vibe coding 也在用先验，只不过是没说好的先验。

第二，Matz 在对谈里说，很多人 vibe coding 一碰真实应用就失败，Ruby 核心团队的人试下来，成功率却高得出奇。他的解释是：老手知道怎么给 agent 定目标。用比特守恒的话说，老手知道哪些区别要紧，就把那几个比特亲手写下来。

第三，英语。英语的表达力确实最强，因为它背后有人类共享的巨大先验，一句话能调动很多比特。可这份先验，模型和你并不完全共享。DHH 承认英语更含糊，含糊的地方，就是 u。

所以我的回答是：英语是最好的前端语言，不是最好的事实来源。用英语说清你要什么，再好不过。可事实来源要有一套事先说好的语义，规定每一句话是什么意思。这正是编程语言的本分，也是 SICP 最关心的事。

Dijkstra 在 1978 年写过一篇短文，专门批评“用自然语言编程”。大意是：形式记号窄，正是它的好处，它逼你把话说死；自然语言让你说得轻松，也让你轻易说错。

SICP 的外号叫“巫师书”，因为封面上画着一个巫师，手里捧着一个球，球上写着 eval 和 apply，那是解释器的两个核心过程。这个外号很贴切，整本书都在教你造咒语，也就是造语言。

回头看 DHH 的做法，会发现一件有意思的事：他嘴上说抽象过时了，手上处处是抽象。

抽象没有消失，它搬了家：从代码里面，搬到了盒子之间。以前的抽象是函数、类和模块；现在是黑箱的边界、给 agent 用的接口、用英语或 Rails 写下的规格，以及判断对错的判据。推论 1.1 说模块会变粗，这里看到的就是变粗了的模块。

SICP 1.1 节开头说，每一门强大的语言都有三样东西：基本元素，组合的手段，抽象的手段。放到今天，这三样在新的一层又出现了一遍。基本元素是一个个由 agent 完成的任务；组合的手段，是怎样把这些任务编排起来；抽象的手段，是给一堆任务划边界、起名字、定判据。

SICP 第 4 章讲“元语言抽象”。对付复杂问题，一个强大的办法是造一门新语言；而决定这门语言里每句话什么意思的求值器，本身也只是一个程序。Rails 就是一门藏在 Ruby 里的小语言。DHH 说英语是更好的编程语言，问的其实也是第 4 章的问题：这门语言的求值器是谁？它的语义写在哪里？

英语的求值器是一个模型，语义是模型的先验。Roundhouse 的做法，是给这个求值器配一份标准答案：用 Rails 写下说好的语义，让模型的翻译去对答案。

这正是书名里的两个词。Structure，是那份事先说好的结构；Interpretation，是同一份结构的多种解释：给人读的，给机器跑的，换成另一种语言的。

MIT 用 SICP 开的入门课 6.001，2007 年秋天上完了最后一个学期。2009 年，Sussman 在国际 Lisp 大会上解释过为什么换课。据 Andy Wingo 的转述，他的意思是：1980 年的工程师，用自己完全理解的小零件搭系统；如今的工程师，得对着文档不全的库做实验，看它怎么反应。

DHH 的黑箱是这条路的尽头：连自己项目里的代码，也只从外面试。照这个趋势，SICP 似乎更没用了。

用四本账再看一遍，结论就不同了。SICP 里有些东西付的是人脑账：亲手写出每一个过程，熟练掌握 Scheme 的写法。这些会贬值，可以交给 agent。另一些付的是数学账，反而更值钱了。

读法也要变。以前做习题是为了练手；今天可以让 agent 帮你写，但写之前先自己预测它会输出什么，写完再让它给你举反例。把 agent 当助教，别当代笔。

Matz 在对谈里说，老手为什么能把 vibe coding 用好，这种本事得想办法形式化，教给下一代。SICP 就是四十年前的一次尝试：把老手心里知道、嘴上说不清的东西，写成一本书。

DHH 的演讲里，我最喜欢的是一张老照片。Tuxen 画了一辈子肖像，晚年坐到相机前，让新技术给自己留了影。

后来我查到一个细节。Tuxen 画那幅王室群像，本来就是照着照片和分组写生拼出来的。相机没有先抢走他的活，而是先成了他的工具：照片管逼真，构图和取舍归他。

照相术到底怎样影响了十九世纪的绘画，艺术史家至今还在争，这里不展开。至少在 Tuxen 身上，相机拿走的是逼真这门苦工，没拿走画家的眼睛。

agent 拿走的，是敲代码这门苦工。没拿走的，是钟表匠的分层，是只存一份的事实，是事先说好的语义和判据。SICP 一直讲的是后面这些。只是它用 Scheme 来讲，我们以前误以为它在教 Scheme。

“相机拿走了逼真，没拿走眼睛。
agent 拿走了打字，没拿走结构。

September 2026, Austin, the Rails World conference. In his opening keynote, DHH (David Heinemeier Hansson), the creator of Ruby on Rails, asked the audience: who here still writes a lot of code by hand every week? By his account, only about five people raised their hands.

He himself had not written code by hand for months. His company, 37signals (the people behind Basecamp and the HEY email service), had just decided to “put down the pencil”: from now on, writing code by hand counts as an anomaly, like an error popping up in monitoring, something to trace back to find out what went wrong.

Then he said he had found a programming language better than Ruby:

He admitted that English is a bit vaguer, and its results less deterministic. But writing programs in English, he said, is a pure joy.

Coming from DHH, this carries extra weight. Rails was built on the elegance of Ruby, and his love of Ruby is famous.

Now go back forty-one years. In 1985, Abelson and Sussman of MIT published a book called Structure and Interpretation of Computer Programs, SICP for short. The preface to the first edition contains a famous line: “programs must be written for people to read, and only incidentally for machines to execute.” The whole book is about one thing: how to tame complexity with abstraction.

In the same keynote, DHH said that in the age of agents, abstraction no longer makes as much sense. If he is right, SICP belongs in a museum.

My view is that DHH is half right. To tell which half, we need three roles to take the stage: a painter, two watchmakers, and a wizard.

DHH's keynote began with a painting.

From 1883 to 1886, the Danish painter Laurits Tuxen worked on a large group portrait of King Christian IX and his family, three years in all. Today it hangs in Christiansborg Palace in Copenhagen. According to DHH, Tuxen was his great-great-grandfather.

In February 1900, Kodak launched the Brownie camera, at one dollar apiece. Capturing an ordinary person's likeness suddenly became something anyone could afford. As DHH tells it, from then on painting people true to life was no longer a good business, and painters had to find another way to make a living.

DHH compared the release of a coding model in November 2025 to the programmer's Brownie camera. On stage he reeled off a long list of what has happened at 37signals since then. All of what follows is by his account:

A small team used to be unable to afford native code for six platforms, so it settled for the web; now it can afford it. He hates the way Rust looks, but since he doesn't have to look at the code, that no longer matters. This August he “wrote” 150,000 lines of code, most of it Rust he has never read.

In a separate conversation, Yukihiro Matsumoto (Matz), the creator of Ruby, joked that he has been a vibe coder for fifteen years already. As the head of the Ruby project, he says what he wants, the core committers write the code, and he reviews and merges it. All that has changed is that the “organic intelligence” has been swapped for agents.

These are real changes, not gimmicks. In the next section, I'll make DHH's case as strongly as I can.

Programmers live by many rules that sound like truths but are really prices.

Why does a small team build for the web rather than native? Because six native codebases need six crews to maintain them, and it can't afford that. Why use Ruby rather than Rust? Because an hour of a programmer's time costs far more than an hour of a machine's, so it is better to let the machine run longer and have people write less. Why does software keep getting more bloated? Because spending engineers' time on trimming it down isn't worth the cost.

Every one of these rules is charged to the money ledger. Labor is expensive and machines are cheap, so that is how the sums come out. Agents have cut the labor cost of writing code by orders of magnitude, so the sums have to be redone. DHH had an agent write an app for making presentations, and its binary is only half a megabyte. In the past, nobody would have paid the wages to save that half megabyte.

Another class of rules is charged to the organization ledger. In 1968, Melvin Conway observed that the structure of a system grows to mirror the communication structure of the organization that designs it. This later became known as Conway's law. Many module boundaries are really team boundaries. When a team turns into one person plus a thousand agents, the boundaries naturally have to be redrawn. DHH says that when thousands of agents are changing one application at once, abstractions become choke points. By Conway's law, that makes sense.

The third class is charged to the brain ledger. Human working memory holds only a few things at a time, so functions should be short, names should be good, and code should fit on one screen. In the conversation, DHH went further: the past sixty years of software engineering have all been about coping with the limits of human cognition, and once those limits are gone, these methods are no longer needed.

On these three, I broadly agree. The trouble comes at the last step: are all rules charged only to these three ledgers?

I want to add a fourth: the math ledger.

The math ledger is different from the other three: it constrains any reasoner that makes mistakes and has limited computing power. That holds for people, and it holds for agents.

The test fits in one sentence: when you hear that something “is obsolete in the age of AI,” first ask which ledger the rule is charged to. Rules charged to the first three may well become obsolete; rules charged to the fourth can't be escaped, no matter who writes the code.

Let's try it on DHH's most radical claim. He said one reason for abstraction is to avoid repetition; now repetition is almost free, and keeping the copies in sync is just as cheap.

Which ledger is “don't repeat yourself” charged to? Typing less is the money ledger, and on that half he is right. But repetition leaves another entry on the books: when the same thing lives in a thousand places, every change has to be made correctly a thousand times. That entry belongs to the math ledger.

Enter the watchmakers.

This part has five theorems, each with a proof. You can skip the proofs; the statements and the figures are enough.

In 1962, Herbert Simon wrote a paper called “The Architecture of Complexity.” He later won the Turing Award, and then the Nobel Prize in economics. The paper contains a parable.

Two watchmakers, Hora and Tempus, make watches with a thousand parts each. They are equally skilled, equally successful, and get equally many phone calls. Every time a call comes in, whatever unfinished piece is in their hands falls apart.

Tempus builds a watch one part at a time, and every call wipes out all his work. Hora first assembles ten parts into a small component, ten small components into a large component, and ten large components into a watch. When a call comes in, he loses only the component in his hands.

Simon supposed that each time a part is added, there is a 1% chance that a call interrupts. How big is the gap between the two? His own rough estimate was that Tempus takes about 4,000 times as long as Hora. Below, a theorem pins it down exactly.

Now plug in the numbers. Tempus has to do 1,000 steps in one go, which takes T(1000) ≈ 2.316 million steps in expectation. Hora has to assemble 111 components (100 small ones, 10 large ones, and the watch itself), 10 steps each, for a total of 111 × T(10) ≈ 1,174 steps. Tempus takes 1,974 times as many steps as Hora. That is about half of Simon's figure, because he used a rough method of estimation; Simon himself said the number shouldn't be taken too seriously. The gap of three orders of magnitude stands.

Simon used this parable to explain why nearly all complex systems in nature are hierarchical: atoms, molecules, cells, organs. The reason is not that the Creator's “brain” isn't big enough, but that complex things can only be built, and only last, when there are stable intermediate forms.

Notice that the human brain plays no part here. Tempus and Hora are equally clever and have equally good memories. The difference comes from one thing only: they get interrupted, and an interruption loses progress. Agents make mistakes too.

This corollary answers DHH head-on. As agents get more reliable, p gets smaller, and the optimal module gets larger:

Cut the error rate from 1% to 0.01%, making agents 100 times more reliable, and the optimal module grows from 14 steps to 142, ten times coarser. Abstraction gets coarser; it doesn't disappear. For no layering to be optimal, the whole job has to be as small as two modules. Computed exactly, at a 1% error rate, the point beyond which even a single layer of components beats no layering is around 27 steps. A real software system is nowhere near that small.

Of course, this is a toy model. Real errors aren't independent, and they don't always send you back to the start; nor is there a clear unit for a “step” in code. But the model captures something real: what a stable intermediate form is worth depends on the error rate and on how long the job is, not on whether a person or a machine does the work.

DHH told a story of his own. In the spring of 2026, 37signals had a few designers use vibe coding to add the last few features to Basecamp 5. By his account, every PR looked fine on its own, but put twenty or thirty of them together and the architecture looked like Swiss cheese, full of holes. His conclusion afterward: it had been the wrong call at the time; wait a few more months for stronger models, and it would be fine.

Stronger models will indeed make p smaller. But the trouble with Swiss cheese isn't that some step went wrong; it is that nothing stable sits between those twenty or thirty steps to hold them together. Hora's components are exactly that intermediate form.

Back to DHH's line: repetition is free now, and syncing is cheap too.

Imagine a rule, say “members get 20% off,” written down in n places. Every time the price changes, an agent has to update all n places correctly. It is very reliable: it gets each place right with probability r.

Take r = 99.9%, which is already more careful than most people. With n = 1000, the chance of getting everything right is only 36.8%; with n = 5000, it is just 0.67%.

The key is the product n(1 − r). “Syncing is cheap” makes 1 − r smaller; “repetition is free” makes n larger. As long as n grows faster than reliability improves, the chance of getting everything right still falls toward zero. Keep only one copy, and the problem disappears: consistency is no longer a matter of probability kept up by carefulness, but a certainty guaranteed by structure.

Databases figured this out more than fifty years ago. In 1970, Codd at IBM proposed the relational model, which later grew the “normal forms”: store each fact in one place only, so that you never change it here and forget it there. In a database, the updates are carried out by machines to begin with, and machines are very reliable, yet databases still insist on normal forms. Engineers often store redundant copies on purpose to make queries faster, but that is a trade-off with a price tag attached: the extra syncing needs a dedicated mechanism in charge of it.

The other half of what DHH said also runs into the math ledger. He said that with thousands of agents changing one application at once, abstractions become choke points. Why do choke points exist? Chapter 3 of SICP deals with exactly this.

Two processes of 10 steps each have 184,756 interleavings; with 50 steps each, about 1.0 × 10²⁹. Each of them may compute a different result. Section 3.4 of SICP has an exercise (Exercise 3.38): an account starts with $100; Peter deposits $10, Paul withdraws $20, and Mary withdraws half of what is there. If the three take turns, the balance can end up at $35, $40, $45, or $50; if they act at the same time, with their steps interleaved, still other numbers turn up.

Locks, queues, and modules with a single way in and out are all ways of squeezing the interleavings back into one order. They do slow down parallel work; on that, DHH is right. But take them away, and what you have to verify is no longer one path but an astronomical number of them. Again, this is not a problem of the human brain: agents have to face those paths too.

DHH also said he doesn't read a single line of the Rust. He treats it as a black box and checks it from the outside, just like every boss in history who has paid programmers to do the work.

Fair enough. But how far can checking from the outside go?

Start with testing. Tests can only try finitely many inputs, and for any finite set of tests, infinitely many programs pass them all while behaving differently everywhere else. Dijkstra put it in a famous remark in 1969: roughly, testing can show the presence of bugs, but never their absence.

Then why not open the black box and read the code, or have another agent review it? After building an interpreter in Chapter 4, SICP leaves an exercise asking readers to prove for themselves that no general program can decide whether an arbitrary program will halt.

The result goes back to Turing's paper of 1936; the name “halting problem” only appeared in the 1950s. SICP turns it into an exercise in Chapter 4, and five lines of Scheme are enough.

In 1953, Henry Rice pushed this as far as it goes.

“Never leaks user data,” “always gets the balance right,” “behaves the same as the old system”: these are all nontrivial behavioral properties. No reviewer, human or agent, can decide them for arbitrary code. The constraint is the same for everyone; the human brain can't escape Rice's theorem either. This is not a question of who is cleverer.

So how does software get built right? By not letting the code be “arbitrary.” We put structure in beforehand: types, interfaces, specifications, reference answers to check against. Particular programs can often be checked; only “arbitrary” programs are hard. My essay on machine proof made a similar point: deciding whether a statement is true is hard, but checking a proof is easy. Structure is the proof a program carries with it.

DHH has a good example close at hand. This year Sam Ruby, of the Rails community, built a project called Roundhouse: it takes a Rails application as the specification and compiles it into versions in a dozen or so languages. How do you know the translation is right? Request the same URL once from the original Rails app and once from the new version, and the pages that come back must match node by node. The original application is the criterion.

In a post responding to DHH, Sam Ruby wrote that with agents, rigor hasn't disappeared; it has moved upstream into specifications and downstream into tests. I agree. You may leave the black box unread, but you can't do without a criterion.

Now we can answer the question in the title: is English the best programming language?

First, a law from cybernetics. In 1956, Ross Ashby proposed the “law of requisite variety”: to keep outcomes within the range you want, the variety a regulator has at hand must be at least as great as the variety of the disturbances. In his own words, “only variety can destroy variety.” What follows is the simplest version of it in information theory.

An application involves thousands of distinctions you care about: where a button goes, how money is rounded, what an error message says, whether a deletion can be undone. Suppose u of them were neither written down by you nor covered by conventions, so the model can only guess them from experience. If each guess matches what you had in mind with probability a, the chance that every guess is right is a^u. Another exponential.

This theorem explains several things.

First, DHH says Rails's “convention over configuration” translates directly into token efficiency. Conventions are the bits both sides have agreed on in advance: how table names map to class names, how URLs map to controllers. Once agreed, they need not be written down, and they can't be guessed wrong. Vibe coding relies on priors too; they are just priors nobody agreed on.

Second, Matz said in the conversation that many people's vibe coding falls apart the moment it meets a real application, yet when members of the Ruby core team tried it, their success rate was surprisingly high. His explanation: veterans know how to set goals for an agent. In terms of conservation of bits, veterans know which distinctions matter, and they write those few bits down by hand.

Third, English. English really does have the most expressive power, because behind it lies a huge prior that humans share, so a single sentence can call up a great many bits. But the model doesn't fully share that prior with you. DHH admits English is vaguer, and wherever it is vague, that is u.

So my answer is this: English is the best front-end language, not the best source of truth. For saying clearly what you want, nothing beats English. But a source of truth needs semantics agreed in advance, fixing what each sentence means. That is exactly the job of a programming language, and exactly what SICP cares about most.

In 1978, Dijkstra wrote a short essay attacking “natural language programming.” The gist: the narrowness of formal notation is precisely its virtue, because it forces you to pin down exactly what you mean; natural language makes it easy to say things, and just as easy to say them wrong.

SICP is nicknamed the “Wizard Book,” because its cover shows a wizard holding a ball inscribed with eval and apply, the two core procedures of an interpreter. The nickname fits: the whole book teaches you to make spells, which is to say, to make languages.

Look back at what DHH actually does, and you'll notice something interesting: while he says abstraction is obsolete, his hands are full of abstractions.

Abstraction hasn't disappeared; it has moved house, from inside the code to between the boxes. Abstraction used to mean functions, classes, and modules; now it means the edges of black boxes, interfaces for agents, specs written in English or in Rails, and criteria that decide right from wrong. Corollary 1.1 said modules would get coarser, and these are what the coarser modules look like.

Section 1.1 of SICP opens by saying that every powerful language has three mechanisms: primitive expressions, means of combination, and means of abstraction. Today all three appear again, one level up. The primitives are individual tasks carried out by agents; the means of combination is how those tasks are orchestrated; the means of abstraction is drawing boundaries around groups of tasks, giving them names, and setting their criteria.

Chapter 4 of SICP is about “metalinguistic abstraction.” One powerful way to deal with a complex problem is to create a new language; and the evaluator, which determines what each expression in that language means, is itself just another program. Rails is a small language hidden inside Ruby. When DHH says English is a better programming language, he is really asking a Chapter 4 question: who is this language's evaluator? Where are its semantics written down?

The evaluator of English is a model, and its semantics are the model's priors. What Roundhouse does is give this evaluator an answer key: write the agreed semantics down in Rails, and check the model's translations against it.

These are exactly the two words in the book's title. Structure is the structure agreed on in advance; Interpretation is the many interpretations of that one structure: one for people to read, one for machines to run, one in another language.

6.001, the introductory course MIT taught from SICP, ran for the last time in the fall of 2007. In 2009, at the International Lisp Conference, Sussman explained why the course had been replaced. As Andy Wingo reported it, his point was that engineers in 1980 built systems out of small parts they understood completely, whereas engineers today have to run experiments on poorly documented libraries to see how they behave.

DHH's black box is the end of this road: even the code in his own projects he only tries out from the outside. On this trend, SICP looks even less useful.

Look again through the four ledgers, and the conclusion changes. Some of what SICP teaches is charged to the brain ledger: writing out every procedure by hand, becoming fluent in the idioms of Scheme. That will lose value and can be handed over to agents. The rest is charged to the math ledger, and it is worth more than ever.

The way of reading has to change too. Exercises used to be for practice. Today you can have an agent write them for you, but before it does, predict for yourself what it will output, and afterward ask it for counterexamples. Treat the agent as a teaching assistant, not a ghostwriter.

Matz said in the conversation that the knack veterans have for making vibe coding work needs to be formalized somehow and taught to the next generation. SICP was such an attempt forty years ago: a book that writes down what veterans know in their bones but can't quite put into words.

My favorite moment in DHH's keynote was an old photograph. Tuxen, who painted portraits all his life, sat in front of a camera in his later years and let the new technology take his picture.

Later I came across a detail. Tuxen's royal group portrait was itself pieced together from photographs and sketches of the sitters made in small groups. The camera did not take his work away first; it became his tool first. The photographs took care of likeness, while composition and choices stayed with him.

Just how photography affected nineteenth-century painting is still debated by art historians, and I won't go into it here. In Tuxen's case, at least, what the camera took away was the drudgery of likeness, not the painter's eye.

What agents take away is the drudgery of typing out code. What they don't take away is the watchmaker's layering, the fact stored in one place only, and the semantics and criteria agreed on in advance. These are what SICP has been about all along. It just used Scheme to talk about them, and we used to mistake it for a book that teaches Scheme.

“The camera took likeness, not the eye.
Agents take the typing, not the structure.