top 50 comments

sorted by: hot top controversial new old
[–] 77 points 1 year ago (2 children)

I feel this -- we had a junior dev on our project who started using AI for coding, without management approval BTW (it was a small company and we didn't yet have a policy specifically for it. Alas.)

I got the fun task, months later, of going through an entire component that I'm almost certain was 'vibe coded' -- it "worked" the first time the main APIs were called, but leaked and crashed on subsequent calls. It used double- and even triple-pointers to data structures, which the API vendor's documentation upon some casual reading indicated could all be declared statically and re-used (this was an embedded system); needless arguments; mallocs and frees everywhere for no good reason (again due to all of the un-needed dynamic storage involving said double/triple pointers to stuff). It was a horrible mess.

It should have never gotten through code review, but the senior devs were themselves overloaded with work (another, separate problem) ...

I took two days and cleaned it all up, much simpler, no mem leaks, and could actually be, you know, used more than once.

Fucking mess, and LLMs (don't call it "AI") just allow those who are lazy and/or inexperienced to skate through short-term tasks, leaving huge technical debt for those that have to clean up after.

If you're doing job interviews, ensure the interviewee is not connected to LLMs in any way and make them do the code themselves. No exceptions. Consider blocking LLMs from your corp network as well and ban locally-installed things like Ollama.

  • source
  • hideshow 4 child comments
  • [–] 16 points 1 year ago

    It should have never gotten through code review, but the senior devs were themselves overloaded with work

    Ngl, as much as I dislike AI, I think this is really the bigger issue. Hiring a junior and then merging his contributions without code reviewing is a disaster waiting to happen with or without AI.

  • source
  • parent
  • [–] 11 points 1 year ago*

    It used double- and even triple-pointers to data structures

    (old song, to the tune of My Favourite Things)

    🎶 "Pointers to pointers to pointers to strings,
    this code does some rather unusual things...!"
    🎶

  • source
  • parent
  • [–] 40 points 1 year ago (2 children)

    I talked to Microsoft Copilot 3 times for work related reasons because I couldn't find something in documentation. I was lied to 3 times. It either made stuff up about how the thing I asked about works or even invented entirely new configuration settings

  • source
  • hideshow 4 child comments
  • [–] 18 points 1 year ago (2 children)

    Claude AI does this ALL the time too. It NEEDS to give a solution, it rarely can say "I don't know" so it will just completely make up a solution that it thinks is right without actually checking to see the solution exists. It will make/dream up programs or libraries that don't and have never existed OR it will tell you something can do something when it has never been able to do that thing ever.

    And that's just how all these LLMs have been built. they MUST provide a solution so they all lie. they've been programmed this way to ensure maximum profits. Github Copilot is a bit better because it's with me in my code so it's suggestions, most of the time, actually work because it can see the context and whats around it. Claude is absolute garbage, MS Copilot is about the same caliber if not worse than Claude, and Chatgpt is only good for content writing or bouncing ideas off of.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 1 year ago

    Are you using Claude web chat or Claude code? Because my experience with it is vastly different eve when using the same underlying model. Clause code isn't perfect and gets stuff wrong, but it can run the project check the output and realize it's mistake and fix it in many cases. It doesn't fix logic flaws, but it can fix hallucinations of library methods that don't exist.

  • source
  • parent
  • [–] 4 points 1 year ago* (last edited 1 year ago)

    In fairness the msdn documentation is prone to this also.

    By "this" I mean having what looks like a comprehensive section about the thing you want but the actual information you need isn't there, but you need to read the whole thing to find out.

  • source
  • parent
  • [–] 36 points 1 year ago (3 children)

    I'll quote myself from some time ago:

    The entire article is based on the flawed premise, that "AI" would improve the performance of developers. From my daily observation the only people increasing their throughput with "AI" are inexperienced and/or bad developers. So, create terrible code faster with "AI". Suggestions by copilot are >95% garbage (even for trivial stuff) just slowing me down in writing proper code (obviously I disabled it precisely for that reason). And I spend more time on PRs to filter out the "AI" garbage inserted by juniors and idiots. "AI" is killing the productivity of the best developers even if they don't use it themselves, decreases code quality leading to more bugs (more time wasted) and reducing maintainability (more time wasted). At this point I assume ignorance and incompetence of everybody talking about benefits of "AI" for software development. Oh, you have 15 years of experience in the field and "AI" has improved your workflow? You sucked at what you've been doing for 15 years and "AI" increases the damage you are doing which later has to be fixed by people who are more competent.

  • source
  • hideshow 3 child comments
  • load more comments (3 replies)
    [–] 28 points 1 year ago* (2 children)

    The study was centered on bugfixing large established projects. This task is not really the one that AI helpers excel at.

    Also small number of participants (16) , the participants were familiar with the code base and all tasks seems to be smaller in completion time can screw results.

    Thus the divergence between studio results and many people personal experience that would experience increase of productivity because they are doing different tasks in a different scenario.

  • source
  • hideshow 4 child comments
  • [–] 45 points 1 year ago (1 child)

    The study was centered on bugfixing large established projects. This task is not really the one that AI helpers excel at.

    "AI is good for Hello World projects written in javascript."

    Managers will still fire real engineers though.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 1 year ago* (1 child)

    I find it more useful doing large language transformations and delving into unknown patterns, languages or environments.

    If I know a source head to toe, and I'm proficient with that environment, it's going to offer little help. Specially if it's a highly specialized problem.

    Since SVB crash there have been firings left and right. I suspect AI is only an excuse for them.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago (1 child)

    Same experience here, performance is mediocre at best on an established code base. Recall tends to drop sharply as the context expands leading to a lot of errors.

    I've found coding agents to be great at bootstrapping projects on popular stacks, but once you reach a certain size it's better to either make it work on isolated files, or code manually and rely on the auto complete.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 1 year ago

    So far I've only found it useful when describing bite-sized tasks in order to get suggestions on which functions are useful from the library/API I'm using. And only when those functions have documentation available on the Internet.

  • source
  • parent
  • [–] 24 points 1 year ago (1 child)

    familiar with the code base

    Call me crazy but I think developers should understand what they're working on, and using LLM tools doesn't provide a shortcut there.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago

    You have to get familiar with the codebase at some point. When you are unfamiliar, in my experience, LLMs can provide help understanding it. Copying large portions of code you don't really understand and asking for an analysis and explanation.

    Not so far ago I used it on assembly code. It would have taken ages to decipher what it was doing by myself. The AI sped up the process.

    But once you are very familiar with a established project you had work a lot with, I don't even bother asking LLMs anything, as in my experience, I come up with better answers quicker.

    At the end of the day we must understand that a LLM is more or less an statistical autocomplete trained on a large dataset. If your solution is not on the dataset the thing is not going to really came up with a creative solution. And the thing is not going to run a debugger on your code either, afaik.

    When I use it the question I ask myself the most before bothering is "is the solution likely to be on the training dataset?" or "is it a task that can be solved as a language problem?"

  • source
  • parent
  • [–] 21 points 1 year ago (2 children)

    Reading the paper, AI did a lot better than I would expect. It showed experienced devs working on a familiar code base got 19% slower. It's telling that they thought they had been more productive, but the result was not that bad tbh.

    I wish we had similar research for experienced devs on unfamiliar code bases, or for inexperienced devs, but those would probably be much harder to measure.

  • source
  • hideshow 4 child comments
  • [–] 17 points 1 year ago (2 children)

    I don't understand your point. How is it good that the developers thought they were faster? Does that imply anything at all in LLMs' favour? IMO that makes the situation worse because we're not only fighting inefficiency, but delusion.

    20% slower is substantial. Imagine the effect on the economy if 20% of all output was discarded (or more accurately, spent using electricity).

  • source
  • parent
  • hideshow 3 child comments
  • load more comments (1 reply)
  • [–] 21 points 1 year ago* (last edited 1 year ago) (2 children)

    Don’t give yourselves to these unnatural men - machine men with machine minds and machine hearts! You are not machines! You are men!

  • source
  • hideshow 3 child comments
  • [–] 4 points 1 year ago (1 child)

    You are not cattle!

    You are men!

    You have the love of humanity in your hearts!

    You don’t hate!

    Only the unloved hate - the unloved and the unnatural!

    Soldiers!

    Don’t fight for slavery! Fight for liberty!

    In the 17th Chapter of St Luke it is written: “the Kingdom of God is within man” - not one man nor a group of men, but in all men!

    In you!

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (1 reply)
    [–] 12 points 1 year ago

    Would ai coders even get faster over time or just stay stagnant since they aren't learning anything about what they're doing

  • source
  • [–] 10 points 1 year ago (1 child)

    People are a bad judge of their own skill and overrely on tools and assistants when present. See also: car adas systems making drivers less skillful. More news at 11.

  • source
  • hideshow 2 child comments
  • [–] 3 points 1 year ago

    See also: car adas systems making drivers less skillful.

    But also making traffic safer

    Think we need to introduce a mandatory period where you need to drive an old car with no ABS when you've just gotten your license. I mean for me that was called being a broke-ass student, but nowadays cars with no ABS are starting to cost more than cars with ABS, traction control and even ESP, because the 80s and early 90s cars where these things were optional, are now classics, whereas you can get a BMW or Audi that was made this century for like 500-800 euros if you're brave or just want to move in to your garage full time.

  • source
  • parent
  • [–] 9 points 1 year ago (1 child)

    Now the interesting question is what it really means when less experienced programmers think they are 100% faster.

  • source
  • hideshow 2 child comments
  • [–] 8 points 1 year ago (6 children)

    Someone told me the best use of AI was writing unit tests and I died on the inside.

  • source
  • hideshow 6 child comments
  • load more comments (6 replies)
    [–] 6 points 1 year ago (4 children)

    🎵Had a great day out,

    Callin' my name like Ferris Bueller,

    Time to wrap this up,

    I'm getting 19℅ slower! 🎵

  • source
  • hideshow 5 child comments
  • load more comments (3 replies)
    [–] 6 points 1 year ago (1 child)

    The only time it really helps me is when I'm following a pretty clear pattern and the auto-complete spares me from copy-pasting or just retyping the same thing over and over. Otherwise I'm double-checking everything it wrote, and I have to understand it to test it, and that probably takes most of my time. Furthermore, it usually doesn't take the entire codebase into account so it looks like it was written by someone who didn't know our team or company standards as well as our proprietary code.

  • source
  • hideshow 2 child comments
  • [–] 3 points 1 year ago

    If there's a clear pattern, regex is your friend. I use it for complex find-and-replace actions, or to generate code based on a template and a list of values (find a value, replace it with the template including the value). Full control over the output, more reliable even than manual copy-pasting.

  • source
  • parent
  • [+] 4 points 1 year ago* (last edited 9 months ago)
    load more comments
    view more: next ›