• justgohomealready@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    19 days ago

    The variable you’re missing is time. There was a big shift in quality by Christmas, and the latest models are much better programmers than models from one year ago. The quality is improving so fast, that most people still think of AI as a “slop generator”, when it can actually write good code and find real bugs and secutity issues now.

    • Zangoose@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      19 days ago

      As someone who has to sift through other people’s LLM code every day at my job I can confirm it has definitely not gotten better in the past three months

      • TrippinMallard@lemmy.ml
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        19 days ago

        We require you to submit markdown plan before working on a feature, which must have full context, scope, implementation details. Also verification tests mardown file of happy path and critical failure modes that would affect customer, and how tests were performed. Must be checked in with the commit. More complex, large features require UML diagrams of architecture, sequences, etc. to be checked in too.

        If your plan or verification docs have wrong context, missing obvious implementation flaws, bad coupling, architecture, interfaces, boundary conditions, missing test cases, etc then PR rejected.

        Every developer’s performance is judged as a systems engineer. Thoughtless features without systems docs and continued lack of improvement in your systems thinking gets you PIPed.

        • Zangoose@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          18 days ago

          That’s the thing though. Even if the code is good, the plans are good, the outputs are good, etc, it still devolves into chaos after some time.

          If you use AI to generate a bunch of code you then don’t internalize it as if you wrote it. You miss out on reuse patterns and implementation details which are harder to catch in review than they are in implementation. Additionally, you don’t have anyone who knows the code like the back of their hand because (even if supervised) a person didn’t write the code, they just looked over it for correctness, and maybe modified it a little bit.

          It’s the same reason why sometimes handwritten notes can be better for learning than typed notes. Yeah one is faster, but the intentionality of slowing down and paying attention to little details goes a long way making code last longer.

          There’s maybe something to be said about using LLMs as a sort of sanity check code reviewer to catch minor mistakes before passing it on to a real human for actual review, but I definitely see it as harmful for anything actually “generative”

          • Everyday0764@lemmy.zip
            link
            fedilink
            English
            arrow-up
            0
            ·
            17 days ago

            at least in my team, we already way past the tipping point, no one knows what the code does, and trying get you called “slow”