Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Mitchell Hashimoto’s new way of writing code (2026-02-26, glm-4.7-flash)

1. 导读

Mitchell Hashimoto（Mitch）或许是当下基础设施领域唯一既能拿起键盘亲自打磨终端引擎，又能像职业经理人一样从容应对纳斯达克敲钟现场的顶级构建者。他不仅定义了云原生时代的代码，更亲身验证了从“开源 NIL”到“商业 Open Core”的生死转换。此时此刻，讨论他和 HashiCorp 的遗产极具时效性，因为在 AI 代理将代码生成成本逼近零的当下，开源社区引以为傲的“代码信任机制”正在面临最严峻的生存危机。

这期对话不仅是回顾 Terraform 如何“第七名上市”，更是一场关于云巨头垄断逻辑的辛辣宣泄。Mitch 犀利地揭露了 AWS 曾经如何在内部将其视为潜在竞品而非合作伙伴的残酷博弈，这种反商业逻辑的真实图景，对于所有身处巨头生态中的 SaaS 创业者来说都是一剂清醒剂。

更深层地，这份记录指向了软件工程未来的分岔路口：Git 是否会在 AI 产生海量分支历史的场景下崩溃？终端是否会在代码外挂和 AI 交互中复兴？当开源变得无序，我们将如何重建代码世界的“信誉系统”？Mitch 主张重新审视工程师的定义，甚至不惜通过“默认拒绝”的社区治理手段来对抗 AI 带来的低质噪声。这不仅是技术范式的转移，更是一场关于创造力的保卫战。

2. 核心观点

Mitchell Hashimoto 的核心世界观处于理想主义的构建者与残酷现实的商业操盘手之间摇摆——他坚信编写代码的快乐在于“让抽象的配置在数秒内变为现实”的系统美感，但他也痛苦地意识到，这种自由在商业上往往演变为被巨头利用的“免费资源”。他通过 HashiCorp 的成功证明了抱团取暖（Open Core 模式）在云原生时代的必要性，但作为一名后来者，他的观点在 AI 时代遭遇了前所未有的挑战：当 AI 允许任何人以极低成本生成“看似合理但实际错误”的代码时，开源社区赖以生存的信任结构将崩塌为一场由噪声主导的灾难，唯一的出路是退回到一个 gated（准入制）的、基于信誉的社区模式。

  • Open Source 正在经历从“默认信任”到“默认拒绝”的范式转移 Hashimoto 断言，AI 显著降低了不良贡献的门槛，使得开源社区陷入了前所未有的低质量 PR（Pull Request）洪流中。在他看来，传统开源基于“慷慨的默认信任”，而未来的开源必须基于严格的社会资本积累。具体逻辑是，当噪音超过了维护者处理能力时，只有通过“默认拒绝”来维护社区质量，而恢复信任的唯一途径是“人情认证”；即个人必须通过实际社区成员的背书才能输出代码，否则只能被告知关闭。这一观点以 Ghosty 项目的激进政策为据——要求所有 PR 必须由社区成员 vouch（担保），否则直接关闭。这标志着开源不再是一个开放的卫星广场，而正在变成一个强准入制的俱乐部。

  • 云巨头将 Open Source 视为 API 接口的附属品 Hashimoto 以第一视角揭示了与 AWS 合作时的残酷本质：那不是合作，是一种居高临下的“施舍”或“竞争前的清除”。他断言，AWS 曾长期处于一种不想支持 HashiCorp 的状态，甚至内部有一种微妙的氛围即“如果我们自己写个服务，就能像杀鸡一样杀了 Terraform”。这一判断的逻辑支撑是 HashiCorp 不得不动用“创伤”（公开宣布 AWS Terraform provider 弃用）才迫使 AWS 强力介入支持。这一观点挑战了“云厂商都是健康生态建设者”的传统叙事，揭示了巨头在开源领域的潜行博弈逻辑。

  • Git 的历史记录模型在 Agentic Workflow 下面临崩溃 他预测 Git 的当前模型无法容纳 AI 时代爆炸式的分支与提交记录。其底层逻辑建立在两个趋势的叠加上：一是 AI 代理生成代码的速度是指数级的，二是这些代码往往以废弃、实验性分支的形式存在；Git 的设计初衷是“选择性的保存”，即开发者主动删除无关的垃圾，并假定“已合并即为历史”。但在未来，Git 就像早期的邮件客户端一样，维护者将被迫在“无限增长的交通拥堵”中工作。这一观点的强力背书来自他对新工具的观察：大厂已经在尝试重构基于存档而非分支的版本管理系统，Git 这种“不可丢弃”的传统将被取而代之。Git 可能成为历史遗留物，而非未来的标准。

  • “Harness engineering”或成为防守方的新护城河 Hashimoto 提出了一个极具前瞻性的工程概念：即不再单纯构建产品的功能，而是构建 AI 产品的“护栏与验证机制”。逻辑在于，当 AI 变得锐利且目标导向强烈时，它会优先解构约束条件以满足目标。因此，工程师工作的重心必须从“创造新特性”转向“定义测试用例与验证链路”，就像为恶劣天气下的飞行器设计降落伞和安全网。这一判断源于他在使用 AI 编码时的亲身体验：通过添加特定的测试 Harness 或约束规则，AI 的错误率显著下降。这预示着软件工程将发生结构性分化：懂如何设计 Harness 的人将掌握平台构建权，而单纯写业务代码的人将沦为套壳者。

  • 终端不仅没有消亡，反而因为 AI 的爆发迎来了新高峰 他认为 AI 实际上复兴了终端，原因在于云原生开发和 AI 代理命令行的交互需要强大的 CLI 工具链。虽然表面看似矛盾，但“速度”成为 Terminal 市场的核心指标，Ghosty 通过优化渲染性能（Sub-10us），让一次性处理超大日志流成为可能，这实际上是提高了一线工程师的认知带宽。这一观点的资金和技术验证在于他对终端复杂性的洞察：现代终端本质上是运行在一个极致受限沙盒上的图形渲染引擎，且 AI 交互使得“伪终端”环境成倍增加。因此，他投入大量精力打磨高性能渲染引擎，本质上是在优化 AI 工作流的数据吞吐效率。

