Sub-2min feedback on any change

Sub-2-minute feedback means that for any change an agent or developer makes to the codebase, the signal "this compiles and the relevant tests pass" arrives within 120 seconds. This is not just a fast CI pipeline - it's a systemic property achieved by combining incremental builds, targeted test selection, dedicated agent CI capacity, and pre-warmed execution environments. The 2-minute threshold is not arbitrary: it's the feedback speed at which agent iteration loops become self-sustaining rather than blocked on infrastructure.

The 2-minute target applies to the full loop: agent makes a change, commits, pushes, CI starts, runs affected compilation and tests, reports result, agent reads result and decides next action. Every second in this loop is latency that the agent cannot use productively. At 2 minutes total loop time, an agent can make 30 iterations per hour. At 10 minutes total loop time, it can make 6. The difference is 5x, which at the scale of 50 parallel agents compounds into the difference between a productive agent fleet and an expensive waiting room.

Achieving sub-2-minute feedback consistently - at p95, not just p50 - requires addressing every component of the feedback loop. Build time is one component. CI queue wait time is another. Test selection (running only relevant tests instead of the full suite) is a third. Test execution time itself is a fourth. Artifact download and upload times are a fifth. Each component needs to be below roughly 20-30 seconds for the total to come in under 2 minutes, with meaningful safety margin for variance.

The pattern that delivers sub-2-minute feedback reliably is: pre-warmed CI runners (eliminate cold-start latency), remote build cache with 90%+ hit rate (eliminate redundant compilation), targeted test selection running only tests affected by the changed targets (reduce test execution time), and dedicated agent CI capacity (eliminate queue wait time). This combination is achievable at L4 with investment in infrastructure.

• Agent iteration rate is directly proportional to feedback speed - every second under 2 minutes translates to more iterations per agent per hour, compounding across the fleet
• Sub-2-minute loops change agent behavior - agents with fast feedback naturally make smaller, more focused changes; agents with slow feedback batch larger changes, increasing the probability of errors
• Human developers get the same benefit - sub-2-minute CI feedback for pre-merge checks dramatically improves human developer experience; it's not only an agent optimization
• The threshold separates "agents can iterate freely" from "agents must batch work" - above 2 minutes, agents start to optimize their changes to minimize CI runs; below 2 minutes, they can iterate as freely as the problem requires
• Demonstrates infrastructure maturity - achieving sub-2-minute feedback consistently signals that the team has solved the foundational build and CI infrastructure problems, which is a prerequisite for autonomous agent workflows

1. Measure your current feedback loop time end-to-end - Instrument the full loop: time from git push to CI result delivered. Break it down into components: CI queue wait, runner cold-start, dependency installation, compilation, test execution, artifact upload. You need to know which component to optimize first.
2. Eliminate CI queue wait with dedicated agent pools - If queue wait time exceeds 30 seconds at p95, add dedicated agent CI capacity with auto-scaling. Queue wait time is the easiest component to eliminate: it's entirely a capacity problem.
3. Eliminate cold-start latency with pre-warmed runners - If runner initialization (checking out code, installing dependencies) exceeds 30 seconds, move to pre-warmed runner images. Pre-warmed images have dependencies pre-installed and the repository pre-cloned. GitHub Actions supports custom runner images; Kubernetes-based runners support pre-pulled images.
4. Implement targeted test selection - Run only tests for targets affected by the current change. For Bazel, this is bazel test $(bazel query 'rdeps(//..., //changed:target)'). For Jest, use --testPathPattern with a list of files affected by the change. For pytest, use pytest-testinfra or similar changed-file-aware plugins. Targeted test selection reduces test execution time from minutes to seconds for small changes.
5. Achieve 90%+ remote cache hit rates - Remote cache misses force full recompilation. If more than 10% of your agent CI runs are cache misses, investigate why: hermetic build violations, BUILD file structure issues, or seeding problems. Fix the root causes until 90%+ of agent builds are cache hits.
6. Set a hard SLO and alert on violations - Instrument the feedback loop with a p95 target of under 120 seconds. Alert on-call when the p95 exceeds 150 seconds. Treat SLO violations as infrastructure incidents, not annoyances. The feedback loop is as critical as production uptime for an AI-enabled team.

Optimizing p50 at the expense of p95. A median feedback time of 45 seconds with a p95 of 8 minutes is not sub-2-minute feedback. Agents and developers experience the tail as frequently as the median - if 5% of builds take 8 minutes, that's 1 in 20 agent iterations spending 8 minutes waiting. Focus optimization effort on reducing the tail, not the median.

Not accounting for the full loop. Teams often optimize CI pipeline time but ignore queue wait time, runner cold-start, and artifact handling. A 90-second pipeline that sits in queue for 3 minutes before starting is a 4.5-minute feedback loop. Measure and optimize the full loop, not just the pipeline.

Allowing test suite growth to erode the target. A sub-2-minute target is not a one-time achievement - it's a sustained property. Test suites grow, and without active management, test execution time will eventually push the feedback loop over 2 minutes again. Enforce per-target test execution time limits and require test parallelization for any test that takes over 10 seconds.

Not enforcing the target for agents specifically. Many teams achieve sub-2-minute feedback for human PR checks but let agent-specific CI run on the same slow pipeline as nightly regression tests. Ensure agent iteration CI runs specifically target the fast feedback pipeline. Agent CI and human pre-merge CI should have separate pipeline configurations optimized for their respective use cases.

Underestimating the impact of artifact download. In builds with remote execution, downloading build outputs can dominate the total build time for large artifacts. Use --remote_download_minimal in CI contexts where output artifacts aren't needed locally, and compress artifacts aggressively. A 200MB artifact download can add 60 seconds to a feedback loop on a throttled CI runner.