[nairb774]

The quality of a PR is a reflection of the author not the tools the author uses. The last thing an engineer should do before sending out a PR is to review it themselves. A PR is a work product with their name on it, and is a reflection of their ability. This was true before LLM tools, and should be true after.

[Anonbrit]

The trouble with AI and junior engineers is that they tend not to have the skills to tell what is good or bad. It used to be the same problem with code taken from stack overflow with no understanding.

It's surprisingly hard to reliably catch either issue in code review. Indeed it's hard to do code review that catches the majority of any class of problem

[isgb]

I don't have any evidence for it, but I feel that watching someone (or something) perform a task has less pedagogical value that performing that task oneself.

Same for attention, it's easier let your mind wander if you're e.g. taking the back seat while you're pair programming.

AI tools also don't really "reason", do they? Even if you use a reasoning model, they perform the most statistically likely steps with the context and instructions that they're provided, so you lose that "deliberateness" that enables you to best understand the problem that you're solving.

> The last thing an engineer should do before sending out a PR is to review it themselves. A PR is a work product with their name on it, and is a reflection of their ability.

Right, but your understanding of a PR that you're reviewing is different when you review your own work vs. when you review someone else's, right? For me personally, I have to expend more effort reviewing someone else's work.

If you can see how all of this adds up, I hope you understand how this leads to AI being more of a handicap than a tool.