|P is for Practical|
The guy did wrong, that's obvious, but I think it indicates a procedural/permissions problem with your development setup also.
Developer's working on multi-user systems and servers should not be able to update system-wide library files. Any and all changes to shared libraries should only be possible from an account specifically charged with systems admin resposibilities. And only after testing has been signed-off.
There should be no need for a developer to have write access to /usr/lib/perl5/*. Even if a developer is specifically charged with modifying a module that normally lives in that pathtree, it is quite easy for him to work on a copy of the module in a private path located ahead of the system path, for his account only.
Once he is satisfied with his changes, the copy should go through at least a minimal regression testing against your existing applications in some sort of test server environment before being signed-off for deployement into shared library trees.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.