• SugarCatDestroyer@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    5 minutes ago

    It’s hard to even call them specialists, they are at the level of cashiers, for whom the computer does everything, and sometimes they do something at the level of communicating with clients and that’s all. I’m certainly not a professional, but I think the main message is clear.

  • Cyberflunk@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    14 minutes ago

    My velocity has taken an unreasonable rocket trajectory. Deploying internal tooling, agent creation, automation. I have teams/swarms that tackle so many things, and do it well. I understand there are issues, but learning how to use the tools is critical to improving performance, blindly expecting the tools to be sci-fi super coders is unrealistic.

  • Scrath@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    17
    arrow-down
    1
    ·
    7 hours ago

    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

    • Senal@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      3 hours 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 tag the whole thing to find out.

    • rozodru@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      4 hours ago

      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.

      • Croquette@sh.itjust.works
        link
        fedilink
        arrow-up
        9
        arrow-down
        1
        ·
        3 hours ago

        LLM are just sophisticated text predictions engine. They don’t know anything, so they can’t produce an “I don’t know” because they can always generate a text prediction and they can’t think.

        • Cyberflunk@lemmy.world
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          12 minutes ago

          Tool use, reasoning, chain of thought, those are the things that set llm systems apart. While you are correct in the most basic sense, it’s like saying a car is only a platform with wheels, it’s reductive of the capabilities

  • _cnt0@sh.itjust.works
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    16 hours ago

    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.

  • Arghblarg@lemmy.ca
    link
    fedilink
    arrow-up
    54
    arrow-down
    1
    ·
    20 hours ago

    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.

    • Rose@slrpnk.net
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 hour 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…!”
      🎶

  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    15 hours ago

    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.

  • Phen@lemmy.eco.br
    link
    fedilink
    arrow-up
    17
    ·
    19 hours ago

    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.

    • staircase@programming.dev
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      13 hours ago

      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).

  • daniskarma@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    29
    arrow-down
    6
    ·
    edit-2
    21 hours ago

    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.

    • 6nk06@sh.itjust.works
      link
      fedilink
      arrow-up
      33
      ·
      20 hours ago

      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.

      • daniskarma@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        20 hours ago

        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.

        • Zos_Kia@lemmynsfw.com
          link
          fedilink
          arrow-up
          5
          ·
          19 hours ago

          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.

          • justastranger@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            ·
            3 hours 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.

    • Feyd@programming.dev
      link
      fedilink
      arrow-up
      16
      arrow-down
      1
      ·
      20 hours ago

      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.

      • daniskarma@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        20 hours 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?”

  • WoodScientist@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    2
    ·
    edit-2
    21 hours ago

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

    • FizzyOrange@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      2 hours ago

      Why? That is a great use for AI. I’m guessing you are imagining that people are just blindly asking for unit tests and not even reading the results? Obviously don’t do that.

      • resipsaloquitur@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        31 minutes ago

        Of course that’s what they’re doing. That’s the whole point. Generate a bunch of plausible-looking BS and move on.

        Writing one UT (actually writing, not pressing tab) gives you ideas for other tests.

        And unit tests are not some boring chore. When doing TDD, they help inform and guide the design. If the LLM is doing that thinking for you, too, you’re just flying blind. “Yeah, that looks about right.”

        Can’t wait for this shit to show up in medical devices.

  • monkeyman512@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    21 hours ago

    It would be interesting to see another study focusing on cognitive load. Maybe the AI let’s you offload some amount of thinking so you reserve that energy for things it’s bad at. But I could see how that would potentially be a wash as you need to clearly specify your requirements in the prompt, which is a different cognitive load.

    • SpaceNoodle@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      19 hours ago

      I seem to recall a separate study showing that it just encouraged users to think more lazily, not more critically.

  • Ek-Hou-Van-Braai@piefed.social
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    5
    ·
    20 hours ago

    I wish AI was never invented, but surely this isn’t ture.

    I’ve been able to solve coding issues that usually took me hours in minutes.

    Wish it wasn’t so, but it’s been my reality

        • vrighter@discuss.tchncs.de
          link
          fedilink
          arrow-up
          4
          ·
          7 hours ago

          yes they can. I regularly do. Regexes aren’t hard to write, their logic is quite simple. They’re hard to read, yes, but they are almost always one-offs (ex, substitutions in nvim).

            • vrighter@discuss.tchncs.de
              link
              fedilink
              arrow-up
              2
              arrow-down
              1
              ·
              2 hours ago

              yes, “complex” regexes are quite simple too. Complex regexes are long, not difficult. They appear complex because you have to “inline” everything. They really are not that hard.

                • vrighter@discuss.tchncs.de
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 minutes ago

                  cryptic != complex. Are they cryptic? yes. Are they complex? not really, if you can understand “one or more” or “zero or more” and some other really simple concepts like “one of these” or “not one of these” or “this is optional”. You could explain these to a child. It’s only because they look cryptic that people think they are complex. Unless you start using backreferences and advanced concepts like those (which are not usually needed in most cases) they are very simple. long != complex

        • TehPers@beehaw.org
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          4 hours ago

          Depends on what you need to match. Regex is just another programming language. It’s more declarative than traditional languages though (it’s basically pattern matching).

          Pattern matching is something I already do a lot of in my code, so regexes aren’t that much different.

          Regardless, the syntax sucks. It takes some time to get familiar with it, but once you get past that, it’s really simple.

            • vrighter@discuss.tchncs.de
              link
              fedilink
              arrow-up
              2
              ·
              3 hours ago

              tests can never prove correctness of code. All they can prove is “the thing hasn’t failed yet”. Proper reasoning is always needed if you want a guarantee.

              If you had the llm write the regex for you, I can practically guarantee that you won’t think of, and write tests for, all the edge cases.

          • Ek-Hou-Van-Braai@piefed.social
            link
            fedilink
            English
            arrow-up
            3
            ·
            8 hours ago

            No, but not everyone is a regex guru.

            If AI can write code half as good and fast as a regex guru, it’s going to increase the average dev’s productivity a lot

            • vrighter@discuss.tchncs.de
              link
              fedilink
              arrow-up
              2
              ·
              3 hours ago

              does the regex search for what you wanted to? Does it work in all cases? Can I be confident that it will find all instances i care about, or will I still have to comb the code manually?

  • rizzothesmall@sh.itjust.works
    link
    fedilink
    arrow-up
    9
    arrow-down
    15
    ·
    edit-2
    22 hours ago

    Ai-only vibe coders. As a development manager I can tell you that AI-augmented actual developers who know how to write software and what good and bad code looks like are unquestionably faster. GitHub Copilot makes creating a suite of unit tests and documentation for a class take very little time.

      • kinttach@lemmy.zip
        link
        fedilink
        arrow-up
        6
        arrow-down
        3
        ·
        21 hours ago

        The article is a blog post summarizing the actual research. The researchers’ summary says:

        We do not provide evidence that: AI systems do not currently speed up many or most software developers. We do not claim that our developers or repositories represent a majority or plurality of software development work.

        The research shows that under their tested scenario and assumptions, devs were less productive.

        The takeaway from this study is to measure and benchmark what’s important to your team. However many development teams have been doing that, albeit not in a formal study format, and finding AI improves productivity. It is not (only) “vibe productivity”.

        And certainly I agree with the person you replied to: anecdotally, AI makes my devs more productive by cutting out the most grindy parts, like writing mocks for tests or getting that last missing coverage corner. So we have some measuring and validation to do.

        • SpaceNoodle@lemmy.world
          link
          fedilink
          arrow-up
          9
          ·
          edit-2
          20 hours ago

          The research explicitly showed that the anecdotes were flawed, and that actual measured productivity was the inverse of what the users imagined. That’s the entire point. You’re just saying “nuh uh, muh anecdotes.”

      • rizzothesmall@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        arrow-down
        7
        ·
        edit-2
        21 hours ago

        I did, thank you. Terms therein like “they spend more time prompting the AI” genuinely do not apply to a code copilot, like the one provided by GitHub, because it infers its prompt based on what you’re doing and the context of the file and application and creates an autocomplete based on its chat completion, which you can accept or ignore like any autocomplete.

        You can start writing test templates and it will fill them out for you, and then write the next tests based on the inputs of your methods and the imports in the test class. You can write a whole class without any copilot usage and then start writing the xmldocs and it will autocomplete them for you based on work you already did. Try it for yourself if you haven’t already, it’s pretty useful.

      • sturlabragason@lemmy.world
        link
        fedilink
        arrow-up
        4
        arrow-down
        7
        ·
        edit-2
        21 hours ago

        I read the article (not the study only the abstract) and they were getting paid an hourly rate. It did not mention anything about whether or not they had expirence in using llms to code. I feel there is a sweet spot, has to do with context window size etc.

        I was not consistently better a year and a half ago but now i know the limits caveats and methods.

        I think this is a very difficult thing to quantify but haters gonna latch on to this, same as the study that said “ai makes you stupid” and “llms cant reason”… its a cool tool that has limits.

        • oantolin@discuss.online
          link
          fedilink
          arrow-up
          9
          ·
          20 hours ago

          One interesting feature in this paper is that the programmers who used LLMs thought they were faster, they estimated it was saving about 20% of the time it would have taken without LLMs. I think that’s a clear sign that you shouldn’t trust your gut about how much time LLMs save you, you should definitely try to measure it.

          • sturlabragason@lemmy.world
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            19 hours ago

            The study did find a correlation between prior experience and performance. One of the developers who showed a positive speedup with AI was the one with the most previous experience using Cursor (over 50 hours).