Why LLM Critics Are Right Yet I Still Use LLMs – A Deep Dive into the Dissonance

Why LLM Critics Are Right Yet I Still Use LLMs – A Deep Dive into the Dissonance

TL;DR – Critics are correct, but LLMs remain useful when used with disciplined workflows that restore trust and amplify human thinking.

The Core Dissonance

The author attended Local‑First Conf in Berlin and heard leading engineers (e.g., Armin Ronacher) denounce LLM‑generated noise while simultaneously using tools like Claude Code on stage. This paradox—recognizing the flaws of LLMs yet relying on them daily—mirrors a broader community tension.

“Are you accepting PRs for Pi, or how do you handle the flood of PRs from LLMs?” – Armin Ronacher, live on stage.

Ronacher answered that his team auto‑closes almost every LLM‑generated PR, yet he encourages humans to submit contributions because “the human will always shine through.” The author sees the same pattern across many projects: a flood of low‑quality, AI‑generated contributions that erodes trust.

Why the Criticisms Matter

1. Quality‑of‑Contribution Slop

  • LLMs produce a high volume of code that often contains hallucinations, duplicated licenses, or insecure patterns.
  • Open‑source projects such as Zig and Gentoo have begun rejecting AI‑generated PRs because maintainers cannot reliably assess the effort behind a submission.

2. Trust Erosion for Junior Engineers

  • Senior reviewers can no longer tell whether a junior’s code reflects genuine learning or a 10‑minute AI prompt.
  • The incentive to mentor diminishes when mundane tasks are outsourced to an LLM, potentially reducing junior hiring.

3. Geopolitical and Legal Risks

  • The U.S. export‑control order that forced Anthropic to disable Fable 5 and Mythos 5 for non‑U.S. users illustrates how sudden policy changes can cut off access.
  • Dependence on proprietary models creates a single point of failure for teams and organizations.

4. Ideological Drift

  • LLMs inherit the dominant viewpoints present in their training data, subtly steering user opinions toward the majority.
  • This “opinion amplification” can homogenize technical discourse, reducing diversity of thought.

Why the Author Still Uses LLMs

1. Local, Open‑Weight Models Offer Resilience

  • Running models on a personal laptop removes reliance on cloud providers and mitigates export‑control shutdowns.
  • Open‑weight alternatives keep large vendors in check and ensure a fallback when commercial services become prohibitively expensive.

2. Amplification of Human Thought, Not Replacement

  • When a skilled engineer frames a problem, the LLM can sharpen language, generate alternatives, and act as a rubber‑duck for debugging.
  • The author uses LLMs to produce fewer but higher‑quality artifacts, spending large token budgets only on critical, human‑reviewed outputs.

3. Trust Is Re‑engineered, Not Abandoned

  • Credibility hinges on whether a human can stand behind the final text or code.
  • The author treats LLM output as a draft 0 that must be vetted, fact‑checked, and often rewritten before public release.

Practical Patterns for Trustworthy LLM Use

The following techniques are distilled from the author’s workflow and community discussions. Each pattern can be quoted independently.

1. The “Grill‑Me” Prompt

Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies one‑by‑one. For each question, provide your recommended answer.

Ask one question at a time and wait for my feedback before continuing. Do not act until I confirm shared understanding.

Forces the model to surface assumptions and lets the human validate each step, preventing silent hallucinations.

2. Three‑Sentence Problem Statements

  • Borrowed from Basecamp’s “Pitch” methodology.
  • Write a concise problem, scope, and exclusion in three sentences before prompting the LLM.
  • The brevity makes it easy for a human to verify correctness and for reviewers to skim quickly.

3. Counter‑Agent “Ralph Wiggum Loop”

  • Spawn a fresh LLM instance whose sole job is to tear apart the current context.
  • Continue until the sub‑agent starts hallucinating contradictions, indicating the original output is robust.

4. Intentional Hallucination (Intuition‑Probe)

  • Let an LLM generate an API or UI design without seeing the real implementation.
  • Compare the hallucinated design to the actual product; alignment suggests good user intuition, misalignment highlights blind spots.

“A blind agent commits the design it expects before seeing the real thing, then reports the shape it reached.” – author’s intuition‑probe skill.

5. Token‑Budget Discipline

  • The author’s June 2026 spend: $9,839 across Opus 4.8, Fable 5, and Sonnet 4.6.
  • After the spike, the author switched to cheaper models (e.g., GLM 5.2) and restricted high‑cost models to selective tasks.

Community Reflections (Selected HN Comments)

“Will LLMs enrich my thinking in the long run, or will they ruin it?” – @mark_and_sweep

“I spend $10k on tokens a month; is that insane?” – @swiftcoder

“Open‑source projects are flooded with low‑quality PRs; blocking external contributors may protect maintainers but reduces community growth.” – @a1o

These comments echo the article’s themes: cost, trust, and the trade‑off between openness and quality control.

Conclusions

  1. Critics are right about the risks: sloppiness, trust erosion, environmental impact, and geopolitical fragility.
  2. LLMs are not obsolete; they become valuable when paired with disciplined, human‑centric processes that restore trust.
  3. Patterns like “grill‑me”, concise problem statements, and counter‑agent loops enable engineers to harness LLM power without surrendering judgment.
  4. Community consensus shows a spectrum of usage—from cautious adoption to outright rejection—highlighting the need for shared best practices.

“If you can tell good from dog‑shit, you can delegate; otherwise, you risk amplifying AI slop.” – author’s final warning.

The dissonance described at Local‑First Conf is real, but it is manageable. By treating LLMs as powerful assistants rather than autonomous authors, developers can reap productivity gains while preserving the credibility and trust that open‑source ecosystems depend on.

Sources