I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money.
Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.
I don't quite understand your argument. Wasn't the post about how users might replace transparent dependencies with transparent LLM drop-ins? I don't see how having an LLM to do the same job would enable someone to learn more. They're probably the kind of person who will ask the LLM to perform a refactor when problems arise, so they won't learn that much through osmosis.
> Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks.
Use of an AI to write your code is also a form of dependency. When the LLM spits out code and you just dump it in your project with limited vetting, that's not really that different from vendoring a dependency. It has a different set of risks, but it still has risks.
Wouldn't call it a risk in itself, but part of the benefit of using a library, a good and tailored one at least, is that it'll get modernised without my intervention. Even if the code produced for you was state-of-the-art at the moment of inclusion, will it remain that way 5 years from now?
Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features.
Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into account all the other possible use cases you don't care about.
But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it.
You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial.
Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point it becomes a self-maintained dependency. Which is a fair decision, but it is all about tradeoffs and sometimes too costly.
Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.
> and you just dump it in your project with limited vetting
Well yes there’s your problem. But people have been doing this with random snippets found on the internet for a while now. The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs
> The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs
True. But the difference is the scale and ease of doing with code generators. With a few clicks you can add hundreds of lines of code which supposedly does the right thing. While in the past, you would get code snippets for a particular aspect of the problem that you are trying to solve. You still had to figure out how to add it to your code base and somehow make it “work”
Surely in any responsible development environment those hundreds of lines of code still have to be reviewed.
Or don't people do code review any more? I suppose one could outsource the code review to an AI, preferably not the one that wrote it though. But if you do that surely you will end up building systems that no one understands at all.
Agree. Any reasonable team should have code reviews in place, but an irresponsible coder would push the responsibility of code quality and correctness to code reviewers. They were doing it earlier too, but the scale and scope was much smaller.
> the era of small, low-value libraries like blob-util is over.
Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell.
npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad".
Instead of writing endless utilities for other project to re-use, write actual working things instead - that's where the value/fun is.
> you just have to do maintenance through manual find-and-replace now
Do you? It doesn't seem even remotely like an apples-to-apples comparison to me.
If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your library (possibly causing more bugs) to accommodate, etc.
If you instead imaging the same functionality being just another private thing within your application, you only need to make sure that functionality works in the one single way you're using it. You don't have to make it arbitrarily general purpose. You can do error handling elsewhere in your app. You can test it only against the range of inputs you've already ensured are the case in your app, etc. The amount of "maintenance" is tiny by comparison to what a library maintainer would have to be doing.
It seems obvious to me that "maintenance" means a much more limited thing when talking about some functionality that the rest of your app is using (and which you can test against the way you're using it), versus a public library that everyone is using and needs to work for everyone's usage of it.
Most of these util libraries require basically no changes ever. The problem is the package maintainers getting hacked and malicious versions getting pushed out.
Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.
Yeah it's the main thing I really dislike about this - how do you make sure you know where it's from? (ie licensing) What if there are updates you need? Are you going to maintain it forever?
For some definition of "small piece of code" that may be ok, but also sometimes this is more than folks consider
Do you know that you can just add a small text file or a comment explaining that a module is vendored code. Ad updates is handled the same way as the rest of the code. And you will be “maintaining” it as long as you need to. Libraries are not “here be dragons” best left to adventurous ones.
If I vendor a dependency that currently works for what my program does, I only have to care about it again if a security hole is discovered in it or if my program changes and the dependency is insufficient in some way. I don't have to worry about the person I'm importing code from going weird or introducing a bug that affects me.
Yep something like blob util could be a blog post or a gist (or several stack overflow answers). And a lot of NPM library falls under that. They always have the anemic standard library of JavaScript forgetting that the C library is even smaller.
Less incentive to write small libraries. Less incentive to write small tutorials on your own website. Unless you are a hacker or a spammer where your incentives have probably increased. We are entering the era of cheap spam of everything with little incentive for quality. All this for the best case outcome of most people being made unemployed and rolling the dice on society reorganising to that reality.
> or a spammer where your incentives have probably increased.
Slight pushback on this. The web has been spammed with subpar tutorials for ages now. The kind of medium "articles" that are nothing more than "getting started" steps + slop that got popular circa 2017-2019 is imo worse than the listy-boldy-emojy-filled articles that the LLMs come up with. So nothing gained, nothing lost imo. You still have to learn how to skim and get signals quickly.
I'd actually argue that now it's easier to winnow the slop. I can point my cc running in a devcontainer to a "tutorial" or lib / git repo and say something like "implement this as an example covering x and y, success condition is this and that, I want it to work like this, etc.", and come back and see if it works. It's like a litmus test of a tutorial/approach/repo. Can my cc understand it? Then it'll be worth my time looking into it. If it can't, well, find a different one.
I think we're seeing the "low hanging fruit" of slop right now, and there's an overcorrection of attitude against "AI". But I also see that I get more and more workflows working for me, more or less tailored, more or less adapted for me and my uses. That's cool. And it's powered by the same underlying tech.
The thing is, what is the actual point of this approach? Is it for leaning? I strongly believe there’s no learning without inmersion and practice. Is it for automation? The whole idea of automation is to not think about the thing again unless there’s a catastrophic error, it’s not about babysitting a machine. Is it about judgment? Judgment is something you hone by experiencing stuff then deciding whether it’s bad or not. It’s not something you delegate lightly.
The problem isn't that AI slop is doing something new. Phishing, blogspam, time wasting PRs, website scraping, etc have all existed before.
The problem is that AI makes all of that far, far easier.
Even using tooling to filter articles doesn't scale as slop grows to be a larger and larger percentage of content, and it means I'm going to have to consider prompt injections and running arbitrary code. All of this is a race to the bottom of suck.
The difference is that the cost of slop has decreased by orders of magnitude. What happens when only 1 in 10,000 of those tutorials you can find is any good, from someone actually qualified to write it?
One instance of definite benefit of AI is AI summary web search. Searching for answers to simple questions and not having to cut though SEO slop is such an improvement
The summary is often incorrect in at least some subtle details, which is invisible to a lot of people who do not understand LLM limitations.
Now, we can argue that a typical SEO-optimized garbage article is not better, but I feel like the trust score for them was lower on average from a typical person.
Quick! Tell me what this does or you're not a real programmer, not a craftsman, and are a total hack who understands nothing about quality (may not even be a good person, want to lay off bread-and-butter red-blooded american programmers)
This author assumes that open sourcing a package only delivers value if is added as a dependency. Publicly sharing code with a permissive license is still useful and a radical idea.
Yeah if I find some (small) unmaintained code I need, I will just copy it (then add in my metrics and logging standards :)
It shouldn't be a radical idea, it is how science overall works.
Also, as per the educational side, I find in modern software ecosystem, I don't want to learn everything. Excellent new things or dominantly popular new things, sure, but there are a lot of branching paths of what to learn next, and having Claude code whip up a good enough solution is fine and lets me focus on less, more deeply.
(Note: I tried leaving this comment on the blog but my phone keyboard never opened despite a lot of clicking, and on mastodon but hit the length limit).
Yep. Even just sharing code with any license is valuable. Much I have learned from reading an implementation of code I have never run even once. Solutions to tough problems are an under-recognized form of generosity.
This is a point where the lack of alignment between the free beer crowd and those they depend on is all too clear. The free beer enthusiast cannot imagine benefiting from anything other than a finished work. They are concerned about the efficient use of scarce development bandwidth without consciousness of why it is scarce or that it is not theirs to direct. They view solutions without a hot package cache as a form of waste, oblivious to how such solutions expedite the development of all other tools they depend on, commercial or free.
I do agree with this, but there are some caveats. At the end of the day it is time people invest into a project. And that is often unpaid time.
Now, that does not mean it has no value, but it is a trade-off. After about 14 years, for instance, I retired permanently from rubygems.org in 2024 due to the 100k download limit (and now I wouldn't use it after the shameful moves RubyCentral did, as well as the new shiny corporate rules with which I couldn't operate within anyway; it is now a private structure owned by Shopify. Good luck finding people who want to invest their own unpaid spare time into anything tainted by corporations here).
I don’t think open source is going anywhere. It’s posed to get significantly stronger — as the devs which care about it learn how to leverage AI tools to make things that corporate greasemonkeys never had the inspiration to. Low quality code spammers are just marketing themselves for jobs where they can be themselves: soulless and devoid of creative impulse.
That’s the thing: open source is the only place where the true value (or lack of value) of these tools can be established — the only place where one can test mettle against metal in a completely unconstrained way.
Did you ever want to build a compiler (or an equally complex artifact) but got stuck on various details? Try now. It’s going to stand up something half-baked, and as you refine it, you will learn those details — but you’ll also learn that you can productively use AI to reach past the limits of your knowledge, to make what’s beyond a little more palatable.
All the things people say about AI is true to some degree: my take is that some people are rolling the slots to win a CRUD app, and others are trying to use it to do things that they could only imagine before —- and open source tends to be the home of the latter group.
True innovation will come from open source for sure. As the developers don't have the same economic incentives to be "safe", "ethical" "profitable" or whatever. large corporations know this and fear this development. That's why i expect a significant lobbying to take hold in USA that will try and make local AI systems illegal. And I think they will be very convincing to the government. Because the government also fears the "peasants" and giving them any true semblance of real AGI like systems. I bet very soon we will start seeing various classifications that will define what is legal and what is not for a citizen to possess or use.
> That's why i expect a significant lobbying to take hold in USA that will try and make local AI systems illegal.
I think they're going to be using porn and terrorism (as usual) to do that, but also child suicide. I also think they're going to leverage this rhetoric to lock down OSes in general, by making them uninstallable on legally-available hardware unless approved, because approved OSes will only be able to run approved LLMs.
Meaning that I think LLMs/generative AI will be the lever to eliminate general-purpose computing. As mobile went, so will desktop.
I think this is inevitable. The real question for me is whether China will partner with the west on this, or whether we will be trading Chinese CPUs with each other like contraband in order to run what we want.
> any true semblance of real AGI like systems.
This is the only part I don't agree with. This isn't going to happen, but I'm not even sure it would be more useful than what we have. We have billions of full AGI machines walking around, and most of them aren't great. I'm talking about restrictions on something technically barely better than what we have now; maybe only a significant bit more compute-efficient. Training techniques will probably be where we get the most improvements.
It's really not. Every project of any significance is now fending off AI submissions from people who have not the slightest fucking clue about what is involved in working on long-running, difficult projects or how offensive it is to just slather some slop on a bug report and demand it is given scrutiny.
Even at the 10,000 feet view it has wasted people's time because they have to sit down and have a policy discussion about whether to accept AI submissions, which involves people reheating a lot of anecdotal claims about productivity.
Having learned a bit about how to write compilers I know enough to know that I can guarantee you that an AI cannot help you solve the difficult problems that compiler-building tools and existing libraries cannot solve.
It's the same as it is with any topic: the tools exist and they could be improved, but instead we have people shoehorning AI bollocks into everything.
This isn't an AI issue. It is a care issue. People shouldn't submit PRs to project where they don't care enough to understand the project they are submitting to or the code they are submitting. This has always been a problem, there is nothing new. The thing that is new is more people can get to a point where they can submit regardless of their care or understanding. A lot of people are trying to gild their resume by saying they contributed to a project. Blaming AI is blaming the wrong problem. AI is a a tool like a spreadsheet. Project owners should instead be working ways to filter out careless code more efficiently.
Sounds like a lot of FUD to me — if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place?
Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.
In such a setting, you’re working within a trusted party — and for a major project, that likely means extremely competent maintainers and contributors.
I don’t think these people will have any difficulty adapting to the usage of these tools …
> Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.
It is a waste of time for large-scale volunteer-led projects who now have to deal with tons of shit — when the very topic is "how do we fend off this stuff that we do not want, because our project relies on much deeper knowledge than these submissions ever demonstrate?"
yeah we are getting lots of "I don't know how to do this and AI gave me this code that doesn't work, can you fix it" or "AI said it can do this" and the feature doesn't exist... some people will even argue and say "but AI said it doesn't take long, why won't you add it"
It weaponises incompetence, carelessness and arrogance at every turn.
AI, to me, is a character test: I'm regularly fascinated by finding out who fails it.
For example, in my personal life I have been treated to AI-generated comms from someone that I would never have expected it from. They don't know I know, and they don't know that I think less of them, and I always will.
I am sure I am not the only one who thinks these micro-dependencies are worthless anyway. You'd be better off just listing the functions in a markdown file for people to copy over than ship an entire package for it.
This isn't "small" open source, "small" would be something you put together in a week or weekend. These are like "micro" projects, where more work goes into actually publishing and maintaining the repository than actually writing the library.
I like the approach C sometimes takes, with the "tiny header file" type of libraries. Though I guess that also stems from the lack of a central build system.
TLDR: [AI promises] a future where we prize instant answers over teaching and understanding
But what this article and the comments don't say: open-source is mainly a quality metric. I re-use code from popular open-source repo's in part because others have used it without complaints (or document the bugs), in part because people are embarrassed to write poor-quality open-source so it's above-par code, and in part because if there are issues in this corner of the world, this dependency will solve them over time (and I can watch and wait when I don't have time to fix and contribute).
The quality aspect drives me to prefer dependencies over AI when I don't want full ownership, so I'll often ask AI to show open-source projects that do something well.
(As an aside, this article is about AI, but AI is so pervasive now as an issue that it doesn't even need saying in the title.)
Small open source is still valuable, but the bar is higher. If your project is something that's trivial and nobody just thought to do it before you and bothered to do it after, that's probably not going to survive, but if your project is a small focused tool that handles something difficult really well, it's 100% got a future.
More likely, what we will see is the decline of low effort projects. The JavaScript/ Typescript ecosystem has been plagued with such packages. But that’s more anomalous to the JS community than it is a systemic problem with open source in general.
So if fewer people are including silly dependencies like isEven or leftPad, then I see that as a positive outcome.
Open source exists because coding was a significant effort and code was a thing of high value. Unsurprisingly companies hesitated to make the code public and free. All of this is changing now as coding has suddenly become trivial. So, yes, the mission of open source, in general, will be challenged.
Why wouldn't you? Your codebase (if you're a business) exists to make you money, people being able to copy some unknown portions of it without further license if they somehow legally get their hands on a copy of it seems entirely irrelevant.
PS. I think this is much less clear and much less settled law than you are suggesting.
It's more nuanced. If I even have a few lines I can prove are mine, those parts are copywritable in the same way Pride and Prejudice is public domain but pride and prejudice and zombies is copyrighted.
> Claude’s version is pretty close to the blob-util version (unsurprising, since it was probably trained on it!).
AI are thieves!
> I don’t know which direction we’re going in with AI (well, ~80% of us; to the remaining holdouts, I salute you and wish you godspeed!), but I do think it’s a future where we prize instant answers over teaching and understanding.
Google ruined its search engine years ago before AI already.
The big problem I see is that we have become WAY too dependent on these mega-corporations. Which browser are people using? Typically chrome. An evil company writes the code. And soon it will fire the remaining devs and replace them with AI. Which is kind of fitting.
> Even now there’s a movement toward putting documentation in an llms.txt file, so you can just point an agent at it and save your brain cells the effort of deciphering English prose. (Is this even documentation anymore? What is documentation?)
Documentation in general sucks. But documentation is also a hard problem.
I love examples. Small snippets. FAQs. Well, many projects barely have these.
Look at ruby webassembly/wasm or ruby opal. Their documentation is about 99% useless. Or, even worse - rack in ruby. And I did not notice this in the past, in part because e. g. StackOverflow still worked, there were many blogs which helped fill up missing information too. Well all of that is largely gone now or has been slurped up by AI spam.
> the era of small, low-value libraries like blob-util is over. They were already on their way out thanks to Node.js and the browser taking on more and more of their functionality (see node:glob, structuredClone, etc.), but LLMs are the final nail in the coffin.
I still think they have value, but looking at organisations such as rubygems.org disrupt the ecosystem and bleeding it dry by kicking out small hobbyists, I think there is indeed a trend towards eliminating the silly solo devs who think their unpaid spare time is not worthy of anything at all, yet the big organisations eagerly throw down more and more restrictions onto them (my favourite example is the arbitrary 100k download limit for gems hosted at rubygems.org, but look at the new shiny corporate rules on rubygems.org - this is when corporations take over the infrastructure and control it. Ironically this also happened to pypi and they admit this indirectly: https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f... - of course they deny that corporations control pypi now, but by claiming otherwise they admit it, because this is how hobbyists get eliminated. Just throw more and more restrictions at them without paying them. Sooner or later they decide to do something better with their time.)
He almost got it right. It's not just the fate of small open source. It's the fate of all programmers now. Why hire a programmer when an LLM costs less, works faster and makes less mistakes (OP compliments better error handling, read the article).
Unless you are a product owner, you have paying clients that love you and your product and won't simply ditch it in favour of a new clone, you are really screwed.
"when an LLM costs less, works faster and makes less mistakes"... indeed, but it doesn't follow at all that it's the fate of all programmers _now_... at least in my experience none of these things are true ATM.
Well, at the very least it costs less than asking intern to look for a lib doing something particular and give some examples... still about as accurate as the intern tho.
So far I've never seen yet a non-programmer release production-grade code using only LLMs. There's just so much to care about (from security, deployments, secret management, event-driven architectures, and a large etc.) that "just" providing a prompt to create an "app" doesn't cut it. You need infra and non-engineers just don't know shit about infra (even if it's 99% managed), you need to deploy your llm-generated code in that infra; that should happen in a ci/cd probably. And what about migrations? Git? Who's setting up the api gateway? I don't mean to say that LLMs don't know how to do that, but you need to instruct them to do so, and even there, they will make silly mistakes and you need to re-instruct them or fix it.
Prompting is just 50% of the work (and the easy part actually). Ask the Head of Product or whoever is there to deploy something valuable to production and maintain it for 6 months while not losing money. It's just not going to happen, not even with truly AGI.
An LLM might be able to replace the majority of the code Sindre Sorhus has put out there, but it's probably a stretch to think that it could replace someone like John Carmack.
Trivial NPM libraries were never needed, but LLMs really are the nail in the coffin for them even when it comes to the most incompetent programmers because now they can literally just ask an LLM to spit out the exact same thing.
That type check is honestly not pointless at all. You can never be certain of your inputs in a web app. The likelihood of that parameter being something other than an arraybuffer is non-zero, and you generally want to have code coverage for that kind of undefined behavior. TypeScript doesn't complain without a reason.
1. Reducing dependencies is a wrong success metric. You just end up doing more work yourself, except you can't be an expert in everything, so your code is often strictly worse.
2. Regenerating the same solutions with a probabilistic machine will produce bugs a certain percentage of the time. Dependencies are always the same code (when versioned).
3. Cognitive overhead for human review is higher with LLM-generated libs, for no additional benefit.
> Reducing dependencies is a wrong success metric. You just end up doing more work yourself
Except it's just not true in many cases because of social systems we've built. If I want to ship software to Debian I have to make sure that every single of my 3rdparty dependencies is registered and packaged as a proper debian package - a lot of time it will take much less work to rewrite some code than to get 25 100-lines-of-code micro-libraries accepted into debian.
I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money.
Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.
The best outcome was things like jquery and then lodash where a whole collection of small util functions get rolled in to one package.
I don't quite understand your argument. Wasn't the post about how users might replace transparent dependencies with transparent LLM drop-ins? I don't see how having an LLM to do the same job would enable someone to learn more. They're probably the kind of person who will ask the LLM to perform a refactor when problems arise, so they won't learn that much through osmosis.
> Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks.
Use of an AI to write your code is also a form of dependency. When the LLM spits out code and you just dump it in your project with limited vetting, that's not really that different from vendoring a dependency. It has a different set of risks, but it still has risks.
Wouldn't call it a risk in itself, but part of the benefit of using a library, a good and tailored one at least, is that it'll get modernised without my intervention. Even if the code produced for you was state-of-the-art at the moment of inclusion, will it remain that way 5 years from now?
Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features.
Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into account all the other possible use cases you don't care about.
But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it.
You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial.
Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point it becomes a self-maintained dependency. Which is a fair decision, but it is all about tradeoffs and sometimes too costly.
Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.
You can avoid all those worries by vendoring the code anyway. you only 'need' to update it if you are pulling it in as a separate dependency.
> and you just dump it in your project with limited vetting
Well yes there’s your problem. But people have been doing this with random snippets found on the internet for a while now. The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs
> The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs True. But the difference is the scale and ease of doing with code generators. With a few clicks you can add hundreds of lines of code which supposedly does the right thing. While in the past, you would get code snippets for a particular aspect of the problem that you are trying to solve. You still had to figure out how to add it to your code base and somehow make it “work”
Surely in any responsible development environment those hundreds of lines of code still have to be reviewed.
Or don't people do code review any more? I suppose one could outsource the code review to an AI, preferably not the one that wrote it though. But if you do that surely you will end up building systems that no one understands at all.
Agree. Any reasonable team should have code reviews in place, but an irresponsible coder would push the responsibility of code quality and correctness to code reviewers. They were doing it earlier too, but the scale and scope was much smaller.
> the era of small, low-value libraries like blob-util is over.
Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell.
npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad".
Instead of writing endless utilities for other project to re-use, write actual working things instead - that's where the value/fun is.
But as Go puts it:
“A little copying is better than a little dependency.”
https://go-proverbs.github.io/
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
> you just have to do maintenance through manual find-and-replace now
Do you? It doesn't seem even remotely like an apples-to-apples comparison to me.
If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your library (possibly causing more bugs) to accommodate, etc.
If you instead imaging the same functionality being just another private thing within your application, you only need to make sure that functionality works in the one single way you're using it. You don't have to make it arbitrarily general purpose. You can do error handling elsewhere in your app. You can test it only against the range of inputs you've already ensured are the case in your app, etc. The amount of "maintenance" is tiny by comparison to what a library maintainer would have to be doing.
It seems obvious to me that "maintenance" means a much more limited thing when talking about some functionality that the rest of your app is using (and which you can test against the way you're using it), versus a public library that everyone is using and needs to work for everyone's usage of it.
Most of these util libraries require basically no changes ever. The problem is the package maintainers getting hacked and malicious versions getting pushed out.
Copied text does not inject bitcoin mining malware three months after I paste it.
Keyword: little.
Dependencies need to pull their own weight.
Shifting responsibilities is a risk that the value added needs to offset.
Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.
Yeah it's the main thing I really dislike about this - how do you make sure you know where it's from? (ie licensing) What if there are updates you need? Are you going to maintain it forever?
For some definition of "small piece of code" that may be ok, but also sometimes this is more than folks consider
Do you know that you can just add a small text file or a comment explaining that a module is vendored code. Ad updates is handled the same way as the rest of the code. And you will be “maintaining” it as long as you need to. Libraries are not “here be dragons” best left to adventurous ones.
If I vendor a dependency that currently works for what my program does, I only have to care about it again if a security hole is discovered in it or if my program changes and the dependency is insufficient in some way. I don't have to worry about the person I'm importing code from going weird or introducing a bug that affects me.
Yep something like blob util could be a blog post or a gist (or several stack overflow answers). And a lot of NPM library falls under that. They always have the anemic standard library of JavaScript forgetting that the C library is even smaller.
> since languages like Go never had this dependency hell
What is the feature of Go that this is referring to?
It's a cultural thing.
And libraries try harder not to have absurd dependencies, than finished products (correctly, IMO).
Less incentive to write small libraries. Less incentive to write small tutorials on your own website. Unless you are a hacker or a spammer where your incentives have probably increased. We are entering the era of cheap spam of everything with little incentive for quality. All this for the best case outcome of most people being made unemployed and rolling the dice on society reorganising to that reality.
> or a spammer where your incentives have probably increased.
Slight pushback on this. The web has been spammed with subpar tutorials for ages now. The kind of medium "articles" that are nothing more than "getting started" steps + slop that got popular circa 2017-2019 is imo worse than the listy-boldy-emojy-filled articles that the LLMs come up with. So nothing gained, nothing lost imo. You still have to learn how to skim and get signals quickly.
I'd actually argue that now it's easier to winnow the slop. I can point my cc running in a devcontainer to a "tutorial" or lib / git repo and say something like "implement this as an example covering x and y, success condition is this and that, I want it to work like this, etc.", and come back and see if it works. It's like a litmus test of a tutorial/approach/repo. Can my cc understand it? Then it'll be worth my time looking into it. If it can't, well, find a different one.
I think we're seeing the "low hanging fruit" of slop right now, and there's an overcorrection of attitude against "AI". But I also see that I get more and more workflows working for me, more or less tailored, more or less adapted for me and my uses. That's cool. And it's powered by the same underlying tech.
The thing is, what is the actual point of this approach? Is it for leaning? I strongly believe there’s no learning without inmersion and practice. Is it for automation? The whole idea of automation is to not think about the thing again unless there’s a catastrophic error, it’s not about babysitting a machine. Is it about judgment? Judgment is something you hone by experiencing stuff then deciding whether it’s bad or not. It’s not something you delegate lightly.
The problem isn't that AI slop is doing something new. Phishing, blogspam, time wasting PRs, website scraping, etc have all existed before.
The problem is that AI makes all of that far, far easier.
Even using tooling to filter articles doesn't scale as slop grows to be a larger and larger percentage of content, and it means I'm going to have to consider prompt injections and running arbitrary code. All of this is a race to the bottom of suck.
The difference is that the cost of slop has decreased by orders of magnitude. What happens when only 1 in 10,000 of those tutorials you can find is any good, from someone actually qualified to write it?
What happens when the monkeys stop getting bananas to work on the typewriters? More stories?
One instance of definite benefit of AI is AI summary web search. Searching for answers to simple questions and not having to cut though SEO slop is such an improvement
The summary is often incorrect in at least some subtle details, which is invisible to a lot of people who do not understand LLM limitations.
Now, we can argue that a typical SEO-optimized garbage article is not better, but I feel like the trust score for them was lower on average from a typical person.
I don't think searching for answers to simple questions was a problem until Google nerfed their own search engine.
There was a time before SEO slop that web search was really valuable
We're fighting slop with condensed slop
> We are entering the era of cheap spam of everything with little incentive for quality
Correction -- sadly, we're already well within this era
But some webdev said they are 10x faster now so it cant be bad for humanity /s
Quick! Tell me what this does or you're not a real programmer, not a craftsman, and are a total hack who understands nothing about quality (may not even be a good person, want to lay off bread-and-butter red-blooded american programmers)
.global main
.text
main:
mflr 27
mr 13,3
mr 14,4
addi 3,3,48
bl putchar
li 3,10
bl putchar
next:
lwz 3,0(14)
bl puts
addi 14,14,4
addi 13,13,-1
cmpwi 13,0
bgt next
lis 3,zone@ha
addi 3,3,zone@l
bl puts
mtlr 27
mr 3,13
blr
.data
.align 2
zone:
.string "Bonjour"
This author assumes that open sourcing a package only delivers value if is added as a dependency. Publicly sharing code with a permissive license is still useful and a radical idea.
Yeah if I find some (small) unmaintained code I need, I will just copy it (then add in my metrics and logging standards :)
It shouldn't be a radical idea, it is how science overall works.
Also, as per the educational side, I find in modern software ecosystem, I don't want to learn everything. Excellent new things or dominantly popular new things, sure, but there are a lot of branching paths of what to learn next, and having Claude code whip up a good enough solution is fine and lets me focus on less, more deeply.
(Note: I tried leaving this comment on the blog but my phone keyboard never opened despite a lot of clicking, and on mastodon but hit the length limit).
Yep. Even just sharing code with any license is valuable. Much I have learned from reading an implementation of code I have never run even once. Solutions to tough problems are an under-recognized form of generosity.
This is a point where the lack of alignment between the free beer crowd and those they depend on is all too clear. The free beer enthusiast cannot imagine benefiting from anything other than a finished work. They are concerned about the efficient use of scarce development bandwidth without consciousness of why it is scarce or that it is not theirs to direct. They view solutions without a hot package cache as a form of waste, oblivious to how such solutions expedite the development of all other tools they depend on, commercial or free.
I do agree with this, but there are some caveats. At the end of the day it is time people invest into a project. And that is often unpaid time.
Now, that does not mean it has no value, but it is a trade-off. After about 14 years, for instance, I retired permanently from rubygems.org in 2024 due to the 100k download limit (and now I wouldn't use it after the shameful moves RubyCentral did, as well as the new shiny corporate rules with which I couldn't operate within anyway; it is now a private structure owned by Shopify. Good luck finding people who want to invest their own unpaid spare time into anything tainted by corporations here).
I don’t think open source is going anywhere. It’s posed to get significantly stronger — as the devs which care about it learn how to leverage AI tools to make things that corporate greasemonkeys never had the inspiration to. Low quality code spammers are just marketing themselves for jobs where they can be themselves: soulless and devoid of creative impulse.
That’s the thing: open source is the only place where the true value (or lack of value) of these tools can be established — the only place where one can test mettle against metal in a completely unconstrained way.
Did you ever want to build a compiler (or an equally complex artifact) but got stuck on various details? Try now. It’s going to stand up something half-baked, and as you refine it, you will learn those details — but you’ll also learn that you can productively use AI to reach past the limits of your knowledge, to make what’s beyond a little more palatable.
All the things people say about AI is true to some degree: my take is that some people are rolling the slots to win a CRUD app, and others are trying to use it to do things that they could only imagine before —- and open source tends to be the home of the latter group.
True innovation will come from open source for sure. As the developers don't have the same economic incentives to be "safe", "ethical" "profitable" or whatever. large corporations know this and fear this development. That's why i expect a significant lobbying to take hold in USA that will try and make local AI systems illegal. And I think they will be very convincing to the government. Because the government also fears the "peasants" and giving them any true semblance of real AGI like systems. I bet very soon we will start seeing various classifications that will define what is legal and what is not for a citizen to possess or use.
> That's why i expect a significant lobbying to take hold in USA that will try and make local AI systems illegal.
I think they're going to be using porn and terrorism (as usual) to do that, but also child suicide. I also think they're going to leverage this rhetoric to lock down OSes in general, by making them uninstallable on legally-available hardware unless approved, because approved OSes will only be able to run approved LLMs.
Meaning that I think LLMs/generative AI will be the lever to eliminate general-purpose computing. As mobile went, so will desktop.
I think this is inevitable. The real question for me is whether China will partner with the west on this, or whether we will be trading Chinese CPUs with each other like contraband in order to run what we want.
> any true semblance of real AGI like systems.
This is the only part I don't agree with. This isn't going to happen, but I'm not even sure it would be more useful than what we have. We have billions of full AGI machines walking around, and most of them aren't great. I'm talking about restrictions on something technically barely better than what we have now; maybe only a significant bit more compute-efficient. Training techniques will probably be where we get the most improvements.
> It’s posed to get significantly stronger
It's really not. Every project of any significance is now fending off AI submissions from people who have not the slightest fucking clue about what is involved in working on long-running, difficult projects or how offensive it is to just slather some slop on a bug report and demand it is given scrutiny.
Even at the 10,000 feet view it has wasted people's time because they have to sit down and have a policy discussion about whether to accept AI submissions, which involves people reheating a lot of anecdotal claims about productivity.
Having learned a bit about how to write compilers I know enough to know that I can guarantee you that an AI cannot help you solve the difficult problems that compiler-building tools and existing libraries cannot solve.
It's the same as it is with any topic: the tools exist and they could be improved, but instead we have people shoehorning AI bollocks into everything.
This isn't an AI issue. It is a care issue. People shouldn't submit PRs to project where they don't care enough to understand the project they are submitting to or the code they are submitting. This has always been a problem, there is nothing new. The thing that is new is more people can get to a point where they can submit regardless of their care or understanding. A lot of people are trying to gild their resume by saying they contributed to a project. Blaming AI is blaming the wrong problem. AI is a a tool like a spreadsheet. Project owners should instead be working ways to filter out careless code more efficiently.
This is an AI issue because people, including the developers of AI tools, don't care enough.
The Tragedy Of The Commons is always about this: people want what they want, and they do not care to prevent the tragedy, if they even recognise it.
> Project owners should instead be working ways to filter out careless code more efficiently.
Great. So the industry creates a burden and then forces people to deal with it — I guess it's an opportunity to sell some AI detection tools.
Sounds like a lot of FUD to me — if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place?
Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.
In such a setting, you’re working within a trusted party — and for a major project, that likely means extremely competent maintainers and contributors.
I don’t think these people will have any difficulty adapting to the usage of these tools …
> Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.
It is a waste of time for large-scale volunteer-led projects who now have to deal with tons of shit — when the very topic is "how do we fend off this stuff that we do not want, because our project relies on much deeper knowledge than these submissions ever demonstrate?"
yeah we are getting lots of "I don't know how to do this and AI gave me this code that doesn't work, can you fix it" or "AI said it can do this" and the feature doesn't exist... some people will even argue and say "but AI said it doesn't take long, why won't you add it"
It weaponises incompetence, carelessness and arrogance at every turn.
AI, to me, is a character test: I'm regularly fascinated by finding out who fails it.
For example, in my personal life I have been treated to AI-generated comms from someone that I would never have expected it from. They don't know I know, and they don't know that I think less of them, and I always will.
I am sure I am not the only one who thinks these micro-dependencies are worthless anyway. You'd be better off just listing the functions in a markdown file for people to copy over than ship an entire package for it.
This isn't "small" open source, "small" would be something you put together in a week or weekend. These are like "micro" projects, where more work goes into actually publishing and maintaining the repository than actually writing the library.
I like the approach C sometimes takes, with the "tiny header file" type of libraries. Though I guess that also stems from the lack of a central build system.
TLDR: [AI promises] a future where we prize instant answers over teaching and understanding
But what this article and the comments don't say: open-source is mainly a quality metric. I re-use code from popular open-source repo's in part because others have used it without complaints (or document the bugs), in part because people are embarrassed to write poor-quality open-source so it's above-par code, and in part because if there are issues in this corner of the world, this dependency will solve them over time (and I can watch and wait when I don't have time to fix and contribute).
The quality aspect drives me to prefer dependencies over AI when I don't want full ownership, so I'll often ask AI to show open-source projects that do something well.
(As an aside, this article is about AI, but AI is so pervasive now as an issue that it doesn't even need saying in the title.)
Small open source is still valuable, but the bar is higher. If your project is something that's trivial and nobody just thought to do it before you and bothered to do it after, that's probably not going to survive, but if your project is a small focused tool that handles something difficult really well, it's 100% got a future.
More likely, what we will see is the decline of low effort projects. The JavaScript/ Typescript ecosystem has been plagued with such packages. But that’s more anomalous to the JS community than it is a systemic problem with open source in general.
So if fewer people are including silly dependencies like isEven or leftPad, then I see that as a positive outcome.
Open source exists because coding was a significant effort and code was a thing of high value. Unsurprisingly companies hesitated to make the code public and free. All of this is changing now as coding has suddenly become trivial. So, yes, the mission of open source, in general, will be challenged.
In the U.S., anything machine generated is uncopyrightable.
Why would you put uncopyrightable code into your codebase?
Why wouldn't you? Your codebase (if you're a business) exists to make you money, people being able to copy some unknown portions of it without further license if they somehow legally get their hands on a copy of it seems entirely irrelevant.
PS. I think this is much less clear and much less settled law than you are suggesting.
I think if you dig a little deeper you will find that the answer is not so black and white.
It's more nuanced. If I even have a few lines I can prove are mine, those parts are copywritable in the same way Pride and Prejudice is public domain but pride and prejudice and zombies is copyrighted.
Autocomplete has been around for decades
Even worse...unmaintained code. Only the human-written one has a maintainer. The other one plagiariased by AI is instant legacy code
> The other one plagiariased by AI is instant legacy code
I have used this "instant legacy code" concept before. It's absolutely true, IMO. But people really, really, really hate hearing it.
> Claude’s version is pretty close to the blob-util version (unsurprising, since it was probably trained on it!).
AI are thieves!
> I don’t know which direction we’re going in with AI (well, ~80% of us; to the remaining holdouts, I salute you and wish you godspeed!), but I do think it’s a future where we prize instant answers over teaching and understanding.
Google ruined its search engine years ago before AI already.
The big problem I see is that we have become WAY too dependent on these mega-corporations. Which browser are people using? Typically chrome. An evil company writes the code. And soon it will fire the remaining devs and replace them with AI. Which is kind of fitting.
> Even now there’s a movement toward putting documentation in an llms.txt file, so you can just point an agent at it and save your brain cells the effort of deciphering English prose. (Is this even documentation anymore? What is documentation?)
Documentation in general sucks. But documentation is also a hard problem.
I love examples. Small snippets. FAQs. Well, many projects barely have these.
Look at ruby webassembly/wasm or ruby opal. Their documentation is about 99% useless. Or, even worse - rack in ruby. And I did not notice this in the past, in part because e. g. StackOverflow still worked, there were many blogs which helped fill up missing information too. Well all of that is largely gone now or has been slurped up by AI spam.
> the era of small, low-value libraries like blob-util is over. They were already on their way out thanks to Node.js and the browser taking on more and more of their functionality (see node:glob, structuredClone, etc.), but LLMs are the final nail in the coffin.
I still think they have value, but looking at organisations such as rubygems.org disrupt the ecosystem and bleeding it dry by kicking out small hobbyists, I think there is indeed a trend towards eliminating the silly solo devs who think their unpaid spare time is not worthy of anything at all, yet the big organisations eagerly throw down more and more restrictions onto them (my favourite example is the arbitrary 100k download limit for gems hosted at rubygems.org, but look at the new shiny corporate rules on rubygems.org - this is when corporations take over the infrastructure and control it. Ironically this also happened to pypi and they admit this indirectly: https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f... - of course they deny that corporations control pypi now, but by claiming otherwise they admit it, because this is how hobbyists get eliminated. Just throw more and more restrictions at them without paying them. Sooner or later they decide to do something better with their time.)
He almost got it right. It's not just the fate of small open source. It's the fate of all programmers now. Why hire a programmer when an LLM costs less, works faster and makes less mistakes (OP compliments better error handling, read the article).
Unless you are a product owner, you have paying clients that love you and your product and won't simply ditch it in favour of a new clone, you are really screwed.
"when an LLM costs less, works faster and makes less mistakes"... indeed, but it doesn't follow at all that it's the fate of all programmers _now_... at least in my experience none of these things are true ATM.
Well, at the very least it costs less than asking intern to look for a lib doing something particular and give some examples... still about as accurate as the intern tho.
How many time has it happened for a company to actually ask an intern for a library?
So far I've never seen yet a non-programmer release production-grade code using only LLMs. There's just so much to care about (from security, deployments, secret management, event-driven architectures, and a large etc.) that "just" providing a prompt to create an "app" doesn't cut it. You need infra and non-engineers just don't know shit about infra (even if it's 99% managed), you need to deploy your llm-generated code in that infra; that should happen in a ci/cd probably. And what about migrations? Git? Who's setting up the api gateway? I don't mean to say that LLMs don't know how to do that, but you need to instruct them to do so, and even there, they will make silly mistakes and you need to re-instruct them or fix it.
Prompting is just 50% of the work (and the easy part actually). Ask the Head of Product or whoever is there to deploy something valuable to production and maintain it for 6 months while not losing money. It's just not going to happen, not even with truly AGI.
An LLM might be able to replace the majority of the code Sindre Sorhus has put out there, but it's probably a stretch to think that it could replace someone like John Carmack.
Trivial NPM libraries were never needed, but LLMs really are the nail in the coffin for them even when it comes to the most incompetent programmers because now they can literally just ask an LLM to spit out the exact same thing.
He also points out a pointless type check in a type checked language...
Your name is very accurate I must say.
That type check is honestly not pointless at all. You can never be certain of your inputs in a web app. The likelihood of that parameter being something other than an arraybuffer is non-zero, and you generally want to have code coverage for that kind of undefined behavior. TypeScript doesn't complain without a reason.
Several issues:
1. Reducing dependencies is a wrong success metric. You just end up doing more work yourself, except you can't be an expert in everything, so your code is often strictly worse.
2. Regenerating the same solutions with a probabilistic machine will produce bugs a certain percentage of the time. Dependencies are always the same code (when versioned).
3. Cognitive overhead for human review is higher with LLM-generated libs, for no additional benefit.
> Reducing dependencies is a wrong success metric. You just end up doing more work yourself
Except it's just not true in many cases because of social systems we've built. If I want to ship software to Debian I have to make sure that every single of my 3rdparty dependencies is registered and packaged as a proper debian package - a lot of time it will take much less work to rewrite some code than to get 25 100-lines-of-code micro-libraries accepted into debian.