Ole Lensmar: stop blaming code review, the changes are waiting in your test pipeline
Oct 29, the Testkube CTO argues that speeding up review just moves the queue downstream: approved AI-written changes pile up behind CI test suites built for a handful of changes a day, so testing has to become its own system that agents can trigger directly.
In Stop Blaming Code Review for AI's Delivery Problem in SD Times, Ole Lensmar of Testkube starts with what his own team sees: engineers building features faster than ever, and releases not keeping up. Review is where teams first notice the slowdown. He cites Faros AI's look at more than 10,000 developers, where high-AI-adoption teams merged 98% more pull requests while review time rose 91%.
His argument is that review isn't where the slowdown starts or ends. Make review faster, with better tools or AI reviewers, and every approved change still has to pass a testing process designed for far less code. The changes just wait there instead. He points to a National Bureau of Economic Research working paper covering more than 500,000 GitHub developers that found autonomous coding agents raised commits by about 240% but releases by only about 30%.
The familiar failures get worse under volume: tests only run when a pipeline runs, one flaky failure means rerunning the whole pipeline, and results end up scattered across hundreds of runs so nobody can say what actually passed for a given release. His proposal is to keep CI/CD for building and deploying, but run testing as a separate system. Tests should run when an API changes, on a schedule, or on demand, in parallel when a lot of changes arrive, against real environments, with results in one place rather than spread across pipeline logs and agent sandboxes. Agents should be able to trigger those tests and act on the results without waiting for a crowded build queue.
Why it matters for code review
This is the cost of verifying a lot of changes at once, seen from the test side. An always-on agent setup that merges steadily overnight needs verification that keeps pace without queuing behind one shared pipeline. Otherwise "approved" just means "waiting." Lensmar's diagnostic questions are worth borrowing for any team stuck on review throughput: how are you running your tests, and where do they run?