AI 时代，编程语言将如何演进
这篇文章汇集了一些简短的随想，探讨编程语言在 AI 时代可能如何演变。
全文分为两部分：反思与 Agentic 工具。第一部分提出一些问题：当大部分代码不再由人类编写时，编程语言、它们的生态和社区会发生什么。第二部分更具体、也更有个人立场：既然编码 agent 已经成为我们语言的使用者，我们的工具该如何改进。
我对这些话题的看法日后可能会变，但这算是近期所思所想的一个还算靠谱的总结。
反思
这一部分探讨：如果 agent 写了我们大部分代码，编程语言及其社区可能会发生怎样的变化。尽管这仍是个有争议的话题，但对许多开发者和团队来说，这已经是现实。因此，无论我们认为这一转变会普及到什么程度，我们都有责任去思考它可能带来的影响。
开始吧。
关于社区
大多数编程语言的核心，都是一群因共同理念而聚在一起的社区。Python 强调做事要有一种显而易见的方式，Ruby 长期倡导程序员的幸福感，Lisp 社区则一直推崇重塑语言本身的能力。
但当我们不再编写大部分代码时，会发生什么？这又会如何影响我们的归属感？我们是应该设法保留这种归属感，还是让社区去寻找下一个凝聚彼此的东西？
沿着这个思路继续想：我们围绕语言构建生态系统，来解决难题、创造共享抽象，比如 web 框架、张量库、数据处理流水线、GUI 工具包等等。编码 agent 可能以两种截然相反的方式影响这些生态。
首先，生态之间的差距可能会缩小。构建这些框架需要大量的时间和精力，而其中很多工作 agent 都有可能大幅压缩。当问题涉及实现已知算法、翻译论文中的思路，或在语言之间移植现有实现时尤其如此，这让较小的社区能够以快得多的速度追赶上大社区。
反过来，如果实现某个功能的成本降到足够低，人们还会愿意齐心协力、协同开发同一个解决方案吗？如果我想解决某个问题 X 需要一个库，我可能直接让 Agent 帮我把需要的功能写出来。
这就产生了一种有趣的张力。Coding Agent 既能大幅降低构建生态的成本，又会同时削弱促成生态形成的关键力量之一。
关于易用性
编程语言演进的一个重要方面，是不断添加语法便利（affordances）并改善人机工程学。但如果没有人类编写大部分代码，这些变化还有多大意义？
以过去十年为例，大量语言引入了可选链操作符，这对人类编写代码确实友好得多，比写一堆显式的空值检查要优雅。另一方面，Agent 并不讨厌样板代码，这种差异对它们来说意义远不如对人类那么大。
有人会说，这些语法便利也能让 Coding Agent 在 token 效率上表现更好。但我认为，token 效率是我们优化编程语言时应放在最后考虑的特性，尤其是随着模型变得更便宜、更高效，上下文窗口也不断扩大。
我甚至想指出，任何宣称“为 Coding Agent 而生”、最终却只聚焦语法的新型编程语言，其实只是在围绕当前的局限性做设计。我用 Agent 写过 HTML、CSS、JavaScript、Elixir、Rust 和 Lean，对我来说差异巨大的语法，对它们来说重要性其实大打折扣。在它们的视角里，一切不过是 token 的输入与输出。
关于编译器
每当在这个语境下讨论编程语言，总有个常见的追问：我们到底还需要编程语言吗？Coding Agent 会不会取代编译器，直接写汇编？
由于几个原因，我并不认同这种说法。
首先，如果你在开发桌面应用，通常不希望为支持的每种架构维护不同的汇编实现。你仍然需要一种与架构无关的表示，以及某种能将其降低到目标机器的工具。换句话说，即便这门语言从未为人类设计，你也至少重新发明了编译器的一部分和一门高级语言。
其次，我们尚未找到一种语言或计算模型，能在所有方面都表现卓越。既有系统编程语言，也有定理证明器；既有面向并发、分布式和高可用软件的语言（例如 Erlang/Elixir），还有查询语言、硬件描述语言等等。这些语言采用了不同的语义和不同层次的抽象，提供的保证也各不相同。指望一种低阶语言统揽所有这些领域，是不合情理的。
如果编程语言本身不会有太大改变，且我们停止针对人类编写者去优化这些语言，那么我们应该为谁来优化？
Agent 工具
过去我曾表示，为人类打造优秀工具，往往也为 Agent 带来了优秀工具。我相信这一点永远成立。因此，我们在构建解决方案时，倾向于自动化那些我们已经在做的事情：让 Agent 编写同样的测试、消费同样的程序元数据，并阅读同样的日志。
那么，如果开始使用 Agent 来执行我们平时不会亲自做的操作呢？可能因为这些任务过于繁琐，学习曲线陡峭，或者涉及的信息量超出了人类处理的上限。本节将探讨这一方向。
本节的工具并不要求 Agent 编写大部分代码。即便你只用 Agent 生成 20% 的代码，也能从上述工具中受益。
更强力的用户约束保证
编程语言需要在多个相互竞争的目标间取得平衡，包括表达力、保证（guarantees）以及易用性。我们希望表达关心的程序，希望语言能证明这些程序的有益性质，同时希望开发者易于上手。如果由 Agent 来编写大部分代码，我们便有机会重新审视这些权衡取舍。
函数签名推断就是一个例子。对人类来说这很有价值，因为手写编译器本来就能推断出来的信息太繁琐了。但编码 agent 不怕繁琐，把类型和意图写清楚，反而能给编译器、其他 agent 以及我们自己提供更多信息。更重要的是，能完全推断类型的语言，通常是类型可检查语言的一个子集，所以为推断做优化，最终会限制语言的表达力，也削弱类型系统能提供的保证。既然我们已经见过 agent 在复杂得多的系统里写证明，为什么还要给它们强加这些限制？
保证也不一定非要静态建立。内存安全既可以静态强制，也可以由运行时实现，比如垃圾回收。模型检查则可以利用模型生成的执行轨迹来验证真实系统，从而在模型和实现之间架起桥梁。Erlang/Elixir 就是个典型案例：它们通过隔离进程和消息传递来约束并发程序的结构，牺牲一些表达力，换来更强的隔离性和容错性。并非所有并发算法都能高效映射到这个模型上，但能映射的程序都继承了这些有用的保证。
总的来说，现在正是为软件提供更强保证的最佳时机。我们无法对全部软件做形式化验证，但可以结合不同方法来增强它：
- 构造即正确：语言让非法状态或非法程序难以甚至无法表达。
- 静态建立：类型、证明和静态分析在执行前确立性质。
- 运行时强制：内存管理、隔离、能力边界等运行时保证的性质。
- 经验验证：通过测试、property-based testing 和 fuzzing 来验证程序。
我认为，不同编程语言在整合这些技术以及探索表达力与可靠性边界的方式上，将在其差异化竞争和普及过程中发挥日益重要的作用。正如“社区”章节所讨论的那样，如果你相信智能体会让生态系统更容易相互追赶，这一点尤为关键。同理，框架层也需要在自身的抽象层面上采纳部分此类实践。
程序数据库优于 LSP
过去两年里，人们多次宣称 IDE 即将消亡。一旦这一讣告最终见报，我不认为 LSP（Language Server Protocol）能幸存下来。
LSP 最初主要面向 IDE 设计，其许多操作都偏向于基于文档和位置的逻辑，如文件、行和列，而智能体并不会精确追踪这些信息。在我们开发 Tidewave（一款允许智能体提问“foo_bar 的文档在哪里？”或“BarBaz 定义在哪里？”的 CLI 或工具）的过程中发现，比起要求智能体提供符号在源代码中精确位置引用，这种方式要合适得多。
此外，LSP 的设计初衷是供人类消费信息，而非供机器探索。你通常需要在源文件之间跳转，一次获取一小部分信息。
好消息是，许多语言服务器已经构建或能够访问编码智能体所需的大部分信息：符号、引用、调用图、类型信息，有时还包括数据流信息。我的建议是，将此类信息作为程序数据库暴露出来，并配备查询语言，无论是 SQLite、Datalog 还是自定义的 DSL。
要求大多数开发者为了查找一个函数的所有引用而去编写查询是不合理的。相反，编码智能体会很乐意这样做：编写程序查询与调用 CLI 或 LSP 工具的工作量相当。更重要的是，它们可以组合那些作为独立 IDE 功能不太实际的查询，例如：查找所有最终调用该函数的公共函数，或查找程序中给定值变为 nil 的所有路径。这些数据库还可以用作 Linter，防止智能体产生不期望的行为。
这意味着局部性依然极其重要，尤其是在大型代码库中。monkey-patching、隐式 hook、动态重绑定，以及其他各种“远程作用”特性，都会让一处代码影响整个系统的行为——即使有程序数据库可用，也很难追踪这些影响。
运行时可观测性优先于调试器
调试器是另一个主要为人设计的接口。我们设置断点，逐行单步执行，边走边检查变量。但 agent 对代码进行插桩、收集 trace、关联信息的速度远快于我们。我们应该为它们提供能发挥这一优势的接口。
此外，既然我们假设编码 agent 将来会编写大部分代码，那就有理由期望它们在软件开发生命周期中承担更多职责，包括在运行时监控和诊断生产系统，而不是只依赖日志和仪表盘。
我们应该把系统中的运行时和状态以 agent 可以编程式查询和探索的方式暴露出来。运行时可观测性可以为 agent 提供一个统一接口，用于在所有环境中实时诊断故障、发现可靠性问题、定位性能瓶颈。
幸运的是，得益于 Erlang VM，Elixir 在这方面一直表现出色。检查 process、socket、应用、supervisor、ETS 表、消息队列等功能都是运行时的内建能力。剩下的工作，是通过一组工具、一门查询语言或沙箱，把这些能力安全地开放给 agent。
致谢：感谢 Quinn Wilton、Chris McCord、Ryan Lopopolo、Chad Fowler、Rob Knight、Danila Poyarkov，以及我在 ElixirConf 上遇到的许多朋友，与他们的讨论和分享的工作帮助我形成了本文的诸多想法。所有观点均为个人观点。
声明：本文在行文风格和语法润色上使用了 AI。