almost 200K lines of code materialized in about 2 weeks, and the code is full of em-dashes. if this wasn't vibecoded, they sure tried their hardest to make it look like it was...
> LLMs are already more persuasive than most human writers.
This is similar to the statement "LLMs are better at chess than most human players." Technically true, but not because they're good. But rather because relatively few people have ever seriously studied chess.
In other words LLMs can be more persuasive than the vast majority of human writers while still being extremely unpersuasive.
I thought we were long past the cultural moment where "argument happening on twitter" was considered noteworthy news.
I rarely complain about the contents of the HackerNews front page (people can upvote whatever they want) but I'm confused why this is even interesting. One could find a group of people on twitter saying anything about anything and write an article about it.
> (we also ask the candidate to open a PR against the repo just to see if they know the basics of git -- you would be surprise how many people cannot do it).
This doesn't really say anything about someone's familiarity with git, considering pull requests are not a feature of git.
When I worked at a FAANG we used git but had our own internal code forge that was nothing like GitHub.
This is a de-AI-izer, not a "humanizer". It removes AI tics, it doesn't add human voice.
This tool appears primarily designed to produce text that's clearer and more concise, not to produce text that fools someone into thinking a human wrote it.
You're exactly right. I've found STE100 formatted responses are a godsend to turn AI responses into something concise, understandable and usable; it's great for creating documentation and such. If someone wants AI as a replacement for actual human interaction, you won't fool anyone.
Does it consider word rhythm in a sentence? When I revise what I write, I hear the words in my head and make sure they sound write together, and often across sentences. I wonder where that came from, and if AI can replicate it. Maybe it’s probabilistic?
Not directly. One rule says to vary sentence length so the text does not fall into a fixed pattern, but that is a blunt tool. The sound of the words in your head is still your job.
The biggest failing is that, when I write something, I have a theory of the world and the mind of the person or the people who might read it, and I adjust accordingly. Current text generation systems completely miss this point no matter how nice the writing can be made.
Functionally speaking, i.e. talking about observable output and not making any claims about LLM "mental states", there are plenty of examples where LLMs demonstrate good theories of the world and theory of mind. They can even exhibit, again from a functional perspective, emotional intelligence.
However, they need input to tell them what the world in question is like and what the minds are like. Otherwise, they're just operating from an enormous amount of often-conflicting pretrained data.
You're more likely to see good results in this area when interacting directly with one, so that it has some history of the interlocutor's writing, or when doing something like coding where "the world" is something like a codebase, along with the pretrained information it has about that kind of code.
Code is a good example, because the results they give in that context would not be possible without some equivalent of a theory of the subject. This applies to pretty much any kind of reasoning that models do - in math, logic, physics etc.
When writing for a more general audience, models lack this kind of information, so you would have to supply it in some form.
The other issue is that whatever theories are implied by their writing are not necessary stable, because of issues like context size limitations, compaction, selective attention, etc. Nevertheless, it's a big oversimplification to say that they don't possess the functional equivalent of such theories.
Fair point. It removes AI tics and makes text clearer. It does not add a voice, and it does not try to fool a detector. "Humanizer" is the name of the skill it builds on (blader/humanizer), so I kept it.
Any community needs not only a bubbling up of good content, but also an immune system against bad content. Otherwise in practice you become inundated with spam and noise.
The reason for this is an effort asymmetry: casting upvotes is easy, and most people do it without much thought, whereas determining that something is spam or misinformation requires looking a lot more closely.
I don't understand that logic. If it's fine for sudo-rs to have different behavior from sudo, why can't it also just have a different executable name? So that people who are expecting traditional sudo will get "executable not found" instead of having subtle silent problems.
"Canonical's Jon Seager mentions that the sudo-rs developers are collaborating with Todd Miller, the original maintainer of sudo, and to think of sudo-rs as a "handshake across generations of secure systems".
He also added that sudo-rs is not expected to bring over all the features of sudo, as the devs are taking a "less is more" approach, excluding features that are too niche or outdated."
So sudo.rs drops some features because "less is more", but it's still called "sudo" because by working together with the original maintainer they capture the spirit of the original, a "sudo 2.0" so to speak.
Even if this change had been in the C version of sudo, I would expect deprecation warnings before the change, followed by error messages after the change, rather than silent failure. That's just good maintainership.
Interfaces are not supposed to change while keeping "the spirit". I don't care if you keep "the spirit" or not, if you change an interface, please change the name or at least the version.
> So sudo.rs drops some features because "less is more", but it's still called "sudo" because by working together with the original maintainer they capture the spirit of the original, a "sudo 2.0" so to speak.
Except when the change of features are seemingly arbitrary. As the article points out when it comes to regexes, the following is not allowed:
/usr/sbin/exim -bp[acru]
but the following would be
/usr/sbin/exim *
So, as the author notes:
> The Rust sudo has apparently opted to keep the single most dangerous wildcard while disallowing all of the wildcards that allow one to be narrow and specific about what you're allowing […]
reply