I work in a place with 99% test coverage requirements and it's honestly still a super brittle system that everyone is afraid to make big changes to. Obviously

I work in a place with 99% test coverage requirements and it's honestly still a super brittle system that everyone is afraid to make big changes to. Obviously tests are going to break when you change the code's APIs and functionality. That's expected, and does nothing to boost your confidence in the part of the code you're working in. The point of tests is to improve your confidence that you're not doing things that have an unexpected impact somewhere else (hence the Bob Martin quote in the article about tests being useful even if you have good design). Tests aren't an alternative to thinking. You still have to consider what changes you're making, and what tests should break as a result. That's just part of your code change. When tests that shouldn't have broken start failing that's when they show their value.