[kX4A8o4mVmX8aW]

The hope here is that this new team member is going to stick around for a while and contribute new insight to the team. Since he's senior I hope you hired him so you could learn from him.

You might want to have a meeting with this new person, his senior peers on the team, and a manager who can oversee and referee things. Talk with him about the stuff he wants to change. If everyone agrees that his ideas are good then you should talk about how to incorporate his ideas into the code.

As a senior person he should understand that simply parachuting in new style to existing code can cause problems. On the other hand you should be willing to find places where these improvements can be added appropriately, perhaps in new code or bulk refactoring that would happen anyway. You want him to feel that you are on his side so this new style should be the team's new style, enforced by everyone where appropriate, and not just his thing. If you review a PR for new code, you'll want to make sure it conforms to the new style, and say it like "following our team's style for new code, class X should be split in two because of reason Z" and not "please split class X in two because that's what NewGuy wants, you know how he can be."

If you just say no to his ideas even if you agree they are good then he might become unhappy and, if rejecting his ideas becomes a pattern, might end up leaving.