Forgot your password?
typodupeerror

Comment Re:But the real cost is increased service prices (Score 1) 65

Also, anything sounds big when you put it in gallons. Doesn't sound so big when you mention that's 92 acre feet, the amount used by less than 20 acres / 8 hectares of alfalfa per year. Or when you mention that a typical *closed loop* 1GW nuclear reactor uses 6-20 billion gallons of cooling water per year (once-through uses 200-500 billion gallons, though most of that is returned, whereas closed loop evaporates it)

Comment Re:That makes sense. (Score 1, Troll) 60

I don't think it has anything to do with that. As soon as I saw the headline, my mind went "cohort study". And sure enough, yeah, it's a cohort study. Remember that big thing about how wine improves your health, and then it turned out to just be that people who drink wine tend to be wealthier and thus have better health outcomes? And also, the "sick quitter" effect, where people who are in worse health would tend to stop drinking, so you ended up with extra sick people in the non-wine group? Same sort of thing. This study says they're controlling for a wide range of factors, but I'd put money on it just being the same sort of spurious correlations.

Comment Re:umm (Score 5, Insightful) 61

Actually, if anything he's saying his software package is so crappy that it *should* have found issues. He considers it's failure to find issues not a testament to how awesome his software package is but how lacking the tool is.

I've seen a few times where the curl developer has stood up to some asinine thing that most projects just roll with and I've appreciated his perspective each time.

His finding is consistent with another analysis I saw: Mythos was not good at finding issues at all. The one thing they could claim was that while other models found more issues, Mythos was able to craft a demonstrator to actually exploit the weakness, rather than just identifying the issue.

Comment Re:Programming graffiti (Score 1) 26

Getting their name on a project they are a fan of is a big factor

Also, they *truly* think they can *finally* be useful without having to actually understand things. They think a code request will be accepted more readily than they ever got attention on feature requests or behavior changes. They think their willingness to let CodeGen go nuts is a differentiation over the developers who mifroght even be using the same CodeGen tools, but with more care. If nothing else, they see tokens as almost like currency, so by generating the code it saves the developers from spending tokens.

So they mean well enough, but they flood folks with slop because they were never in a position before to do anything but slop, but CodeGen lets them realize their slop.

Just like the AI art is generally slop by lack of any artistic vision to start with. If they had sat down to actually draw the art, it still would have been slop, but now it just accelerates the process.

Comment Re:aaaand now I'm curious (Score 1) 26

Well, github seems to be throwing a fit, but I can say from my experiences:

- Uselessly verbose. One AI pull request I was asked to review was aiming to do a minor adjustment the layout of a singular webui element. The pull request was hundreds of lines of CSS because the LLM just started firing the random bullshit CSS cannon, often repeating itself probably because the operator said "no, it's still messed up" until by some miracle the one change he wanted managed to finally appear, alongside a whole bunch of other crap with side effects that the operator didn't bother to find out about. When getting to the heart of what they *actually* wanted, it was a single line one minute css tweak.

- Missing the glaringly obvious. Had a pull request seeking to adjust behavior to be compatible with newer things in the ecosystem. Ok, great, but adjustments had already been made and released a year ago, the operator had a stale container they had never updated. At no point in the clone/pull/mod/pull request flow did the AI stop and say "oh, it appears equivalent changes have already been made", but instead submitted different ways that were actually functionally broken.

- Operators tend to fire off just tons of requests to many projects. A relatively low traffic project I work with that might have a pull request every couple of months woke up with 50 pull requests from one guy that were opened over the course of an hour. The operator had pointed at the issue tracker (which admittedly had poor issue hygiene, resulting in issues open that should have been closed) and said make a pull request per issue to fix everything. One example was a 15 year old issue asking to change the project to support python 2.4, and since then the project had moved to require python 3.9, but the LLM still submitted patches around the specific examples of python 2.4 incompatibilities, despite it being ugly and also useless since so much more of the codebase was python 3 only. Several issues that had been fixed but not updated in the tracker had a pull request to 'fix' it.

- Fixing issues that weren't an issue. They pull a project and ask llm to do a code review and then submit pull requests based on what the LLM represents as needing changes.

So tons of volume, useless changes, changes with side effects...

The main issue is that CodeGen enthusiasts that were formerly intimidated by code syntax and toolchains think they can finally make an impact. The issue being is that code syntax and toolchains are the least of the challenges associated with good software. So CodeGen can significantly mitigate the tedium of those items, but now you have to contend with people that formerly were filtered by the intimidation.

Slashdot Top Deals

The trouble with money is it costs too much!

Working...