NixCI Blog - The purpose of Continuous Integration is to fail

CI is only valuable when it fails. This is the uncomfortable truth about continuous integration that nobody wants to say out loud. When your CI passes, you've just added friction to your deployment pipeline without getting anything in return - the code would have worked fine without those checks. The value only emerges when CI catches a mistake before it reaches production.

The article walks through the feedback loop with and without CI. Without automated checks, mistakes only surface after deployment, when users hit them or teammates notice something broke. At that point you're rolling back, fixing, and redeploying - a long, manual, dangerous cycle. CI shortens that loop by catching problems immediately after commit, before they cause damage. But here's the catch: this only helps when CI actually catches the mistake. When it doesn't, you're back to the no-CI scenario, except now you've waited for checks to pass.

There's such a thing as too much CI. Every check you add slows down the happy path where no mistakes exist. And flaky CI is worse than no CI - when a failing run passes on retry, you've lost the signal that tells you whether you caught a real problem or just hit a random failure. The piece makes a compelling case that we've got the colors backwards: CI failure (catching a bug) should be green, and CI success (adding overhead) should be yellow.

The reframing here matters for how you design your CI pipeline. You're not trying to make CI pass as often as possible. You're trying to catch real mistakes while minimizing the tax you pay on correct code. That means being rigorous about what checks actually prevent production problems, and ruthless about removing flaky or low-signal tests that just slow everyone down.