zlacker

I wonder how long npm/pip etc even makes sense.

Dependancies introduce unnecessary LOC and features which are, more and more, just written by LLMs themselves. It is easier to just write the necessary functionality directly. Whether that is more maintainable or not is a bit YMMV at this stage, but I would wager it is improving.

>>jmacd+(OP)
This is like saying Wikipedia doesn't make sense because there's now Grokipedia

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

>>jmacd+(OP)
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.

>>jmacd+(OP)
best to write assembly instead.

>>jmacd+(OP)
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.

>>jmacd+(OP)
That was already the case for a lot of things like is-even.

>>jmacd+(OP)
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

>>jmacd+(OP)
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.

>>ford+V61
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.

>>jmacd+(OP)
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

>>jmacd+(OP)
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.

>>sersi+ao1
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)

>>kristi+gm
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.

>>jmacd+(OP)
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?

>>jmacd+(OP)
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

>>physic+nA1
What do supply chain attacks look like against one of these containers?

>>Punchy+2B1
And your opinions on how average people use these tools are 100% accurate?

>>fendy3+ox1
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.

>>hdjrud+Ay1
>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.

>>baby_s+6G
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.

>>hluska+XF1
at least 5% more accurate than average LLM

>>jmacd+(OP)
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.

>>hluska+XF1
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.

>>antonv+kL2
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: >>46779522

>>simonw+hO2
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.

>>jmacd+(OP)
It still takes a little bit of time for an LLM to rewrite all the software in existence from scratch.