What a bizarre comment. Take something like NumPy - has a hard dependency on BLAS implementations where numerical correctness are highly valued for accuracy and require deep thinking for correct implementation as well as for performance. Written in a different language again for performance so again an LLM would have to implement all of those things. What’s the utility in burning energy to regenerate this all the time when implementations already exist?

What do supply chain attacks look like against one of these containers?

Interesting thought (I think recently more than ever it's a good idea to question assumptions) - but IMO abstractions are important as ever.

Maybe the smallest/most convenient packages (looking at you is-even) are obsolete, but meaningful packages still abstract a lot of complexity that IMO aren't easier to one-shot with an LLM

Concretely, when you use Django, underneath you have CPython, then C, then assembly, and finally machine code. I believe LLMs have been much better trained on each layer than going end-to-end.

This is like saying Wikipedia doesn't make sense because there's now Grokipedia

there are people (on Hacker News Dot Com, even) who believe this without a shred of shame or irony.

The most popular modules downloaded off pip and npm are not singular simple functions and cannot easily be rewritten by an llm.

Scikit-learn

Pandas

Polars

I consider packages over 100k download production-tested. Sure LLM can roll some by themselves but if many edge cases to appear, (which may already be handled by public packages) you will need to handle it.

Don't base anything on just download numbers, not only is it easily game-able, it's enough with like 3 small companies using a package and push commits individually and CI triggering on every new commit for that number to lose any sort of meaning.

Vanity metrics should not be used for engineering decisions.

At times I wonder why x tui coding agent was written in js/ts/python, why not use Go if it's mostly llm coded anyway? But that's mostly my frustration at having to wait for npm to install a thousand dependencies, instead of one executable plus some config files. There's also support libraries like terminal ui that differ in quality between platforms.

Funny because as a non-Go user, the few Go binaries I've used also installed a bunch of random stuff.

This can be fixed in npm if you publish pre-compiled binaries but that has its own problems.

>the few Go binaries I've used also installed a bunch of random stuff.

Same goes for rust. Sometime one package implicitly imports other in different version. And look of rustup tree to resolve the issue just doesn't seem very appealing.

Well you do need to vet dependencies and I wish there was a way to exclude purely vibe coded dependencies that no human reviewed but for well established libraries, I do trust well maintained and designed human developed libraries over AI slop.

Don't get me wrong, I'm not a luddite, I use claude code and cursor but the code generated by either of those is nowhere near what I'd call good maintainable code and I end up having to rewrite/refactor a big portion before it's in any halfway decent state.

That said with the most egregious packages like left-pad etc in nodejs world it was always a better idea to build your own instead of depending on that.

I've been copy-pasting small modules directly into my projects. That way I can look them over and see if they're OK and it saves me an install and possible future npm-jacking. There's a whole ton of small things that rarely need any maintenance, and if they do, they're small enough that I can fix myself. Worst case I paste in the new version (I press 'y' on github and paste the link at the top of the file so I can find it again)

Tokens are expensive and downloading is cheap. I think probably the opposite is true, really, and more packages will be written specifically for LLMs to use because their api uses fewer tokens.

As long as "don't roll your own crypto" is considered good advice, you'll have at least a few packages/libraries that'll need managing.

For a decent number of relatively pedestrian tasks though, I can see it.

LLMs are great at the roll you own crypto foot gun. They will tell you to remember all these things that are important, and then ignore their own tips.

It still takes a little bit of time for an LLM to rewrite all the software in existence from scratch.

That was already the case for a lot of things like is-even.

You have insane delusions about how capable LLMs are but even assuming its somehow true: downloading deps instead of hallucinating more code saves you on tokens

And your opinions on how average people use these tools are 100% accurate?

If average people try vibecoding their dependencies, they’ll fail, simple as that. We’ve already seen how that looks with the “web browsers” that have recently been vibecoded.

There's a new web browser project today that's a heck of a lot more impressive than the previous ones - ~20,000 lines of dependency-free Rust (though it uses system libraries for image and text rendering), does a good job of the Hacker News homepage: https://news.ycombinator.com/item?id=46779522

Thanks for the heads up, that does look much more interesting.

I don't think it really affects the point discussed above for now, because we were discussing average users, and by definition, the first person to code a plausible web browser with an agent isn't an average user - unless of course that can be reliably replicated with any average user.

But on that note, the takeaways on the post you linked are relevant, because the author bucked a few trends to do this, and concluded among other things that "The human who drives the agent might matter more than how the agents work and are set up, the judge is still out on this one."

This will obviously change, but the areas that LLMs need to improve on here are ones they're notoriously weak on, so it could take a while.

at least 5% more accurate than average LLM