Live data from Hacker News

No LLM Code in Dependencies

joeyh.name

101–110 of 120 posts

Re: No LLM Code in Dependencies

#101

Earlier quoted context omitted.

> never rely on anything that wasn't at least seriously looked over by an LLM I can imagine LLMs becoming a mainstay, but what you are describing isn't wholly different from sufficiently advanced static code analysis - where you'd want more determinism than most LLMs normally provide. The problem is that such a thing might take a decade and billions of dollars of investments to create per-language (e.g. actually usef…

I remember back in the pre-2023 days where SonarQube was a big deal for Java static analysis, and I let it rip across an entire 120k line project at one point upon which it found something like seven issues, out of which only one or two were actual bugs. It was almost entirely useless. I think even Qwen would've done leagues better today. Most bugs are far too nuanced to be caught by static analysis imo, you do need…

> everything technically checks out

So who's responsible for all of the Spring Dependency Injection bullshit with circular dependencies and AOP issues, stuff like @Transactional only working when called from a different bean, as well as the other hundreds of issues I've seen throughout the years? One can't just ignore that, because in many places that is most of the job market (alongside maybe .NET or PHP).

There's got to be some traditional way to spot every single one of the states that can be represented in code by the frameworks available in a given language, surely the correct answer is not "Yeah, an LLM said it looks okay because it's close enough to some training data that we have." It might be the practical answer, but only because all of our tech is built wrong.

Then again, writing provably correct code might be impossible in Java, at least with the currently available tools, because the ecosystem is such that the compiler can't do anything about all of the dynamic stuff that evil developers make you deal with at runtime.

Re: No LLM Code in Dependencies

#102

Earlier quoted context omitted.

I find your comment here interesting. The parent never called out LLM-coding, they said "sloppers". If we take that choice of word as deliberate, it stands to reason there's a distinction there between "sloppers" and LLM assisted coding in general. You quoting "This is not true of every slopper" as proof they are equating the two seems like a weakly defended assertion. It's entirely possible there are 3 broad classes…

The article is about LLM code. I’m sure you can condense the many lines into less than 5 lines. I’m not sure what you are trying to say.

If reading 1 and a half paragraphs is too much, then I guess we shouldn't try to communicate.

Re: No LLM Code in Dependencies

#104

This is completely infeasible in the age of mythos. The reality is that the velocity is just not going to feasible from a security PoV without leveraging these tools.

In ten years we'll look at human written code like the unreliable garbage it is, and never rely on anything that wasn't at least seriously looked over by an LLM. It won't be even close.

In ten years, crypto will be the world’s primary currency. Oh look, stupid hot takes aren’t that hard to have after all.

Re: No LLM Code in Dependencies

#105
post #73

Earlier quoted context omitted.

Then you don't have time to maintain the codebase. Sad, but sometimes true.

When given the choice between putting food on the table, and being a purist, I'd take some bread. It is hard out there.

Sure. I did not mean to throw shade at people whose professional survival depends on doing this.

I'm merely trying to establish that it's bad. A lot of HN seems to be cheering for the badness. That is, to me, unfathomable.

Re: No LLM Code in Dependencies

#106

Earlier quoted context omitted.

The article is about LLM code. I’m sure you can condense the many lines into less than 5 lines. I’m not sure what you are trying to say.

If reading 1 and a half paragraphs is too much, then I guess we shouldn't try to communicate.

It isn’t what I said. I’d rather communicate with people who do not use 3 words where 1 would do.

Re: No LLM Code in Dependencies

#107

Earlier quoted context omitted.

I hear you, but again there are a lot of assumptions in this statement: "sloppers are diving head-first into a world where not knowing". The problem is you've redefined LLM-coding as slopping. "This is not true of every slopper".

I find your comment here interesting. The parent never called out LLM-coding, they said "sloppers". If we take that choice of word as deliberate, it stands to reason there's a distinction there between "sloppers" and LLM assisted coding in general. You quoting "This is not true of every slopper" as proof they are equating the two seems like a weakly defended assertion. It's entirely possible there are 3 broad classes…

Indeed. I wouldn't call everyone who uses LLMs to generate code a slopper. But I'm afraid that there are so many sloppers that they pose a real danger to the ecosystem, especially considering the amount of code they generate. A volunteer project has limited resources, and I can totally understand why it doesn't wanna use those to separate the wheat from enormous amounts of chaff. If that's the case, an outright ban might be a smart move.

Note that a ban on LLM-generated code is not a prohibition on other forms of LLM-based assistance. Those other forms don't incur a direct burden on the maintainers.

Re: No LLM Code in Dependencies

#108

Earlier quoted context omitted.

If reading 1 and a half paragraphs is too much, then I guess we shouldn't try to communicate.

It isn’t what I said. I’d rather communicate with people who do not use 3 words where 1 would do.

This conversation does not exist primarily for your benefit though.

Re: No LLM Code in Dependencies

#109

Earlier quoted context omitted.

In ten years we'll look at human written code like the unreliable garbage it is, and never rely on anything that wasn't at least seriously looked over by an LLM. It won't be even close.

In ten years we'll be drowning in subtle bugs introduced by the unreliable garbage that is machine-generated code, and the industry will hopefully have learned to never rely on anything that wasn't at least seriously looked over by an actual thinking human being that understands it. We'll look back on our youthful idealism and cultish faith in this new technology with embarrassment.

I'm a bit more pessimistic.

> In ten years we'll be drowning in subtle bugs introduced by the unreliable garbage that is machine-generated code

Yes. But replace

> and the industry will hopefully have learned to never rely on anything that wasn't at least seriously looked over by an actual thinking human being that understands it.

with: "and the industry will throw even more LLMs at the problem, producing an even deeper soup of garbage that in some cases perform a tiny bit better, and when things do break it's always the fault of someone else. So for example a bank denies you a mortgage or an insurance company fails to process your claim, and you are almost certain that it's due to some slopcode somewhere, but you have to suck it up because the world has become accustomed that this is just how things are done."

It's a way of breaking computers that I'd never thought I'd see. We're wilfully taking the one cool thing about computers – them exactly interpreting instructions carefully crafted by humans to do exactly the right thing – with bucketloads of vibes that hopefully mostly do the right thing most of the time ("the tests pass"). What the hell are we doing.

Re: No LLM Code in Dependencies

#110
post #108

Earlier quoted context omitted.

It isn’t what I said. I’d rather communicate with people who do not use 3 words where 1 would do.

This conversation does not exist primarily for your benefit though.

Fair enough, but I was addressed directly, so I'm sure I can leave my 2p.
Post reply on HN