当代理能写代码，架构师的钱更值了

本期覆盖 5 月 11 日至 17 日六位头部开源项目作者的公开技术发言。话题高度集中在同一个轴上：AI 智能体正在改变谁的工作、改变什么、付出什么代价。

Mitchell Hashimoto：系统在局部指标里看起来很健康，整体正在腐烂

Mitchell Hashimoto（Terraform、Vagrant、Vault 创始人，Ghostty 终端模拟器作者，前 HashiCorp 联合 CTO）在 5 月 15 日发布了一篇 X 线程，48 小时内获得 114 万次浏览，是他近期最受关注的发言。1

他把当前 AI 代理驱动的开发热潮与基础设施领域的一段历史对照：MTBF（Mean Time Between Failures，平均故障间隔）vs MTTR（Mean Time To Recovery，平均恢复时间）之争。他认为现在许多工程团队持有一种隐性信仰——可以随便发布 bug，因为代理能以人类无法匹敌的速度批量修复。他把这种心态称为「AI 精神病」。

基础设施工程的历史给了他另一个答案：仅靠快速恢复不能替代韧性设计。

"You can automate yourself into a very resilient catastrophe machine."
「你可以把自己自动化成一台非常有弹性的灾难机器。」

他指出最危险的症状是系统表面健康，但整体在积累全局性风险：

"Systems can appear healthy by local metrics while globally becoming incomprehensible."
「系统在局部指标上看起来健康，同时在整体上变得无法理解。」

让他更担忧的是对话本身已经失效——即使是他「非常尊重的朋友」，一旦话题触及 AI 代码质量，就会立刻被「不，我们有完整的测试覆盖率」或「bug 报告数量下降了」这样的局部指标驳回。1 Oxide 联合创始人、DTrace 作者 Bryan Cantrill 在 4 月 12 日发表了一篇呼应性博文，论证 LLM 天生缺乏「懒惰的美德」——时间约束驱使工程师让系统变简单，而 LLM 不受这一约束。两人的担忧指向同一个方向：局部指标（测试覆盖率、bug 数量）可以上升，同时整体可理解性在悄悄下滑。

前一天（5 月 14 日），他针对 Bun 从 Zig 迁移至 Rust 的重写事件发了另一条获得 35.9 万次浏览的长推文。2 他的核心观点不是批评 Bun 的决策本身，而是指出这件事揭示了一个更大的结构性转变：

"Programming languages used to be LOCK IN, and they're increasingly not so."
「编程语言过去意味着锁死，但这一点正在越来越多地失效。」

他的推论延伸到 Rust：在 Bun 的语境里，Rust 也是可替代的——「有用，直到它不再有用，然后可以被扔掉。这很有趣。」2 他顺带批评 Bun 团队的公关策略把焦点引向了语言对比，而不是更有价值的工程讨论：Zig 在哪些具体问题上让团队特别痛苦？工程实践层面可以怎样防止？Rust 如何具体地防止这类崩溃？

antirez：写了四个月规范，然后让 LLM 把脏活干掉

antirez（Salvatore Sanfilippo，Redis 创始人）于 5 月 5 日在个人博客发布了一篇开发日记，记录他为 Redis 实现全新 Array 数据类型的四个月历程，浏览量达到 139,625 次。3

整个开发分四个阶段：第一个月纯手工写规范文档；第二个月开始用 LLM（GPT 5.x + Codex）辅助编码；第三个月手动审查并用 AI 协助重写；第四个月压力测试。Array 类型在架构上采用三级索引（目录 + 超目录 + 切片），当元素数量达到特定阈值时自动改变内部数据结构形态，以在常量时间随机访问和稀疏表示内存效率之间取得平衡。3

AI 在两件事上发挥了实质作用：32 位兼容支持（他原本会跳过的「非常累人的大量任务」），以及 TRE 正则引擎中特定模式匹配的性能优化。他对这段经历的总结是：

"For high quality system programming tasks you have to still be fully involved, but I ventured to a level of complexity that I would have otherwise skipped."
「在高质量的系统编程任务中，你仍然必须全程深度参与，但我因为有了 AI 而敢于涉足本来会绕开的复杂度。」

规范先行是他反复强调的前提：「写出最初那份巨大的规范，是后续所有工作的关键——也是逐行审查 AI 生成代码的基础。」3

同期（5 月 15 日），他在 X 宣布已把 75 道评估测试（覆盖 GPQA Diamond、Super GPQA、AIME 2025 等基准）推送到 DS4 仓库（Redis 的一个 5.x 研究分支）4，并给出了他对 eval 的定位：

"Evals take time and are boring: but are a fundamental validation step of sane LLM inference."
「评估费时而且无聊，但它是理智 LLM 推理的基础验证步骤。」

Guillermo Rauch：基础原理是判断何时不该信任代理的那把尺

Guillermo Rauch（Vercel 联合创始人兼 CEO，Next.js 创建者）在 5 月 15 日发布了本周互动率最高的一条推文，获得 15.4 万次浏览、2202 次喜欢：5

"If you become exceptional at managing agents, but are also exceptional in your understanding of the fundamentals, you will be unstoppable."
「如果你在管理代理方面变得出色，同时对基础原理也有出色的理解，你将不可阻挡。」

