Exactly.

Another problem with LLMs is that they are actually useful in some tasks and they can generate very good quality code if you're diligent enough developer. I also have built personal tools with them, but I don't have the knowledge of the code the LLM has hallucinated which means that before I would push this code forward I will have to basically familiarise myself with the code in a way how a code review works.

The knowledge you gain from this is also different from that of actually writing and running the code yourself. I have seen people who use LLMs to write commit messages which is the last thing you should do. Commit messages are probably the only places were we can meaningfully store the knowledge gathered during development and the more I see LLM commits the more I lose hope.

Everyone starts off without references, and there's already less of a pipeline from user to helpful contributor to fellow maintainer than most projects want without having to add more chokepoints. There isn't a solution without downsides while there are people using LLMs.

This works if you have the luxury to select the people whose PRs you review, but in a corporate environment you just don't have that option. I would love to just reject obvious LLM code, but it's not going to keep me employed. Instead I'm stuck at figuring out how to meaningfully review LLM changes and how to manage the mental model with these rapid changes.