And that's true in most companies. So then the question is, how acceptable is it to cause a break in some dependent project by making a change in a dependency. That will depend on the company and the type of product. For a consumer product company like Meta this is probably ok, but for an enterprise company that makes mission-critical software it may be less ok.

And yet, as someone working on core language infra, we apply exactly that sort of ideal when making changes. If a diff doesn't break any tests, then it's "safe" to land, and if something does indeed break afterwards, then it's the broken team's responsibility to fix forward or otherwise provide proof that it's a big enough problem to roll back. If we end up in SEV review for a change, and there were no broken tests on the diff, then there are going to be some hard questions for the team that didn't write tests.

Ie, tests aren't mandatory, but if you aren't writing tests, it's your responsibility when someone else's change breaks your project.