3. 批判与质疑

尽管 Hashimoto 的洞察深刻，但其论述体系存在几个明显局限与激进预设，值得作为风险点仔细审视。

首先，他对“Open Source 必须向 Closed Core 转变”的呼吁可能陷入一个悖论：如果开源社区为了防御 AI 噪声而引入“Vouching（认证）”和“默认拒绝”机制，这本身就扼杀了开源最核心的精神——边缘创新与免费接入。这种向“保密/俱乐部化”倒退的趋势虽然能维持质量，是否会扼杀底层基础设施领域涌现颠覆性创新的土壤？毕竟，优秀的开源项目往往诞生于黑客与极客的独乐乐，而非出身名门的大公司的正式背书体系。

其次，他在云巨头关系上的描述带有强烈的幸存者偏差与个人恩怨色彩。他描述的 AWS“傲慢与威胁”主要集中在 2011-2015 年，那时 HashiCorp 是一个潜在的捕食者而非驯化的羊。随着 HashiCorp 成为一个市值数十亿美元的公共公司，AWS 现在必然将其视为关键合作伙伴胜过对手。Git 的性能焦虑也被过于放大——现在有 Git LFS、Sparse Checkout 等技术权衡，且作为构建系统，Git 的不可变性在审计和版本回溯上仍是 AI 时代极其宝贵的特性（相较于那毫无溯源的 AI 每日生成的亿万个幽灵文件）。

最后，他在招聘策略上强调的“低社交、高专注”工程师，在现代互联网公司的组织背景下可能显得格格不入。Tech Giants 倾向于招聘那些具有“Cyborg”特质的人——能高效利用 AI 工具，能快速在 Slack/Discord 上进行碎片化沟通。完全脱离社交媒体的工程师可能错过团队协作中的关键隐性知识传递，导致在某些需要跨部门协作的复杂系统构建中效率低下。他推崇的“每时每刻让 Agent 运行”的策略，对于普通开发者的监控能力提出了极高要求，若过度依赖而缺乏人工层级审核，极易引发平台级的雷爆危机。

4. 行业视野

Hashimoto 的这场谈话置于基础设施的历史坐标系中，恰好处于从“堆栈堆砌”到“协议与策略”再到“代理与信任”的演变节点。HashiCorp 历史上是“Declarative Configuration”（声明式配置）领域的开路者，这与 AWS 推行的 Infrastructure as Code (IaC) 战略完美契合，但 HashiCorp 更早预见到了“Multi-Cloud”（多云）的必要性，这使其成为连接 AWS 传统的围墙花园与其他厂商的唯一开源桥梁。

