[d3Xt3r]

If that's going to be your definition, then it's going to be extremely difficult, if not impossible to have a 100% human made program, unless you've personally hand-coded the entire OS, or you've verified beyond doubt that no vibe-coded dependency exist in the entire dependency chain - both build and runtime, direct and indirect.

I'm not sure how feasible verification of that would be, unless we have some "certified 100% human" certification program of some sort, with an external auditing agency or something - because you can't trust humans, they will 100% lie.

[g-b-r]

If "verifying the entire dependency chain" is that difficult for your project, you have a problem in any case (and you're probably using npm).

You don't need to have personally hand-coded the OS, of course, you just need a OS that's not vibe-coded, and hopefully that just means avoiding Windows.

Even if you actually consider the OS a dependency, which is a stretch

And hopefully vibe coding doesn't get as widespread to become hard to avoid it.

[d3Xt3r]

> If "verifying the entire dependency chain" is that difficult for your project, you have a problem in any case (and you're probably using npm).

That's a problem for anyone coding a modern app these days, not just npm users.

> You don't need to have personally hand-coded the OS, of course, you just need a OS that's not vibe-coded, and hopefully that just means avoiding Windows.

That's a problem too, because Linux is already accepting gen-AI code, and you can bet your arse that Google and Apple are too. So that just leaves the niche OSes, and although I don't know of their individual stances, the trust problem still remains - how do you know they're not using gen-AI in some shape or form, without some sort of formal certification and auditing system?

[g-b-r]

> That's a problem for anyone coding a modern app these days, not just npm users

I wouldn't really say that

> That's a problem too, because Linux is already accepting gen-AI code

If it's accurately reviewed it's fine for me, although yeah, it wouldn't fit the 100% human definition.

Just as you can make GPL software for closed-source operating systems, though, I think you could ignore the OS in a definition of 100% human-made software.

[d3Xt3r]

> I wouldn't really say that

We can agree to disagree, but pretty much every modern app uses dependencies at some level, and that's a problem for everyone. Sure, npm is probably the worst of them all, but even the so called "safe" Rust is very heavy on dependencies - just look at any popular Rust project these days. It's only a matter of time until a malicious or poor quality code makes its way in a popular Rust project... or any other project for that matter. Just see the state all the popular FOSS projects are in, they're all getting swamped by LLM-driven PRs, so much so that some projects (like Ladybird) have decided to stop accepting PRs completely.

The problem isn't just about whether or not the code is accurately reviewed, because under pressure, humans are bound to slip up - just take a look at what happened with the XZ project, it has now become a textbook example of how projects can be compromised. LLMs have made the situation worse, it's only a matter of time until we see a second or third Jia Tan due to the pressure maintainers are in - or we see more FOSS projects stop accepting PRs altogether.

In such a scenario, every dependency is a liability.

And if you ignore the OS, that means you're drawing an arbitrary line in the sand - because how would you define what consists of an "OS"?

Going back to our example app, what if the app's dependency is Qt, and if Qt has vibe-coded components - by your original definition a few comments ago, that would make your app not human-made. But many distros also include Qt components OOTB due to some dependency or other (eg for KDE), so that would mean the OS is also not 100% human-made right?