Hacker News Reader

Comment by pecheny | Hacker News Reader

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

View on HN

The author’ blog was on HN a few days ago as well for an article on SBOMs and Lockfiles. They’ve done a lot of work in the supply-chain security side and are clearly knowledgeable, and yet the blog post got similarly “fuzzified” by the LLM.

There are a handful of things in TFA that, while not outright false, are sloppy enough that I'd expect someone knowledgeable to know/explain better.

I didn't notice that - can you give some examples?

how they claim fetching from a single index magically solves dependency confusion attacks, when in reality it makes the attack much more trivial and able to succeeded. typical llm syncopation.

It says:

> uv picks from the first index that has the package, stopping there. This prevents dependency confusion attacks and avoids extra network requests.

As long as the "first" index is e.g. your organization's internal one, that does ensure that some random thing on PyPI won't override that. A tool that checks every index first still has to have the right rule to choose one.

It is, however, indeed a terrible point. I don't think I've even seen evidence that pip does anything different here. But it's the sort of problem best addressed in other ways

By "syncopation" perhaps you mean "sycophancy"? I don't see how musical rhythms are relevant here.

Some issues I noticed were:

> PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet.

In 2020 you could still have a whole bunch of performance wins before the PEP 658 optimization. There's also the "HTTP range requests" optimization which is the next best thing. (and the uv tool itself is really good with "uv run" and "uv python".)

> What uv drops: Virtual environments required. pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code.

pip also refuses to touch system Python without explicit flags?

For uv, there are flags that allow it, so it doesn't really "removes a whole category of permission checks and safety code"? uv has "permission checks and safety code" to check if it's system python? I don't think uv has "dropped" anything here.

> Optimizations that don’t need Rust: Python-free resolution. pip needs Python running to do anything.

This seems to me to be implying that python is inherently slow, so yes, this optimization requires a faster language? Or maybe I don't get the full point.

> Where Rust actually matters: No interpreter startup. ... uv is a single static binary with no runtime to initialize.

This one's pretty petty/pedantic, but "Rust technically has a very lightweight runtime." https://users.rust-lang.org/t/does-rust-have-a-runtime/11406...

Interestingly I didn’t catch this, I liked it for not looking LLM written!

“Why this matters” being the final section is a guaranteed give away, among innumerable others.

I realized once I was in the "optimizations that dont need rust" section. Specifically "This is concurrency, not language magic."

Yup. The author has now swapped that part out for “Any language can do this.”

Just commenting to preempt any comments telling you that the article doesn’t say this.

I used to rely on this, and still mostly do - but you’d be surprised how quickly this has entered the normal vernacular! I hear people using it in conversation unprompted all the time.

I definitely found the thesis insightful. The actual content stopped feeling insightful to me in the “What uv drops” section, where cut features were all listed as if they had equal weight, all in the same breathless LLM style

I would be able to absorb your perspective better if it were structured as a bulleted list, with SUMMARY STRINGS IN BOLD for each bullet. And if you had used the word "Crucially" at least once.

I have reached a point where any AI smell (of which this articles has many) makes me want to exit immediately. It feels tortuous to my reading sensibilities.

I blame fixed AI system prompts - they forcibly collapse all inputs into the same output space. Truly disappointing that OpenAI et all have no desire to change this before everything on the internet sounds the same forever.

You're probably right about the latter point, but I do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt.

As you said, reading this stuff is taxing. What's more, this is a daily occurrence by now. If there's a silver lining, it's that the LLM smells are so obvious at the moment; I can close the tab as soon as I notice one.

> do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt.

Fairly easy, in my wife's experience. She repeatedly got accused of using chatgpt in her original writing (she's not a native english speaker, and was taught to use many of the same idioms that LLMs use) until she started actually using chatgpt with about two pages of instructions for tone to "humanize" her writing. The irony is staggering.

