87
4欢迎听众打赏支持，您的支持是我不断创作的动力🍻
- Mitchell Hashimoto
- Ghostty 是一款快速、功能丰富且跨平台的虚拟终端仿真器，它使用平台原生 UI 和 GPU 加速。
- 跨国串门儿计划
AI 总结
Mitchell Hashimoto's new way of writing code (2026-02-26, gemini-3-flash-preview)
这是一份基于 Mitchell Hashimoto 近期访谈的深度研报。Mitchell 作为HashiCorp 的联合创始人，曾主导开发了 Terraform、Vagrant等改变云基础设施规则的工具。如今他离开管理一线，以独立开发者和观察者的身份，重新定义AI 时代的编程范式。
1. 导读
在硅谷的叙事中，Mitchell Hashimoto是一个特殊的坐标：他不仅凭借一己之力推动了“基础设施即代码”（IaC）的普及，更在一个工程师驱动的公司里完成了从开源到商业化的艰难跃迁。如今，当行业普遍迷失在AI 幻觉与生成式代码的狂潮中时，Mitchell却回归到了最原始的“手艺人”状态——开发一款极致性能的终端 Ghosty。
这场对话不仅是对 HashiCorp创业史的回溯，更是一次关于“软件工程尊严”的辩论。Mitchell在这里揭示了他如何与傲慢的云巨头博弈，为什么他认为 AI正在摧毁开源社区赖以生存的信任体系，以及他如何通过“始终运行一个Agent”的策略，在效率巅峰期保持着一种近乎冷酷的清醒。读完你会发现，真正的技术变革，往往发生在人类决定“不把时间浪费在什么地方”的那一刻。
2. 核心观点
Mitchell Hashimoto的核心世界观可以概括为：*软件工程的本质正从“编写逻辑”转向“意图调度与约束管理”。*在他看来，AI带来的不是单纯的效率提升，而是对软件开发生命周期的重构——从代码的版本控制（Git的局限）到社区的准入机制（开源信任的崩塌），所有基于“人类精力有限”这一假设建立的旧秩序都在失效。他主张开发者应该像管理一支廉价但不可靠的实习生团队一样管理AI，将重心从“造物”转移到“构建测试支架（Harness）”上。
关键判断
- 开源社区的“默认信任”模式已经终结。 Mitchell 指出，AI让制造“看起来像样但低质量（Slop）”的代码成本降为零。过去开源项目通过观察贡献者的“努力程度”来建立信任，而现在Agent 可以瞬间提交成百上千个PR。他断言，所有主流开源项目必须转向“默认拒绝（DefaultDeny）”和“显式背书（Vouching）”的准入系统，否则会被 AI生成的垃圾信息淹没。
- 云巨头的性格决定了生态位的生存策略。 基于多年与 AWS、Azure 和 GoogleCloud 的博弈，Mitchell 总结了三大巨头的技术文化：AWS是极其傲慢且具有掠夺性的（时刻准备用原生产品杀死合作伙伴）；Microsoft则是极其职业且具备共赢思维的（优先问：我们如何共同获利？）；Google拥有顶尖的技术审美，却在商业感知上几乎完全失明。这一判断解释了为什么HashiCorp 必须坚持多云策略，因为中立性不仅是技术需求，更是政治生存。
- Git 正面临其“Gmail 时刻”。 现有的 Git工作流（克隆、分支、合并队列）是为人类的产出速度设计的。Mitchell观察到，在高度 Agent 化的公司中，代码流转速度提升了 10-100 倍，Git的性能和冲突解决机制在巨大的代码吞吐量面前开始崩溃。他预言版本控制系统需要从“快照记录”转向“全量上下文索引”，不再允许丢弃任何一次尝试。
- 开发者正进化为“支架工程师（Harness Engineer）”。 Mitchell提出一个反直觉的习惯：无论是否在写代码，后台始终运行一个 Agent负责调研或处理琐事。他认为，为了让 Agent 输出高质量结果，开发者 70%的精力将花在构建“验证环境”和“测试规格书”上。如果 AI犯了错，不要去修代码，而要去修那个“防止 AI 犯错的支架”。
- 性能是软件工程中最后的“匠心堡垒”。 在开发 Ghosty 时，Mitchell执着于将渲染延迟压缩至 10微秒以内。他承认这在商业上可能“溢出”，但认为在 AI生成代码泛滥的时代，对底层细节（如 GPU 内存管理、SIMD指令集）的极致把控，是区分“真正的工程师”与“代码调度员”的唯一标志。
这些观点构成了一个逻辑链条：因为 AI 降低了生产成本（产生垃圾PR），所以我们必须提高过滤标准（信任背书制）；因为代码生成不再是瓶颈，所以验证代码的正确性（HarnessEngineering）和底层运行效率（极致性能）成了新的核心竞争力。
3. 批判与质疑
尽管 Mitchell 的论述极具前瞻性，但其体系中仍存在一些值得考量的盲点。
首先，他提倡的 “显式背书系统（Vouching System）” 虽然能解决 AI垃圾贡献问题，但极易导致开源社区的 精英阶层固化。这种类似“Lobsters”社交网站的邀请制，会增加新人入行的隐形门槛，可能扼杀那些非科班出身、缺乏社交资本但有潜力的天才开发者。
其次，他在 AI 工作流中对 “始终运行 Agent”的依赖，隐含了一个未经验证的前提： 开发者具备极强的任务拆解能力和 Review心理阈值 。普通开发者在面对 Agent生成的源源不断的代码片段时，极易陷入“决策疲劳”，最终为了追求速度而放弃深度审查。这种“幻觉累积”可能在短期内表现为高产，但在长期维护中会埋下巨大的技术债。
此外，Mitchell 对 Git 衰落 的断言虽然激进且有趣，但忽略了工具链的巨大惯性。Git不仅仅是技术，更是全球软件工业的“共同协议”。即便它在 Agent协作中效率低下，更有可能的结果是插件式的补丁（如 Merge Queue的普及）而非彻底的范式更迭。
4. 行业视野
Mitchell 的分析将我们带入了一个 “后开源时代（Post-Open Source Era）” 。
在行业历史图谱中，这场对话呼应了 2010年代初从“本地服务器”向“云原生”转型的剧烈震荡。正如当年 AWS的崛起让运维工程师（Admin）转型为 SRE，现在的 AI浪潮正在让编码者转型为意图架构师。
他提到的 AWS对开源软件的“武器化”（利用开源协议直接推出商业服务）曾引发了 Elastic 与Redis 等公司的许可协议大战。Mitchell的观点预示着这种冲突的第二阶段：冲突点不再仅仅是商业利益的分配，而是 协作契约的失效 。当AI可以模拟人类行为去贡献开源代码时，开源作为一种“社会化生产方式”的根基正在动摇。这种趋势印证了近年来行业内对“主权代码”和“受控生态”的回归。
5. 启示与建议
这场对话强化了一个核心假设： 编程的门槛正在消失，但构建稳定系统的门槛正在指数级提高。
给不同读者的建议
对开发者：
- 改变学习路径：不要只练习写逻辑，要练习写“规格说明书（Spec）”和“验证用例”。当你发现AI 做错时，第一反应应是更新你的=agents.md=（约束文件），而不是手动修改那几行代码。
- 构建“后台意识”：练习在处理高难度思维任务时，将一个低难度的调研任务（如：对比三个库的性能、查找特定协议的边缘案例）外包给Agent。习惯“并发工作”，而非“线性写码”。
对技术领导者与创始人：
- 预算权大于技术优劣： 像 Mitchell早期反思的那样，企业采购软件不看它是开源还是闭源，而看“谁的预算付钱”。在设计AI 驱动的 B端产品时，优先搞清楚你的产品解决的是安全预算、网络预算还是人力预算。
- 重新评估人才背景：寻找那些能够长时间进入“深度流（Flow）”且不频繁切换上下文的人。Mitchell指出，最优秀的工程师往往是那些在社交媒体上“隐身”、工作专注度极高的9-to-5 职业选手。
对开源维护者：
- 建立“防御性”准入制：即使你的项目目前还小，也要考虑引入自动化检测或人工背书机制，防止被AI 生成的无效 PR 耗尽精力。
信号判断： Mitchell 对 AI改变编程节奏的观察是 强信号 ，具有极高的实践价值；而他关于“Git 将在 5年内消失”的论断更多是基于极端场景的 合理推断 ，不必急于抛弃现有的版本控制技能。
6. 金句摘录
- "AI makes it trivial to create plausible looking but incorrect andlow-quality contributions." （AI让创造那种看起来像模像样、实则错误且低质量的贡献变得易如反掌。）—— 语境：讨论为什么开源社区必须放弃“默认信任”贡献者的旧习。
- "Hitting the merge button is the easiest step. It's the years ofmaintaining whatever you just merged… that's the hard part."（点击“合并”按钮是最简单的一步。难的是在那之后的数年里，你必须在产品路线图、Bug修复和客户需求中持续维护你刚才合并的东西。） —— 语境：提醒开发者fork 一个项目很容易，但接手维护意味着无尽的责任。
- "Use AI as a way to choose what you think about." （将 AI视为一种让你能够自主选择“该思考什么”的工具。） —— 语境：反驳“AI让人变笨”的论点，主张将平庸的思维过程外包，保留核心创造力。
- "We are at the 'Gmail moment' for version control."（我们正处于版本控制系统的“Gmail 时刻”。） ——语境：预言未来代码管理将不再需要删除分支或清理尝试记录，而是全量存储与语义检索。
收听方式
反馈 ✉️
- 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net
