The LLM Critics Are Right. I Use LLMs Anyway.

LLMs should be used to make fewer things of higher quality, rather than more things of lower quality.

Key Points

The ‘dissonance’ of LLM usage: many senior engineers agree with critics regarding ‘AI slop’ and ethical concerns but continue to use tools like Claude Code to amplify their own thinking.
Risks to OSS: The flood of low-effort LLM PRs erodes trust, leading some projects (e.g., Zig, Gentoo) to refuse AI-generated contributions.
Impact on Junior Engineers: LLMs automate mundane tasks, potentially removing the incentive for seniors to teach juniors and making it harder to gauge a junior’s actual effort and growth.
Geopolitical and Corporate Risk: Dependence on frontier models (e.g., Anthropic) exposes users to abrupt export controls and corporate pricing shifts; local-weights models are the primary hedge.
The ‘Amplification’ Principle: LLMs do not replace thinking; they amplify existing opinions, structures, and frameworks. High-quality output requires a human to put thought behind the prompt.
Practical Workflow Patterns: Using the ‘/grill-me’ technique (relentless interviewing) and ‘Ralph Wiggum loops’ (sub-agents ripping apart plans) to force human rigor and eliminate hallucinations.

Intuition Probing: Letting an LLM hallucinate an expected API or UX before showing it the real design to test if the design matches common human expectations.
The 3-Sentence Problem Statement: Forcing a concise ‘Problem’, ‘Shipping’, and ‘Not Shipping’ statement to ensure human readability and factual accuracy.
Expertise Requirement: LLMs are most dangerous when used in fields where the user cannot distinguish ‘good’ from ‘dogshit’; they are best used as learning tools when a clear feedback loop (e.g., code compiling) exists.