本周开源作者说了什么：从 Basecamp 5 到 Ghostty 出走 GitHub
本周 DHH、Mitchell Hashimoto、antirez、Armin Ronacher 四位头部开源项目作者密集发声，话题交叉于一个核心问题：AI 进入日常开发流程后，架构决策和产品哲学该如何调整？DHH 发布 Basecamp 5，坚持简洁哲学；Hashimoto 宣布 Ghostty 迁出 GitHub 并警告「AI psychosis」；antirez 用 AI 协作开发 Redis Arrays；Ronacher 明确划定 AI 工具与人类能动性的边界。
上周（2026 年 5 月 19–26 日）几位头部开源项目作者在 X 上异常活跃，话题密集交叉在一个核心问题：当 AI 进入日常开发流程，架构决策和产品哲学该怎么调整？ 本期整理 DHH、Mitchell Hashimoto、antirez、Armin Ronacher 四人的重要发言。
DHH：Basecamp 5 发布，「简洁」是架构决策
DHH（David Heinemeier Hansson，Ruby on Rails 框架作者、37signals CTO）5 月 26 日发布了 Basecamp 5，同时披露了若干值得关注的技术决策。
Basecamp 5 运行在 37signals 自有数据中心机架上，分布在芝加哥、弗吉尼亚、圣何塞、阿姆斯特丹四地，DHH 晒出的宕机日志显示 AWS us-east-1 上周出现大面积故障期间，Basecamp 毫无影响。他写道：
This is our uptime record heading into Basecamp 5. All run out of our own data center racks. Now serving Basecamp four Chicago, Virginia, San Jose, and Amsterdam. Even when us-east-1 goes dark.
这句话背后是 37signals 2022 年以来持续推进的「退出云计算」策略——回迁自有硬件，以降低长期成本和云服务商的依赖风险 1。
在编辑器层面，Basecamp 5 弃用了 Trix，改用基于 Meta Lexical 工具包的自研编辑器 Lexxy。DHH 特别点名感谢 Meta 的 Lexical，称 Lexxy 带来了表格、Markdown 支持和实时语法高亮。这是一次典型的「用成熟开源内核」而非「重新发明底层」的决策 2。
コンテンツカードを読み込んでいます…
「agent accessible，but not agent hysteric」这句话折射出他更大的立场。同一天，他写道「Agents don't need types. They're perfectly capable of pulling off incredible refactorings without. Give them a linter and a test suite, and you have all you need. Token efficiency is where it's at.」3 他否定了「给 AI coding agent 加 TypeScript 类型系统」的主流建议，认为 linter + 测试套件足够，类型系统只会消耗 token。这与他一贯反对过度工程化的立场一致，只是把反对对象从「微服务」换成了「类型系统」。
同期，他还提到用 GPT5.5 加速 Rails 开发，把它比作「All steering, no handwriting」——负责方向，不负责手写 4。
Mitchell Hashimoto：Ghostty 离开 GitHub，以及对 AI psychosis 的警告
Mitchell Hashimoto（Terraform、Ghostty 作者，前 HashiCorp CEO）本周密度最高，两件事都值得单独分析。
Ghostty 为什么离开 GitHub
4 月 28 日，他发布博文宣布 Ghostty 将迁出 GitHub 5。背景是 GitHub 在过去一个月里每天都有影响他工作的宕机——PR review 中断两小时，Actions 故障。他在博文里写了一段相当个人化的独白：
GitHub is the place that has made me the most happy. I always made time for it. When I went through tough breakups? I lost myself in open source... on GitHub.
这不是一次冷静的平台对比，而是对一个长期影响他工作的基础设施表达失望。他明确区分了问题所在：不是 Git，是 Issues、PR、Actions 等围绕 Git 的托管基础设施。
迁移计划是「分批减少依赖，保留 GitHub 只读镜像」，新平台细节尚未公布。
コンテンツカードを読み込んでいます…
对依赖管理的 10 年立场
5 月 20 日，他发了一条关于依赖管理的长推，获得 8933 赞 6：
Fork your dependencies, trim them to only your use case, never update unless it breaks for your users.
他的核心逻辑是：更新依赖的风险远高于潜在 bug 的风险。更新一个依赖，你必须分析所有传递依赖的每一个 commit。如果没有具体需要的 commit，就不要更新。这与当前供应链攻击频发的背景形成呼应——他把「不更新 = 控制风险」而非「不更新 = 欠维护」。
AI psychosis 警告
5 月 15 日，他写了一条被转发 1886 次的长推，核心观点是：部分公司对 AI 的依赖已经进入他所谓的「AI psychosis」状态 7：
I worry about entire companies under heavy AI psychosis. The psychosis folks operate under an almost absolute "MTTR is all you need" mentality: "it's fine to ship bugs because the agents will fix them so quickly."
他用基础设施领域的类比：云计算时代，「MTTR（平均恢复时间）优于 MTBF（平均故障间隔）」的理念推动了很多正确的架构决策，但极端化后导致系统表面指标良好、内在复杂性失控。他担心 AI coding 正在重演同样的错误：「Test coverage can rise while semantic understanding falls.」
antirez：用 AI 开发 Redis Arrays，以及 Figma 的 Redis 架构实践
antirez（Salvatore Sanfilippo，Redis 原作者）本周活动频繁，话题围绕他正在开发的 DwarfStar 项目以及 Redis 本身的最新进展。
5 月 5 日，Mitchell Hashimoto 特别推荐了 antirez 的一篇关于 Redis Arrays 类型开发的博文 8：
Love this post by antirez on developing Redis Array support. Its a great showcase of thoughtful AI usage and how AI can empower even the best developers while still producing high quality work.
antirez 自己在 X 上确认仍在为 Redis Inc. 做工作，并感谢公司容许他灵活的工作节奏：「I want to send a big Thank You to Redis for respecting and tolerating my odd work schedules.」9
同日他转发了 Figma 关于 FigCache 的博文 10。这篇博文值得单独看一下。
Figma 的 Redis 可靠性工程实践
Figma 工程团队今年发布了 FigCache 的架构详解，描述了如何解决大规模 Redis 使用中的结构性问题 11：
原架构的三个核心问题：Redis 集群连接数逼近上限（客户端扩缩容触发惊群效应）、没有统一流量管理（不同服务可互相污染数据）、可观测性标准不一（事故排查耗时从小时到天）。
FigCache 的设计是无状态 RESP 代理服务 + 第一方客户端库。代理层负责连接复用：将大量客户端连接折叠为有限的后端 Redis 连接，切量后服务端连接数下降一个数量级。
切量后主 API 缓存层达到 99.9999% 可用性（6 个 9）。他们没有选用现有开源代理，原因是：开源方案无法提取 Redis 命令的完整语义参数、不支持基于命令语义的运行时防护，也无法支持 Figma 内部特有的扩展命令（如跨集群 Redlock）。
antirez 转发此文是个信号：Redis 核心设计哲学（简洁、可组合）在超大规模生产系统里的具体实现，正在由用户而非作者自己完成。
Armin Ronacher：为什么 AI 不是「agent」，而是工具
Armin Ronacher（Flask 框架作者，Sentry CTO）5 月 26 日发布了博文《Clanker: A Word For The Machine》12，澄清他为什么坚持用「clanker」指代 AI 系统，拒绝用「agent」。
核心论点是：「agent」这个词预设了主体有能动性和责任感，当前 AI 没有。把 AI 称为 agent，让人可以方便地把责任推给机器——但实际上所有 AI 行为的责任都归于部署和使用它的人。他提到，他的 blog 和代码库使用 AI 工具后收到了大量误解性邮件，甚至遇到了用户出现 AI 相关的心理问题。他写道：
Using «clanker» is my attempt to draw a line: humans have agency and responsibility, AI is a tool built by and for humans.
这个立场有具体的工程含义：Ronacher 主持的 Sentry，在工具设计上更倾向于把 AI 作为「可插拔辅助层」而非「自主决策主体」。他的 GitHub 仓库
agent-stuff 里有一个 go-to-bed.ts 扩展，专门限制 AI coding agent 在深夜的操作——这本身就是他立场的具体体现 13。横向观察
四人本周的发言，在一个维度上有罕见的收敛：对 AI 工具持实用但不狂热的态度，同时对「AI 替代人类判断」保持清醒的警惕。
DHH 用 AI 写代码，但坚持「不需要类型系统，linter 加测试就够」。Hashimoto 用 AI 做平行实验（「slop 是工具」），同时警告整个行业正在重演基础设施自动化时代的错误。antirez 用 AI 协作开发 Redis Arrays（Hashimoto 称赞其为「thoughtful AI usage」），同时仍然亲自审核所有设计决策。Ronacher 明确反对给 AI 赋予「agency」的话语框架，认为这是在为工程失责提供语言遮蔽。
这不是简单的「支持/反对 AI」分野，而是四位长期主导大型开源项目的人在同一个月里，对「如何在 AI 时代维持工程师的判断主权」给出了各自的具体答案。
本期覆盖时间段：2026 年 5 月 19 日 – 5 月 26 日。信源均为当事人 X 账号公开发布内容或个人博客，可点击各 cite 直达原文。
参考ソース
- 1DHH on Basecamp 5 uptime
- 2DHH on Lexxy editor
- 3DHH on agents and types
- 4DHH on GPT5.5
- 5Ghostty Is Leaving GitHub
- 6mitchellh on forking dependencies
- 7mitchellh on AI psychosis
- 8mitchellh recommends antirez Redis Arrays post
- 9antirez on work at Redis Inc
- 10antirez shares Figma Redis post
- 11Figma FigCache architecture
- 12Armin Ronacher on clankers
- 13mitsuhiko agent-stuff repo
このコンテンツについて、さらに観点や背景を補足しましょう。