> I get it; I do. It's rapidly challenging the paradigm that we've setup over the years in a way that it's incredibly jarring,

But it's not the argument. The argument is that these tools provide lower-quality output and checking this output often takes more time than doing this work oneself. It's not that "we're conservative and afraid of changes", heck, you're talking to a crowd that used to celebrate a new JS framework every week!

There is a push to accept lower quality and to treat it as a new normal, and people who appreciate high-quality architecture and code express their concern.

"Find any inconsistencies that should be addressed in this codebase according to DRY and related best practices"

This doesn't hurt to try and will give valuable and detailed feedback much more quickly than even an experienced developer seeing the project for the first time.

These kinds of instructions are the main added value of LLMs and I use them every day. Even though 30%-60% the output is wrong/irrelevant, the rest is helpful enough. After the human reviews it, the overall quality of the codebase increases, not decreases. This is on the opposite end of the spectrum when compared to agentic coding, though.

  > It will accelerate the work and change your role from what it is today to something different;

We yet to see if different is good.

My short experience with LLM reviewing my code is that LLM's output is overly explanatory and it slows me down.

  > something that takes time and experience to work with.

So you invite us to participate in sunken cost fallacy.

Tell it to summarize?

I cannot because these reviews are comments in Github PRs. I have to read them.

I don’t doubt that companies are willing to try low quality things. They play with these processes all the time. Maybe the whole industry will try it.

I’m available for consulting when you need something done correctly.