Dudzik: parallel agent changes hit a one-runner CI queue

Dudzik: parallel agent changes hit a one-runner CI queue

First-person operating record. Frederik Dudzik, Fixing CI contention caused by agentic coding (August 21, 2026), reports on a one-engineer hobby project, about 500,000 lines of code. Coding agents produced overlapping changes faster than one approximately 20-minute suite could verify them; while waiting, other branches accumulated, and landing one forced rebases and fresh CI. A mechanical bottleneck alongside Cursor's task-claim lock, but different workload and constraint.

Intervention and before/after. On one dedicated runner, he combined test runtime coverage records with a TypeScript dependency graph to select tests a given change could plausibly affect. Unknown changes are not assumed safe; broad shared files still trigger a large suite, and a full run executes nightly. He also tightened code boundaries and combined two E2E jobs that actually contested the same runner. Reported full PR suite wall time fell about 21→13 minutes, p95 E2E time on successful PRs that ran E2E about 23→6 minutes, and p95 total CI including queue about 7h35→35m. The final figure mostly reflects queue relief, not tests becoming 92% faster.

Limits and relevance. This is a self-reported before/after with several concurrent process changes, no sample counts or published raw run data, no rate of bugs missed by selective testing, and no human planning/review or shipped-value comparison. The source explicitly says selection cannot guarantee that a skipped test would never fail. Measure wait separately from active human orientation; eliminating CI queue may simply expose review as the next bottleneck. Compare parallel coordination and total cost, not a claim that more concurrent agents increase net throughput.