CI > 15 minutes

CI pipelines that take longer than 15 minutes are a defining characteristic of the Ad-hoc maturity level.

·CI pipeline exists but takes longer than 15 minutes
·Agents receive no real-time CI feedback (wait for full pipeline completion)

·CI runs on every PR (not just on manual trigger)
·Shared runner queue exists even if slow

Evidence

·CI pipeline configuration file in repository
·CI run duration logs showing median > 15 minutes

What It Is

CI pipelines that take longer than 15 minutes are a defining characteristic of the Ad-hoc maturity level. At this stage, CI was designed for human developers who push code a few times per day and can tolerate a 15-20 minute wait while doing other things. The pipeline typically runs a full test suite sequentially, pulls dependencies fresh on every run, and executes on a single shared runner that handles all branches and all teams.

The 15-minute threshold matters because of what it means for AI agents. A developer can tolerate waiting 15 minutes - they context-switch to another task, come back, and review the results. An AI agent cannot. When an agent submits a change and has to wait 15 minutes for feedback, the entire iteration loop stalls. If the agent is attempting 10-20 iterations to get a feature working correctly, a 15-minute CI wait means 2.5-5 hours of wall-clock time just in CI waiting. That's not AI-assisted development; that's AI-assisted bottleneck creation.

Slow CI in the pre-AI era was an irritant. In the AI era, it becomes a ceiling. Agents can generate code faster than any human, but they can't make CI go faster. A 20-minute pipeline hard-caps the iteration rate at 3 attempts per hour, regardless of how capable the agent is. Teams that don't address CI speed before scaling AI tool adoption will find their infrastructure is the limiting factor, not their agents.

The warning signs of CI > 15 minutes are usually visible: developers who push code and immediately open Slack, a culture where "waiting for CI" is a normal activity, runners that are perpetually at capacity, and test suites that no one has touched in years because "that's just how long it takes." These are not inevitable facts of software engineering - they are infrastructure debt that compounds badly in the AI era.

Why It Matters

Agent iteration rate is throttled - every CI wait directly multiplies total delivery time; at 20 minutes per run and 10 iterations, that's 3+ hours of blocked agent time before a feature ships
Human review bottleneck amplified - slow CI means PRs sit in "CI running" limbo before humans can even start reviewing, doubling the total cycle time per change
Runner saturation becomes constant - at L1, agents are rare; but even 2-3 agents per developer submitting changes simultaneously can overwhelm shared slow pipelines
Developers lose the feedback loop - when CI takes 20 minutes, developers stop running it locally and start treating CI results as a surprise, not a quality gate they actively engage with
Cost accumulates invisibly - slow CI on cloud runners bills for idle compute while waiting for sequential test stages, making the financial cost proportional to slowness

Getting Started

Measure before optimizing - Run git log --oneline -100 | wc -l to count recent commits, then pull CI timing data from your platform (GitHub Actions run time reports, CircleCI analytics, BuildKite metrics). Know your actual p50 and p95 build times before touching anything.
Identify the top three slow stages - In your CI YAML, look at which steps consume the most time. In most slow pipelines, the culprits are: dependency installation (no caching), a single sequential test run, and Docker image builds. Time each stage explicitly by adding timing logs.
Separate fast feedback from slow validation - Split your pipeline into a fast path (lint, type-check, unit tests) that runs in under 5 minutes, and a slow path (integration tests, E2E, security scans) that can run in parallel or on merge. This immediately changes the agent feedback loop without fixing the underlying slowness.
Enable basic dependency caching - This single change often cuts 5-10 minutes from pipelines with no caching. For GitHub Actions: add a cache step for your package manager. For CircleCI: add a restore_cache / save_cache block. See the Basic Caching guide for step-by-step instructions.
Document current state and set a target - Write down today's p50 CI time and commit to a 10-minute target within the next sprint. Visibility creates accountability. Put it in your team's weekly metrics report.
Audit test suite for obvious waste - Look for tests that sleep (literal sleep() calls), tests that make real network calls to external services, and tests marked as flaky that run unconditionally. Removing or mocking these is often a 20-30% time reduction with no risk.

Tip

Don't try to fix everything at once. The dependency caching change alone often cuts 5-8 minutes and can be done in an afternoon. Shipping that improvement and measuring the result is more valuable than a comprehensive CI refactor that takes three weeks.

