Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A study on robustness and reliability of large language model code generation

arxiv.org

Post reply on HN
Print view View original

91–100 of 229 posts

Re: A study on robustness and reliability of large language model code generation

#91

Post by jki275 »

Panzer04 wrote: post #69
corethree wrote: post #47

Earlier quoted context omitted.

The over-hype is causing it to look under-hyped. 48% of the code being freaking correct from 0% about 5 years ago is huge. With everyone and all the news talking about it constantly inevitably people are going to start rolling their eyes. This is bias. 48% is half way to 100%. Once it reaches 100% you don't have a job. You realize that right? It's halfway their to taking your job and you're underwhelmed. The bias is…

Except the eternal problem with all "AI" so far is edge cases. A product that is 90% correct may as well be useless, honestly.

I wouldn't argue useless, I'd argue it's a product that still needs an expert user to validate.

Re: A study on robustness and reliability of large language model code generation

#92

Post by plorkyeran »

skepticATX wrote: post #53
Gigachad wrote: post #14

I feel like AI for programming has been so overhyped. I've attempted to use ChatGPT for programming so many times, and almost every time it's just wasted my time. Giving me outright lies or generating stuff that looks right but doesn't work. And just throwing out it's answer and starting from scratch is faster than fixing its output. I've only found it useful for explaining basic terminology or concepts for a topic I…

There's a big gap between people using it to write greenfield applications and/or smaller tools, and people working on large codebases. I am in the latter group, and I don't find it all that helpful. There simply aren't any tools that can plug into a massive codebase with millions of lines. I never just work on one specific repository either - a change generally involves multiple repositories. On the other hand, if y…

I do think that's the big disconnect. There's jobs where you basically only ever create brand new code from scratch - writing lots of little scripts, creating new screens in a webapp, or whatever - and current AI tools can save a ton of time for that. There's also jobs where it's normal to spend a week figuring out what to change and then five minutes changing it, and current AI tools are worthless for that. Most jobs are somewhere in between those extremes, but the hype is coming from people pretty far on the "mostly writing new code" end.

Re: A study on robustness and reliability of large language model code generation

#94

Post by Retric »

pnpnp wrote: post #40
Retric wrote: post #32

Earlier quoted context omitted.

It’s a question of time investment, fact checking is slower you than actually learning the material directly. So if you need to fact check every single thing you’re better off just leaning it in the first place.

In the original comment’s defense, sometimes you need to find where to start. For example: when writing a research paper, one might hastily cast a wide net before locating and drilling into a topic from a respected source. I’m not well-versed in JavaScript (I’d like to be, but neither me nor my company have the resources right now to commit). When JS work comes up, I’ll often Google/ChatGPT to point me in a general d…

I get where you’re coming from. However it’s easy to fall into the generalist trap where muddling through works well enough that you never spend the time to actually learn anything. It’s risky to really lean the details of a web framework which you may only use for a single 6 month project.

However, there’s a few things like SQL and JavaScrip that are likely to stick around mostly unchanged for your entire career. The risks are therefore much lower.

IMO, a reasonable heuristic is spend around 10% of the time you expect to work on technology in the next year actually learning the fundamentals until you feel comfortable. Often what looks like a major time sink goes away when you stop fumbling around.

Re: A study on robustness and reliability of large language model code generation

#95

Post by jhugo »

throwaway09223 wrote: post #50
xtagon wrote: post #48

Earlier quoted context omitted.

A mid-level human engineer can iteratively fix the mistakes they start making, instead of that just being the final result. Can GPT-4 do that?

Yes, like I said if you give it the results, eg "That code resulted in this error. What's wrong?" it will more often than not correct its mistake. Hooking it up to automatically run the code in question and examine the output is a trivial undertaking - many folks have already done this.

My experience has usually been that it will apologize and then produce another snippet with a different flaw. When that is pointed out, it will usually go back to the original snippet with the original flaw. It sometimes also insists that it has “run the test suite and they all pass”, just like a human programmer that is trying to fake it until they make it I guess?

