LLMs as Compilers: 核心观点摘要
综合多篇文章，探讨将大型语言模型（LLM）视为“编译器”的构想。这一概念认为，未来的软件开发将从编写具体代码转向通过自然语言和测试来“编译”出所需功能。
Kadhir: 从“助手”到“编译器”的跃迁
核心论点：LLM将从辅助编码的“助手模式”进化为直接生成功能的“编译器模式”，工程师的角色将转变为“上下文管理者”。
- [观点] 当前的LLM主要作为助手（如代码补全），未来将发生质变，成为直接产出功能的编译器。
- [观点] 工程师的工作重心将不再是审查代码，而是：
- 构建和提供给LLM的上下文（Context）。
- 测试LLM生成的功能，而非代码本身。
- 让LLM自行处理新功能与现有代码库的集成。
- [观点] 这种模式将带来两大影响：
- 工程民主化：构建复杂应用不再需要高度专业化的编码技能。
- 开发速度提升：处理上下文比直接处理代码的效率更高。
- [观点] 针对“LLM不像传统编译器那样可证明”的反驳：我们可以通过评估和测试来确保其可靠性，并将“上下文”视为输入，“功能”视为输出。LLM可以不断迭代直至通过所有测试。
Vivek Haldar: 英语是“新的热门编程语言”
核心论点：LLM是将自然语言编译成高级语言的下一代编译器，代表了编程抽象层次的又一次飞跃。
- [观点] LLM的角色类似于传统编译器：传统编译器将C++编译成汇编，LLM则将英语编译成Python/Java等高级语言。
- [事实/论据] 引用Andrej Karpathy的观点:
“The hottest new programming language is English.”（最热门的新编程语言是英语。）
- [事实/论据] 论文表明，Copilot能轻松通过大学入门级编程课程，仅通过调整问题描述就能解决大部分问题。
- [事实/论据] 开发者在遇到LLM生成错误代码时，倾向于修改提示词（Prompt）而非调试代码本身。
- [事实/论据] 引用Crista Lopes教授的实验：用ChatGPT成功实现了一个玩具语言的词法和语法分析器，这通常是研究生级别的编译器课程内容。
- [观点] 随着时间推移，LLM的可靠性终将达到现代编译器的水平，届时我们无需再关心它生成的中间代码。
Dave Hoover: 由行为规范驱动的LLM编译器
核心论点：下一代编程语言革命将由专门的LLM驱动，开发者通过类似Cucumber的行为驱动开发（BDD）规范来指导LLM生成代码。
- [事实/论据] 历史类比：C语言（1972年）和Perl/Python等脚本语言（1987年后）都带来了生产力的巨大飞跃，LLM是下一次革命。
- [观点] 设想的开发流程：
- 使用类似Cucumber的Gherkin语言描述高级行为。
- 用更技术性的语言（如“step definitions”）细化规范。
- 将这些规范喂给专门的LLM编译器，生成最终代码库。
- 手动验证行为，并通过修改规范进行迭代。
- [观点] 这将带来又一次数量级的生产力提升。
- [观点] 这不会淘汰现有工程师，而是会使产品开发团队数量增加5倍，因为单个工程师的生产力大大提高了。
Avik Das: 关键区别——“代码是负债”
核心论点：LLM与传统编译器的类比成立，但存在一个根本性差异——当前LLM工作流中，作为“真理之源”的是生成的代码，而非原始提示，这是一种负债。
- [观点] 对AI编码的常见抱怨（代码质量差、失控、不懂底层）与早期对编译器的抱怨如出一辙，这些问题都会随着技术进步而改善。
- [关键区别] 根本不同点：
- 传统编译器：源码是“真理之源”。我们修改源码，然后重新编译。编译产物（二进制文件）是可丢弃的。
- 当前LLM：生成的代码是“真理之源”。我们检入、维护和调试的是LLM生成的代码。原始提示（Prompt）被抛弃了。
- [观点] 理想的未来是：当AI足够稳定和确定时，我们可以只存储和版本控制提示（Prompts），每次都从头生成代码，就像我们对源码进行干净构建一样。
- [事实/论据] 作者个人虽然认同LLM是重要工具，但仍享受“手工”编码的乐趣，这表明不同编程范式和个人偏好会长期共存。