6 steps to get from here to the next level

Common Pitfalls

Optimizing the wrong stages. Teams often spend engineering time optimizing stages that take 3-4 minutes while ignoring a 12-minute sequential test run that could be parallelized. Measure first, then optimize the stages that actually dominate runtime. The Pareto principle applies strongly here: 20% of your pipeline stages probably consume 80% of the time.

Treating CI slowness as permanent. Engineering teams that have lived with 20-minute CI for years develop a learned helplessness around it. "That's just how long our test suite takes" is a belief system, not a fact. Every team that has systematically attacked CI speed has found 50-70% reduction opportunities within the existing test suite. The slow CI isn't inevitable; it's unaddressed technical debt.

Fixing CI speed only for the main branch. Many teams optimize their CI pipeline for merges to main but leave branch CI slow. Agents run primarily on feature branches. If branch CI is still 20 minutes, agents are still blocked even if main pipeline is fast. Optimize the branch pipeline first - that's where agents iterate.

Confusing CI time with test quality. Slow CI does not mean thorough testing. A 20-minute pipeline with many redundant tests and slow external calls may provide less meaningful coverage than a well-structured 5-minute pipeline. When you cut CI time, you are typically cutting waste, not coverage.

Starting a CI overhaul without buy-in. CI pipeline changes affect every developer on every team. Changes that break developer workflows create backlash that kills the initiative. Get agreement on the approach, communicate changes before they happen, and maintain backward compatibility for the fast-path / slow-path split.

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

How Different Roles See It

BobHead of Engineering

Bob's team has 15 developers and just started rolling out AI coding tools. Three weeks in, he notices that agent adoption has stalled - developers are using the tools for chat and autocomplete but not for autonomous agent tasks. When he digs in, the answer is clear: no one wants to wait 18 minutes to see if the agent's code passes CI. The feedback loop is too slow to make agent iteration feel worthwhile.

Bob needs to treat CI speed as a prerequisite for AI tool ROI, not a nice-to-have. He should make "CI under 10 minutes within 30 days" an explicit team goal, assign one developer to own the CI pipeline for the sprint, and track progress publicly. The developer assigned to CI optimization will find that dependency caching and basic parallelization of the test suite can cut 8-12 minutes off the current pipeline within a week. Bob should frame this as infrastructure investment that pays for itself: if 15 developers are each waiting 18 minutes for CI 5 times per day, that's 22.5 developer-hours per day lost to waiting. Cutting that to 5 minutes recovers 16 hours per day.

SarahProductivity Lead

Sarah tracks developer experience metrics and has noticed that "CI wait time" consistently appears in developer satisfaction surveys as a friction point. Now that AI agents are part of the workflow, the problem is acute: agents need to iterate quickly, but 18-minute CI turns every iteration cycle into a multi-hour affair. Her DORA metrics show lead time for changes is dominated by CI time, not code review time.

Sarah should create a CI feedback latency dashboard that tracks p50 and p95 CI run time per day, per team, and per pipeline stage. Making the data visible is step one. Step two is setting a team target (10 minutes within 30 days) and reporting progress weekly in the engineering all-hands. Sarah should also interview developers who are getting the most value from AI agents to understand how they handle the CI wait - most high performers have already developed workarounds (running a subset of tests locally, batching multiple changes before pushing). Systematizing those workarounds into pipeline infrastructure is the path from workaround to standard practice.

VictorStaff Engineer - AI Champion

Victor runs 3-4 parallel agents and feels the pain of 18-minute CI acutely. He's already hacked around it: he has a local script that runs just the affected tests before pushing, and he only pushes to CI when he's reasonably confident. But he knows this is a local workaround that doesn't scale to the team. The real fix is in the pipeline, not in individual developer habits.

Victor should volunteer to own the CI speed project and approach it as a systems problem. His first move: instrument every stage of the pipeline with explicit timing and publish the data to the team's dashboard. His second move: implement the fast-path / slow-path split so agents get feedback in under 5 minutes even before the full suite is optimized. His third move: document the impact - before and after CI times, and the resulting agent iteration rate improvement. Victor should position this work not as "CI cleanup" but as "agent infrastructure" - the framing that gets engineering leadership to prioritize it.