Hacker Newsnew | past | comments | ask | show | jobs | submit | nextaccountic's commentslogin

> There's a widespread problem of anti-intellectualism and acting-out, including, in the US, by both right and left.

As of 2026, it's disingenuous to both sides this issue, at least in the US


That's a purely mathematical result, the top comment of this thread has a link to the paper

I don't think it has been experimentally verified or anything


Well regardless of the origins of Claude-speak, I'm sure millions of humans are picking up some of its idioms, and at least some fraction of it will enter standard English in some decades

It's probably better to optimize rust-analyzer first (and now, this became easier). I mean, see rust-glance: it's not feature complete but it points out to different tradeoffs in this space

> An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte

You mean a grep over terabytes of data vs a LLM with gigabytes of parameters?

If you have so much data, you can use an index to search. It's unlikely that LLMs are going to be cheaper than properly indexed search DBs (which is what we should be comparing them with)


Gigabytes loaded into GPU memory being processed by custom silicon designed for the task that’s exactly the same on every inference? Even now parameters physically baked into the silicon for super low latency? Yes.

The point of a grep is for adhoc analysis of data that isn’t in a database. At best you could use an inverted index, which is extremely expensive to create and maintain, but if you don’t know a priori what you’re going to search for, or even if an inverted index helps with your query, it’s pointless and expensive to index literally everything you could ever use to save some time on a tool call.

The point isn’t to find a way to make searching more efficient. It’s that LLMs are becoming very efficient, and a measure is relative to grep. Making grep and searching more efficient has been a task in CS for decades. LLMs is relatively new beyond a very small crowd. It’s also not a goal to make LLMs better at grep than grep, but as a relative reference point that inference is getting cheap and fast and has opportunity to get faster far beyond grep simply due to unclaimed optimizations more available for the newer technology.


At some point the bottleneck becomes tool calling.. and as such, it's preferably if the model is co-hosted (in the same datacenter, at least) with your code repository and all other reference/context it needs (full documentation for most ecosystems, maybe even a copy of common crawl to minimize web fetch usage, etc)

Jev is prompted with natural language, so it is flexible and a good fit to replace subagents for certain tasks

A LLM agent could be trained to use jev effectively as a tool call, even (but even without specific RL they do a good job already)


Maybe their internal edge dried up in the last months

Maybe Covid killed a smaller but nonzero amount of technologies?

> What happens if the LLM saw the leaked code in its training material?

Exactly the same that would happen if the LLM saw GPLed code in its training material and was asked to replicate it


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: