Adam Storm and Rafi Shamim, senior engineers at Cockroach Labs, spent five months starting in April 2026 running a group of coding agents like a teaching hospital. It was not a company-wide change in how software gets built. The two started it as their own experiment. Issues were patients, a merge was a discharge, and the human was the “Chief of Medicine.” The two run the agents overnight and review the results in the morning. As they put it, “A full day of meetings can now lead to 10 high quality merged PRs.” But in the same post, they gave a whole section the title “We built a teaching hospital that doesn't really teach” and wrote that the setup does not fit new engineers well.
They split planning, coding, and review across AI agents, and no code could be written until a plan passed review
The pipeline is called MOLT Sinai. MOLT is the company's database migration tool, and Sinai is the agent hospital that develops it. There are 15 agent roles, all driven by GitHub Actions and issue labels. A single issue moves through these steps.
- Triage Nurse
Sorts incoming issues. - Fellow
Diagnoses the problem, writes a plan, then implements the approved plan. - Review Attending
A separate agent, launched independently of the Fellow, reviews the plan and the code and sends the work back to the Fellow when it falls short. - Discharge Nurse
Audits whether the review followed the process. It does not check the code itself. - Chief of Medicine (human)
Takes the problems the agents could not resolve among themselves, decides them, and records each decision as precedent for later calls.
The core rule is “No code before a plan, no plan without review.” The agents were told “Don't improvise.” Turning off tests or weakening them was banned. Reviewers first check that the new tests fail with the change removed, and any change over 1,000 lines gets split.
Whether this design actually works has not been confirmed. On Hacker News, Storm said of splitting the author and reviewer roles that “we haven't validated that it does,” and added that they had not run ablations, removing components one at a time to compare. He also said the work is the two engineers' “side project”.
The agents added support for a new database in two days, rejecting each other's work 55 times and asking a human only twice
On a Wednesday evening in April 2026, the two put one issue into the hospital: adding IBM Db2 support to MOLT (“Support Db2 LUW for convert/fetch/verify #526”). The Fellow writing the plan broke it into 15 sub-issues and set the order of what to build first. When the work wrapped up Friday afternoon, the sub-issues had grown to 32, and 27 PRs had been merged.
Along the way, the Review Attending sent the Fellow's work back 55 times. Nine problems were escalated because the agents could not settle them, and only two of those reached the human Chief. No human wrote any code, and the token bill came to $4,172.
The company compared this with adding Oracle support to the same tool in 2024. The post says “the equivalent work took 9 months, and cost around $160K in engineering time,” and calls the new run “164x faster, and 38x cheaper.” The two projects added support for different databases, and the post only calls them equivalent work. Rex Factor, in a VarOps column, wrote that these figures should be read as the company's claim. The reasons: the company set 2024 human costs against 2026 token costs, left the human time spent on Db2 out of the math, and the code on the faster side is still being verified. On Hacker News, tujux split $160K across 9 months and $4,172 across two days and got a daily rate of about $600 for the humans and about $2,086 for the agents, so per day the agents cost more. thomascountz countered that people cost more than their salaries.
No human reviewed the first Db2 code, and it is still being checked. After that, every change needed human approval before merging
The authors say that during the hospital's early trial, “we weren't reviewing any of the code that the hospital wrote.” So the correctness of the Db2 code is being checked now. They wrote that its test coverage matches the company's PostgreSQL support, its best-tested piece.
After the first week of fully autonomous runs, the two turned on “human approval mode,” so every change an agent proposed merged only after a person approved it. They wrote: “It was only in this mode that we could be certain that the code was high enough quality to ship to customers.” The post places the Db2 work in that first trial, when humans were not reviewing code, but the public account gives no dates, so it is unclear whether that trial is the same period as the first autonomous week. From then on, while agents wrote the code, the humans' job became approval and judgment.
The operating numbers below come not from the actual product repository but from a separate copy the two kept, a mirror repository. They cover April 21 to September 11, 2026, a span that includes the first week of autonomous runs without human approval.
| Metric | Count |
|---|---|
| Merged code changes (PRs) | 1,238 |
| Changes reverted after merging | 7 |
| Issues closed | 1,322 |
| Issues agents created for other agents | 1,299 |
| Issues sent to the human Chief | 92 |
| Median PR size | 527 lines added |
| Claude token cost since April | A little over $135,000 |
The 7 reverts are merged changes that were later undone. The 55 send-backs mentioned earlier happened during review, before merging, so the two numbers come from different stages.
The speedup did not make the human share disappear. An issue usually stays in the hospital for a day or two, and the post says that time is “often dominated by the time spent waiting on a human reviewer”. Citing this passage, VarOps argued that the cost of producing code dropped, but the cost of trusting it moved to human review. The authors put the average at about $84 per issue but did not say which issue count they divided the $135,000 in tokens by. VarOps pointed out that dividing by the table's 1,322 issues or 1,238 PRs gives more than $100.
Some reviews dragged on. A one-line fix marked urgent (issue 1777) went through 11 rounds of rework over two days. In turn, it got held up on comment cleanup, a wrong claim in the PR description, small gaps from the plan, test quality, two rebases, two workflow failures, and the human approval step. Afterward, the two built a mechanism that automatically stops rework past a set limit and escalates it. It kicks in after four consecutive rounds in which the reviewer raised a new blocking issue each time, or after six meaningful rounds in total. They wrote that they do not yet have data showing it works.
Built for seniors who judge from experience, the setup falls short for new grads still learning to judge, the two wrote
The authors are open about who the hospital was built for. The post describes MOLT Sinai as “exactly what you'd expect to see built by two senior engineers (with over 40 years of collective industry experience).” This paragraph comes right after the line about merging 10 PRs on a day full of meetings.
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.
In this setup, the human does the Chief's job: deciding the 92 issues the agents could not resolve, approving every merge, and leaving precedents that set the standard for later calls. Only humans create precedents, and agents read the precedent record before escalating a problem to the Chief. Planning and implementation belong to the Fellow agent. What the post says new grads lack is exactly the judgment built from experience that this approving and deciding requires.
Storm also drew a limit on the teaching-hospital metaphor. On Hacker News, he replied: “medical students learn to become doctors. Cheaper models never learn to become more capable models, so the metaphor is not apt.” In this hospital, the ones who can learn and grow are the people, not the agents, and the current setup has only one place for a person to practice judgment: the Chief's seat.
So they are building a way for new grads to write the plan themselves and defend it before agent reviewers
The two wrote that they are “currently working on” a feature that lets a person pick up a triaged issue, write the plan, and have the hospital's agents review it. A person takes over the planning the Fellow agent does now, while agent reviewers such as the Review Attending still do the review. During review, the person is asked to defend their decisions and gets pushback urging them to consider alternatives. They can also write the code themselves from the approved plan: small fixes by hand, the rest in interactive LLM sessions.
The post also describes a case where plan review caught a serious problem. A fix was meant to strip host names and database names from customer logs. While reviewing the plan for the fix, not the code, the Review Attending found a small gap through which information could still leak. The authors wrote that catching it at the code review stage would have been “highly unlikely.” Fewer than 10% of reviewed plans were rejected. Going by the post's examples, the important judgment calls happen before any code is written, when the plan is drafted and reviewed.
The authors wrote that the new-grad feature aims to have new engineers learn the codebase, weigh implementation tradeoffs as they go, and be evaluated in the code review that follows. But the feature is still a plan with no results. The public account does not say how many new grads take part or what improved. The post appears on the engineering blog of a company that sells a migration tool, it carries a hiring link, and the pipeline runs on Anthropic's Claude models. It ends: “we'll still need people with sound judgement and critical thinking skills.”
New engineers have built judgment by writing code and having it reviewed. On a team that hands code writing to agents, new engineers have nowhere to learn judgment unless someone deliberately makes room for that practice. The place the two engineers' experiment found is the step before code: writing the plan yourself and defending it before agent reviewers.
Further reading
Five months treating bugs like patients and coding agents like a medical team Cockroach Labs' original post, covering the 15 roles, the rework limit, the prompt audits, and the planned changes for new grads. cockroachlabs.com
Hacker News discussion The thread where author Adam Storm replies directly, noting what hasn't been validated and where the metaphor breaks down. news.ycombinator.com
Producing code with AI agents and trusting it are two separate costs The VarOps column that picks apart the 9-months-versus-two-days comparison and the missing math behind $84 per issue. varops.com