人工智能的未来是Ruby on Rails
大型语言模型在生成和编辑代码方面表现出色。目前，这可能是人工智能的“杀手级应用”：真正通过语言模型赚钱的公司——如GitHub Copilot、Cursor、Windsurf——都在做代码生成。
在小规模项目上，这种方法效果惊人，但当代码库变大时，就会出现一个明显的问题。一旦代码库无法完全放入模型的上下文窗口中，为你写代码的工具就会遇到瓶颈。突然之间，修改不再奏效，试图修复问题的尝试反而在其他地方引入了更多错误。即使是那些宣传拥有大上下文窗口的模型，也不一定有大的有效上下文窗口。你往上下文窗口中塞入的内容越多，语言模型的表现就越差。这就是为什么在编辑器中的代码补全仍然是AI辅助编程的黄金标准。它利用了模型在小规模修改方面的优势，效果出奇地好。
Paul Graham有一篇著名的博客文章，他在其中谈到某些编程语言比其他语言更强大。他所说的“强大”指的是拥有更多基础语言特性（例如递归、宏），从而能够做到其他语言根本无法做到的事情（或者至少需要写更多繁琐的代码才能做到）。
考虑到这一点，我认为这可以很好地衡量AI辅助编程的能力：表达一个实现X功能的程序需要多少个token？
这里有一个简单的例子。如果你想让一个大型语言模型构建一个博客Web应用，你应该选择Python还是Golang？（暂且忽略Golang可能性能更好，只需考虑哪个选择更有可能让你得到一个可用的应用）。我认为很明显你应该选择Python。Golang有更多的样板代码——错误处理、集合遍历——这意味着你会更快地达到token限制。你的Python应用将占用更少的token，因此你可以在达到限制之前添加更多功能。
Golang对人类来说比大型语言模型更容易，因为人类程序员可以或多或少地安全地忽略Golang的额外token。你可以略过if err != nil或for循环。但大型语言模型不能以同样的方式略过这些代码：无论是不是样板代码，每个token都会占用其上下文窗口的空间1。那么，大型语言模型是否应该编写压缩后的代码，以尽可能少地占用空间？我不这么认为——它仍然需要表达性强的变量名，原因和人类一样。因此，理想的编程语言应该是在每个功能上使用尽可能少的token，同时仍然保持可读性。换句话说，一种从头开始设计以确保开发者幸福的语言。
这就是Ruby！这种语言的核心思想是，你应该能够尽可能简洁优雅地表达你的程序，即使它需要更多的CPU周期来运行。Ruby on Rails有其自身的问题——委婉地说——但它做得好的一点是将大量功能浓缩在少量代码中。这正是大型语言模型所需要的。
我们是否应该将所有“氛围编码”都放在Ruby on Rails中进行？也许还不到时候。我确实认为使用一种类型化的语言是一个好主意，这样可以通过类型检查器来弥补大型语言模型的一个重大缺陷——它们无法像人类一样测试自己的代码。坚持使用Javascript和Python也有很好的理由，因为它们在大型语言模型的训练数据中占据了重要地位。
不过，这确实是一个有趣的想法。Ruby是我所知道的最“人性化”的语言：为人类编写，带有有趣的人类瑕疵，读起来像人类的语言，等等。如果它也最终成为机器人的语言，那将是一个相当讽刺的结局。
