  Given that some 80% of developers are now using AI in their regular work, blob-util is almost certainly the kind of thing that most developers would just happily have an LLM generate for them. Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks.

Letting LLM write utility code is a sword that cuts both ways. You often create a throw-away code that is unproven and requires maintenance. It's not a guarantee that the blobutil or toString or whatever created by AI won't fail at some edge cases. That's why e.g. in Java there is Apache commons which is perceived as an industry standard nowadays.

▲ jaapz 8 hours ago | parent | next [-]

Exactly. When you assume blob-util to be a utility library that has been in use for quite a while by many people in many different contexts, hasn't seen much changes and just "works", IMHO the risk of weird bugs is a lot larger with LLM-generated code. Code generated by LLM's often have the problem that the code seems logical, but then contain weird bugs that aren't immediately obvious.

	▲	p0w3n3d 8 hours ago \| parent [-]
		Agreed. The code available in e.g. Apache commons is not perfect, but it's seasoned and has the edge cases documented

▲ safety1st 5 hours ago | parent | prev | next [-]

This mostly sounds like a good thing to me from a utilitarian standpoint. Getting all your utility classes from somewhere like npm and creating dependencies on 20 different people and organizations who may or may not maintain their software has been a security nightmare with many highly public examples. If a LLM writes a utility class for me then my supply chain is smaller, meaning less surface area to attack plus I probably benefit from some form of security through obscurity for whatever non-trivial amount that's worth. "Downside" is I don't have some rando, probably unpaid labor out there updating a piece of my app for me...

▲

philipov 3 hours ago | parent [-]

Your supply chain is superficially fewer, but not smaller. The way you're counting the number of suppliers is heterogeneous: ChatGPT has a bigger surface area than 20 individuals.

▲

safety1st 2 hours ago | parent [-]

Your supply chain is smaller in the sense that every person or organization you obtain code from is similar to a vendor, just an unpaid one. They are a separate entity your business depends on.

If we replace code written by 20 of those organizations with code written by ChatGPT, we've gone from 20 code "vendors" we don't know much about who have no formal agreement to speak of with us, to 1 tools vendor which we can even make an enterprise agreement with and all that jazz.

So whatever else the outcome may be, from this perspective it reduces uncertainty to quit using random npm packages and generate your utility classes with ChatGPT. I think this is the conclusion many businesses may reach.

	▲	dbalatero 2 hours ago \| parent [-]
		What enterprise agreement would you make with OpenAI that would make you feel better about the supply chain? Seems to me you just get stochastic output that may or may not be battle tested level code, without guarantees either?

▲ Cthulhu_ 4 hours ago | parent | prev | next [-]

It's not a new thing either, many years ago there was already the debate whether you should trust utility code copied from SO or use an NPM library. In fact, I'm 99% confident that the slew of single function NPM libraries became a thing because of that mindset.

▲ Menschlio 7 hours ago | parent | prev [-]

The proper way to do it, would be to have an industry standard on the default things people blindly but massivly pull through dependencies.

I also don't get how code can be so massivly inefficient. left-pad needs 9kb to download and the code is a handful of lines: https://www.npmjs.com/package/left-pad?activeTab=code

If my unit tests run through, i don't have 'unproven' code. I have well working code which doesn't need to go through a dependency hell upgrade cycle just because one function in that lib, i don't use, has some CVE too high to be ignored.