Dora NodaCircleCI shipped a second, parallel CI system this year — not to replace the pipeline your pull requests already run through, but because that pipeline is too slow for the thing writing most of your commits now. Chunk Sidecars are lightweight microVMs that mirror your project's stack, sync an agent's uncommitted changes, and hand back pass/fail feedback in under 60 seconds, agent-agnostic across Claude Code, Cursor, and Codex. It's a genuinely useful product.
It's also a tell: building a whole new microVM fleet, CLI, and hook system was the only way CircleCI could get validation in front of an agent fast enough to matter, because it doesn't own the one place that validation could have lived for free — the build step that already runs on every git push. A platform that does own that step doesn't need a second pipeline. It needs to expose the one it has, one step earlier.
Why This Exists Now
The problem CircleCI is reacting to isn't hypothetical. Teams adopting AI coding agents saw feature-branch commit activity rise roughly 15% — agents commit far more often than humans, in smaller increments, testing hypotheses as they go — while main-branch merge throughput actually fell about 7%. More commits were going in, but fewer were making it out the other side as shippable, merged work.
The bottleneck wasn't code generation. It was validation: a CI pipeline built for a human who pushes a handful of times a day, reads the logs, and fixes what breaks, doesn't hold up against an agent that wants to push, get feedback, and self-correct dozens of times in a single session. Waiting five or ten minutes for a pipeline run, every time, turns the agent's fast inner loop into the slowest part of the process.
What a Chunk Sidecar Actually Does
Strip away the marketing and the mechanism is two hooks wired into whatever agent you're running.
A PreToolUse hook watches for the agent calling git commit. Before the commit lands, it runs the project's local test command; a failing exit code (2, by convention) blocks the commit and hands the failure straight back to the agent instead of letting broken code get committed at all.
A Stop hook fires when the agent thinks it's done — the moment it would otherwise hand control back to you. That triggers chunk validate, which syncs the agent's full working tree to a remote sidecar and runs the entire test suite inside a clean microVM, the same environment parity a full CI job would give you, just without the CI job. A failure there returns the same exit code, and the agent gets up to three automatic retries before it's forced to stop and surface the problem.
Because chunk validate is just a CLI command, the wiring is nearly identical across agents — it's the hook file that differs:
// .claude/settings.json (Claude Code)
{ "hooks": { "Stop": [{ "command": "chunk validate" }] } }// .cursor/hooks.json (Cursor) / .codex/hooks.json (Codex)
{ "hooks": { "stop": [{ "command": "chunk validate" }] } }The sidecar itself auto-detects your stack, build system, and test commands — no per-project config to write. And because spinning up a fresh microVM from scratch takes time, Chunk snapshots a configured environment (dependencies installed, tooling in place) and boots subsequent sidecars from that cached state: in CircleCI's own demo, a cold boot-to-green-test run took about 59.7 seconds, and the snapshot-based run took about 25.8 seconds — roughly 2.3x faster, and comfortably inside the 60-second window agents are tuned to work within.
The Math, Without Rounding Up
The topic that put Chunk Sidecars on a lot of radars framed the speedup as "30x faster than pipeline CI." That specific multiple isn't something CircleCI states directly, and it's worth being honest about what is and isn't sourced rather than repeating a nice round number. What's actually documented:
- Boot time: ~59.7s cold vs. ~25.8s from a snapshot — a 2.3x delta, sidecar-to-sidecar.
- Pipeline comparison: CircleCI describes traditional CI pipelines as typically taking "five to ten minutes." A ~25-30 second sidecar run against a 5-10 minute pipeline lands somewhere in the 10-20x range, not a fixed 30x — the real number depends entirely on how long your specific pipeline runs, and a team with a leaner 3-minute pipeline gets a much smaller multiple than a team with a bloated 12-minute one.
- Token efficiency: microbuild output is roughly 3x more token-efficient for an agent to parse than raw CI logs — a real cost, since every log line an agent reads to diagnose a failure is context it's spending instead of using to fix the bug.
- Cost per core: CircleCI reports sidecars as 10-20x more cost-effective per core than a full pipeline run, mostly from prewarmed environments and fail-fast behavior — a sidecar stops at the first red instead of fanning out every check regardless of what already failed.
None of that needs rounding up to make the case. A ten-times speedup on the loop an agent runs dozens of times a session is already the difference between an agent that self-corrects in place and one that pushes broken code because waiting was more expensive than shipping and hoping.
What CircleCI Had to Build From Scratch
Here's the part worth sitting with: CircleCI is a CI company. Environment provisioning, snapshotting, and fast parallel test execution are its entire business. And it still had to stand up a parallel system to solve this:
- A separate microVM runtime and fleet, distinct from the one running its pipeline jobs
- A snapshot/caching layer to make that fleet boot fast enough to matter
- A standalone CLI (
chunk) with its own sync, validate, and setup subcommands - Three separate hook integrations — one per agent's own hook file format and lifecycle events
- A new pricing surface layered onto its existing plans
That's not a small lift, and CircleCI took it on because there was no other way to get validation in front of an agent before a push — its product boundary starts at the push. It cannot reach earlier into the loop without building an entirely separate thing that lives earlier.
What a Git-Push PaaS Already Has
A platform like bex, whose whole pitch is "push a repo, get a running HTTPS service," starts from a different position — because most of what CircleCI had to invent from scratch, a git-push PaaS already runs on every single commit, just later than an agent would like:
| Piece Chunk Sidecars needed | CircleCI | Git-push PaaS (e.g. bex) |
|---|---|---|
| Auto-detect stack/build/test commands | Built new (sidecar auto-detect) | Already exists — buildpack/Nixpacks-style detection runs on every push |
| Fast, cached environment boot | Built new (microVM snapshots) | Already exists — build-layer caching (deps, base image layers) on every deploy |
| A place for validation to run | Built new (separate microVM fleet) | Already exists — the build worker that runs on git push |
| Machine-readable pass/fail for an agent | Built new (chunk validate CLI + exit codes) | Missing — build output today is a human-readable log stream, not a structured signal |
| Sub-minute, pre-push invocation | Built new (hook-triggered sidecar sync) | Missing — the build step only runs after push, on a full commit |
The gap is genuinely narrow. A PaaS build worker already knows how to detect a stack and build it with cached layers — that's the hard, general-purpose part, and Chunk Sidecars had to reinvent it. What's missing is not infrastructure, it's exposure: a CLI entrypoint that lets an agent invoke the exact same build-and-test step the platform already runs on push, but locally or against a scratch remote build, before the commit — plus swapping a human-readable build log for the kind of structured exit-code signal an agent's Stop hook can act on. That's a CLI and an API endpoint, not a second fleet of microVMs.
The Strategic Asymmetry
This is the actual shape of the bet each side is making. CircleCI doesn't own deploy, so inner-loop validation has to be a product an agent calls out to — separate infrastructure, a separate CLI, a separate thing to adopt and pay for. A platform that owns build-and-deploy doesn't need a second product between an agent and a working, tested app; it needs to let the agent call the first one earlier. Products built to plug a gap tend to get absorbed once the platform on the other side of that gap notices it was never as far away as it looked. CircleCI's own numbers make the case for closing that gap better than any pitch deck could: a 10-20x tighter validation loop is worth having, wherever it lives — it's just cheaper to build when you already own the step it's a faster version of.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. The build worker that ships your app on every push is the same one an agent-facing microbuild would run against; star the repo on GitHub or deploy your first app today.
