Coding agents got fast, so review and CI became the bottleneck

The agent that will not wait

LangChain is shifting its agent architecture toward asynchronous subagents, because the standard ReAct loop has a responsiveness problem: it blocks the loop and queues other tasks during long tool calls. By delegating long-running work to background workers, the orchestrator stays available for the user while tasks execute in parallel. The pattern is being implemented across the LangChain Agents ecosystem, and the orchestrator manages async subagents using five specific tools, including an interrupt strategy that stops and restarts a subagent with new instructions and an enqueue strategy that holds follow-up instructions until the current run finishes. m:…5956

The idea is not new, which is the point. Claude Code runs subagents in the background by default, DeepSeek Harness uses a router to talk to people and background workers for parallel tasks, and OpenAI has added support for async tool calling. Async subagents are available in LangChain's Agents for Python and JavaScript, with task notifications currently in beta. The industry has converged on the same answer: an agent that handles bigger goals cannot be a single loop that freezes while a tool runs. Responsiveness is now an architectural property, not a model property. m:…5956

The same logic is hitting code review. Warp's Ben Holmes argues that the volume of agent-generated pull requests is creating a bottleneck for human reviewers, and the fix is to put an agent in front of the human: adversarial code review by an agent before human intervention can reduce review times, simulated environments and computer-use tools can verify user flows end to end, and scoring merge risk on pull requests helps reviewers focus on critical changes. Production incidents and reverts serve as high-signal feedback for improving review quality. The review queue is where agent speed goes to die, and the only way through is to let machines do the first pass. m:…9876

CI is the new compile time

Scale Ventures ran into the same wall in continuous integration. Coding agents operate in a loop where they write changes, check them, and iterate until tests pass — and they send far more code through the pipeline than human engineers. Merged pull requests to main at Scale Ventures grew from 100 to more than 600 per month in the past year, and the median full CI workflow runtime for its Deckhand agent reached 36 minutes. An agent that waits 36 minutes between iterations is not an agent, it is a batch job. m:…9809

The fix was hardware and structure. Scale Ventures upgraded its CI runner from a 2-vCPU GitHub default to a 4-vCPU Namespace runner, adopted pytest-xdist for test parallelism across the new cores, and used tiered testing — fast tests versus slow tests — to keep quality while cutting time. The median full CI workflow runtime for Deckhand fell from 36 minutes to 8.9 minutes, and the fast tier improved from 276 seconds to 92 seconds. Small jobs run full CI on every pull request, while large features use release branches with full CI only on the final merge to main. None of this is glamorous, and all of it is what makes an agent loop usable. m:…9809

Forter makes the general argument: faster coding does not necessarily result in faster delivery of software. The company is building an AI-assisted software development lifecycle that connects context, execution, validation, review, and feedback, using a central MCP server as the tool-execution layer and a hardened runtime for repeatable agent execution. Its CI Failure Doctor has recorded at least 5,000 workflow runs across many repositories, and its median first-human-review latency is 50 minutes. The bottleneck is no longer writing the code, it is everything that happens after the code is written. m:…4431

The quality question underneath

Forter's numbers also warn against declaring victory too early. A historical fit test classified 59% of 715 sampled pull requests as low risk and eligible for AI approval, and its Grumpy Reviewer agent has a median review duration of 2.5 minutes. But the company estimates that if pull-request volume grows tenfold and 60% of human reviews are removed, the human review load still increases fourfold. Automation that removes most reviews still leaves more human work than before, because the volume grows faster than the automation. Engineering leaders should plan for that arithmetic rather than for a world where review disappears. m:…4431

BoundaryML adds the quality caveat. It observed that AI agents produced lower-quality code in its BAML language than in TypeScript or Rust, and responded with new coding guidelines and a codequality tool that measures cognitive complexity, cyclomatic complexity, NPath, nesting, and exit counts. It evaluated agent performance on four program skeletons — a POSIX extended regex engine, chess move generation, a Conduit blogging API, and GTFS transit feed lookups — and each treatment level improved the cognitive complexity of the outcome. The lesson is that agents write worse code in languages they have seen less of, and the fix is guidance and measurement, not a bigger model. m:…7824

What to do about it

The practical programme that falls out of this week's posts is short: make agents async so they stay responsive, put an adversarial agent review ahead of the human, score merge risk so humans look at the dangerous changes first, and keep implementation and review agents communicating outside the GitHub thread to reduce noise. None of these steps is about a better model. All of them are about the system around the model — which is where the time is actually going. m:…5956 m:…9876