“手写代码已不再必要！”Redis之父罕见表态：AI将永远改变编程，网友质疑：我怎么没遇到这么好用的AI！

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

当 AI 开始提笔写代码，程序员的饭碗真的要被抢了吗？

关于这个话题，科技圈大佬们的看法堪称“神仙打架”。

Google 首席工程师 Jaana Dogan 曾分享过一个颇具冲击力的对比：“谷歌团队耗时一整年攻坚的工作成果，Anthropic 的 Claude Code 仅用 1 小时，就拿出了一份方向高度一致的方案。” 这并不是“AI 写几行脚本”的层面，而是直接对工程效率与组织协作方式的挑战。

而 Linux 之父 Linus Torvalds 则给出了截然不同的视角。他坦言：“就我个人来说，因为我是维护者，代码审查对我非常重要，所以我对‘用 AI 写代码’反而没那么感兴趣。很多人一谈编程就想到用 AI 写代码，但在我看来，这远没有‘用 AI 来帮助维护代码’有意思。” 话虽如此，这位嘴上说着 “不感兴趣” 的大佬，不久前却悄悄体验了一把 Vibe coding，还顺势捣鼓出一个全新的开源项目，身体力行地打破了自己立下的 “flag”。

如果说 Jaana Dogan、 Linus 的态度仍然偏向克制与保留，那么 Redis 之父 Salvatore Sanfilippo（网名 antirez）的表态，则直接抛出了一个颠覆性论断：

在绝大多数情况下，写代码本身已经不再是必要的工作了。

在他看来，倘若开发者一味抵触 AI，很可能会错过这场已经发生的行业变革。

这个观点瞬间戳中了无数程序员的痛点——多少个挑灯夜战的夜晚，多少行反复调试的代码，都是自己实打实的心血，如今机器却能轻松代劳，心里难免五味杂陈。

对此，antirez 发出了灵魂拷问：

“当年你熬夜敲代码，只为见证项目成功跑通的那一刻，内心真正燃烧的热情是什么？答案其实是‘创造’。既然 AI 能帮我们更快抵达创造的终点，又何乐而不为呢？”

这番犀利的言论，正出自他撰写的文章《不要被反 AI 的炒作所蒙蔽》。文章一经发布，立刻在科技圈掀起轩然大波，截至目前，浏览量已突破 30 万，热度持续居高不下。接下来，我们就一起来看看 antirez 的最新观点。

从“手写一切”到和“模型一起写”

在文章中，antirez 率先明确表明了自己的立场：他一直热爱亲手写代码，追求简洁、可读、带有个人风格的软件设计。

“可以说，我的整个职业生涯，都是在努力写出结构良好、尽可能简洁、以‘人的痕迹’为核心特征的软件。我也一直希望生活在一个不会遗忘弱者的社会里。”

他甚至开玩笑地坦言，如果 AI 最终冲击现有经济结构，迫使社会重新思考财富分配，他也无所谓：

“我并不希望 AI 在经济层面取得成功——但如果现有的体系因此被颠覆，我并不在意。老实说，如果这能推动一次大规模的财富再分配，我甚至会感到高兴。”

当然，这番话中带着幽默，但他也强调：如果因为自己对软件和社会的理想，就扭曲对现实的判断，“那我既不尊重自己，也不尊重理性。”

他进一步说道——“事实就是事实：AI 将永远改变编程。”

“亲自去写所有代码已经不再是一个理性的选择”

事实上，这场转变并非一蹴而就。

早在 2020 年，antirez 就离开工作岗位，开始构思一部探讨 AI、普遍基本收入以及自动化时代社会适应问题的小说。到 2024 年末，他进一步把注意力转向现实技术实践，开设了一个专门讨论 AI 编程应用及其社会、经济影响的 YouTube 频道。

回顾这段经历，他坦言：尽管很早就意识到 AI 会对编程产生深远影响，他曾认为，这个转折点至少还需要几年才会到来。然而，最近的实际体验让他改变了判断。

他指出，随着最先进的大语言模型不断成熟，AI 已经能够在几乎不需要人工干预的情况下，独立完成中等规模的子任务，甚至是完整的中等体量项目——前提是开发者能给出清晰的目标描述，明确希望得到的结果。

在 antirez 看来，模型的表现很大程度上取决于两点：

• 编程任务类型——任务越独立、越容易用文本完整描述，模型表现就越好。系统编程就是典型例子。

• 开发者能力——能否在脑中建立对问题的清晰抽象，并准确传达给模型。

基于这些观察，他得出了一个相对激进、但越来越难以回避的结论：在当下的技术条件下，对大多数项目来说，亲自去写所有代码已经不再是一个理性的选择——除非你只是为了享受写代码本身的乐趣。

