In April, Cockroach Labs added support for IBM Db2 sources to MOLT, its tool set for moving databases to CockroachDB. According to the company's blog, the work took less than two days, from a Wednesday evening to a Friday afternoon, and no human wrote any of the code. A pipeline of AI coding agents did the work, orchestrated by a system the company calls MOLT Sinai and designed to resemble a teaching hospital.
The headline figures are striking. Cockroach Labs says that when it added Oracle support to the same tools in 2024, the equivalent work took nine months and roughly $160,000 in engineering time. The Db2 token bill came to $4,172, which the company puts at 164 times faster and 38 times cheaper. Those comparisons come from the vendor itself, so they are worth reading alongside the details of how the work was done.
What Db2 support required
IBM Db2 is one of the earliest commercially available relational databases. It has a rich SQL dialect, a complex type system and a native wire protocol, all of which made it a demanding target. Adding it to MOLT meant several separate components: a new schema converter, a Fetch path to pull rows from the source and load them into CockroachDB, a Verify path to compare data after loading, a vendored ANTLR grammar, a Docker image for continuous integration, and more than ten thousand lines of test fixtures.
The original request arrived as a single GitHub issue. A planning agent judged it too large to handle at once and split it into fifteen sub-issues with an explicit dependency graph, running from the foundation and type system through row iteration, Fetch, Verify, Convert, continuous integration and test data. Two of those sub-issues were themselves considered too large and were broken down again. Along the way, agents opened about a dozen further issues covering gaps they found in their own work.
By the time the parent issue closed, Cockroach Labs reports that 32 sub-issues had been opened, 27 pull requests had merged, reviewers had sent work back 55 times, and nine issues had been escalated, two of them to a human engineer. Measured against PostgreSQL, the project's best-tested dialect, the company says test coverage was equivalent.
Why build a hospital?
Cockroach Labs says the design started from a concern about trust rather than speed. Its databases are expected to preserve correctness above all else, and a subtle bug in a migration tool could corrupt customer data on its way in. The company argues that the useful question is not how many pull requests an agent can produce in an hour, but how many of them the team would be embarrassed to merge itself.
That reasoning led the company away from the throughput-focused designs that have proliferated over the past year. It points to Gas Town, which runs many agents in parallel with a merge layer to resolve collisions, and to a Cursor experiment that rebuilt SQLite so quickly that it needed a custom version control system. Both are presented as useful for speed but not designed to ship database code to customers. Instead, the team looked for a model used to manage high-stakes work by staff of uneven ability, with mandatory handoffs and second opinions. A teaching hospital fit that description. The name MOLT Sinai is a nod to Mount Sinai, a prominent teaching hospital in both Toronto and New York, the cities the company's team calls home.
How the hospital works
In this model, every GitHub issue is a patient. Its progress is tracked through labels on the issue and through scratch files that record each patient's chart. Each stage is a GitHub Actions workflow that starts when its incoming label is applied. When an agent finishes, it writes a structured note marked with a sentinel comment so that later agents can find and parse it, then applies the next label. Rejected plans, failing continuous integration runs and stalled stages send work back to earlier steps or up to a human Chief.
The rules that do most of the work
- No code before a plan, and no plan without review. A Fellow agent must reproduce the problem, investigate it and post a treatment plan. A separate Review Attending agent, prompted to find faults, must approve the plan before any code is written.
- Don't improvise. If scope changes during treatment, work stops and returns to plan review.
- No shortcuts on testing. Agents may not disable, skip or weaken a test to get a pass. Reviews start by disabling the change to confirm that the new tests fail.
- Never flail. A stuck agent writes a structured handoff and escalates rather than trying harder. The receiving agent must restate what it understood before it starts work.
- Audit the reviewer. The final gate checks that the review actually happened, with an approval, a completed template, resolved threads and green continuous integration, rather than re-reviewing the code itself.
- Check the precedents first. Human decisions are recorded in an append-only log that agents must consult before escalating. Only humans can add entries.
The company says the plan gate exists because an agent that confidently implements the wrong fix wastes more time and tokens than one that pauses to check its plan. It also says the precedent log has reduced how often agents escalate to the Chief over the five months of operation. The handoff format, known as I-PASS, is borrowed from hospitals, where studies report a 50% reduction in adverse events during shift changes when patient information is recorded in a standardised way.
Cockroach Labs is careful not to oversell the approach. It acknowledges that a hospital model is neither cheaper nor simpler than a single agent, and that it brings its own bureaucracy, waiting time and cost. The company's view is that these trade-offs are worth making when the product is a database.
Results over five months
The company ran the pipeline on a mirror of its MOLT repository from April 21 to September 11. In that period, it says the pipeline landed well over a million lines of code, split into changes small enough for agents to review confidently.
The pipeline also generated much of its own work. Of roughly 1,299 issues filed in the repository, nearly half were created by the hospital itself, including decomposition tasks, follow-ups, proposals from the research team and corrective actions from the safety team. A human still decides what gets admitted, but the company says people stopped being the main source of work in the second month.
After the first week of autonomous operation, the team switched on a human approval mode that requires a person to review every merge. The company says this was necessary before it could be certain the code was good enough for customers. The larger goal was a Migration Assistant, an AI-based tool that guides users through a complete Postgres to CockroachDB migration, covering schema conversion, data loading, verification and routine conversion. It is now in preview for Postgres migrations, and the company says the hospital wrote almost all of it.
Cost and the model mix
Cockroach Labs says MOLT Sinai has consumed just over $135,000 in Claude tokens since April, or about $84 per issue. Issues typically spend one to two days in the hospital, and much of that time is spent waiting for a human reviewer.
The model mix has changed over time. The company says it first ran an Opus model at every stage, then moved planning to a newer model it calls Fable. The Fable-generated plan selects the model used for implementation, and harder cases can escalate to a more capable model when a Sonnet or Opus implementation struggles. Cost is tuned in optimisation rounds roughly every two weeks, which explains some of the variation in the company's cost chart. The company also notes that user interface work costs more, because agents must process screenshots and other visual data.
The hospital built itself
Soon after launch, the company split the pipeline code out of the MOLT repository into a separate Sinai repository, so that other teams could embed the hospital model in their own projects. That repository has about 1,570 commits, and roughly 85% of them, about 1,340, were authored by the pipeline itself.
The company says this was not planned. The framework had bugs, and those bugs went through the hospital like any other issue. The Charge Nurse workflow that rounds every thirty minutes, for example, exists because an agent hit a race condition in GitHub Actions label events, filed an issue about it, and another agent designed and shipped the fix.
Cockroach Labs presents the experiment as evidence that process design, rather than raw agent speed, determines whether AI-written code can be trusted in production. The figures are the company's own and have not been independently verified. Even so, the account gives other engineering teams a concrete example of how far to let coding agents work unsupervised, and which checks they might need before doing so.
Related: Agent Standup Turns Claude Code Sessions Into a Live Team Call · Reverse Engineering with an AI Coding Agent: How REA Works
Comments (0)