The LLM Critics Are Right. I Use LLMs Anyway

This article highlights a critical tension in the AI/ML space: the reliance on LLMs despite their acknowledged flaws. It's an interesting observation that even skilled engineers like Armin Ronacher, who is navigating these waters with his startup Earendil, resort to auto-closing PRs to mitigate the flood of low-quality contributions generated by LLMs. Here's the thing: the problems with LLMs are well known—they produce slop, present ethical dilemmas, and are tied to a questionable economic model. Yet, the allure of using these models persists, even among those who are aware of the risks, creating a cognitive dissonance in the community.

What they're not saying is that this auto-closing approach isn’t just a sign of caution; it reflects a deeper operational burden that many teams will face as they integrate these technologies. Managing the contributions from LLMs can quickly become a full-time job, diverting attention from actual product development. For data engineers and developers still keen on using LLMs, it’s essential to weigh the benefits against the additional complexity and trust issues they introduce.

The catch? Many practitioners are using tools like Claude Code while simultaneously acknowledging their limitations, highlighting a community grappling with ethical concerns even as they embrace the technology. This contradiction isn't just philosophical; it has practical implications on project timelines, code quality, and team dynamics.

So who benefits here? Teams already comfortable with a robust review process can leverage LLMs to enhance productivity but must be prepared to invest in managing quality control. If that’s not your team's strength, you might find yourselves overwhelmed by the noise these tools generate. As for a concrete action: assess your current workflow and determine if you have the capacity to handle the operational complexity that comes with LLM contributions before diving deeper into the LLM rabbit hole.