Directory batching restored CI throughput after per-file AI commits overloaded an industrial C++ repo

Build-on-commit CI has a one-line cost model. Build count equals commit count, so a tool that commits file by file schedules one build for every file it touches ^[1]. According to the dev.to write-up of the paper, the per-file approach turned CI into a backlog machine ^[10]. Queue length and rerun cost dominated elapsed time, however fast any single review finished ^[10].

Directory batching is a pipeline setting. It changes how many builds a given volume of change triggers, and no reviewer is involved in choosing it ^[11]. The write-up does not give the file cap the developer chose or the build counts before and after, so the size of the recovery cannot be checked from it.

The paper lists CI capacity, review effort and change orchestration as the primary bottlenecks once mechanical editing is cheap ^[8]. In the write-up's account, the AI never slowed down while CI and the reviewers did ^[4].

GitHub's documentation describes the other end of the pipeline. Copilot code review runs through GitHub Actions, offers Lite and Balanced effort levels, and "usually takes less than 30 seconds" ^[9]. A reviewer that fast brings the human reading minutes close to zero. The open-to-merge interval is mostly waiting, batching, CI runs and follow-up, the write-up argues, and a fast AI reviewer barely moves it ^[12]. It cites telemetry, surveyed in what it calls the vibe-coding review, showing review time up 441% under AI-assisted development ^[13]. It also cites a Salesforce finding that review time on its largest pull requests plateaued because reviewers had stopped engaging deeply ^[14]. Neither figure comes from the paper.

The design idea I would adopt first is the semantic change set. "Fix all instances of warning X" is one meaningful unit, and the authors argue the developer should not be forced to ship it as one massive commit or as hundreds of per-file commits ^[15]. Each consumer wants a different slice of it. CI wants bounded jobs, the reviewer wants a coherent change, and the developer wants to verify progressively ^[16]. Letting those slices diverge is what allows a large remediation to move without stalling ^[16]. I think this is the right abstraction. It separates what CI needs from what a reviewer needs, and the per-file experiment showed what happens when one commit has to be both ^[5].

Whether this transfers depends on the pipeline. The evidence is one developer, one closed-source C++ repository and 15 days ^[1][2]. The CI result applies where every commit triggers a build and the AI work is a mechanical sweep across many files ^[5][2]. A team whose CI already batches commits is running a different workload, and this study did not measure where its limit sits.