[syrusakbary]

Fully disagree with this take. Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions:

  I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.

[1]: https://github.com/nodejs/node/pull/61478#issuecomment-40772...

[indutny]

I appreciate hearing your point of view on this. In my opinion the future of Open Source and AI assisted coding is a much bigger issue, and different people have different levels of confidence in both positive and negative outcomes of LLM impact on our industry.

It is great to have a legal perspective on compliance of LLM generated code with DCO terms, and I feel safer knowing that at least it doesn't expose Node.js to legal risk. However it doesn't address the well known unresolved ethical concerns over the sourcing of the code produced by LLM tooling.

[jaredklewis]

AI coding is great, but iteration speed is absolutely not a desirable trait for a runtime. Stability is everything.

Speed code all your SaaS apps, but slow iteration speeds are better for a runtime because once you add something, you can basically never remove it. You can't iterate. You get literally one shot, and if you add a awkward or trappy API, everyone is now stuck with it forever. And what if this "must have" feature turns out to be kind of a dud, because everyone converged on a much more elegant solution a few years later? Congratulations, we now have to maintain this legacy feature forever and everyone has to migrate their codebase to some new solution.

Much better to let dependencies and competing platforms like bun or deno do all the innovating. Once everyone has tried and refined all the different ways of solving this particular problem, and all the kinks have been worked out, and all the different ways to structure the API have been tried, you can take just the best of the best ideas and add it into the runtime. It was late, but because of that it will be stable and not a train wreck.

But I know what you're thinking. "You can't do that. Just look at what happens to platforms that iterate slowly, like C or C++ or Java. They're toast." Oh wait, never mind, they're among the most popular platforms out there.

[syrusakbary]

Since when we accepted that we can’t go fast and offer stability at the same time?

Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed. This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)

[jaredklewis]

IME there's a reason it's "move fast and break things" and not "move fast and don't break anything," because if the second was generally possible, we wouldn't even need this little aphorism.

And again, I'm not making a claim that the slow and steady tradeoff is best for all situations. Just that it is a great tradeoff for foundational platforms like a runtime. On a platform like postgresql or the JVM, the time from initial proposal to being released as a stable feature is generally years, and this pace I think has served those platforms well.

But I'm open to updating my priors. Do you think there are foundational platforms out there that iterate quickly and do a good job of it?

[dijksterhuis]

it’s a well known true-ism you can have it cheap, correct or fast.

but you can only have two of them at the same time.

and we’re talking about FOSS here, so cheap kinda has to be one of them.

[syrusakbary]

Well, with the help of AI now you can have Fast, Affordable, and Correct.

[dijksterhuis]

"Correct" usually means "exactly matches the specification" .... these systems do not do that based on what's been indicated on a bunch of articles, HN discussions, etc. etc. documenting people's collective experiences. It often doesn't one-shot tasks, it requires hand-holding. Oftentimes to a significant degree. Especially if not working on a CRUD webapp with a lot of boilerplate which heavily skew the training data. LLMs return the most likely sequence of individual elements of code, not the most correct code.

So, it's fast if you get lucky and are able to one-shot it, affordable-ish if you get lucky and are able to one-shot it and correct if you get lucky.

And that tends to happen if you're working on a specific set of codebases which are close to the most commonly occurring codebases in the training data set -- i.e. CRUD webapps / heavy boilerplate usage. Most FOSS projects probably don't fit in that camp (i have no data to support this, it's just my gut experience).

[oystersareyum]

Allowing AI contributions results in lower quality contributions and allows wild things to come in and disrupt it, making it an unreliable dependency. We have seen big tech experience constant outages due to AI contributions as is...

[UqWBcuFx6NV4r]

Your comment is why advertisers say that you should repeat your core call to action at least a few times to make it stick.

You’ve read people saying the same thing hundreds of times and have somehow taken that as meaning that it’s credible.

Neither you nor I nor anyone else here knows what the “effects” are, because this is brand new tech, and it’s constantly changing. Yet you’re speaking with absolute confidence.

“Big tech” has downtime all the time, and LLMs did not change that fact. The only difference is that the peanut gallery that is already worked up about AI for philosophical / cultural reasons is suddenly ready to blame AI for every issue under the sun.

You think that you’re making a technical argument but you’re just repeating the same taking points I see teenagers regurgitating on TikTok. There’s nothing intelligent or credible about it.

[habinero]

My dude, you're making the classic problem of assuming because you don't have any first-hand knowledge of problems, other people are equally ignorant.

Don't slap someone else down because you don't know something.

[szmarczak]

> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

It's not an AI issue. Node.js itself is lots of legacy code and many projects depend on that code. When Deno and Bun were in early development, AI wasn't involved.

Yes, you can speed up the development a bit but it will never reach the quality of newer runtimes.

It's like comparing C to C++. Those languages are from different eras (relatively to each other).

[lmm]

> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

If and when there is evidence that AI is actually increasing the speed of improvement (and not just churn), it would make sense to permit it. Unless and until such evidence emerges, the risks greatly outweigh the benefits, at least for a foundational codebase like this.

[petercooper]

Not allowing AI assistance on PRs will likely decimate the project in the future,

I can't help but wonder if this matter could result in an io.js-like fork, splitting Node into two safe-but-slow-moving and AI-all-the-things worlds. It would be historically interesting as the GP poster was, I seem to recall, the initial creator of the io.js fork.

[KronisLV]

> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

That sort of statement might also be sarcasm in another context: I personally use AI a lot, but also recognize that there are a lot of projects out there that are suffering from low quality slop pull requests, devs that kinda sign out and don't care much about the actual code as long as it appears to be running, alongside most LLMs struggling a lot with longer term maintenance if not carefully managed. So I guess it depends a lot on how AI is used and how much ideological opposition to that there is. In a really testable codebase it could actually work out pretty well, though.