CI < 2 minutes

CI under 2 minutes is the Governed (L4) milestone and represents a qualitative shift in how CI is used. At this speed, CI is no longer a gate that agents and developers wait for - it's a feedback mechanism they interact with continuously. A 90-second CI run means an agent can iterate 40 times per hour. The loop becomes tight enough that agents can run exploratory iteration: try an approach, get feedback, adjust, repeat - in a way that resembles test-driven development but at machine speed.

Achieving sub-2-minute CI is not primarily a configuration problem at this level. The pipeline architecture has already been optimized with caching, parallelization, and incremental builds. What remains is infrastructure-level work: pre-built base images that eliminate container startup time, warm runner pools that eliminate job startup latency, and distributed build systems (Bazel, Pants, Buck) that can execute build and test steps in true parallel across many machines rather than within a single runner.

The 2-minute target also changes what "passing CI" means. At 5-minute CI, teams run a meaningful fast-path and accept that some slower tests run post-merge. At 2-minute CI, teams invest in making the meaningful fast-path comprehensive enough to be a real quality gate. This requires significant test architecture work: tests that run in 2 minutes across a large codebase must be highly selective, highly parallelized, and architecturally isolated from I/O. Teams at L4 have typically invested 6-12 months getting their test suite to this shape.

The payoff at 2-minute CI is visible in throughput numbers. Stripe's engineering blog describes internal tooling that supports 1,000+ merges per week on monorepos, enabled by fast CI. Teams running dozens of parallel agents can sustain high PR throughput without CI becoming the bottleneck. The 2-minute threshold is where CI scales with agent usage rather than constraining it.

• Agent iteration reaches machine speed - 40+ iteration cycles per hour means agents can work through complex multi-step implementations within a single 30-minute window
• CI becomes a development tool, not a gate - at 2 minutes, developers and agents use CI as a rapid feedback mechanism during development, not just before merge
• Merge queues become high-throughput - a 2-minute pipeline can process 30 PRs per hour per runner, enabling teams running dozens of parallel agents to sustain throughput without queuing
• Enables agent autonomy - when CI feedback arrives in 2 minutes, agents can close their own iteration loops without human intervention; the human reviews the final result, not each intermediate step
• Dramatically reduces total delivery time - a feature that requires 15 CI iterations takes 30 minutes at 2-minute CI versus 75 minutes at 5-minute CI; at scale, this compounds across every story point

1. Invest in pre-built runner images - Cold runner startup (downloading and installing tools) can add 30-90 seconds to every CI run. Pre-build custom Docker images with your full toolchain already installed and push them to a registry. In GitHub Actions, use a custom runs-on image or self-hosted runners with pre-configured AMIs. Eliminating runner startup is often a 30-60 second win.
2. Implement a distributed build system - Bazel, Pants, or Buck can distribute build and test steps across multiple machines. This is the step that takes large codebases from "5 minutes with parallelism on one machine" to "90 seconds with distribution across 8 machines." See the Bazel + Remote Caching guide for implementation details.
3. Maintain a warm runner pool - On-demand runners have startup latency (30-120 seconds for cloud VMs). Self-hosted persistent runners or pre-warmed runner pools eliminate this. GitHub's larger runners and BuildKite clusters support warm pools. The investment pays back immediately on every CI run.
4. Instrument CI with sub-stage timing - At 2-minute CI, every 10 seconds matters. Instrument each stage with explicit timing output so you know exactly where time is spent. Use GitHub Actions' job summary output or BuildKite's annotation API to surface timing data on every run.
5. Eliminate all remaining real I/O from unit tests - Any test that opens a real file, real socket, or real database connection does not belong in the 2-minute path. Use strict linting rules (custom ESLint rules, Checkstyle rules) to prevent new real-I/O tests from being added to the fast suite. Put them in an explicitly labeled slow suite that runs post-merge.
6. Set and enforce a per-stage time budget - Define explicit time budgets: lint must complete in 20 seconds, unit tests in 60 seconds, build in 40 seconds. Enforce these with timeout-minutes and fail the build if any stage exceeds its budget. Budget enforcement prevents gradual drift back toward slowness.

Distributed build complexity without organizational support. Bazel is powerful but requires significant investment in BUILD file maintenance and a team that understands the tool. Adopting Bazel to hit 2-minute CI without the organizational commitment to maintain it creates a brittle system. Assess team capacity for Bazel ownership before adopting it.

Achieving 2 minutes on the happy path only. Fast CI that takes 8 minutes when a certain module changes is not 2-minute CI. Profile your CI across a representative sample of recent PRs - not just simple changes - to understand the actual distribution of CI times. If the p95 is 6 minutes, you have a 2-minute median with a 6-minute tail, not 2-minute CI.

Undermining quality to hit the time target. If the only way to hit 2 minutes is to remove tests that would catch real bugs, the speed target has been set incorrectly relative to the test suite quality. The right response is to improve test architecture (faster tests with equivalent coverage), not to remove coverage to hit an arbitrary time budget.

Neglecting the local development environment. If CI is 2 minutes but local tests take 15 minutes, developers stop running tests locally and push speculatively. The local test path should mirror the CI fast path and run in comparable time. This requires the same test architecture investments - isolation, parallelization, incremental execution.

Allowing the runner pool to become a bottleneck. A 2-minute CI pipeline only delivers 2-minute feedback if runners are available immediately. If the runner pool is undersized for the team's push rate, jobs queue and wall-clock time to feedback grows. Size the runner pool for peak agent load, not average human load - agents generate bursts of CI activity.