Why LLM Critics Are Right Yet I Still Use LLMs – Lessons from Local‑First Conf 2026

TL;DR – The core takeaway

The biggest critiques of LLMs (copyright leakage, environmental impact, trust loss, and geopolitical fragility) are valid, but the author still uses LLMs because they can dramatically boost personal productivity when paired with disciplined workflows that enforce human oversight and quality control.

1. The criticisms are spot‑on

Conclusion: Every major objection to LLMs holds water and explains why many engineers are wary.

  • Copyright and plagiarism – LLMs are trained on massive copyrighted corpora, so generated code can unintentionally reproduce protected snippets.
  • Environmental cost – Training and inference consume significant electricity; the author’s own token spend in June 2026 cost $9,838.85 (see screenshot).
  • Trust erosion – Auto‑generated pull requests (PRs) make it impossible to tell whether a contributor spent hours on a solution or simply let an LLM do the work. Projects such as Zig and Gentoo have begun refusing LLM‑generated contributions.
  • Geopolitical risk – Export‑control orders can abruptly cut off access, as happened when the U.S. forced Anthropic to disable Fable 5 and Mythos 5 for non‑U.S. users in June 2026.
  • Opinion amplification – LLMs inherit the dominant viewpoints in their training data, subtly steering users toward the majority perspective.

"the probability of a conflict between Europe and the US is still very low. But last year, it was zero." – Martin Kleppmann, Local‑First Conf, 2026

These points are echoed in the Hacker News discussion, where commenters warn that long‑term reliance could atrophy engineering skills and create a “smartphone‑like” addiction to AI.

2. Why the author still uses LLMs

Conclusion: LLMs remain useful when they are treated as assistants, not authors.

  • Local execution – Running open‑weight models on a personal laptop avoids vendor lock‑in and government shutdowns.
  • Productivity boost – The author can produce higher‑quality output faster, spending many tokens to craft a few well‑vetted sentences.
  • Human credibility – When a speaker publicly attributes a result to an LLM, they risk losing credibility; therefore, most presenters use the model only for drafting and then personally verify every line.
  • Thought amplification – LLMs sharpen existing ideas, acting as a rubber‑duck or devil’s‑advocate, but they cannot generate original insight without human direction.

"If you read the text word‑for‑word and are not ashamed of it, congratulations, it is a good text." – Author’s own rule for distinguishing AI slop from genuine writing.

3. Practical patterns for safe LLM use

Conclusion: Structured prompting and rigorous review turn LLMs into reliable collaborators.

3.1 The /grill‑me skill

A step‑by‑step interrogation forces the model to confirm every decision before proceeding.

Interview me relentlessly about every aspect of this until we reach a shared understanding.
Ask one question at a time, wait for feedback, and never act until I confirm.

This technique prevents the model from silently hallucinating and keeps the human in the decision loop.

3.2 Three‑sentence problem statements

Borrowed from Basecamp’s Shape Up methodology, the author writes a concise Problem, What we ship, and What we don’t ship description. The brevity makes it easy to manually verify the LLM’s output.

3.3 The Ralph Wiggum loop (or Claude Ultracode)

Lock the primary LLM’s context, then spawn fresh sub‑agents whose sole job is to tear the context apart. When sub‑agents start hallucinating, the author knows the main output is solid enough to proceed.

3.4 Intuition‑probe hallucination test

Let an LLM guess the API or UX it expects before seeing the real design. If the hallucination matches typical user expectations, the design is likely intuitive.

"A blind agent commits the design it expects before seeing the real thing, then reports the shape it reached for." – Screenshot from the author’s GitHub gist.

4. When to trust the model – the “knowledge‑gap” rule

Conclusion: Use LLMs only in domains where you can objectively verify the result.

  • Clear success criteria – Compile‑time success, test‑suite pass, or protocol correctness give binary feedback.
  • Expert oversight – If you lack the expertise to judge output, involve a human expert before merging.
  • Avoid opinion‑heavy tasks – For stylistic or architectural decisions, the model will merely echo the most common practice, which may not be optimal for your context.

5. Community sentiment from Hacker News

Conclusion: The broader community shares the author’s mixed feelings.

  • Supportive voices note that LLMs “make my work easier and faster” and that disciplined use yields tangible benefits.
  • Skeptical voices warn of skill atrophy, echoing the comment: “Actual muscles need exercise to stay in shape… can we be sure thoughts will still be sharper after 20 years of daily AI use?”
  • Cost concerns surface repeatedly; one commenter highlighted the author’s $10 k token spend as “insane” while others report staying under $20 per month.
  • Ethical worries about corporate control and geopolitical shutdowns are echoed throughout the thread.

6. Final recommendation

Conclusion: Treat LLMs as powerful, but fallible, tools; enforce strict human review, limit usage to verifiable tasks, and stay aware of the broader societal implications.

By acknowledging the criticisms, adopting disciplined prompting patterns, and keeping the human in the loop, engineers can reap the productivity gains of LLMs without surrendering trust, skill, or ethical responsibility.

Sources

Related