Exactly: that’s tight feedback loops. Agents are also capable of reading docs and source code prior to generating new function calls, so they benefit from both of the solutions that I said people benefit from.

As an even more obvious example: students who put wrong answers on tests are “hallucinating” by the definition we apply to LLMs.

making the same mistakes

This is key, and I feel like a lot of people arguing about “hallucinations” don’t recognize it. Human memory is extremely fallible; we “hallucinate” wrong information all the time. If you’ve ever forgotten the name of a method, or whether that method even exists in the API you’re using, and started typing it out to see if your autocompleter recognizes it, you’ve just “hallucinated” in the same way an LLM would. The solution isn’t to require programmers to have perfect memory, but to have easily-searchable reference information (e.g. the ability to actually read or search through a class’s method signatures) and tight feedback loops (e.g. the autocompleter and other LSP/IDE features).

This seems like it doesn’t really answer OP’s question, which is specifically about the practical uses or misuses of LLMs, not about whether the “I” in “AI” is really “intelligent” or not.

One list, two list, red list, blue list

(I genuinely thought that was where you were going with that for a line or two)

That is a pretty lame “poisoning”.

This also makes me realize that I sometimes enunciate “the” unvoiced.

distributing relay knowledge among chatters (TBD)

This is the core reason that centralization is currently necessary. So admitting that it’s an unsolved problem for a federated alternative is basically reinforcing Signal’s point.

Two, arguably: one with Apple and one with upstream Linux.

Fair, but it’s one that the typical tools for finding bugs, tests and static analysis, cannot actually help with.

Here it is:

Presumably, it already used SIMD, and that’s how the existing GNU utility beat Rust by a factor of 17x.

Presumably, it already used SIMD, and that’s how the existing GNU utility beat Rust by a factor of 17x.

What’s wrong with the explanation given?

…the rest of it explains the context, and then briefly says that some people will disagree with the decision, but those people should just use a different distro. What are you complaining about?

You could also just alias find back to ^find. I don’t use nushell as my daily driver for other reasons, and I agree with the comment above that it’s a bit questionable for them to have a built-in with that name, but I don’t understand why you’d even try out a new shell, let alone one that’s radically different from POSIX-style shells, much less complain online about the shell you just tried, when you’re already happy with the shell you’re using and are not willing to adapt any habits or explore the configuration options to match your needs.

I genuinely can’t tell if you’re being sarcastic or not.

Fair!

I really don’t think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.

Busybox ls has 26 flags. GNU ls has 60.

From the busybox “about” page:

The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts… BusyBox has been written with size-optimization and limited resources in mind.

Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.