> likely unaware of many complexities, dependencies, and edge cases that the code must account for All of this argues in favor of having an overall architectur

> likely unaware of many complexities, dependencies, and edge cases that the code must account for All of this argues in favor of having an overall architecture that can help a team member grasp these complexities. Maybe there is one that OP cannot see. However, edge cases also cry out for automated tests. Whether or not a codebase has automated tests is explicitly clear from the first day. > So it's important to have their support in refactoring This is absolutely true. A software team is made of people and trying to drive change without respecting people's need to be persuaded is both rude and doomed to failure. That persuasion is hard and I wish I had better advice for OP than to read books by the Harvard Negotiation Project. > How do you think they felt when you told them it needs a whole refactoring? Depends on the teammates. I've built a codebase that was a pile of spaghetti before and I felt terrible about it and left. So there may be people who agree with OP that the codebase needs significant improvement. There may be other people who, in the style of https://danluu.com/wat/ https://danluu.com/wat/, never imagined that things could be better. But one thing that the current teammates have in common is that they all have not left. The people who care most about clean code are the people who self-selected out of the team already. > It seems like a needless risk. So is making any change to the codebase without tests.