You must log in or register to comment.
Microslop played the long game when they bought github
Eh. I never considered myself some hard-core old professional, but:
The LLM will not interact with the developers of a library or tool, nor submit usable bug reports, or be aware of any potential issues no matter how well-documented
If an LLM introduces a dependency, I will sure as hell go see it myself. Enough people do not do that for this to become a problem?
There’s a term called “dependency hell”. Sure, this one dependency is fine, but it depends on 3 other libraries, those 3 depend on a sum of 7 others, etc…
Nah, dependency hell is when two things you want to use depend on same thing, but different versions. The depth of dependencies needed to make “this one thing” work may or may not be a problem
It’s exacerbated by “oh this library is updated for no reason than its version is newer so we need to force that bleeding edge on any ecosystem we’re in” thinking.
We’ve absolutely lost the careful, measured long-term release and maintenance cadence that we built the Internet on.
Compare Systemd.
The worst dependency hell is when a library has a strict version dependency, and another library uses that same dependency. When the second library updates their minimum version of the dependency to one that is higher than the exact version needed for the first, THAT’S dependency hell.
This wouldn’t be a problem if libraries didn’t frequently make breaking changes to their api.
“Move fast and break things” is for startups with no userbase, not libraries with millions of users.
There are times when things need to be broken. But I also definitely understand your angle.
Vibe coding is a black hole. I’ve had some colleagues try and pass stuff off.
What I’m learning about what matters is that the code itself is secondary to the understanding you develop by creating the code. You don’t create the code? You don’t develop the understanding. Without the understanding, there is nothing.
Yes. And using the LLM to generate then developing the requisite understanding and making it maintainable is slower than just writing it in the first place. And that effect compounds with repetition.
TheRegister had an article, a year or 2 ago, about using AI in the opposite way: instead of creating the code, someone was using it to discover security-problems in it, & they said it was really useful for that, & most of its identified things, including some codebase which was sending private information off to some internet-server, which really are problems.
I wonder if using LLM’s as editors, instead of writers, would be better-use for the things?
_ /\ _
A second pair of eyes has always been an acceptable way to use this imo, but it shouldnt be primary or only
They are pretty good at summarisation. If I want to catch up with a long review thread on a patch series I’ve just started looking at I occasionally ask Gemini to outline the development so far and the remaining issues.
How AI is killing everything.
Which is really it’s purpose, as far as i can see
I just wanna say that’s such a good thumbnail
Oh yeah. If it was drawn by AI, well, it sure fooled me.
A Matrix guard thing but with cat details?
Btw, how do typesetters call that kind of image? I’ve seen “hero-image” in some newspapers’ html/css.
If the abominable intelligence is killing every corner of things we consider good its time to start killing the “AI”…
The killing part is not necessarily people vibe coding programs into OSS projects, but even if the OSS itself is not vibe coded, people using AI to integrate with it will result in lower engagement and thus killing the ecosystem:
Together, these patterns suggest that AI mediation can divert interaction away from the surfaces where OSS projects monetize and recruit contributors.
From Section 2.3 of the reported paper.
