That could be even worse, even if your co-founder is still available. What if your co-founder is stuck on a difficult problem, and needs a second set of eyes on the code to help him out? If he has been writing vomit-code the whole time, will you be able to help?

The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work.

This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.

I think the core idea of #7 is to give a vast amount of freedom to each person in their work so they can let their brain run wild on the problem without restriction. Even if that's not what PG meant, it certainly is what I mean.

I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.

No problem with the idea of letting peoples' brains run wild on a problem. I suspect you and I could debate for some time about your latter point; I'd worry about things ranging from bus factors to developers who become expert in some set of things later being confined to those areas of expertise to avoid stretching their knowledge portfolio to thin, whatever that means. Maybe it is worthy of it's own conversation somewhere; maybe such a conversation already happened that I could get more insight from.