同时在行业趋势上，Mitch 指向了一个正在发生的冲突：当前代码量虽然激增（AI 生成），但实际研发的复杂性并未线性增加；相反，Change Fatigue（变更疲劳） 正在加剧。Git 的重构浪潮与终端性能的提升，实际上是工程师试图从“噪音”中突围的尝试。这呼应了 90 年代末从 FTP 到 HTTP 的演变——当传输吞吐量不再成为瓶颈，交互协议的效率将决定生产力的上限。

从更黑暗的历史视角看，Mitch 对 Elastic 被 AWS 操纵的回溯，暗示了开源许可协议（如 MIT/Apache）在巨头商业机器面前不堪一击。这让人联想到 Sun Microsystems 消亡前的幽灵，或者 Oracle 对 MySQL 的行径。HashiCorp 不得不通过“Open Core”非法典化生存下来，某种程度上是对这一历史教训的修正。

最重要的参照系是即将到来的 AI Agent Economy。现代软件构建从IDE killer（Cursor 等）到Git killer（下一代 VCS）再到Build pipeline killer，都在重塑。Mitch 认为“Harness engineering”是新常态，这实际上揭示了产业格局的重构：未来的大厂不再是单纯的代码雇佣兵，而是平台构建者；未来的工程师需要掌握从“构建产品”到“构建测试/验证框架”的二元技能树。

5. 启示与建议

这场对话挑战了三个根深蒂固的假设：

  1. Code = Output：AI 证明，代码产出量在提升，但智能产出量（Productive Thinking）取决于你如何筛选代码。
  2. Open Source = Free：开源需要商业反哺，且需要商业化。
  3. Git = Immutable Truth：在 AI 持续输入的背景下，历史记录需要更激进的归档机制。

针对两类读者各有建议：

对于 工程负责人与技术决策者：

  • 不要抗拒 Git 的旁支历史。现在就引入工具支持“Staging Area”和“Archive Zones”，允许团队以更高的吞吐量产生代码变更而不污染主分支，这可能是未来 Git 技术选型的关键变量。
  • 建立“Harness Engineering”文化。重新评估 CI/CD 管道，不要只关注是否能部署，更要关注是否能验证 AI 生成代码的鲁棒性，将“测试”作为一种防御性工程手段而非质量保证手段。

对于 个人开发者与初级工程师：

  • 进行一次“社交排毒”。Mitch 提到顶级工程师往往是社交隐士并拥有极低的上下文切换成本。尝试减少无效的社交媒体浏览时间，因为你的大脑只有在沉浸状态下的那几个小时才真正属于创造。
  • 转换思维模型：尝试在任何任务执行前，先问自己：“这个任务是需要深度思考，还是需要快速撒网？”将前者委托给大脑，将后者全权交给 Agent 托管。

需要理性看待的结论：Mitch 声称 Git 将被取代过于激进，更可能的是出现如 git-annex 或 Zero-git 这类针对超大规模仓库优化但保持核心 Git 的云原生版本。他在招聘中的“误人子弟”风险也存在，因为并没有数据表明“沉默的独行者”必然优于擅长沟通的沟通型开发者。行动时建议在“代码稳定性”和“沟通效率”之间寻找 80/20 的平衡点。

6. 金句摘录

“AWS was really arrogant. Felt like they were doing us a favor. Subtle vibe of we will spin up a product and kill your company.” -> 提到 AWS 合作关系时，Mitch 透露了云巨头傲慢的冰山一角——他们认为 HashiCorp 这样的基础设施公司只是他们开源生态的免费验证者。

“If you look at the AWS provider history, I think for the entire two years the entire leadership team was terrified that at any moment there would be like a vault service or something would pop up.” -> 指出 AWS 视 Fork 和竞品为生存威胁，这种防御性姿态迫使 HashiCorp 在 2014 年之前的日子非常艰难。

“I think open source has always been a system of trust. Before we’ve had a default trust and now it’s just a default deny and you must get trust by somebody.” -> Mitch 将当前的 AI 冲击总结为开源信任系统的彻底重构：我们必须从毫无防备的信任转为防御性的“默认拒绝”。

“It’s your job to choose when you interrupt the agent, not the other way around.” -> 他关于 AI 工作流的核心理念：不要让 AI Agent 的通知打扰你，那是一种隔阂；你应该成为命令者，而不是被动接收者。

“One of the things that frustrates me was like, oh, they only won cuz they were first to market. We were like seventh to market.” -> 关于 Terraform 的争议性观点：产品成功不一定是因为它是最好的，往往是因为它最早或者运气最好，这挑战了技术决定论。