Linus On LLMs For Coding

Large language models are likely to become a routine part of coding—first as assistants that help generate or check code, and eventually as tools that can contribute to code review and maintenance—but their usefulness depends heavily on human understanding and strong testing, not on “autopilot” trust. The conversation centers on a practical question: will LLM-written code be submitted as a request? The answer lands on “yes,” already happening in smaller ways, because automation has steadily moved closer to the developer workflow over decades.

A key tension runs through the discussion: optimism about LLM capability versus skepticism about reliability. One side points to the near-term value of catching “obvious stupid bugs” and flagging patterns that deviate from expected norms—similar to what compilers and linters do, but potentially at a higher level of nuance. The other side highlights a hard limit: LLMs can hallucinate, invent code paths, or produce confident-sounding mistakes. That risk becomes more serious when models are allowed to act without a human catching errors, especially in security-sensitive contexts.

The most concrete example involves security bug reporting around curl. A reported issue allegedly stems from a buffer-related error path that, in practice, does not match the repository’s actual code. The current maintainer pushes back, arguing the problematic snippet isn’t present, and describes an interaction where the person using the LLM believed the model’s output rather than verifying it against the codebase. The takeaway isn’t that LLMs can’t help; it’s that they can generate plausible but wrong details, and those errors can waste time or even misdirect security work.

Another thread argues that LLMs are best when they support—not replace—developer judgment. Manual translation between languages (cited in the discussion as an approach where a team outperformed “automagic” conversion) is used to illustrate why nuance matters: understanding edge cases and the real problem domain can outperform automation that merely “gets the syntax right.” The same logic extends to testing. The conversation repeatedly returns to the idea that good automated tests are the gatekeeper for safe adoption, yet there’s skepticism that “good enough” coverage exists broadly enough to make fully automated LLM-driven changes dependable.

The discussion also challenges how people talk about LLMs. Claims of being “10x better” after minimal use are treated as misleading, because they may only reflect improvement from a low baseline rather than mastery of what “good” looks like. There’s also a call for longer, deliberate experimentation—trying tools like Claude and other assistants over months rather than minutes.

Overall, the core insight is conditional: LLMs can be powerful accelerators for developers who understand the nuance of the system and can validate outputs with tests and review. Without that grounding, hallucinations and subtle misunderstandings can turn productivity gains into costly bugs—especially when teams scale usage faster than their verification practices.