However, one thing to note is the senior level positions, the higher you go, the more you're a people person. A low-level developer can think about architecture all day long, but because they never talk to anyone about the ideas, discuss if it's really good or bad, understand the pros and cons of the ideas that others have, they're going to remain a low-level developer. This is why senior developers move in and out of management very often in a lot of companies. The jobs are not nearly as different as people would imagine. In both cases, you're more a people person than a technical person. It's just that as the senior developer, you still keep that developer hat on and write code, whereas as a manager, you're only a people person.
This doesn't contradict the Peter Principle, which doesn't imply you're increasing competence on a single axis.
In its most bare form, the principle states that people get promoted until they get stuck at a role in which they cannot adapt and do a bad job at. It never states it's a single dimension of competence or incremental over their last role.
For example, getting promoted to "senior developer" may mean higher expectations than just "developer". But you may also be expected to architect parts of systems, mentor more junior staff, provide guidance etc. Even more starkly, if you get promoted to something like "team lead" or a more managerial/executive level position, your need to be focus more on prioritization, managing people, etc. Very different skills than writing code.