Redis 之父自己的亲身体验

antirez 并没有泛泛谈论 AI 能“提高效率”，而是用自己的具体经历说明变化到底发生在什么地方。

就在过去一周，他仅仅通过不断向模型提示、偶尔检查生成代码并给出方向性指导，就在几小时内完成了原本可能需要数周才能完成的一些事情：

1. 改进 linenoise 库。

   他修改了自己的 linenoise 库，使其支持 UTF-8，并为行编辑功能构建了一套测试框架。这个框架使用模拟终端，能够精确报告每个字符单元格的实际显示内容。antirez 解释道，这一直是他想做的事情，但过去很难为一个个人小项目投入如此多的测试成本。现在，只需描述自己想法，AI 就能直接在代码中实现，一切就变得不一样了。

2. 修复 Redis 测试中的瞬态失败。

   所谓瞬态失败，指的是由于网络波动、服务器暂时不可用、连接池耗尽、高并发下的资源争抢或部分节点故障等原因，导致 Redis 命令执行短暂失败。这些问题极其令人头疼，涉及各种时间相关的问题、TCP 死锁条件等等。Claude Code 会持续反复运行测试，直到复现问题为止，然后检查各个进程的状态，理解到底发生了什么，最后修复了这些 bug。

3. 构建纯 C 实现的 BERT 推理库。

   antirez 透露，当自己有这样的想法时，仅用了 5 分钟，Claude Code 就完成了这个库，输出结果与 PyTorch 一致，速度只慢了大约 15%。总代码量大约 700 行，同时还生成了一个用于转换 GTE-small 模型的 Python 工具。

4. 复现 Redis Streams 内部实现。

   在过去几周，antirez 对 Redis Streams 做了一些修改，并写了一份设计文档。他把文档交给 Claude Code，大约 20 分钟内就复现了全部实现。主要耗时反而是他自己检查结果、确认并允许模型执行必要的操作。

「在这样的现实面前，你几乎不可能视而不见。在绝大多数情况下，写代码本身已经不再是必要的工作了」，antirez 说道，「现在真正更有意思的，是理解“要做什么”，以及“应该如何去做”——而在第二点上，大语言模型同样是非常出色的伙伴。」

对于 AI 是否能带来经济收益、股市是否会崩盘，antirez 认为长期来看并不重要。”某个独角兽公司的 CEO 说了什么令人不适或荒唐的话，也并不重要。无论如何，编程已经被永久性地改变了。“

antirez 对自己亲手写的代码被大模型“接手”持坦然态度，甚至感到欣慰。

因为在我看来，这正是我一生所做事情的延续：让代码、系统和知识更加民主化。大语言模型将帮助我们更快地写出更好的软件，也将让小团队拥有与大公司竞争的机会——就像 90 年代的开源软件所做的那样。

然而，antirez 也指出，AI 这项技术的重要性决定了它不能只掌握在少数几家公司手中。目前，不同团队在预训练和强化学习方面各有优势，但开放模型——尤其是中国的一些模型——仍在与封闭实验室的前沿模型竞争，即使暂时略有差距。AI 在一定程度上保持了民主化，但这种状态能否长期维持，仍不确定。

他对技术集中化表示担忧，同时也相信，大规模神经网络本身具备做出惊人成果的能力，而最前沿的 AI 并不存在多少“不可复制的魔法”，否则难以解释 OpenAI、Anthropic 和 Google 多年来结果如此接近。

作为一名程序员，antirez 称，自己现在比以往任何时候都更想写开源代码。他计划维护一些因时间原因被搁置的仓库，把 AI 引入 Redis 工作流，继续改进 Vector Sets，并像处理 Streams 一样，逐步优化其他数据结构。

与此同时，他对可能因此失业的人表示担忧。企业最终会走向哪种路径仍不明确：是雇佣更多人、构建更多产品，还是削减薪酬成本，仅保留少数擅长提示模型的程序员？在其他行业，人类甚至可能被完全取代，这让他感到不安。

针对社会层面的影响，antirez 表示：”创新一旦发生，就无法被收回。我认为，我们应该通过投票支持那些真正理解正在发生什么、并愿意为失业人群提供支持的政府。随着失业人数增加，政治压力也会随之增大，促使更多人支持能够提供一定保障的政策。“

此外，antirez 也对 AI 的积极影响抱有期待，比如推动科学进步、减少人类生活中的痛苦，而这种改善并不总是直接带来幸福，但确实能提升人类整体生存状态。

开发者质疑：自己的 AI 为什么没那么好用？

然而，antirez 的判断并非所有人都认同。

在 Hacker News 上，这篇文章引发了长时间讨论。一些开发者指出，目前的 AI 在复杂系统设计、长期维护和边界条件处理上依然存在明显不足。

