Really? I am having difficulty thinking of any examples of code that doesn't need to be understood. If it isn't understood by someone, then how is it even working?
If you mean like a library you are using, where you aren't even reading the internals or might not even have access to it, OK, but that code is stull understood by its authors, surely?
They're relatively simple, they do the task they need to and then they wait until they're needed again (or not).
In the past I wrote them, then forgot how they worked, until I needed them again, relearned what I did and adapted it.
Now I just don't have to know how exactly they work, I just get an AI to read the documentation anytime I need to reuse the project and I'll query the AI to fill in the details and to make changes and I ask the AI to run the code and debug it.
Perfect use cases for today's AIs. Doesn't even require SOTA, I can run comfortably on a Sonnet 5 or a Qwen 3.8 and it'll do exactly what it needs to do without making too many mistakes.
Not all code is large corporate code bases.
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.
I'm not following.. When we write regression tests those tests encode invariants we expect to be maintained under source code transformations over time. If I don't understand the test code I've written, how can I know which invariants I've imposed? That's why, broadly speaking, we write test code to be as simple as possible above all else--it's absolutely imperative that these invariants are not only intentional and easy to reason about, but also that when an invariant is violated we can easily discover why. Often, on a team, the person encountering a test failure after making a code change is not the person who originally established the invariant, so it's very important they be able to easily understand it.
I see no possible world in which failing to understand the test code is... possible? Like, if you have indecipherable test code things are really bad in your codebase. Fixing that is P0, because it'll compound rapidly.