> I didn't make a decision on the tradeoff, the LLVM community did. I also disclosed it in the PR.

That's not what the GP mean. Just because a community doesn't disallow something doesn't mean it's the right thing to do.

> I also try to mitigate the code review burden by doing as much review as possible on my end

That's great but...

> & flagging what I don't understand.

It's absurd to me that people should commit code they don't understand. That is the problem. Just because you are allowed to commit AI-generated/assisted code does not mean that you should commit code that you don't understand.

The overhead to others of committing code that you don't understand then ask someone to review is a lot higher than asking someone for directions first so you can understand the problem and code you write.

> If your project has a policy against AI usage I won't submit AI-generated code because I respect your decision.

That's just not the point.

> It's absurd to me that people should commit code they don't understand

The industrywide tsunami of tech debt arising from AI detritus[1] will be interesting to watch. Tech leadership is currently drunk on improved productivity metrics (via lines of code or number of PRs), but I bet velocity will slow down, and products be more brittle due to extraneous AI-generated, with a lag, so it won't be immediately apparent. Only teams with rigorous reviews will fare well in the long term, but may be punished in the short term for "not being as productive" as others.

1. From personal observation: when I'm in a hurry, I accept code that does more than is necessary to meet the requirements, or is merely not succinct. Where as pre-AI, less code would be merged with a "TBD" tacked on

[dead]