My boss thinks it’s very cute to talk about AI as much as possible, and today asked if I’d heard of “vibe coding”. I said yeah, and explained to my coworker that it’s where you get a chatbot to write all your code.

My boss has just announced that he’s vibe coding. I know the project he’s working on. It took us months to put that codebase together, and there are a lot of very complex functions and plugins in that site that we’ve written to integrate with all the systems our client needs the site to use.

What am I supposed to do here? He’s just letting a chatbot go rogue on the codebase. Do I just leave him to it with the full knowledge that it’ll fall on me and my colleague to repair all this damage, presumably while being accused of breaking the site in the first place? I need the money from this job so unfortunately leaving isn’t an option at this stage.

  • Rayquetzalcoatl@lemmy.worldOPEnglish
    5·
    9 days ago

    We do have it on git, after long insistence on my part, but it’s just a pain in the arse having to undo all of what he’ll merge into main.

    • TragicNotCute@lemmy.worldEnglish
      40·
      9 days ago

      Get really excited about vibe coding and tell your boss it works better if you make an AI specific branch. Toss main branch protections in and you’ve basically given your little brother an unplugged controller to play with.

      • Ephera@lemmy.ml
        English
        3·
        9 days ago

        Oh, what the heck. We’ve always worked rebase-only, so it never occurred to me that with merges you can’t just check out a past commit and have it actually be the state of the project that it was back then…? Is that right?

        If so, why does anyone work with merges?

        • dream_weasel@sh.itjust.works
          4·
          9 days ago

          So you can get the exact state at any commit, that still works. The problem really is that the merge commit itself contains the changes necessary to resolve conflicts between branches being merged, and may also include reviewer changes or who knows what.

          Some people like it because it is more like the “real” history of your project; however it can make reversion of atomic changes much more difficult because the “atoms” in the final project may belong to more than one commit. It also makes the history pretty hard to follow on my opinion. I think it also opens the door to craziness like people having self-merges in their own branches because they didn’t keep server code and local code for their branch in sync, though CI/CD might catch that… I never had an automated review process at work.

          There is probably a time and a place, like when you’re literally combining projects, but for fixes and features I don’t agree.

          I learned git working with students, and I need shit to be easy to follow and easy to revert. Hence atomic commits only and linear history :).

OSZAR »