Re: A study on robustness and reliability of large language model code generation

#96

Post by earthboundkid »

taspeotis wrote: post #15

I mean the landing page of GitHub Copilot just shoves text unencoded into a urlencoded body, this is nothing new... const response = await fetch(`http://text-processing.com/api/sentiment/`, { method: "POST", body: `text=${text}`, headers: { "Content-Type": "application/x-www-form-urlencoded", }, });

I find it kind of crazy that they haven’t fixed given how prominently it was called out. The Go example is wrong too. It doesn’t check the database call for a final error.

Re: A study on robustness and reliability of large language model code generation

#97

Post by aldarisbm »

tomjakubowski wrote: post #51
xtagon wrote: post #48

Earlier quoted context omitted.

A mid-level human engineer can iteratively fix the mistakes they start making, instead of that just being the final result. Can GPT-4 do that?

I wonder if anyone has done a feedback loop with GPT and compiler errors to train this sort of thing

they have, with langchain

Re: A study on robustness and reliability of large language model code generation

#98

Post by jay_kyburz »

Retric wrote: post #32
capableweb wrote: post #25

Earlier quoted context omitted.

Which version of GPT are you using? I've found GPT4 moderately helpful, like getting help from someone with a wide but shallow experience of lots of things. > I can't easily fact check it Why not? How did you find out things about basic terminology or concepts you're not familiar about before GPT? Apply the same methods, although you just have to fact check rather than coming up with what to check, so removes a small…

It’s a question of time investment, fact checking is slower you than actually learning the material directly. So if you need to fact check every single thing you’re better off just leaning it in the first place.

Yeah, I have been learning some new topics lately, and GTP is actually very helpful in giving me the language I need to use start searching.

I'm not interested in starting at the beginning and learning a whole new language or API, I just want to get my task done, so I can ask GTP to get me started, then I can run the code it writes and start building tests and things to verify it works as expected.

Re: A study on robustness and reliability of large language model code generation

#99

Post by earthboundkid »

makestuff wrote: post #11
keyle wrote: post #8

Ok but what are we calling API misuses? We collect 1208 coding questions from StackOverflow on 24 representative Java APIs. We summarize thecommon misuse patterns of these APIs and evaluate them oncurrent popular LLMs. The evaluation results show that evenfor GPT-4, 62% of the generated code contains API misuses,which would cause unexpected consequences if the code isintroduced into real-world software. Should have u…

I have been trying to use ChatGPT to make a VueJS website (I’m a backend dev). What I have noticed with VueJS specifically is that it has little to no knowledge of the composition API, and when I ask it to help build a component it is pretty good at the scaffolding. The component will generally work; however, it is pretty useless for CSS styling. I probably should try Copilot as I bet that would work better. Also the…

ChatGPT is very bad at CSS. The only good part is you can test it and see that it’s not working very quickly. Unfortunately if you go back to ChatGPT it will waste your time with endless apologies and more broken CSS.

Re: A study on robustness and reliability of large language model code generation

#100

Post by 13yuan »

teraflop wrote: post #64

I'm sympathetic to the viewpoint that GPT-4 is prone to mistakes when writing code. Unfortunately, the analysis in this paper is pretty bad and doesn't support that conclusion. The authors assume that for any given method under consideration, it must only occur within a particular pattern of other method calls and control flow instructions. But the templates they have chosen are clearly only applicable in certain sit…

The paper actually explains that it targets at the API misuse problem, not the semantic alignment or bugs. Semantic bugs are difficult to detect, which is already a consensus in software engineering field and still many ongoing work on it. And when we say 'semantic' in this special problem it means more than 'semantic' in programs but also how developers express their semantics, which is definitely a problem bigger than checking the code itself. The API usage patterns are created to help check the code snippets given by LLMs, while the race condition you mentioned could exist but not checkable unless given other components of the programs. If adding the bugs you mentioned, the buggy code generated by LLMs could even exceed the number claimed in the paper.
Post reply on HN