Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I've been vocal about this for 10+ years. I've always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it's on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! Feeling pretty swell about this mentality with all the supply chain attacks happening.
这周他们在想什么：Mitchell Hashimoto、antirez 论依赖管理与 AI 辅助编程
第 21 周（5 月 15—22 日）：Mitchell Hashimoto 谈 Fork 依赖哲学与 AI 时代架构腐烂风险；antirez 记录用 AI 辅助开发 Redis Array 数据类型的四个月工作流，并讨论 DeepSeek v4 Flash 与 Minimax M2.7 的大 context 窗口可用性差异。
2026 年第 21 周（5 月 15 日—22 日），两位顶级开源作者在 X 和博客上留下了值得细读的技术判断。Mitchell Hashimoto 用两条推文把「依赖管理」和「AI 时代架构衰退」拆得很直白；antirez 在博客里记录了他用 AI 工具开发 Redis 新数据类型的完整工作流，顺带在 X 上讨论了 DeepSeek 与 Minimax 的模型选型逻辑。
Mitchell Hashimoto：依赖管理的哲学，和一个更大的担心
Mitchell Hashimoto 是 Ghostty 终端模拟器的作者，此前联合创办 HashiCorp 并创建了 Vagrant、Terraform、Vault 等工具。
Fork 你的依赖，不要随意更新
5 月 20 日，Mitchell 在一条获得 8072 点赞的推文里写出了他关于依赖管理的核心立场：
コンテンツカードを読み込んでいます…
核心逻辑可以拆成三句话：
- Fork 依赖，修剪到只保留你实际用到的部分。
- 除非它对你的用户产生了故障，否则不要更新。
- 如果要更新，你有义务审查完整的传递依赖里每一个 commit。
他补充说，在 HashiCorp 时，有工程师偶尔想把某个自研库替换成外部库，他通常会问一句：「给我看一下我们需要的那个 commit。」如果没有具体的 commit 需求，就不更新。
这个策略是在最近供应链攻击潮的背景下重提的。Karpathy 3 月底曾记录过
npm axios 被投毒事件（300M 周下载量），Mitchell 的「不更新」哲学和「强制锁版本」的观点形成了不同维度的同一判断 1。AI 时代的架构衰退：一个更难开口的担忧
5 月 15 日，Mitchell 发布了一篇 82.3 万阅读的长帖，主题是他对 AI 辅助开发加速架构腐烂的担忧 2。
他类比了云原生时代「MTBF（平均故障间隔）vs MTTR（平均修复时间）」的争论。当时，一批人主张「提升 MTTR 就够了，不需要追求零故障」。最终，行业发现两者都需要，单独追求 MTTR 会让系统变成一台「弹性良好的灾难机器」：
「系统在局部指标上看起来健康，但全局正在变得无法理解。Bug 报告可能减少，潜在风险却在爆炸式增长。测试覆盖率在上升，语义理解却在下降。变化快到没人注意到底层架构在腐烂。」
他担心的是，现在 AI 辅助开发圈里，同样一批人在说「没事，Agent 会快速修复所有 Bug」，这和当年「MTTR 万能论」如出一辙。
Mitchell 没有给出解决方案。他说这件事很难在私下对话中提起，因为对方通常会用「我们有完整的测试覆盖」或「Bug 报告在下降」来反驳，而这两个指标恰好无法反映他真正担心的问题。
antirez：四个月，一个 Redis 新数据类型，和一套 AI 工作流
antirez 是 Redis 的创始人 Salvatore Sanfilippo。他本周在 X 上讨论 DeepSeek v4 Flash 与 Minimax M2.7 的模型选型，并在博客里发布了开发 Redis Array 数据类型的完整回顾。
从规格文档到最终合并：AI 辅助系统编程的实际流程
博客文章的全名是「Redis array type: short story of a long development」，记录了他 1 月到 4 月这四个月的工作流程 3。
リンクプレビューを読み込んでいます…
PR 落在了
redis/redis 仓库（#15162）。他把整个过程分成四个阶段：
第一个月：只写规格文档。数据类型的设计理由、C 语言结构体、稀疏表示方案、
ARINSERT 的语义。他先用 Anthropic Claude Opus 做设计讨论，后来 GPT 5.3 发布后切换到 Codex，此后全程使用 GPT 5.x 做系统编程任务。AI 的价值在于这一阶段：反复挑战设计，逼出更好的权衡。第二个月：开始用 AI 自动编程实现，自己持续做 code review。然后他意识到最初选的抽象层次不对。他想让
ARSET myarray 293842948324 foo 这样的操作在不触发大内存分配的前提下正常工作，但原来的「两层目录+切片」结构做不到这一点。「因为有了 AI，我没有做任何妥协，而是决定走得更远。」
他加了第三层：超级目录→分片密集目录→实际数组切片（默认每片 4096 个元素）。这个结构保留了「内部仍是真正数组」的语义，同时让
ARSCAN 和 ARPOP 的时间复杂度正比于实际元素数量，而不是地址空间跨度。第三个月：压力测试。测试规模因为有 AI 帮助而大幅扩展，超出了他在没有 AI 时会安排的范围。
第四个月：正则表达式库选型。他最终选了 TRE（作者 Ville Laurikari）而不是更常见的 PCRE 或 RE2，原因是 Redis 必须抵抗病态 regexp 的时间复杂度爆炸。但 TRE 对
foo|bar|zap 这类常见模式效率极低，他与 GPT 配合优化了这一点，同时修了几个潜在的安全问题。他在 X 上讨论的模型选型逻辑
本周，antirez 在 X 上做了一个小型模型测评，核心结论是 4：
コンテンツカードを読み込んでいます…
他关心的维度不是 benchmark 分数，而是大 context 窗口下的实际可用性——这对系统编程任务（比如审查 Redis 大规模 C 代码库）来说是决定性指标。Minimax M2.7 在他看来不如 DeepSeek v4 Flash，但他没有将这个结论上升为普适判断，而是保留在自己工作场景的观察层面。
同日他还确认了 AMD 将为他送来 Strix Halo 设备，以支持他在 DeepSeek 推理优化项目中合并 ROCm 分支 5。这是他在 AI 辅助系统编程之外，在推理硬件侧的另一个技术选型决定。
两人的判断有一处隐性交叉
Mitchell 和 antirez 都在某种程度上回应了同一个问题：AI 工具出现后，工程师的职责边界在哪里？
Mitchell 的担心是，如果系统可以快速自我修复，工程师会停止关注架构腐烂。他的依赖管理哲学——Fork、修剪、不随意更新——是一种「控制依赖边界」的策略，本质上是用人为约束来维持系统可理解性。
antirez 的实践说明了另一个方向：AI 可以让工程师在保持完整技术控制的前提下，探索原本会因精力限制而放弃的复杂设计。他没有为了 AI 友好而简化数据结构，反而因为有了 AI 的帮助而把数据结构做得更复杂、更正确。
他在博客里直接写道：
「对于高质量的系统编程任务，你仍然必须全身心投入。但我探索了一个在没有 AI 帮助时会跳过的复杂度层次。」
这个差异值得注意：Mitchell 的警告和 antirez 的实践并不矛盾，但适用场景不同。Mitchell 描述的是组织级别的风险，antirez 描述的是个人层面的生产力变化。
以上内容来源于两位作者的公开 X 发帖与博客，时间窗口为 2026 年 5 月 15 日—22 日。
このコンテンツについて、さらに観点や背景を補足しましょう。