# LLM Smells: The Tells in AI Writing, and the Costlier Ones in AI Code > Source: > Published: 2026-06-06 01:20:02+00:00 there is a piece by shrijal shrestha called "various llm smells" that put words to something i think a lot of us have been feeling but not naming. the argument is simple: ai-assisted work leaves a residue. once you have seen enough of it, you can spot it instantly, the same way you can hear autotune. he calls it ai-smell, and his point is that it shows up across very different tasks. writing has its tells. websites have their tells. and now that the tools are everywhere, the tells are everywhere too. i build comparison content and small dev tools, and i run a content pipeline that posts to real communities, so this is not an abstract aesthetics debate for me. i have a humanizer step in my own stack whose entire job is to strip these tells out before anything goes public, because the tells are not free. so i want to take shrestha's observation seriously, extend it to the place it costs real money, and tell you what i actually do about it. the prose smells he points at are the ones you already half-noticed. the constant punchline cadence, where every few sentences lands a quotable little zinger. the run of three short sentences in a row for fake emphasis. the "x is the y of z" metaphor that sounds clever and says nothing. and the rhetorical move where a sentence sets up a contrast it does not earn. none of these are wrong on their own. a human writer uses all of them. the smell is the density. the model reaches for them constantly because they are cheap and they pattern-match to "good writing," and the result reads like someone doing an impression of insight. the design tells are the same story in a different medium. the jetbrains mono font on a marketing page. every step in a list styled identically. uniform card components, the same button treatment, the little blinking-dot "live" badge that every ai-scaffolded landing page now ships with. shrestha is careful to say he is not against using these tools, and neither am i. the point is recognition, not purity. here is why it matters beyond taste. i have watched what these tells do in the wild. communities flag them. moderators and automated filters treat the cadence as low-effort spam, sometimes correctly. readers discount the content the moment they clock it. that is the whole reason my pipeline runs every draft through a humanizer before it touches reddit or anywhere else. the smell is a signal, and the signal people read is "nobody actually cared about this." in a feed that is already drowning in generated text, that signal gets you ignored at best and removed at worst. prose smell is annoying. code smell is a bill. and ai-generated code has its own recognizable residue once you have reviewed enough of it. you learn the patterns fast. the redundant defensive checks for conditions that cannot happen. the dead variable that gets assigned and never read. the function that reimplements something already three files over, because the model could not see the rest of your codebase and had no reason to look. the comment that restates the line below it in english. the solution that solves the problem exactly as stated, which is the problem, because the stated problem is usually a little different from the real one. the model does not know your table has fifty million rows or that the endpoint gets hammered ten thousand times a second. it answers the prompt, not the system. the difference from prose is that here the cost is measured, not felt. veracode ran `80` curated tasks across more than `100` models in their 2025 genai code security report and found that `45%` of the generated code introduced a security flaw, against a human baseline closer to `25-30%` on the same kind of testing. it gets worse by language and category. java-generated code failed security checks more than `70%` of the time. cross-site scripting came in at an `86%` failure rate, log injection at `88%` . these are not exotic bugs. they are the boring cwe entries that have been on every checklist for fifteen years, and the model ships them while sounding completely confident. there is a quieter cost too. a 2026 study on ai-generated pull requests found measurably more code and measurably less reuse than human prs, which is technical debt arriving silently because the surface looks fine. the code reads plausible, passes a glance, and quietly duplicates logic you already had. you do not notice until the third copy drifts out of sync. the obvious move is to point a second model at the first model's output and call it review. it half works and it hides a trap. when the generator and the reviewer reason from the same artifact, they fail in correlated ways. the reviewer checks the code against the code, not against what you actually meant. and models are sycophantic, so a reviewer model will often agree with a confident wrong answer rather than push back. you end up with two ai's nodding at each other while the cwe-89 sql injection sails through. so the review has to be anchored to something the model did not write. that means a few unglamorous habits. write the intent down as an executable spec or a test before you accept the code, so there is an external thing to check against. review for architecture and reuse, not just syntax, because syntax is exactly what the model gets right and structure is what it gets wrong. and run the security tooling you would run on any code, because "an ai wrote it" is not a clean bill of health, it is the opposite. the through-line from shrestha's piece holds in both worlds. the smell is a tell that the work was generated and not yet owned. in prose you fix it by actually rewriting in your own voice. in code you fix it by actually reviewing against your own intent. the tool is fine. the residue is the part you are still responsible for. if you want the concrete version of the code half, the test patterns, the review checklist, and how to anchor an ai's output to a spec instead of trusting it, i pulled them together in the [claude code testing cookbook](https://contrite5.gumroad.com/l/uvkros). and if you like these teardowns, i write more of them at [tools.thesoundmethod.me](https://tools.thesoundmethod.me?utm_source=devto&utm_medium=article).