PRs are the final chance to avoid mishaps; be it some junior overdoing DRY, be it someone in the team misunderstanding (or insufficiently understanding) a requirement, something being forgotten, edge-case missed - practically anything! Before/During PR, a single person owns the code, after merge it's everyone in the project.

Someone who just rubberstamps PRs works either in a completely different setting than anything I can imagine or it's just someone who doesn't take ownership & responsibility as serious as I'd require people I want to work with; I can't quite see much room for gray area there...

Very well put. A PR is the final (and ultimate) chance to say "no" to a change - after that it's part of the software, it needs to be maintained, it can have impact on stability/quality etc.

I don't quite understand how someone in charge of a software (techlead or similar title) can't take this serious; I know a few such people and I generally prefer to avoid working with them...

Tao can use LLMs on his own terms, on his conditions. Under those circumstances, it's an absolutely fantastic tool.

In an enterprise, everyone gets to use LLMs. Everyone can create slop. In an enterprise environment, this can lead to weird situations where the senior has to put in extra efforts to contain the slop of others... so I can kind of see where the "hinders seniors" is coming from.

I don’t think it’s even “seniors” containing slop of others.

I think it’s those who still care about quality (which seems to be decreasing in the industry overall) trying to keep the whole thing running, in a sea of people who think going really really fast and not understanding their code is fine because LLMs can make sense of it and clean it up later.

Just look at the condition of open source contributions recently