Jeremy Theocharis, CTO of UMH, published a post that puts words to a widespread feeling: LLM critics are right about almost everything, and he uses them anyway. The piece gathered over 300 points on Hacker News, and the comments show that the dissonance he describes is shared by many.

Theocharis recounts being at Local-First Conf in Berlin, where speakers criticized LLMs to thunderous applause, while the audience had Claude Code open on their laptops. Armin Ronacher, creator of Flask, admitted from the stage that he auto-closes almost all PRs and issues on his Pi.dev project, because they’re flooded with model-generated contributions.

Why it matters to you. If you’re using AI in your work, you probably already know this tension. The problems are real: the flood of low-quality contributions is eroding trust in open source, and people who should have learned from tedious work delegated by seniors find themselves without a growth path. But the tool, used with judgment, saves real hours. As we noted when the creator of Zig and George Hotz converged on the same position, LLMs are useful and singularity hype is empty (/en/radar/zig-geohot-anti-hype-convergence).

The useful conversation is among those using the tool and wanting to use it better, knowing exactly where it breaks.

In detail

Theocharis structures the post in three parts: the valid criticisms, why he uses LLMs anyway, and the concrete patterns he found.

The criticisms he shares. Training on copyright-protected material, environmental impact, the financial bubble around NVIDIA and OpenAI: Theocharis says he agrees on almost everything. The point he explores most is the quality of open source contributions. Before LLMs, creating a decent pull request required human time, and that time served as a natural filter. Now anyone can open a GitHub account and run a model on a repository, and the maintainer can’t distinguish thoughtful contributions from mass-generated ones. Projects like Zig and Gentoo have already tried rejecting AI-generated PRs, but Theocharis notes it’s impossible to verify reliably.

The second point concerns juniors. A senior always corrected junior code, but used to know the junior had spent hours on that task. Now they don’t know that anymore. And since repetitive tasks (the ones that served as apprenticeship training) can be delegated to an LLM, the senior has less incentive to take on juniors and teach them the craft.

Why he uses LLMs anyway. Theocharis doesn’t offer a philosophical defense. He says the tool works for his job, and denying it would mean denying the evidence. The position converges with other technical voices in the community: recognizing the flaws means using the tool with eyes open, not abandoning the benefit.

The Hacker News comments show the same split. Many confirm the trust problem in contributions. Others point out that the open source business model based on volunteerism was already fragile before LLMs. Some note that the solution lies in building different verification and trust systems, perhaps based on verified identity off-chain, instead of banning outputs you can’t distinguish.

What remains open. The post doesn’t resolve the tension, it names it. For those working with AI, the practical takeaway is what the course covers in the lesson on calibrated trust: not all errors weigh the same, and knowing where to look before using a result matters more than checking everything or checking nothing.