• ianhclark510@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    21
    ·
    5 days ago

    “We’re going faster by passing the slow part (the reading, the actual understanding) to whoever comes next”

    sounds like my boss, no docs, no procedure XD

  • Pika@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    5 days ago

    This article I think shares my thoughts on it, Arguably I don’t know if the devs even got faster… Like its a nice resource but, there’s so much trial and error involved now, and every prompt now requires essentially relearning a new codebank.

    Like sure immediate result got faster… but you lose all that with the extended time taken learning how it works and why it works.

    • elephantium@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      5 days ago

      I work as a glorified code monkey. It feels faster, sort of, in fits and starts.

      When I start working on a task, the AI tooling almost feels like it’s doing the job for me. It picks out the relevant part of the code base, makes changes in the right places, and even updates tests.

      Assuming that part all went well, the waiting game begins.

      Either run the “git” AI prompt or do it by hand. The prompt way has some nice bells and whistles in how it formats commit messages , but

      It’s

      Just

      So

      Slow!

      Then, either way, my commit goes. Now I wait for the auto build and test pipeline, the code scanner job, and copilot’s review pass. Sometimes it brings up helpful things, sometimes it raises silly objections.

      Then, ok, I think it looks good. I need approval from a busy coworker to actually click merge, so I send a link to the chat and hope someone isn’t too busy.

      Once I get that approval, it’s wait again for a build agent to deploy my changes.

      Now, hours later (sometimes the next day), I can load it up and see my change reflected in our test environment.

      The wheels sure are spinning, but I can’t say for sure that we’re going any faster.

      • ranzispa@mander.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        5 days ago

        I can assure I work much faster. Maybe it is a bit different since I work in research and that’s indeed different from working on a large established codebase. Most of my projects are greenfield.

        However, recently using Claude code I started many different projects I’d never have approached since I knew it would have taken me months to complete correctly. We are talking about porting file format readers and writers to new languages, then implementing novel algorithms to process such data and optimize it to work on different GPU architectures. Getting a working software takes about a week of work. A publishable cleaned up codebase 2/3 weeks. No way I could do this myself alone in such span of time.

        On the other hand, I have students working with me, using AI is definitely not helping them to learn how to code and how to reason. In several occasions I had them showing me a novel huge equation which apparently worked, but then looking at it properly was just over fitting data and they had no way to explain why such an equation should be used.

  • tailiat@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    5 days ago

    Inevitable conclusion: “Ah, reading the code is expensive. It’s probably fine to trust it, right???”

  • MangoCats@feddit.it
    link
    fedilink
    English
    arrow-up
    3
    ·
    5 days ago

    What I have found is: if the AI operator cares, they can tell it to make the instructions, or summary, or whatever it is, whatever length they want it to be. Just summarize the most important parts to half a page, or go into extreme depth on every section. Target 300-400 words, or 3500-4000… whatever you feel is appropriate for the topic and the target audience.

    Not strictly about AI, when I write something explaining something technical for my manager (who is technical and can understand it all, but rarely has the time to) what I often find myself doing is getting to the end, then going back and writing a 25 words or less summarization of what he actually wants to know to communicate this up the line to his managers - then leaving the 3-5 pages of technical regurgitation of details that led me to that conclusion as reference for the one or two little details he’ll possibly be interested in for his own curiosity.

    The problem I have with short instructions is: you never know what details you’re leaving out that are going to matter in the future until people start using your instructions and making bad assumptions because you didn’t over-emphasize a point - like: writing an instruction that says “accept all the defaults” - well, apparently our colleagues in the overseas office weren’t capable of following that particular instruction without an additional big bold NOTE: hitting them over the head to emphasize: no, really, you’re going to regret all the extra work you have to do if you don’t accept the default options.

    It’s an iterative process, and should be the same whether or not you’re using an AI agent to do the writing for you. Try, fail. Try again, fail again, fail better next time.

  • HubertManne@piefed.social
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 days ago

    Nights of winter turn me cold
    Fears of dying, getting old
    We ran the race, the race was won
    By running slowly