Live data from Hacker News

Various LLM Smells

shvbsle.in

201–210 of 312 posts

Re: Various LLM Smells

#201
post #11

> The LLM generated writing obviously felt significantly better than my own writing. A general pattern for LLMs is that they look really good at things you are bad at. What that means is that if you find yourself thinking of its output as significantly better than yours in a particular domain, there's a high chance that you are not equipped to judge that quality effectively.

Honestly, I can't fathom thinking that LLM writing is even remotely passable. People that think this should honestly read more. One book a month is hardly an aspirational goal. You don't even have to read Melville or Hemingway or Chaucer or Shakespeare, just pick up any popular NYT best seller, and it'll be significantly better than anything an LLM can generate.

Depends on the type of writing. Blogs and the like? LLM generates prose that, to me anyway. is unbearable.

However, in fiction I’ve found it a useful collaborator. There have been more than a few occasions when, given some notes of how I want a character’s arc to develop in a particular scene, that the LLM gives some excellent pointers and ‘new’ ideas I hadn’t considered.

As far as editing my prose, I use it as a ‘thesaurus of phrases.’ When lazy, I can give it a rough sketch of the paragraph, giving it the gist of what I want, and have it generate a dozen or so versions. I usually can find nuggets of good phrases therein that are useable… much as I would refer to Roget’s to find a more precise word.

That said, one has to resist tbe temptation of using a chunk of generated text verbatim; no matter how good it sounds in isolation, the repetitive grammatical structure and other LLM-smells add up quick and become nauseatingly obvious if used frequently.

In any case, I think LLM’s get a bad wrap for writing… when used correctly, it is incredibly useful. And, it’s tiresome to hear pretentious snobs assume that an author who uses LLM simply lacks the taste to appreciate how bad the prose sounds. Not true in all cases.

Re: Various LLM Smells

#202

> The LLM generated writing obviously felt significantly better than my own writing. A general pattern for LLMs is that they look really good at things you are bad at. What that means is that if you find yourself thinking of its output as significantly better than yours in a particular domain, there's a high chance that you are not equipped to judge that quality effectively.

You can triangulate. Ask it the same thing in different ways and with different LLMs. Operate in domains where the output is verifiable, like in the sciences but in terms of numerical computing. Study the output, graph it, learn it, reason with it, rinse, and repeat until your mental model makes practical sense.

Re: Various LLM Smells

#204
post #85

Earlier quoted context omitted.

> A general pattern for LLMs is that they look really good at things you are bad at. This is true for coding, too, which I think, to a large degree, might explain the polarized differences in opinions on HN about the quality of LLM-produced code. You have the 1. "AI produces code better than I could possibly write, one shots things it would take me days to do, and has made me 10X more productive!" camp, and you have…

Well, I have bad news for camp 1.. It's bad if they work in a part of the industry where code quality or efficiency matters. That's maybe 10% of the total though.

I see this sentiment occasionally brought up, and at the same time see what’s happening to Github where the majority of their distributions is not security or efficiency related (not saying it’s because of LLMs, we don’t know). The point is, these things matter beyond beautiful code. You loose trust and you lose customers and money.

Re: Various LLM Smells

#205

