Prompt 到 AI 生成的二进制是可行的。程序员的末日临近吗？

Source: Dev.to

@Freeze (视频)

如果你搜索 “elon musk ai will skip code machine code”，会发现大量软件开发者出于各种原因不同意并批评这个想法。下面列出几篇深入的文章，作者们似乎拥有广泛的知识并对计算机科学和软件工程有深刻的理解。

• 埃隆希望 AI 跳过代码直接生成二进制。这不是进步
• 我认为埃隆关于‘AI 超越编译器’的说法是错误的。真正的技术钢人论点是什么？
• 埃隆称 AI 将在 2026 年生成二进制。以下是为什么这是个糟糕想法
• 埃隆·马斯克预测 AI 将在 2026 年绕过编码：二进制生成与 IT 职业的未来 – 来自 Cloud Soft Solution，兴趣小组
• “代码 + 编译器”模式即将消失吗？
• 埃隆·马斯克预测 AI 将在 2026 年使编码变得过时

---

我的看法

我认为埃隆的说法相当可行。我没有内部消息；埃隆·马斯克的意思是，AI 将直接生成机器码，而不是生成源代码再调用针对特定处理器的编译器。

Current: Code → Compiler → Binary → Execute
Future: Prompt → AI‑generated Binary → Execute

Grok‑Code 的训练方式必须与其他生成可读源代码的 LLM 代码代理的训练方式根本不同。

编程历史回顾

免责声明

• 我 不是 计算机科学家或 AI 专家，只是一个活跃的全栈开发者——因此也是程序员。
• 我不够老，没用过插线板、开关、穿孔卡或纸带，但在大学物理学士课程中使用过 Fortran、汇编语言和 PLC。
• 为了我的硕士论文，我用 C++ 编写了一个 M68K 处理器模拟器，解释 M68K 机器码。

多年来，我在日常编码中使用过 C / C++、Turbo Pascal、VB、Delphi、C# 和 TypeScript。据我理解，高层语言和大多数计算机科学/软件工程原理都是为有血有肉的人脑设计的，例如：

• 高内聚 & 低耦合
• SOLID 原则
• 设计模式
• 敏捷宣言、XP、DevOps 等
• 可复用的库和框架

无论你多么遵循这些原则，或你的源代码多么整洁，最终它都会被编译并链接成类似意大利面条的东西——这是人脑讨厌但计算机不在乎的。

整洁的代码可以促进更好的编译时、链接时和运行时优化；性能提升可能高达 25 %。我 认为 当前的优化算法在很大程度上是由程序员以固定规则编写的，而这些规则往往奖励整洁的代码。

简而言之，这些实践的存在是为了帮助人脑消化功能和技术复杂性，从而交付可工作的程序。

编程与 LLM AI 代码代理

我猜您对 AI 代码代理厂商如何训练模型已有基本了解，但我不确定他们收集了哪些原始代码以及如何对其进行标记：

• 他们是否只是扫描 GitHub、SourceForge 以及一些商业程序/库中的所有代码？
• 他们是否会用关于代码质量的信号来标记代码？

作为程序员，我受益于 AI 代码代理颇多，部分原因是我不擅长记住琐碎的技术细节。到目前为止，我发现当我让 AI 代码代理实现一个非平凡的功能——无论提示多么详细、正式或简洁——生成的源代码在设计和实现上通常过于臃肿，行数通常是应有的3–5 倍。

AI 生成的源代码与平庸但“政治正确”的手工编写代码

“3–5 ×” 对我来说听起来像是一个魔法数字。在几个商业重写项目以及一次开源工具的重写中——使用相同的技术栈和语言——我观察到：

• 我的代码库的 ≈ 1/3 – 1/5 行数（LoC）相较于遗留版本（仅相差几个月或一年）要少得多。
• 我的设计更为简洁，第三方依赖更少，DI/IoC、SOLID 和设计模式的使用也更精简。
• 运行时性能提升了 20 % – 50 %。
• 最终产品更可靠、更稳健。

关于遗留代码库：

