Opus 5.5 cut Arvid Kahl's test suite to 6m27s
He says the model found an inactive cache setting in his PHP runtime and refactored several thousand serial tests to run in parallel.
Arvid Kahl says he pointed Opus 5.5 at his test suite and watched the runtime fall from about 15 minutes to 6m27s.
Halving that time means almost 2x'ing my output, which is pretty sweet, knowing that nothing has broken.
Testing speed matters even more with agents, and Opus 5.5 just halved my test suite runtime from ~15min to 6m27s.
His account of what the model actually changed is specific. It found an inactive cache setting in his PHP runtime. It found a config flag that was slowing down app load. And it refactored several thousand serial tests to run in parallel. Three fixes, one sitting, and none of them the kind of work a founder volunteers for on a Tuesday.
Why the number matters more than it used to
A slow test suite used to be a tax you paid a few times a day. Kahl's argument is that agents changed the arithmetic. He runs cross-agent reviews, Codex reviewing his Claude code output and the other way round, which means the suite runs a couple of times per pass to confirm nothing is broken. Every one of those runs used to cost fifteen minutes of waiting.
"Halving that time means almost 2x'ing my output, which is pretty sweet, knowing that nothing has broken," he writes. That is his framing, not a measured throughput figure, and worth reading as such. But the logic holds for anyone running loops where a machine, not a person, is the thing sitting idle. You can tolerate a fifteen minute suite when you check it after lunch. You cannot tolerate it when three agents are blocked on it in sequence.
The business read
Test runtime has quietly moved from a hygiene concern to a throughput cost. When the bottleneck in your day was your own hands, suite speed was a nice-to-have and everyone knew it. When the bottleneck is how many review-and-verify cycles you can push through before you go to bed, the suite is the ceiling on your output.
The other thing in Kahl's post, easy to skim past, is that the fixes were not exotic. An inactive cache setting and a stray config flag are the sort of thing that sits in a codebase for years because nobody has a reason to go looking. Pointing a model at the problem is cheap enough that looking is now worth it, which is a different proposition from asking it to write features.
One caveat. This is one founder's own before-and-after on his own codebase, reported by him, on a suite of several thousand tests that were apparently running serially to begin with. If yours already runs in parallel, the headroom is smaller. Nobody has published a wider set of numbers yet.