LLM code smells: hedging language and structural filler

Someone compiled a list of LLM code smells and it reads like a field guide to spotting generated pull requests. The tell is not the code itself. It is the prose wrapper. Hedging language everywhere. “It’s important to note that”, “arguably”, “potentially”. The model outputs uncertainty markers because it was trained on academic papers and Stack Overflow answers where people cover themselves. Production code does not need a disclaimer. Structural filler is the other flag. Every function gets a docstring, even the one-liner that returns true. Every block of logic gets a comment that restates the code in slightly different words. The model thinks documentation density equals quality. It does not. The list includes less obvious markers too. Variable names that are suspiciously descriptive. Error messages that apologise. Type hints on everything, even when the type is obvious from context. None of these are wrong individually, but together they form a signature. What surprised me is how fast these patterns became recognisable. Six months ago I would not have noticed. Now I see it in vendor SDKs, in GitHub issues, in documentation PRs. The writing has a uniform smoothness that human inconsistency lacks. The fix is not to ban generated code. It is to treat the output as a draft that needs the filler stripped out. Delete the hedging. Cut the redundant docstrings. Rename the variables to something a human would actually type. The logic might be fine. The presentation gives it away.

---

Source: Various LLM Smells