Copilot, Cursor, and the hidden CI cost of AI-assisted development

AI coding assistants have meaningfully changed how software gets written. Code is produced faster, in higher volume, with less friction. That is largely good news for developer productivity. It is more complicated news for CI carbon.

More code means more CI

The link is simple. AI-assisted developers commit more frequently, produce larger diffs per session, and explore more implementation paths before settling on one. Each of those commits triggers a CI run. Each CI run consumes energy. The aggregate effect is measurable.

In our data, repositories where the majority of contributors use AI coding assistants , identified by commit message patterns, diff characteristics, and self-reported tooling surveys , show 40–65% higher CI run frequency compared to repositories with similar team sizes and codebases that do not use AI assistants.

Run duration does not increase , AI-generated code is not slower to test than human-written code. But run frequency does. The result is a CI carbon footprint that grows faster than headcount, faster than codebase size, and faster than most engineering teams expect.

The compounding effect

The increase is not uniform across the workflow. Most of the additional runs are small: a single-file change, a bug fix, a refactor that touches two functions. These are cheap runs individually. But they represent a tail of high-frequency, low-urgency CI activity that adds up.

One pattern we see frequently: an engineer uses an AI assistant to rapidly iterate on an implementation, pushing five or six commits in an hour where they might previously have pushed one or two. Each commit is a valid, working change. But four of the six CI runs are effectively redundant , the final commit is the one that matters, and the intermediate ones consume energy without producing lasting signal.

What helps

Path filtering is the highest-leverage response. If an AI-assisted workflow produces many small commits, configuring CI to skip the full test suite when only certain file types change eliminates the redundant runs without any change to how developers work.

Concurrency limits on PR workflows also help. Rather than running every push in a PR branch, configuring the workflow to cancel in-progress runs when a new commit arrives means only the latest commit in a rapid sequence gets a full CI run.

Neither of these is a new technique. But the incentive to implement them has increased significantly as AI tooling makes high-commit-frequency development the norm rather than the exception.

The broader point

AI coding assistants are not a CI carbon problem , they are a CI efficiency opportunity. The teams that instrument their CI carbon, identify the high-frequency low-value run patterns that AI-assisted development creates, and respond with path filtering and concurrency controls will keep their carbon footprint flat even as their output scales. The teams that do not will find a quiet, growing line item in their Scope 3 emissions that is hard to explain to an auditor.