正如 HN 热评第一的 totallykvothe 写道：

我一直无法理解这样一种说法：AI 现在已经可以自动化完成非简单的编程任务。

自从 GPT-3.5 发布以来，我几乎持续不断地在尝试这件事，几乎用遍了当下所有最先进的模型，从 GPT-5.1 Codex Max 到 Opus 4.5，没有例外。

每一次，AI 确实都能给我一个“能跑起来”的结果。但问题在于，当我开始对这些代码进行自我审查，准备提交给同事评审时，最终几乎都会重写其中大约 70% 的内容。AI 方案里有太多细节处理得不到位，很多时候甚至存在根本性的架构问题，以至于无论我怎么继续通过 prompt 去修正，都很难补救——哪怕我在整个原型阶段都深度参与、一步步引导。

到最后，我只能得出两个结论之一：

1）要么是我真的不擅长写 prompt。可问题是，我算是我身边最早一批把 AI 用在编码里的开发者之一，而且已经持续使用很多年了，这个解释我自己都很难接受。

2）要么就是其他人没我这么挑剔，或者他们的代码评审文化没那么严格，更容易放过质量一般的代码。

我实在想不出还有什么别的解释。

作为背景说明：我目前维护的是一个有 15 年历史的 Java Spring + React 的 Web 应用（其中还有一些老页面仍然使用 Thymeleaf）。系统包含多个子服务、两套独立的数据库，同时还需要与客户的硬件设备进行双向通信。

这当然不是一个简单的项目，但即便如此，我也很难相信它会比大多数企业级、遗留系统复杂到哪里去……

这种经历让不少开发者都感同身受。另一位网友补充道：

“到目前为止，我向大语言模型提出过的所有技术问题，只要是我自己已经知道答案的，几乎无一例外都会在某些方面出现明显错误。

我经常遇到的另一个问题，是错误率与响应速度之间的权衡。那些速度最快的前沿模型，错误频率高得惊人，错误程度也相当严重，以至于我根本不敢把它们当作可靠的搜索工具来用；而那些更大、更慢、花更多时间“思考”的模型，虽然给出的结果确实更好一些，但等待时间又长到让我觉得，与其等它们回复，不如直接自己去做一次网页搜索来得更快。

在我刚开始接触某个新领域，或者还没完全熟悉某个 API、语言或相关文档之前，这些模型确实能发挥一定作用。但一旦我花了些时间完成“入门”，哪怕只是顺着它们给出的链接自己看过几次资料，后续再查问题时，直接自己搜索反而更高效。”

除此之外，还有开发者担心，过度依赖 AI 可能削弱工程师对系统的整体理解。有人指出，这类工具更适合原型开发或中小项目，而非严肃的生产环境。

这些质疑并非毫无道理，反而说明，AI 在工程实践中的角色仍在快速演化，真正的价值和局限都还有待进一步验证。

逃避并不会让变化消失

即便如此，antirez 的态度依然明确：无论你认为什么才是“正确的道路”，拒绝眼前正在发生的事情，并不能让你掌控它。

他进一步指出：

“也许你会觉得，自己曾经那么努力学习编程，而现在机器却替你做了这件事。但当年熬夜写代码，只为了看到项目跑起来时，你真正追求的是什么？是‘创造’。现在，如果能找到有效使用 AI 的方式，你能够创造得更多，也创造得更好。那种乐趣依然存在，丝毫未减。”

对此有网友表示认同。HN 用户 daxfohl 写道：

“我同意你的看法，但想补充一点：过去几个月里，AI 发展出现了一次明显跃迁，现在这已经是一种不可避免的趋势。曾经我还在期待 AI 会撞上‘天花板’，到那时我们回头看，会觉得‘它们怎么可能取代程序员’这种想法很可笑。但现在，这件事看起来只是时间问题。

从更长远来看，我认为未来一到两年内，Anthropic 和 OpenAI 会把产品从‘编码助手’升级为‘工程团队替代方案’。这些产品可能内置完整的标准工具和框架，也会提供接口接入其他技术栈。它们的直接客户，可能不再是单个工程师，而是没有深度技术经验的产品团队。

我还预计，单体架构可能会回潮。现在采用微服务，很大程度上是为了并行开发和减少冲突。但如果 AI 能显著加快开发周期，这种优势就没那么重要；反而把业务逻辑放在一个统一‘容器’里，更便于 AI 整体分析和理解。”

antirez 最后提醒——「跳过 AI，不会对你或你的职业生涯有任何帮助。相比快速体验几分钟，他建议花几周时间，谨慎而深入地测试这些新工具。如果一开始不适合自己，可以隔几个月再尝试一次。」