Cockroach Labsのシニアエンジニア、Adam StormとRafi Shamimは、2026年4月から5か月間、複数のコーディングエージェントを教育病院のように運営しました。会社全体で開発のやり方を変えたのではなく、2人が独自に始めた実験です。イシューは患者、コードのマージは退院、人間は「内科部長（Chief of Medicine）」と呼びます。2人は夜通しエージェントを走らせ、朝に結果をレビューします。原文には「会議で丸一日が埋まっても、質の高いPRを10件マージできるようになった（A full day of meetings can now lead to 10 high quality merged PRs.）」とあります。ところが2人は同じ記事に「教えない教育病院をつくってしまった（We built a teaching hospital that doesn't really teach）」という節を設け、このやり方は新人にはうまく合わないと書いています。
2人はAIエージェントに計画・実装・レビューを分担させ、計画がレビューを通るまでコードを書かせませんでした
2人がつくったパイプラインの名前はMOLT Sinaiです。MOLTは同社が販売するデータベース移行ツールで、Sinaiはそのツールを開発するエージェントの病院です。エージェントの役割は15種類あり、すべてGitHub Actionsとイシューのラベルで動きます。1件のイシューは次の順に進みます。
- Triage Nurse
届いたイシューを振り分けます。 - 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）」と答え、構成要素を1つずつ外して比べる実験（ablation）もしていないと述べました。この取り組みが2人の「サイドプロジェクト（side project）」であることも明かしています。
新しいデータベース対応をエージェントが2日で仕上げ、その間エージェント同士で55回差し戻し、人間に尋ねたのは2回だけでした
2026年4月のある水曜日の夜、2人はMOLTにIBM Db2データベースへの対応を加えるイシュー1件（“Support Db2 LUW for convert/fetch/verify #526”）を病院に入れました。計画を書くFellowはこれを15件のサブイシューに分け、何から作るかの順番を決めました。金曜日の午後に作業が終わったとき、サブイシューは32件に増え、27件のPRがマージされていました。
その間、Review AttendingはFellowの作業を55回差し戻しました。エージェント同士で解決できず上の段階に上げた問題は9件で、そのうち人間のChiefまで届いたのは2件でした。人間が書いたコードはなく、トークン費用は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）」と表現しています。2つは別々のデータベースへの対応で、原文は「同等の作業」と言っているだけです。VarOpsのコラムでRex Factorは、この数字を同社の主張として読むべきだと書きました。同社は2024年の人件費と2026年のトークン費用を並べ、Db2にかかった人間の時間は計算から外しており、速いとされた側のコードはまだ検証中だというのが理由です。Hacker Newsのtujuxは、16万ドルを9か月で、4,172ドルを2日で割って1日あたりの単価を出すと、人間側は約600ドル、エージェント側は約2,086ドルで、1日あたりではエージェントのほうが高いと指摘しました。thomascountzは、人にかかるコストは給与より大きいと反論しています。
最初のDb2のコードは人間がレビューしておらず、いまも確認中です。その後はすべての変更を人間が承認してからマージしました
著者たちは、病院を初めて試していた間「病院が書いたコードを一切レビューしていなかった（we weren't reviewing any of the code that the hospital wrote）」と明かしています。そのためDb2のコードが正しいかは、いま確認しているところです。テストカバレッジは、社内で最もよくテストされているPostgreSQL対応と同じ水準だと書いています。
自律で回した最初の1週間のあと、2人は「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の作業を、人間がコードをレビューしていなかった最初の試行のこととして書いていますが、その試行が自律で回した最初の1週間と同じ期間なのかは、公開された説明に日付がないため分かりません。このときから、エージェントがコードを書く間、人間が担う仕事は承認と判断になりました。
下の運用データは実際の製品リポジトリではなく、2人が別に用意した複製リポジトリ（ミラーリポジトリ）で数えたものです。期間は2026年4月21日から9月11日までで、人間の承認なしに自律で回した最初の1週間も含まれています。
| 項目 | 数 |
|---|---|
| マージしたコード変更（PR） | 1,238件 |
| マージ後に取り消した変更 | 7件 |
| 処理を終えたイシュー | 1,322件 |
| エージェントが別のエージェントのために作ったイシュー | 1,299件 |
| 人間のChiefに回ったイシュー | 92件 |
| PRの規模の中央値 | 527行の追加 |
| 4月以降のClaudeのトークン費用 | 13万5千ドル強 |
取り消した7件は、いったんマージした変更をあとで取り消した数です。先に見た55回はマージ前のレビュー段階で差し戻した回数なので、2つは別の段階の数字です。
速くなった分だけ人間の役割が消えたわけではありません。イシューはふつう病院に1〜2日とどまりますが、原文はその時間について「多くは人間のレビュー担当を待つ時間が占めている（often dominated by the time spent waiting on a human reviewer）」と書いています。VarOpsはこの箇所を根拠に、コードを作るコストは下がったが、そのコードを信頼するコストは人間のレビューに移ったと見ています。著者たちはイシュー1件あたり平均約84ドルかかったと書いていますが、トークン費用13万5千ドルをどのイシュー数で割ったのかは明かしていません。VarOpsは、表にあるイシュー1,322件やPR1,238件で割ると100ドルを超えると指摘しました。
レビューが長引いた例もありました。緊急と表示された1行の修正（イシュー1777）は、2日間で11回の手直しを経ました。コメントの整理、PR説明の誤った主張、計画との小さなずれ、テストの質、2回のリベース、2回のワークフロー失敗、人間の承認段階に順に引っかかったのです。2人はその後、手直しが決まった回数を超えると自動で止めて上の段階に回す仕組みを作りました。レビュー担当が毎回新しいブロッキングの問題を指摘する手直しが4回続くか、意味のある手直しが合計6回になると回します。ただし、この仕組みが効果を上げたというデータはまだないと書いています。
経験で判断できるシニア向けのこの仕組みは、判断をまだ学んでいる新人には合わないと2人は書きました
著者たちは、この病院が誰のために作られたかを隠していません。原文はMOLT Sinaiを「業界経験を合わせて40年を超えるシニアエンジニア2人が作れば、まさにこうなるという構造（exactly what you'd expect to see built by two senior engineers (with over 40 years of collective industry experience)）」と紹介しています。会議で埋まった日でもPRを10件マージできるという一文のすぐ後に、この段落が続きます。
予定が詰まっているわけでもなく、数十年の経験で培われるソフトウェアの判断力もまだない新人はどうでしょうか。このモデルは彼らにも合うのでしょうか。手短に言えば、新人のニーズを十分には満たしていません。
（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しかありません。
そこで2人は、新人が自分で計画を書き、エージェントのレビュー担当の前でそれを弁護する機能を作っています
2人は、人間が振り分け済みのイシューを引き取って自分で計画を書き、その計画を病院のエージェントにレビューしてもらう機能を「現在作っている（currently working on）」と書いています。いまFellowエージェントが担っている計画づくりを人間が代わりに引き受け、レビューはこれまでどおりReview Attendingのようなエージェントのレビュー担当が行う形です。レビューの間、人間は自分の判断を弁護するよう求められ、ほかの選択肢を考えるよう反論を受けます。レビューを通った計画をもとに、自分でコードを書くこともできます。小さな修正は手で、それ以外は対話型のLLMセッションで書きます。
計画レビューの段階で重要な問題を見つけた例も原文にあります。顧客のログからホスト名とデータベース名を消す修正がありました。Review Attendingはコードではなくその修正の計画をレビューしているときに、情報がまだ漏れうる小さな隙間を見つけました。著者たちは、コードレビューの段階でこの隙間を見つけられた可能性は「きわめて低い（highly unlikely）」と書いています。レビューを受けた計画が差し戻される割合は10%未満でした。原文の例を見る限り、重要な判断はコードを書く前、計画を書いてレビューする段階で生まれています。
著者たちは、新人向け機能の目的を、新人がコードベースに慣れ、実装のトレードオフをその都度見極め、その結果としてのコードレビューで評価を受けられるようにすることだと書いています。ただし、この機能はまだ結果の出ていない計画です。何人の新人が参加しているのか、何が良くなったのかは公開された説明にありません。この記事は移行ツールを販売する会社のエンジニアリングブログに掲載されたもので、採用ページへのリンクが付いており、パイプラインはAnthropicのClaudeモデルで動いています。原文は「健全な判断力と批判的思考力を持つ人は、これからも必要だ（we'll still need people with sound judgement and critical thinking skills.）」で締めくくられています。
新人はこれまで、自分でコードを書いてレビューを受けることで判断力を身につけてきました。コードを書く仕事をエージェントに任せるチームでは、その練習の場をあえて作らない限り、新人が判断を学ぶ場所はありません。2人の実験が見つけた場所は、コードを書く前の段階です。自分で計画を書き、その計画をエージェントのレビュー担当の前で弁護することです。
さらに詳しく知りたい方へ
Five months treating bugs like patients and coding agents like a medical team 15の役割、手直しの上限の仕組み、指示文の監査、新人向けの見直し計画までを収めたCockroach Labsの原文です。cockroachlabs.com
Hacker Newsの議論 著者のAdam Storm本人が回答し、検証していない部分やたとえの限界を明かしたスレッドです。news.ycombinator.com
Producing code with AI agents and trusting it are two separate costs 9か月対2日の比較と、イシュー1件あたり84ドルの計算の空白を検証したVarOpsのコラムです。varops.com