Th nuance of flakiness (if you work at a very large company with one continuous build system and one big repository for everyone) is that in order to not break

Th nuance of flakiness (if you work at a very large company with one continuous build system and one big repository for everyone) is that in order to not break dependent teams with your checkins, you run all their tests before checkin. Sometimes this catches major, subtle issues - out of a run with a million+ test targets, one test fails and it reveals a critical security bug in a widely used open source library. But most of the time, large numbers of poorly written (or neglected) tests fail, and it's not because of your change. The important thing is to show a distinction in the UI between a flaky test and a passing test, so that people don't look at a wall of green and see success, and push broken code to production.