It’s pretty easy. I’ve written a fairly detailed guide to help Claude write in my tone of voice. It also coaxes it to avoid the obvious AI tells such as ‘It’s not X it’s Y’ sentences, American English and overuse of emojis and em dashes.

It’s really useful for taking my first drafts and cleaning them up ready for a final polish.

https://ember.dev ’s deeper pages (not the blog, but the “resumelike” project pages) was written by claude with guidance and a substantial corpus of my own writing and i still couldn’t squash out all the GPTisms in the generation passes. probably net waste of time, for me, for writing.

It’s definitely partially solved by extensive custom prompting, as evidenced by sibling comments. But that’s a lot of effort for normal users and not a panacea either. I’d rather AI companies introduce noise/randomness themselves to solve this at scale.

I don’t think that’s a solution.

The problem isn’t the surface tics—em dashes, short exclamatory sentences, lists of three, “Not X: Y!”.

Those are symptoms of the deep, statistically-built tissue of LLM “understanding” of “how to write a technical blog post”.

If you randomize the surface choices you’re effectively running into the same problem Data did on Star Trek: The Next Generation when he tried to get the computer to give him a novel Sherlock Holmes mystery on the holodeck. The computer created a nonsense mishmash of characters, scenes, and plot points from stories in its data bank.

Good writing uses a common box of metaphorical & rhetorical tools in novel ways to communicate novel ideas. By design, LLMs are trying to avoid true (unpredictable) novelty! Thus they’ll inevitably use these tools to do the reverse of what an author should be attempting.

I also don't read AI slop. It's disrespectful to any reader.

Read our paper on de-slopping LLM outputs. It's far more than simply all having the same fixed AI system prompts. It's an overuse of post-training and contempt for pre-training.

https://arxiv.org/pdf/2510.15061

Editing the post to switch five "it's X not Y"s[1] is pretty disappointing. I wish people were more clear with their disclosure of LLM editing.

[1]: https://github.com/andrew/nesbitt.io/commit/0664881a524feac4...

This is terrible. So disrespectful. It's baffling how someone can do this under their own name

I recsind my previous statement. Also, people have to stop putting everything on github.

Why? To me, hosting previous versions of an article in a public git repo adds transparency. Or perhaps you are talking about GitHub specifically?

That is correct for the collective as a whole, but in his instance, if this wasn't connect to a public github, it would have been substanially more difficult to prove he used a LLM.

You're supposed to also remove the fancy UTF-8 quotes that people can't normally type, the EM dashes, and reorder sentences/clauses because the paragraph level "template" slop is really obvious to people who use these models all the time. (I'm also pretty sure that the UTF-8 shenanigans with LLM responses was done very on purpose by those who have a vested interest in making it easier for mass surveillance of written communication.)

Or, use the "deep research" mode for writing your prose instead. It's far less sloppy in how it writes.

These people are amateurs at humanizing their writing.

To me, unless it is egregious, I would be very sensitive to avoid false positives before saying something is LLM aided. If it is clearly just slop, then okay, but I definitely think there is going to be a point where people claim well-written, straightforward posts as LLM aided. (Or even the opposite, which already happens, where people purposely put errors in prose to seem genuine).

> To me, unless it is egregious, I would be very sensitive to avoid false positives before saying something is LLM aided. If it is clearly just slop

Same. I'm actually more tired of this AI witch hunt

> Ironically, some day we might employ LLMs to re-humanize texts

I heard high school and college students are doing this routinely so their papers don't get flagged as AI

this is whether they used an LLM for the whole assignment or wrote it themselves, has to get pass through a "re-humanizing" LLM either way just to avoid drama

We wrote the paper on how to deslop your LLM outputs and if you use our factory de-slopped versions of gemma3 you don't have to worry about this, similarly if you use our antislop sampler, your LLM outputs will look very close to human.

https://arxiv.org/abs/2510.15061

there is going to be a point where people have read so much slop that they will start regurgitating the same style without even realising it. or we could already be at that point

Reply on news.ycombinator.com