Cockroach Labs的资深工程师Adam Storm和Rafi Shamim从2026年4月起，用五个月时间把一组编码智能体当作教学医院来运营。这不是全公司改变开发方式，而是两人自己发起的实验。issue是病人，代码合并是出院，人则被称为“内科主任（Chief of Medicine）”。两人让智能体通宵运行，早上再审查结果。原文写道：“即使开了一整天会，现在也能合并10个高质量的PR（A full day of meetings can now lead to 10 high quality merged PRs.）”。但两人在同一篇文章里专门写了一节《我们建了一所不怎么教人的教学医院（We built a teaching hospital that doesn't really teach）》，指出这套做法并不太适合新人。
两人让AI智能体分工负责计划、实现和审查，计划没通过审查就不许写代码
两人搭建的流水线叫MOLT Sinai。MOLT是这家公司销售的数据库迁移工具，Sinai则是开发这个工具的智能体医院。智能体共有15种角色，全部靠GitHub Actions和issue标签驱动。一个issue会依次经过以下环节。
- Triage Nurse
对新进来的issue进行分类。 - Fellow
诊断问题、写出计划，再按批准的计划实现。 - Review Attending
一个独立于Fellow启动的智能体审查计划和代码，不合格就把工作退回给Fellow。 - Discharge Nurse
审计的不是代码，而是审查是否按流程进行。 - Chief of Medicine（人）
接手智能体之间解决不了的问题并做决定，再把这些决定留作后续判断的先例。
规则的核心是“没有计划不写代码，没有审查不执行计划（No code before a plan, no plan without review.）”。他们给智能体写明“不要即兴发挥（Don't improvise.）”，并禁止关闭或削弱测试。审查者先确认去掉改动后新测试会失败，改动超过1,000行就要拆分。
这套设计是否真的有效，目前还没有得到证实。Storm在Hacker News上谈到把编写者和审查者分开的设计时回答“我们还没有验证它是否有效（we haven't validated that it does）”，还表示没有做过逐一去掉组件进行比较的消融实验（ablation）。他也说明，这是两人的“副业项目（side project）”。
智能体两天就接上了新数据库支持，期间互相退回55次，只问过人两次
2026年4月的一个周三晚上，两人把一个为MOLT增加IBM Db2数据库支持的issue（“Support Db2 LUW for convert/fetch/verify #526”）送进了医院。负责写计划的Fellow把它拆成15个子issue，并排好了先做什么。到周五下午完工时，子issue增加到32个，合并了27个PR。
这期间，Review Attending把Fellow的工作退回了55次。智能体之间解决不了、上报到更高一级的问题有9个，其中只有2个到了身为人的Chief手里。人没有写任何代码，token费用为4,172美元。
公司把这次工作和2024年为同一工具增加Oracle支持的工作做了对比。原文说当时“同等的工作花了9个月，工程人力成本约16万美元（the equivalent work took 9 months, and cost around $160K in engineering time）”，并称这次“快164倍，便宜38倍（164x faster, and 38x cheaper）”。两者支持的是不同的数据库，原文只说是“同等的工作”。VarOps专栏作者Rex Factor写道，这些数字应当被视为公司的说法。理由是：公司拿2024年的人力成本和2026年的token费用作对比，把Db2投入的人工时间排除在计算之外，而且被说成更快的那一方的代码仍在验证中。Hacker News用户tujux把16万美元除以9个月、4,172美元除以两天，算出日均成本人工约600美元、智能体约2,086美元，按天算智能体反而更贵。thomascountz则反驳说，人的成本不止工资。
最早那批Db2代码没人审查过，至今仍在核实；此后每个改动都要人批准才能合并
作者们坦言，在最初试运行医院期间，“我们没有审查医院写的任何代码（we weren't reviewing any of the code that the hospital wrote）”。因此Db2代码是否正确，目前还在核实。他们写道，其测试覆盖率与公司测试最充分的PostgreSQL支持处于同一水平。
完全自主运行的第一周过后，两人开启了“human approval mode”，智能体提交的每个代码改动都必须经人批准才能合并。原文写道：“只有在这种模式下，我们才能确信代码的质量足以交付给客户（It was only in this mode that we could be certain that the code was high enough quality to ship to customers.）”。原文把Db2工作写成没有人审查代码的首次试运行期间的事，但公开说明里没有日期，所以无法判断那次试运行和自主运行的第一周是不是同一段时间。从这时起，智能体写代码期间，人负责的工作变成了批准和判断。
下面的运行数据并非来自真正的产品仓库，而是来自两人另外维护的副本仓库（镜像仓库）。统计时间为2026年4月21日至9月11日，其中也包括无需人批准、完全自主运行的第一周。
| 项目 | 数字 |
|---|---|
| 合并的代码改动（PR） | 1,238个 |
| 合并后又被回滚的改动 | 7个 |
| 处理完成的issue | 1,322个 |
| 智能体为其他智能体创建的issue | 1,299个 |
| 交给人类Chief的issue | 92个 |
| PR规模中位数 | 新增527行 |
| 4月以来的Claude token费用 | 13.5万美元出头 |
回滚的7个是已经合并、后来又撤销的改动。前面提到的55次是在合并前的审查阶段退回的次数，两者属于不同阶段的数字。
速度上去了，人的那份工作并没有消失。issue通常会在医院里停留一两天，原文说这段时间“往往主要花在等待人类审查者上（often dominated by the time spent waiting on a human reviewer）”。VarOps据此认为，生产代码的成本降下来了，但信任这些代码的成本转移到了人的审查上。作者们写道，每个issue平均花费约84美元，却没有说明13.5万美元的token费用是除以哪个issue数得出的。VarOps指出，用表中的1,322个issue或1,238个PR去除，结果都超过100美元。
也有审查拖得很长的例子。一个标为紧急的一行修复（issue 1777）在两天里经历了11轮返工。它先后卡在注释整理、PR说明里的错误表述、与计划的细微出入、测试质量、两次rebase、两次工作流失败，以及人工批准环节。两人随后做了一个机制：返工超过设定次数就自动停下，升级到更高一级。审查者每次都指出新的阻塞问题的返工连续出现4次，或者有意义的返工累计达到6次，就会升级。不过他们写道，目前还没有数据表明这个机制有效。
这套做法是为凭经验做判断的资深工程师设计的，两人写道，它不太适合还在学判断的新人
作者们并不讳言这所医院是为谁建的。原文介绍MOLT Sinai时说，它“正是两位资深工程师（行业经验合计超过40年）会搭出来的样子（exactly what you'd expect to see built by two senior engineers (with over 40 years of collective industry experience)）”。这一段紧跟在“会议排满的日子也能合并10个PR”那句话之后。
那么新人呢？他们的日程没有排满，也还没有几十年经验换来的软件工程判断力。这种模式对他们管用吗？简单说，它不能完全满足新人的需要。
（But what about the new-grad who doesn't have a full calendar, the software engineering judgment that decades of experience buys...? How does the model work for them? In short, it doesn't fully meet their needs.）
在这个结构里，人做的是Chief的工作：接手智能体之间解决不了的92个问题并做决定，批准每一次合并，留下作为后续判断标准的先例。先例只能由人来定，智能体在把问题上报给Chief之前，会先读这些先例记录。写计划和实现的环节由Fellow智能体负责。原文指出新人欠缺的，恰恰是这种批准和决策所需的“靠经验积累的判断力”。
Storm也承认教学医院这个比喻有局限。他在Hacker News上回答：“医学生会学着成为医生，但便宜的模型永远不会学着变成更强的模型，所以这个比喻并不恰当（medical students learn to become doctors. Cheaper models never learn to become more capable models, so the metaphor is not apt.）”。在这所医院里，能边学边成长的是人而不是智能体，而现在的结构中，人能练习判断的位置只有Chief一个。
于是两人正在做一项功能：让新人亲手写计划，并在智能体审查者面前为它辩护
两人写道，他们“正在开发（currently working on）”一项功能：让人领取已分类的issue，亲自写计划，再交给医院里的智能体审查。也就是由人接手现在Fellow智能体负责的写计划工作，审查仍由Review Attending这类智能体审查者来做。审查过程中，人会被要求为自己的决定辩护，也会受到反驳，被要求考虑其他方案。通过审查的计划，人也可以自己动手写代码：小修改手写，其余用交互式LLM会话来写。
原文里也有在计划审查阶段抓到重要问题的例子。有一项修复要从客户日志中删除主机名和数据库名。Review Attending审查的不是代码，而是这项修复的计划，结果发现了一个仍可能泄露信息的小漏洞。作者们写道，如果到代码审查阶段，发现这个漏洞的可能性“极低（highly unlikely）”。经过审查的计划被驳回的比例不到10%。从原文的例子看，重要的判断出现在写代码之前，也就是写计划和审查计划的阶段。
作者们写道，面向新人的功能，目的是让新人熟悉代码库，随时权衡实现上的取舍，并在由此产生的代码审查中接受评估。不过这项功能还只是一个没有结果的计划。有多少新人参与、改善了什么，公开说明里都没有。这篇文章发表在一家销售迁移工具的公司的工程博客上，附有招聘链接，流水线跑的是Anthropic的Claude模型。原文的结尾是：“我们仍然需要具备良好判断力和批判性思维的人（we'll still need people with sound judgement and critical thinking skills.）”。
新人一直是靠亲手写代码、接受审查来练就判断力的。把写代码交给智能体的团队，除非专门留出这种练习的位置，否则新人就没有地方学习判断。两人的实验找到的位置在写代码之前：亲手写计划，并在智能体审查者面前为它辩护。
想深入了解
Five months treating bugs like patients and coding agents like a medical team Cockroach Labs的原文，涵盖15种角色、返工上限机制、指令审计，以及面向新人的改造计划。cockroachlabs.com
Hacker News讨论 作者Adam Storm亲自回复的讨论串，说明了哪些部分尚未验证，以及比喻的局限。news.ycombinator.com
Producing code with AI agents and trusting it are two separate costs VarOps专栏，剖析了9个月对两天的比较，以及每个issue 84美元背后的计算空白。varops.com