Hacker News Reader

Comment by landgenoot | Hacker News Reader

Doesn't the LLM spit out the code of the dependency it has been trained on? How is that any different from just forking the dependency and treating it like your own?

View on HN

One advantage might be that you would only implement the (small) part of the library that you actually need, potentially avoiding bugs such as Log4Shell.

The risk of code duplication is a serious one though, and it would be nice if AI could automatically detect and clean this.

I guess we are in an annoying "in-between" state of things, with a pretty unsure future.

The benefit of using a library directly is your 3rd party library checks will warn you when a CVE is found in the version you are using. If an LLM creates the same functionality from copying a version of a library, you might be getting a version that already has known vulnerabilities, and you probably won't be pulling in any fixes/improvements in future until you find them.

Why not both?

Fork the dependency and use that, to have a stable non-changing base which you use. And additionally, make the original project a dependency but don't actually use it. This way you'll get CVE information from your tooling.

If you fork a dependency and change features, the CVE information on original depenency is now no longer valid for your code. Your additions or removals can induce new CVEs, or render CVE for original lib a moot point.

You would (probably) be avoiding commonly known exploits while introducing subtle AI-induced bugs like printing logs out of order or not locking/ordering resources properly.

Oh yes, I fully agree. It will be quite horrible if we don't handle things properly.

Not necessarily, you can task the AI Agent with writing your tool without the use of external dependencies. Often the tool itself will be absolutely horrible, but this doesn't matter if the output of the tool is fine. As in the case of OpenAPI documentation, you basically get the LLM to write the equivalent of C#'s Swashbuckle (or whatever it's called these days) for your language. What it produces is horrible in comparison to the third party dependencies you would have pulled 5 years ago, but the output is the same.

You can also let it use outside dependencies, but then you're right, then it would make little difference in regards to security.

We figured this out because Go didn't have a "Swashbuckle", and nobody wanted to write the documentation or use codegens to go in the opposite direction. When it turned out to be so easy to use LLM's for these things, it grew into it's own thing in regards to replacing a lot of dependencies. Obviously the LLM is still the dependency, but you can replace all other external dependencies for a lot of things like this. Which means you won't acidentially pull something malicious.

I imagine we're going to see more and more of these in-house dependency replacement tools. Coming from Go, I obviously use SQLC (which is run inside it's own isolated container that is only available for requests from developers and is only updated by hand). If we couldn't run SQLC in total isolation then I imagine we would have had to build our own "SQLC". I haven't tried but I'm pretty confident that you could use LLM's to build a similar (but much worse in quality) tool. In an ideal world, we would have been allocated the resources we needed, but in reality, it would have just made us slower as "IT" is still viewed as a cost center on par with HR except that we aren't even "IT".

It’s easier to incrementally review the generated, specific code of an AI agent than it is to review a generic, overly featured long-lived library— and to keep on top of (and review) all changes to that library over time.

Reply on news.ycombinator.com