How to Speed Up CI in the Age of AI-Written Code
By Manish Shivanandhan ยท November 13, 2026 ยท #GitHub
Coding agents now write code faster than most CI pipelines can check it. In April 2026, GitHub COO Kyle Daigle said that the platform was handling 275 million commits a week, on pace for 14 billion in the year, up from about 1 billion in 2025. In the same post, he put GitHub Actions at 2.1 billion minutes in a single week, up from 500 million a week in 2023.
That second figure shows where all those commits end up: in CI. A 15-minute pipeline is tolerable if a developer pushes a few times a day. When an agent opens ten PRs in an afternoon, that pipeline turns into a queue. You wait for results, agents wait to retry, and the time saved writing code is lost checking it.
Most of that delay comes from a few causes, and each has a known fix. You can speed up CI in five ways:
- Measure where the time goes.
- Cache what you can reuse.
- Run jobs on faster hardware.
- Split tests across parallel jobs.
- Skip work that doesn't need to run.
- Measure First, Then Optimize
- Cache Dependencies and Build Layers
- Run on Faster Hardware
- Split Tests Across Parallel Jobs
- Skip Work That Doesn't Need to Run
In this article, we'll walk through each fix in order. You'll learn how to find the slowest steps in your GitHub Actions workflows, cache dependencies and Docker layers with stable keys, and move heavy jobs to faster runners. You'll also see how to shard tests across a matrix of parallel jobs, and how to skip unneeded work with path filters, affected-only tests, and concurrency groups.
What We'll Cover
via FreeCodeCamp
