> If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere.
"everyone writes it" in the long term can still allow specific people to write/fix/augment/refactor/etc specific parts in the short to medium term. i think it's a good goal to never have a part of the code that less than two or three people can maintain, but preferably more (depending on size of team(s) and codebase(s), obviously). i think this generally results in better quality code, and higher bus factor is inherently a good thing anyway.
i used to be kind of against style guides and style checking. but a not-too-rigid set of style norms, the willingness to bend or discard them when justified, and a generally well-behaved group of people that can collaborate well and agree that shared understanding has a lot of inherent value... those things together can get you a good codebase where "everyone writes some of it", or at least everyone can deal with most of it, even if people might have areas of expertise. nowhere near a panacea, and not even necessary depending on the team, but it can be useful even if it means people give up style tics they love or tolerate ones they hate. it also mechanically eliminates a lot of the temptation to nitpick a whole class of things that probably doesn't deserve nearly as much nitpicking as it'd get in code review, because everyone thinks their own personal taste matters more than it actually does (me included, that's why i used to not like style guides).
all the above is much easier if everyone's able to keep their ego in check, be collegial, enjoy the challenge of justifying decisions and accepting constructive criticism, etc. i guess that can be an unfortunately difficult setup to come by, but i've been really lucky on that front, by and large.
> To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors.
if you have what i described above, peer level code review with team leads and managers for the occasional tie breaker should work fine the vast majority of the time.
> In this process, people lose autonomy and can't fully act on their own vision.
if you work on a team, you have to work toward shared goals and vision. if a person wants to fully act on their own vision, they should be self-employed in a company of one (though they'll still be subject to market forces). if you're collaborating, you're necessarily involved in a shifting balance of autonomy, delegation, and being delegated to (which is often but not always where the autonomy comes in).