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.

·Any change gets build feedback in under 2 minutes
·Agent-specific build profiles exist (optimized for agent iteration patterns - fast feedback over comprehensive build)
·Build system understands agent iteration patterns and pre-caches likely next builds

·Build profiles are auto-selected based on invoker (agent vs. human vs. CI)
·Pre-caching hit rate exceeds 70% for agent iterations

Evidence

·Build duration dashboard showing sub-2-minute feedback for all change types
·Agent-specific build profile configuration
·Pre-cache hit rate metrics for agent iteration patterns

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

The easiest way to validate your sub-2-minute target is to create a synthetic monitoring job: every 5 minutes, make a single-line change to a low-impact file, push it to a test branch, and measure the time until CI reports a result. This gives you continuous real-world measurement of feedback loop latency, not just analysis of historical data.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob has been running agents at scale for 9 months and has seen good results, but his team is consistently running below the theoretical productivity ceiling. Agents are iterating at 8-12 cycles per hour when the infrastructure could theoretically support 30+. Bob suspects build infrastructure but doesn't have the data to confirm.

What Bob should do: Bob should commission a "feedback loop audit" - a one-week project to instrument and measure the full agent iteration feedback loop for a representative sample of agent sessions. The audit should measure each component: queue wait, cold-start, compilation (cache hit vs. miss), test execution, and total time. The audit will identify the specific bottlenecks. Bob should then fund infrastructure work to address the top 2-3 bottlenecks with a target of getting p95 feedback time to under 2 minutes. He should set this as a quarterly OKR with a measurable outcome: "95th percentile agent CI feedback time under 120 seconds."

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has a p50 feedback time of 55 seconds but a p95 of 6 minutes. The tail is caused by two things: occasional CI queue saturation during peak hours, and cache-miss builds that hit slower code paths. She wants to narrow the distribution.

What Sarah should do: Sarah should address queue saturation first because it's operationally simpler: increase agent runner pool capacity by 50% and add peak-hour auto-scaling. This should drop the queue-related tail events significantly. For cache-miss builds, Sarah should investigate what's causing them: are they new branches seeding cold? Are they BUILD file changes invalidating large portions of the cache? Each root cause has a specific fix. Sarah should set a target of p95 under 2 minutes and track progress weekly, reporting to Bob monthly. The target should not be considered met until it's sustained for 30 consecutive days.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor is already achieving sub-2-minute feedback at p99 for his own agents. His setup: pre-warmed runners with custom images, BuildBuddy remote execution with 93% cache hit rate, affected-targets-only test selection, and a dedicated agent CI pool with auto-scaling up to 20 workers. His p99 feedback time is 85 seconds.

What Victor should do: Victor should write up his infrastructure configuration as a replicable template for the team. Not a blog post - a terraform/bazel-ci-infra/ directory with all the configuration files, a README.md with the reasoning behind each choice, and a scripts/validate-feedback-loop.sh script that tests the full loop and reports p50/p95/p99. He should present the template to Bob with the business case: rolling out Victor's setup to the full team would increase agent iteration capacity by 3-5x at current agent adoption levels. That's the infrastructure investment that unlocks the next step change in agent productivity.

What Victor should do - role-specific action plan