This is one of the reasons code requires maintenance, and where possible, point and click should be used instead of code.
For example, if I create an "application" or coded solution for your org and you later install a trigger that's essentially a "validation trigger". I'm not aware of any way that can be detected programmatically. It's not a validation rule, but it has the effect of making fields required that may not have previously been required.
I can't anticipate those kinds of things when I created my coded solution. Dynamic Apex won't find them for me. They may or may not turn up using the metadata API, depending of course on how the code was written in the trigger. However, I can't easily call that API from Apex can I?
Will my client want to pay me to "future proof" my code? In my experience, most are reluctant to spend money for "better or best" practices test classes that include more than just obtaining line coverage with a single record. So, will they want to pay for these features? That could be a very tough sell. Sadly, code is too often purchased solely on price, at least until something breaks...