LLM Critics Are Right. Senior Engineers Use Them Anyway.

The critique is familiar: LLMs hallucinate, produce plausible-sounding nonsense, flatten nuance, and fail on tasks requiring genuine multi-step reasoning. None of that is wrong.

The practitioner position is different from the critic position. Critics evaluate LLMs against what they claim to be. Practitioners evaluate them against the next-best alternative — which is often a blank editor and a slower afternoon.

The honest frame is cost-benefit with known failure modes. LLMs accelerate a specific class of task: boilerplate generation, first-draft scaffolding, pattern-matching against familiar codebases, documentation stubs. On those tasks, the failure rate is low enough and the output reviewable enough that the net gain is real. On tasks requiring precise reasoning, unfamiliar domains, or correctness guarantees, the failure rate is high enough that unsupervised LLM output is a liability.

Senior engineers who use LLMs fluently are not ignoring the critics. They have internalized the failure modes and routed work accordingly. They review generated code the same way they review a junior's PR — with the assumption that something is probably subtly wrong. The tool accelerates drafting; judgment still lives with the engineer.

For solo founders, the calculus skews further toward use. A solo founder does not have a senior engineer to review unfamiliar code. LLMs fill that role imperfectly but consistently. Imperfect and consistent beats absent.

The productive synthesis: maintain the critic's epistemic standards — verify outputs, test thoroughly, do not trust confident-sounding generated text on anything load-bearing — while keeping the pragmatist's workflow. The critics and the practitioners are both right. They are answering different questions.

The gap worth closing is not between critics and users. It is between engineers who have calibrated their LLM usage and those still treating the tool as either oracle or useless.

Source