LLM Critics Are Right. Here Is Why Builders Use Them Anyway.

The critique of LLMs is not wrong. Hallucination is real. Context windows lie about their effective recall. Code generation produces plausible-looking bugs. Models are opaque, non-deterministic, and expensive at scale. Critics who raise these points are raising legitimate engineering concerns, not FUD.

The practical counterargument is not that the flaws do not exist. It is that the alternative is slower.

For a solo founder or a small team, the relevant comparison is not LLM output versus a senior engineer working at full attention. It is LLM output versus no output yet. The marginal cost of a first draft — whether code, documentation, a test scaffold, or a data transformation — collapses when you have a capable model in the loop. The human still reviews, edits, and owns the result. The model compresses the time before that review begins.

This is the actual workflow: treat the model as a fast, unreliable junior. You would not ship code from a junior without review. You do not ship LLM output without review. The trust model is the same. The throughput gain is real.

The honest version of this position also acknowledges the ceiling. LLMs perform well on tasks with clear structure and abundant training signal — standard library usage, boilerplate, pattern-matching against known problems. They degrade on novel architecture decisions, subtle concurrency bugs, and anything requiring institutional context the model cannot have. Knowing where that ceiling sits is the skill.

The critics are doing useful work by mapping the failure modes. Engineers who internalize those failure modes and deploy accordingly are not ignoring the critique. They are applying it.

The post at theocharis.dev articulates this position clearly: you can hold both things simultaneously — a clear-eyed view of the limitations and a pragmatic decision to use the tool anyway, with appropriate skepticism baked into the workflow.

Source