WordPress

728 readers

1 users here now

A place to talk about WordPress the open source content management system. Also a place to ask for help with WordPress. Don't be rude, don't spam.

I check this once a week, so if you don't hear from me hit me up on Mastodon ([email protected])

founded 2 years ago

MODERATORS

[email protected]

Boss is "vibe coding" (lemmy.world)

submitted 1 week ago by [email protected] to c/[email protected]

24 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 week ago (1 children)

Time to change to rebase only workflow. Easy reverts.

[–] [email protected] 2 points 1 week ago (1 children)

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?

[–] [email protected] 4 points 1 week 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 :).