- “(The) honest caveat:” (or “genuine caveat:”, both with the colon) - “(The) honest answer:” (again, with colon) - “The thing to internalize:” - “The smoking gun:” (really, sentences that start with “The :” are a strong tell, but those four are the most prolific) - “load bearing” (when not talking about architecture) - “blast radius” (when not talking about actual explosives, but rather the effect of an event/action…

for me the most annoying one is “escape hatch”. Everything is an escape hatch, try catch is an escape hatch, a cli flag is an escape hatch. It makes no sense, and quickly ended up in my “banned words and phrases” md file

Huh, we have a process which has several exit criteria - which are pretty expensive to calculate with multiple rest calls to get through each...

I've always called them exit hatches, entirely unrelated to llms...

Now I wonder if I need to reword the docs... But realistically speaking, llms are the only readers of them nowadays, so I guess it doesn't matter.

Re: Various LLM Smells

#206
post #82
post #50

The LLM writing sameness is bad. Use LLMs to help your writing! But don't include a word they generate, even just a vocabulary adjustment, in your own output. Have them critique structure and flow, spot overused words and passive constructions and dumb picks for topic sentences. It's great for that, and those are all objective improvements in your writing that won't mess up your style. The LLM sameness in web design…

> The LLM sameness in web design is good. Most sites shouldn't try to be idiosyncratic. The best design for a site with real utility is legibility, and LLMs are better at that than the median developer. Always laying out the same buttons? Always using the same type scales? Good! If it looks good to you, you weren't going to do better on your own, and you were very likely to do worse. See, I disagree. Having seen plen…

Before LLM you could sum up the web as the hamburger menu, bootstrap and materialize. Even Apple threw everything in a hamburger at some point.

Re: Various LLM Smells

#207

> The LLM generated writing obviously felt significantly better than my own writing. A general pattern for LLMs is that they look really good at things you are bad at. What that means is that if you find yourself thinking of its output as significantly better than yours in a particular domain, there's a high chance that you are not equipped to judge that quality effectively.

> A general pattern for LLMs is that they look really good at things you are bad at. This is true for coding, too, which I think, to a large degree, might explain the polarized differences in opinions on HN about the quality of LLM-produced code. You have the 1. "AI produces code better than I could possibly write, one shots things it would take me days to do, and has made me 10X more productive!" camp, and you have…

It really depends. If you're cranking out prototypes or testing ideas, it's genuinely great. But if you're familiar with the code it's very easy to spot its (many) mistakes. It's Gell-Mann amnesia.

Then again, I just caught Claude writing setTransparent(!opaque == false), opaque being a bool, on a purely vibecoded project. Which was pretty impressive. ("• You're right, that's nonsense.")

Re: Various LLM Smells

#208

> The LLM generated writing obviously felt significantly better than my own writing. A general pattern for LLMs is that they look really good at things you are bad at. What that means is that if you find yourself thinking of its output as significantly better than yours in a particular domain, there's a high chance that you are not equipped to judge that quality effectively.

> A general pattern for LLMs is that they look really good at things you are bad at. This is true for coding, too, which I think, to a large degree, might explain the polarized differences in opinions on HN about the quality of LLM-produced code. You have the 1. "AI produces code better than I could possibly write, one shots things it would take me days to do, and has made me 10X more productive!" camp, and you have…

I'm in camp 3, where sometimes I don't really care how good or bad the code is. For internal tools for example, you can let the LLM crunch out code really fast, you can validate output but don't even have to look at the code. These kind of "weekend projects" can get finished in an hour or two, and so are really 10x.

For bigger production ready code, you indeed have to guard the architecture. But for the code, in some corners you can get away with sloppy code, as long as it kind of works.

What I'm saying is, code doesn't always has to be great. You will just have to judge the places where it needs to be high quality, and other places where you can get away with sloppy code.

Re: Various LLM Smells

#209

- “(The) honest caveat:” (or “genuine caveat:”, both with the colon) - “(The) honest answer:” (again, with colon) - “The thing to internalize:” - “The smoking gun:” (really, sentences that start with “The :” are a strong tell, but those four are the most prolific) - “load bearing” (when not talking about architecture) - “blast radius” (when not talking about actual explosives, but rather the effect of an event/action…

The funniest one I've seen with regularity is belt-and-suspenders/belt-and-braces, when I've never seen anyone ever use that term. I had to tell AI to stop using it, it was just annoying.

Re: Various LLM Smells

#210

> The LLM generated writing obviously felt significantly better than my own writing. A general pattern for LLMs is that they look really good at things you are bad at. What that means is that if you find yourself thinking of its output as significantly better than yours in a particular domain, there's a high chance that you are not equipped to judge that quality effectively.

> A general pattern for LLMs is that they look really good at things you are bad at. This is true for coding, too, which I think, to a large degree, might explain the polarized differences in opinions on HN about the quality of LLM-produced code. You have the 1. "AI produces code better than I could possibly write, one shots things it would take me days to do, and has made me 10X more productive!" camp, and you have…

I disagree this is the source of the polarization. Maybe it's part of it.

I have been coding since about 1983 or so. I shipped high quality products that have been used by millions of people. From embedded software to desktop applications to distributed systems.

I don't think I'm in the "don't understand what code should look like camp" (I mean you never know but the evidence seems to show that I do know what I'm doing). I use AI as a tool and it helps me be more productive. I don't "one shot things that would take me days to do". I use it to help me automate things that I could do manually where it is faster and more effective. I review every step and if I don't like something I adjust. There are some specific situations where it basically does as good a job as I would do in running some experiments, doing some analysis or writing some small amount of code. I still know what the changes need to look like broadly, where to make them, and what patterns to follow. It just automates the work and sometimes does have some additional insight that can complement my views. Unlike me it is all knowing about everything in terms of access to "knowledge". It knows all the details of how a certain runtime manages memory, Linux internals and various open source software. I could go look it up myself (which I'd do before AI) but I don't hold it all in my head like AI basically does. It is also "all knowing" in the code base I work in (more so than me, it's a huge code base, I have an outline and a high level picture in my head but not every single code line) where again I can dive into the code but it helps me extract the relevant information faster.

I think the polarization is more on the how you use the tool, what situations you use the tool for, which domain are you operating in (languages, applications etc.). You can also one-shot simple tools and helpers that are not the production software which is another way to accelerate your workflow.

Post reply on HN