The LLM Critics Are Right. I Use LLMs Anyway

Jeremy Theocharis wrote this after Local-First Conf in Berlin (July 2026), where he noticed a dissonance he shares: rooms full of engineers with Claude Code open, applauding speakers who say critical things about LLMs. He agrees with almost every anti-LLM argument and uses LLMs heavily anyway — his June 2026 token spend was $9,838 (Opus 4.8 $5,042, Fable 5 $4,179, Sonnet 4.6 $452). The piece is an attempt to describe the reconciliation rather than resolve it.

The concessions

Theocharis grants the critics' points up front and doesn't relitigate them: copyrighted training data, environmental cost, the NVIDIA/OpenAI circular-financing setup, the bubble that will burst. Where he adds detail is the effects on software culture:

• Slop kills the trust OSS ran on. A proper PR used to cost human time, which filtered out trolls and signaled the author had spent hours. That signal is gone — a maintainer can't tell a carefully-built PR (Claude used only for the description) from an OpenClaw machine acting on its own. This is the same collapse i-dont-want-your-prs and agent-principal-agent-problem describe. His speculative fix: only let a small set of verified people contribute, verification via a real-life meetup. He thinks bans like Zig's and Gentoo's (simonw-zig-anti-ai, llm-enshittification) can't work because you can't reliably tell.
• The junior-engineer pipeline breaks two ways. (a) A senior reviewing a junior's code no longer knows if it was vibe-coded in 10 minutes or genuinely struggled over for hours. (b) The teaching incentive disappears — mundane tasks that used to be the junior's growth path now go to the LLM, so why hire juniors? This is the apprenticeship-loss argument programming-still-sucks names.
• Geopolitical cutoff risk is not hypothetical. He cites Anthropic being forced to disable Fable 5 and Mythos 5 for all customers in June 2026 under a US export-control directive suspending access by any foreign national. Quotes Martin Kleppmann: the probability of a Europe/US conflict is still very low, "but last year, it was zero."
• Silent opinion drift. LLMs sneak in the majority view of their training data (or the model-makers' convictions). Like two people talking, opinions merge over time — except one participant isn't human.

Why he uses them anyway

His central claim: LLMs amplify what you already have; they don't supply what you don't. "If you have thoughts, they come out sharper and faster. If you have nothing, nothing comes out, very fluently." They're good at brainstorming, grammar, alternatives, rubber-ducking, devil's advocate — and good at producing large volumes of plausible content nobody would read aloud. The value for him is making fewer things higher quality (he cites Nolan Lawson's "using AI to write better code more slowly"), spending an extreme number of tokens to prepare a few sentences for a human. This is the inverse of the llm-as-average-democratizer failure mode — using amplification deliberately instead of settling for the cheap average.

On open-weights models: they keep the large vendors honest when subsidies end, can't be cut off overnight by a government, and survive the bubble bursting. Programmers can fall back on them. This is the titit-local-ai / lucumr-local-models argument, arrived at from the resilience angle.

The credibility test

The load-bearing idea. Amplified bullshit sounds like genius, so from the outside you can't tell "I use AI to think better" (Theocharis) from the identical sentence out of an AI tech-bro. All that's left is trust, which is hard to gain and easy to lose — a single em dash can invalidate a whole piece. His personal test for whether text is slop: would you stand in front of an audience and read it out, word for word, unashamed? If your answer is "well, I'd explain what was meant" — it's slop. This is credibility-as-slop-test.

The patterns

The workflow half of the piece — concrete techniques that counter LLM agreeableness:

• /grill-me (adapted from Matt Pocock): a short skill that tells the LLM to interview you relentlessly, one question at a time, resolving the decision tree branch by branch, looking up facts itself but putting every decision to you, and not acting until you confirm shared understanding. Forces you to form your own thoughts. He now uses this for everything, including writing this article sentence by sentence.
• Basecamp "Pitch" discipline. For any code change he writes a three-sentence Problem / What we're shipping / What we're not shipping. The constraint works because it was designed for humans — three sentences are short enough that he actually reads them, so another human can too. Analogy to code review: 1,000-line PR gets "LGTM"; 100-line PR gets 15 comments. He skims most LLM output but fact-checks the three-sentence problem statement hard.
• Adversarial subagents (the Ralph Wiggum loop / Claude's ultracode): lock the LLM to a plan, then keep spawning fresh-context subagents whose only job is to rip it apart, until they're forced to hallucinate problems. When they hallucinate, the weakness becomes a signal — they want to agree there are problems but can't find real ones.
• Intuition probe (from Anselm Eickhoff): let a blind LLM hallucinate the API/UX it expects before seeing the real thing. Whatever it guesses is probably what most humans would guess, so it's a cheap test of whether your design matches expectations. He built it into a skill.

The precondition

Every pattern depends on one thing: he has to be able to tell whether the result is good. The more he uses LLMs, the more he ends up in fields he doesn't know — and then he needs experts, because "I can only program things if I understand them." Delegation to an LLM works like delegation to a teammate: only for tasks where you understand the basics and know what good looks like.

He splits learning by whether correctness is cleanly checkable. Where there's a hard check — code compiles or not, tests green or not, protocol decodes or not — you can point the LLM at it and learn together (his example: someone reverse-engineering binaries with Opus 4.6, needing only basic RE knowledge, because the patched binary either worked or bricked the device). In opinion-heavy fields like programming, the LLM just returns the most popular technique, which may be wrong for your case — there you need humans to give you good starting opinions. He recounts a team argument about "AI slop" that turned out to be a disagreement about TDD, not about AI at all: LLMs amplify, so a fight over LLM output was really a fight over human opinions.

Where it sits

This is the reconciliation slot the anti-llm-discourse map was missing — someone who accepts the critics' premises and neither refuses (Moser, i-am-an-ai-hater) nor routes around them via career strategy (Verna, elena-verna-job-2027), but tries to describe a disciplined middle. Closest neighbors: simonw-vibe-coding-agentic (Willison conceding the vibe-coding/engineering line collapsed in his own practice) and ai-assisted-workflow (planning-before-code discipline). The load-bearing move that keeps it out of tech-bro territory is the same one cult-of-vibe-coding makes from the other direction: you must be able to evaluate the output, or you're just running a slop factory.

Interesting from the discussion

The Lobsters thread pushed on the piece's blind spot:

• The output is bad writing, and the post assumes it isn't. The top comment (Corbin): the author lists copyright, ethics, slop, and economics as the critics' concerns but "completely fails to notice that the output of Transformer-driven chatbot harnesses is bad writing." The post only reads as coherent if you assume chatbots are good writers; treating that as almost-agreement is "a dire misreading of a neighboring culture." A reply notes the author literally says "let me go through the biggest ones one by one" and then discusses none of them.
• Amplification is not augmentation. "Just because you can yell louder doesn't mean what you have is worth yelling about." LLMs replicate patterns humans read as high quality; there's no guarantee the quality is real, only that it appears so — the appears-to-be vs proves-to-be distinction.
• Friction is a gating function. The sharpest counter to "if you have thoughts they come out sharper and faster": friction forces you to decide which ideas are worth fleshing out, adopting, and defending. A system that turns every shower thought into a multi-page essay removes that and produces "cognitive diarrhea" — and the arguments you get out are uniformly same-y, literally the same text everyone else gets. Proposed test: do you have any AI-written blogs you love and await the next post from? Probably a short list.