• 某工具的作者热衷于 SOLID 和 DI/IoC，但误解了高内聚和低耦合，在错误的地方使用了 DI/IoC。
• 那些遗留商业程序的作者对 SOLID 和设计模式非常熟悉，却错误地应用它们——可能是因为对内聚/耦合的误解以及过早引入了过于高级的设计。

基本上，这些遗留代码库在 SOLID 方面看起来“政治正确”，但实际上却过于复杂且冗长。

我是如何编写简洁短小代码的

我认为那些程序员直接跳到实现他们的第一个可行想法，而没有评估更简单的替代方案，也没有花足够的时间了解业务和技术背景，更没有遵循基本的敏捷实践。

---

实践

• 从基本、可运行的代码开始。
• 编写大量单元测试和集成测试。
• 在每次迭代中积极重构。

其目的并不是让设计看起来优雅或令人印象深刻；而是通过与技术同事和业务利益相关者的频繁沟通，加深对业务和技术环境的理解。

我写的代码行数是所在城市普通高级开发者的 2–4 × 吗？

不。 当我主导软件开发生命周期（SDLC）时，我通常会在可计费时间的 ≈ 1/3 – 1/4 用于编码（包括测试），尤其是在 SDLC 前期 1/4 – 1/3，此时架构和设计正在形成。
其余时间用于 思考、学习和与利益相关者沟通。即使我产出的代码量相同或更少，整体维护成本也会大幅降低。

SOLID 原则（摘自 Robert C. Martin，《UML for Java Programmers》）

何时应用它们

• 在出现痛点的第一时间。
• 不要试图让每个系统始终符合所有原则；这会浪费时间去想象 OCP 的可能环境、寻找 SRP 的变更来源、为 ISP 创建数十个小接口，以及发明毫无价值的 DIP 抽象。

最佳实践： 以 被动 的方式应用 SOLID——当你检测到结构性问题或注意到某个模块受到其他地方变更的影响时，考虑是否可以利用一个或多个原则来帮助。

被动方法仍然需要 主动 的推动：刻意寻找痛点。最好的方法之一是编写大量单元测试——最好 在编写代码之前（这是另一个章节的话题）。

AI代码代理 vs. 高级开发者

Prompt‑to‑AI‑Generated Binary 的优势

• 这种方法可能避免其他 AI 代码代理通常产生的 代码膨胀。
• 具备强大硬件的足够强大的 AI 能在 不依赖 为人类程序员开发的传统计算机科学/软件工程技术的情况下处理巨大的复杂性。
• Grok Code 可能有自己的机制来避免代码膨胀，因此 SOLID 和设计模式的作用 几乎为零。

Prompt‑to‑AI 生成二进制的一个根本问题

• 这种方法 消除了人工干预（审查、验证、确认），从而影响产品质量。
• 即使你把机器码反汇编成汇编代码，结果也极其难以阅读，即使 AI 添加了符号名称。
• 整个二进制文件变成了 黑盒：
  • 最佳情况：它的行为符合预期，但超出了你的预期。
  • 最坏情况：它包含多个“潘多拉盒子”，除非你完全信任基于 AI 的审查、验证和确认。

Grok Code 可能发光的领域

• 纯数学问题和算法。
• 基于数学基础的其他 AI 系统开发。
• 领域专家 AI。
• 视频游戏。
• “消磨时间”的应用。
• 高级黑客、垃圾邮件或欺诈工具（运行时是否有 AI 辅助均可）。
• …

示例： 作为数学家，你可以使用 Grok Code 生成完整的类似 Matlab 的库。

我的常规 AI 代码生成器挑战

问题： 给定一个复杂的 Swagger/OpenAPI 定义——例如 Medicare Online 使用的定义——AI 代码生成器能否生成可用的 C#、TypeScript、Java 等语言的客户端库？

观察： ChatGPT 和 Copilot 做不到（否则微软会发布一个在线 AI 代码生成器来完成此任务，而不是 Microsoft Kiota）。

未来兴趣： 到今年年底，Grok Code 能否基于 Medicare Online OpenAPI 定义，生成 机器码客户端库，在 Windows 11 和 Intel 处理器上运行？