最近用 AI 辅助编程,最大的感想就是上下文窗口太小,LLM 能力很强,但是因为开发软件需要输出和记忆的代码量太大,所以经常写着写着它就忘记了。如果你要求它只输出一个文件的代码(几百行),现有的大语言模型多半都能够胜任。 这就解释了为什么很多人对现有 AI 编程能力的评价两极分化——很多人的工作都是在对已有的系统进行二次开发和优化,这些系统都有大量的历史代码,现阶段的 LLM 很难完整读完并记忆这些代码。这其实就和我们人类一样,我们也没有谁可以准确记忆操作系统内核里面的每一行代码。
所以可以预测,在不远的将来,我们将会看到使用 AI 进行软件开发出现两个分支:1. AI-agent,在这个发展分支中一个大规模的软件开发将被分化成很多小的功能模块,然后每个功能模块由受过专项训练(只用相关代码进行训练,比如只负责编写后端代码)的 AI-agent 来负责编写并测试。这个应该也是所有人目前的共识了。AI-agent 系统最大的问题就是资源开销太大,另外这个想法也没什么创新,只不过就是用 AI 强行替换人类而已。 2.我们会看到一个全新设计的低上下文开销的编程语言(Low Context Window Programming Language, LCWPL),这个编程语言设计的初衷就是适合现阶段的 AI 编程,同时也能保证基础的语法方便人类维护(在现阶段,AI 维护还为时尚早)。现有的 Java ,C++这类类名冗长,编程范式繁杂的软件开发语言将被逐渐抛弃(或者是在人们的辅助下,用AI自动翻译部分Java/C++模块到LCWPL,并逐渐替换掉),用这些语言编写的系统也会被这种新编程语言所替代(有了这种编程语言,再用AI来重写一个操作系统并不难)。Python 等动态语言因为其丰富的库可能还会在学术界等地方继续存活一段时间,最后应该和 Fortran一样慢慢消亡。
根据我个人使用的体会,现阶段Go语言非常适合LLM,主要是因为Go语法简单、解决同类问题的方式统一,不像一些语言有多种风格和大量奇特库。这种一致性使模型更容易学到单一正确的做法,减少上下文混乱。同理,某些更古老的严格语言(如Ada、Eiffel)也许在未来因其规范性重新受到青睐,用作AI编程的基石。综上所述,我们可以预测新的编程语言将具有这些特性:1. 一定是编译型语言,而不是 Python 这样的动态解释语言。因为动态解释型语言对于 AI 来说Debug复杂度太高(编译过程会自动做较多检查,编译型语言将减少AI需要追踪的所有动态场景,另外编译型语言常常有显式类型的好处)。2. 一定保持简单的语法,可能会有语法糖,但是绝对不会有很多复杂的编程范式,过于复杂的编程范式就导致 AI 理解混乱。简单便捷对 AI 来说就是最好的。3.一定是支持功能导向的集成(feature-oriented integration),也就是组件在被开发(AI 编写)的时候是根据人设定的功能而递归的一项一项开发的。这也使得在集成之前,AI 可以彻底测试实现新功能的那些类,然后增量的将这些功能集成进入系统。——》换句话说,AI在使用这种编程语言开发的时候,将会先开发“骨架“代码(树形结构),然后再分别开发小的功能组件并把它们挂到树上。这种编程开发基本上不需要“脚手架“(底层的程序库类除外,搭“骨架”的时候可能需要一点脚手架,否则在添加特定的功能之前,骨架中的某些部件可能根本无法使用)。然后把各个功能挂在骨架上之后,就无需脚手架了,既然每个功能都是自成一体的,那么它会包含自己所需的支持代码。4. 这种编程语言会在语法层面存在类似于Rust的借用(Borrowing)的机制,可以显式的告诉 AI这个文件和哪些文件/函数是强关联,和哪些文件/函数是弱关联,。这样开发或者后续修改的时候AI 只需读入相关联的文件和函数,而不需要读入整个项目。这样将显著降低系统开发整体的复杂度。这个也和人类开发的方式相同,人类开发的时候也只是专注于自己开发的功能模块和与之相关联的有限几个模块,而不会尝试在脑子里装入整个系统。
旧语言或许不会马上消亡,但从可维护性和AI兼容的角度看,新语言出现是大势所趋。