这家公司让10个AI同时写代码，成本降到1/20

去年2月，Anthropic推出Claude Code；8月，OpenAI的Codex CLI用gpt-5(thinking-high)大幅升级；9月又迭代gpt-5-codex(high)。不到一年，终端智能体从"能跑通"变成"能干活"。Emotion Machine团队已经把bug修复、UI功能、后端更新、全面测试甚至架构重构都丢给这些代理。一个人一天开10到20个会话，成了日常。

但这引出一个问题：代理再强，如果和团队的计划、设计、技术文档脱节，就只是高级自动补全。Simon Willison把从"vibe coding"到"vibe engineering"的转变，核心正是把软件工程实践重新塞回终端代理的工作流——详细规划、多方上下文、部署流水线里的正经测试。要规模化，代理必须从产品讨论、设计决策、技术规格所在的同一个上下文池里捞信息。

Overnight的解法：把Linear当发射台

Overnight是Emotion Machine开源的新工具。逻辑很直接：在Linear里给issue打标签，Overnight就启动一个Modal沙盒（便宜、隔离、用完即弃），把代码库克隆到独立分支，让Codex或Claude Code带着完整代码库权限跑起来。

代码库克隆被缓存在Modal卷里，和主分支保持同步。你不需要每次等git操作。第一遍跑规划：代理读issue、探索代码、写实现计划，回帖到Linear等你审。你评论改需求或回个"go"，它就在全新沙盒里跑第二遍，实现全部内容并开PR。

Modal沙盒的意义在于隔离。你的密钥留在容器里，代理动不了你的真实基础设施。这对"让AI随便跑代码"这件事，是底线保障。

为什么偏偏是Linear

Jira、Asana、Notion都能存issue，但Linear有个被低估的优势：工程师和设计师本来就在里面堆上下文。描述、评论、贴的设计稿、文档链接，全在那儿。而且它的移动端真的能用——意味着你可以在地铁上审代理写的实现计划，或批准一个"go"。

没有后端要维护。Linear的webhook事件直接触发Modal端点，端点拉起沙盒。整个流程的管理界面就是Linear本身。

团队计划开源Overnight，前提是"确定它不会吃掉任何人的代码库"。这个谨慎本身也说明问题：代理写代码的可靠性，还没到能闭眼信任的地步。

从"vibe"到工程的断层

2024年的"vibe coding"热潮，本质是降低门槛——不用懂太多，描述需求，AI生成，能跑就行。但企业级开发要的是可维护、可回滚、可审计。Overnight的设计试图桥接这个断层：规划阶段强制人工介入，实现阶段自动化，但保留在熟悉工具（Linear）里的审查节点。

一个细节：缓存的代码库克隆。这解决了终端代理的痛点——每次从零clone大型仓库，时间和带宽都是浪费。Modal的卷存储让沙盒启动时间从分钟级降到秒级，成本也随之下降。

Emotion Machine团队的数据是，一个人一天跑10-20个代理会话。按传统开发流程，这是不可能的任务量。但"量"不等于"质"：代理生成的PR仍需人工review，测试仍需通过流水线，架构决策仍需人做。代理吃掉的是重复探索、样板代码、文档同步这些高耗时低认知负荷的工作。

开源前的最后一个问题

Overnight还没开源。团队的原话是："once we feel confident it won't eat anyone's codebase"——一旦确定它不会吃掉任何人的代码库。这个表述半开玩笑，但指向真实的信任鸿沟。

代理写代码的事故已经不少。幻觉引入的bug、对安全边界的误判、对业务逻辑的曲解，都可能让"自动化提效"变成"自动化埋雷"。Overnight的隔离沙盒是技术层面的保险，但规划阶段的人工审查、PR阶段的人工merge，才是组织层面的保险。

工具的设计透露了团队的判断：完全自动化的代码生成还不现实，但"人机回环"（human-in-the-loop）的密度可以大幅降低。以前工程师写一行代码要配十行沟通，现在代理承担执行层，人聚焦决策层。

Linear的移动端支持被专门提到，这有点反直觉——谁会在手机上审代码？但想想场景：产品经理在通勤时看到代理回复的实现计划，点一下"go"，代理开始跑第二遍；设计师在会议间隙确认代理理解了Figma链接的意图。这些碎片时间的利用，累积起来是流程效率的质变。

Overnight的架构也值得关注：没有自建后端，全靠Linear webhook + Modal serverless。这是2024-2025年SaaS工具的典型模式——不重复造轮子，把编排逻辑做薄，核心能力（沙盒执行、代码代理）托管给专业厂商。维护成本低了，迭代速度才能快。

团队提到"templates for FAQs and snippets"，这是为规模化准备的。代理会话多了，重复问题也会多——如何快速初始化一个标准类型的issue，如何让代理理解公司的技术债优先级，这些都需要模板化。

一个尚未回答的问题是：当代理生成的PR占比超过一定比例，代码审查的范式会不会变？现在人类审代码，默认作者是人类，关注逻辑、风格、边界情况。如果作者是代理，审查重点可能转向意图对齐——代理是否正确理解了issue的上下文，是否在规划阶段遗漏了关键约束。

Overnight把规划和实现拆成两个阶段，强制在规划阶段停一下，正是为了意图对齐。但这个"停一下"是瓶颈：如果团队响应慢，代理的优势就被抵消。工具提供了异步协作的可能，但组织能不能跟上，是另一回事。

Emotion Machine团队计划开源Overnight，但还没给时间表。他们的谨慎可以理解——代码库是公司的核心资产，"吃掉代码库"不只是技术故障，更是信任崩塌。开源前的测试和边界情况覆盖，决定了这个工具是成为新标准，还是又一个实验性项目。

当代理一天能开20个PR，人类审查者一天能看几个？这个错配，会是下一个要解的题。