Test code for a new bug is a good example. You can prove the test covers the bug without understanding the test code (you need to understand the bug, of course). There are some domains/tests where you can't do that - you need to be sure its failing for the right reason, but often you can do that without understanding every line of the test code. You can extend this to lots of related test infrastructure. If you can watch playwright test the app the way you expect it to, you don't have to understand all the code.

You can also do this for apps that are just tools for your own use. You satisfy yourself that they are working, and you use them because they save your time. You review enough to be sure its implemented the way you think it is - and if it is working, that tells you quite a lot. Sometimes you will be surprised and have some time wasted.

Yes, yes - there are people who will make the wrong choices in some of these cases but that doesn't mean there are never cases where you can do it.

More broadly - anyone who works in a team is already working with code they don't fully understand. I have code I wrote years ago I don't fully understand. I trust its observable properties and its track record.