• hperrin@lemmy.caEnglish
    4·
    3 天前

    Even if it does write code that works, it usually (about 50% of the time in my experience) has bugs, and sometimes those bugs can be really difficult to spot. For me, it has never saved me any time. I’m either fixing something it doesn’t know how to do correctly, or going over its code with a fine tooth comb because when it says, “this is production ready code, with no bugs,” it’s usually wrong. That takes a lot of time. It’s easier for me to just write the code correctly myself.

    Admittedly, I haven’t used that new model that Anthropic revoked access to the public to recently. Maybe that one is good enough for government work.

    • Lovable Sidekick@lemmy.worldEnglish
      2·
      3 天前

      When I first tried it I felt lost, but after watching a couple videos about writing good prompts I had no trouble getting it to produce perfectly good code that did what I wanted. Your mileage may vary.

      • x74sys@programming.dev
        3·
        3 天前

        Honestly, I think what you consider „good code“ is just shifted from what the previous commenter considers „good code“. Prompting is about giving enough information so the AI can solve the task without needing to reconstruct a lot of context. Most people using AI somewhat regularly will have figured out to write good enough prompts. I‘ve never seen AI generate perfectly good code beyond hello world and the fibonacci sequence. And by perfectly good I mean I wouldn’t change beyond 30% of what it produces, which is not a high bar.

    • toofpic@lemmy.world
      1·
      3 天前

      Fable was “just ask and get it done” quality level, but really I don’t get THAT much bugs - about the same amount that I see irl developers do: get a new feature, find 5 problems, get them fixed, find one more, done. As a recommendation - try to alleviate the biggest problems that ai models have:

      • overconfidence - skipping wrong stuff “because they have a note saved that it works” or losing the point where they stopped after a session broke, then making things up. Test Driven Development solves the majority of problems like that - when Claude writes tests first, then it’s not able to bullshit me that the job is done when “everything is red”
      • even with large contexts, they run out and stuff gets lost. So if you’re not doing something really compact, make your ai document everything, document the feature they are working on now, make it then offload it to permanent doc when that piece is finished. When the ai will fuck up next time, you can tell it to “go read some docs” and most of the times it will work
      • hperrin@lemmy.caEnglish
        3·
        2 天前

        I’m glad it works for you, but it simply does not work for me. Maybe you could try yourself on some of my libraries, because I have never gotten it to save me any time. It’s just spending money and making the work less fun for no reason. Oh, also not having the copyrights to the things that go in my code base, don’t forget that.