RE: https://mean.engineer/@indutny/116245283352156779

Over the night I got so many responses and boosts to my original Toot that I decided to start the petition to Node.js Technical Steering Committee (TSC) to make sure all our voices are heard.

If you don't want Node.js core to be diluted with AI slop - please sign it by opening a Pull Request here and boosting this Toot for reach:

https://github.com/indutny/no-ai-in-nodejs-core?tab=readme-ov-file#petition-to-nodejs-tsc-no-ai-code-in-nodejs-core

Thank you, you are the best!

#NoSlopInNodejsCore

I've got asked so I'll post a clarification - you don't have to be affiliated with Node.js core or have contributions there to sign the petition. As long as you care about and use Node.js itself - your signature is very welcome!

https://github.com/indutny/no-slop-in-nodejs-core

#NoSlopInNodejsCore

GitHub - indutny/no-slop-in-nodejs-core: A petition to disallow acceptance of LLM assisted Pull Requests in Node.js core

A petition to disallow acceptance of LLM assisted Pull Requests in Node.js core - indutny/no-slop-in-nodejs-core

GitHub

@indutny

i lersonally doubt this is possible. slop will make it into node.

...but i'm pretty sure bare will stay high quality code

https://bare.pears.com 🙂

Bare | Fast, Lightweight Runtime for Modular JavaScript Apps

Bare is a minimal and modular JavaScript runtime designed for building high-performance apps across desktop and mobile. Open-source, fast, and built for the peer-to-peer web.

@serapath we don't have to draw the line at 0 LLM code precisely, but I think we have to draw it somewhere, though, because 19k LoC PR is not what I want to see in Node.js.

Please sign the petition! :-)

@indutny

why not switch to bare? 🤷‍♀️

@serapath @indutny I don't think it's a particularly healthy approach to switch to the next best/uprising thing. Especially when it's a socio-technical matter thing that the alternative solutions will inevitably run into discussing as well.

I'd put it like this: Let's fight first. We can still boycott and switch to another solution later.

@f09fa681 @indutny

no, there is a long history going back to the inception of nodejs.

node was forked early on and the fork was called `iojs`, even isaac schlueter, is on record saying he wished nodejs or node was cut in half and just called `no`, meaning it should be ultra minimal.

the folks who started bare are nodejs core contributors and around since inception and bare is LITERALLY what nodejs was meant to be before it was taken over by big tech as main sponsors and main openjs members

@f09fa681 @indutny

bare is NOT "the next best thing" and isnt venture capitalist sponsored like deno or bun.

why? ...because when lots of ppl build friends and learn the stack of a language and ecosystem, its hard to switch - you trained your brain and you lose a lot if you quit, thus later enshittification is hard to escape.

bare is different.
its ultra minimal and empowers userland.

@f09fa681 @indutny

why havent you heard about `bare` before?

...because you have to be deep in the scene and a long term nodejs dev and ooen source enthusiast to know it. ...these people run projects have no marketing budget compared to VC backed big tech poster childs.

...they will advertise it to you in a million ways so you feel familiar and they will pay influencers too.

@serapath @indutny But this discussion isn't about whether Bare or Node is the better choice. It's about the stance on LLM driven contributions to a project with enormous reach.

@f09fa681 @indutny

if you follow the L4 design principle adapted to a js runtime:

A concept is tolerated inside the runtime only if moving it outside the runtime, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality.

If you stick to that, it all becomes about occams razor and radical minimalism and empowering userland. applying it removes surface or room where LLMs could even do anything useful.

Feature creep is made for LLMs

@serapath @indutny I'm convinced that there is room for significant LLM driven contributions to such a design, too. It could even be based on it. Isn't it naive to assume that substantial refactorings can't be LLM driven?

But besides, while there is some undeniable truth to feature creep being perfect for the average LLM usage, it would just shift the discussion to all the little supporting library projects that people will inevitably require.

So, I'd rather focus on that discussion now. Generative AI usage has opened a huge can of worms. I think it's clear by reading some of my comments where I stand regarding LLMs. But, honestly, I don't exactly know what my position should be.

@f09fa681 @indutny

the point is, if it is userland, everyone can make their own decisions what dependencies they wanna use.

the core is forced on everyone.

if LLM isnt in the core, there can even be competing projects - ones with embrqce LLMs and ones that make it their goal to not use LLMs ...and we can all observe the results in the long run.

And also, i disagree that there is room in a minimal runtime core for LLMs. Such a project is mostly about removing lines, not adding 🙂

@f09fa681 @indutny

using an LLM in a meaningful way would require such extraordinary precise prompting, that you can also just write the code, because the code will be very minimal anyway.