Before making changes, ask for the up to date specification. Then design tests to verify that the code implements the spec. Get the product owner or your boss i

Before making changes, ask for the up to date specification. Then design tests to verify that the code implements the spec. Get the product owner or your boss if more appropriate to confirm in writing that the tests will be sufficient to prove that the code is correct. Then implement and run the tests. The code will fail some of the tests, so make sure that those tests really do correspond to the spec and then present the remaining failures to product owner/your boss. Maybe the spec will change, and then the tests will change and the code will pass. If there are still failures then get written instruction to fix the code. Eventually you will have code that passes all the tests. Now you are in control. You know what the code should do and that it does it. And best of all, you can make changes to the code and know if the code is still correct. Additionally, you might find yourself looking at the awful spaghetti in a different way. After all, the spaghetti does exactly what it's supposed to. Maybe you can make it do it better and be more maintainable etc, but as far as anyone else cares, it'd better taste exactly the same or else you'll have screwed it up.