One agent goal has landed 575 PRs moving OpenClaw to async
Steinberger calls sync database access his biggest design mistake after the move to SQLite, and says the fix is shipping as it goes.
Peter Steinberger says a single /goal running on Astra has landed 575 PRs converting OpenClaw from synchronous SQLite access to async workers.
Pretty insane how even huge refactors are no longer scary.
now that one agent might do 50 sessions in parallel and the whole team works on it, it is limiting
His framing is a post mortem on his own architecture. Sync database access, he says, was the biggest design mistake he made when OpenClaw moved to SQLite. It was fine when the product was one agent reporting to you on Slack or iMessage. It stopped being fine once one agent might run 50 sessions in parallel and the whole team is working on the codebase at the same time. Blocking calls that nobody noticed at one session become the thing everything queues behind at fifty.
The rollout is incremental rather than a big bang. Steinberger says the improvements ship as the work progresses, so the 575 PRs are not sitting on a branch waiting for a merge weekend.
What this is evidence of
This is one person's report on one codebase, not a benchmark, and the only number in it is the PR count. It does not tell you how many of those PRs were reviewed closely, or how much of the conversion is left. What it does show is the shape of work that agents are currently good at, the wide mechanical refactor that touches hundreds of call sites, is individually boring at every site, and would otherwise never get scheduled because no single quarter can justify it.
It is also the second time recently that Steinberger has pointed an agent at a large sweeping change in OpenClaw rather than a feature. He previously reported that OpenClaw deleted 400k lines of tests with coverage holding. The pattern in both cases is the same. The agent is doing the volume, and the human is choosing which structural bet is worth 575 PRs of churn.
For working engineers, the interesting claim is not the throughput, it is the change in what counts as too risky to attempt. As Steinberger puts it, huge refactors are no longer scary.