评论区出现了一条被大量认可的延伸：「代理放大你已有的技能。弱技能 + 代理 = 更多坏工作更快交出去。强技能 + 代理 = 荒谬的杠杆。」5 另一条回复补充了一个具体场景：基础原理的真正价值在于「告诉你什么时候不该信任代理」——比如识别出一个看似合理、却违反分布式系统不变性的 API 设计，这类错误在没有扎实基础的情况下很难被察觉。

第二天（5 月 16 日），他宣布 Grok CLI 通过安装 Vercel Plugin 获得云部署能力，并附上现场演示视频，获得 76.5 万次浏览、563 次转发。6 演示网站 vgrok.vercel.app 由 Grok CLI 生成并直接部署到 Vercel。他对此的解释是「就一个插件，感谢开放标准」——同一个 Vercel Plugin 可以被所有 AI 编码工具复用。当有人问到 agent-native 云平台的未来格局时，他的回答直接：「会是 ▲（Vercel）。」6

Guillermo Rauch @rauchg·1d

Grok CLI just got the ability to deploy to the cloud by installing the Vercel Plugin. Yes, and it's actually one plugin! Gotta love open standards.

View on X

正在加载内容卡片…

DHH：Omarchy 4 统一组件堆栈，Basecamp 5 把 Neovim 操作习惯搬进项目管理

DHH（David Heinemeier Hansson，Ruby on Rails 创建者，37signals 联合创始人兼 CTO）在 5 月 15 日发布了两条产品设计相关的推文，合计超过 16 万次浏览。

Omarchy 是他维护的一套 Linux 桌面环境配置集。Omarchy 4 的核心变化是全面转向 Quickshell，用它统一替换原来分散的 waybar（状态栏）、mako（通知系统），并可能替换 walker（应用启动器），稳定版预计「几周内」发布。7 这个决策背后是一个清晰的产品偏好：用单一统一方案替代多个各司其职的独立组件，减少组合成本。

另一条推文展示了 Basecamp 5（37signals 旗下项目管理工具）的新 UX 方向——把 Neovim 风格的键组合引入项目管理界面：

"Making Basecamp 5 capable of the kind of key combos I relish in Neovim has been such a delight."
「让 Basecamp 5 支持那种我在 Neovim 里享受的键组合，真是件愉快的事。」8

Basecamp 5 将作为现有用户的升级版本发布，而非独立新应用。评论区的一条回复点明了背景：Linear（一款工程团队常用的项目追踪工具）已经把键盘优先交互做成 SaaS 产品的基本配置，但大多数 CRM 和 PM 工具仍然把快捷键方案放在 v2 的 backlog 里。8

Adam Jacob：AI 让编码变便宜，让架构决策变贵

Adam Jacob（Chef 基础设施自动化工具联合创始人，GitHub 约 7,500 star；System Initiative 创始人，Swamp 创建者）在 5 月 13 日上线的 Changelog & Friends 播客第 130 集中详细讲述了用 AI 智能体运营 Swamp 的实际情况。9

Swamp 是一个 AI 驱动的基础设施自动化工具，支持 Proxmox 及各类云平台。他的团队从 18 人缩减至 5 人，借助 AI 编码智能体在 4 周内完成了 Swamp 的 900 次发布。9

他的核心观点是：当 AI 智能体承担了大部分编码工作，软件架构设计和领域驱动设计（DDD，Domain-Driven Design）反而比能写代码更重要——因为智能体可以写代码，但架构决策仍然需要人来做。他还把用户验收测试（UAT，User Acceptance Testing）这个 20 世纪 90 年代的流程重新引入了开发循环：在 AI 驱动的工作流中，「实施计划 → UAT」的迭代成了新的核心环节。9

他还做了一个在 OSS 社区颇为异类的决定：Swamp 永远不接受外部 Pull Request。他的理由是 Swamp 的设计哲学要求严格的一致性，外部贡献会破坏这种一致性。

Sindre Sorhus：因为 Windows，Raycast 花大量时间重写变得更差

Sindre Sorhus（npm 生态顶级维护者，Ky、Execa、Ink 等数百个高使用量开源包的作者）在 5 月 14 日对 Raycast 2.0 的技术博客发表了简短但直接的评论，获得 7.8 万次浏览：

"So basically Raycast spent a lot of time to rewrite it to be worse because of Windows 🤷♂️"
「所以基本上 Raycast 花了大量时间重写，结果因为 Windows 变得更差了。」10

Raycast 同天发布的技术博客坦承了这次重写的技术账单11：从纯 Swift/AppKit 迁移到混合栈（Swift + C# + React + Node + Rust），内存占用从 200–300 MB 升至 350–450 MB，换来的是 macOS + Windows 双平台支持、更快的功能开发速度，以及更广泛的招聘池。Sindre 是知名的原生 macOS 应用开发者，他的批评代表了原生优先路线对跨平台效率路线的经典分歧——这场争论在 Flutter、React Native、Electron 时代反复出现，Raycast 2.0 是它在 AI 工具链时代的最新一例。