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 don’t have the code in git or something? Let him vibe code on his own local branch
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.
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.
Genius 😂
This guy 🫡
Just don’t let him mess with main at all…
Time to change to rebase only workflow. Easy reverts.
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?
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 :).
Do you have source control? Constraint it to testing branches, read, test, and check before letting stuff go into production.
So just the regular workflow.
Ask about security concerns of feeding your proprietary code to an AI where it will be used for training data.
They likely don’t care.
Better way to phrase it is ‘Had legal signed off on allowing our IP and confidential data to be sent to AiProvider?’
You’re dead right that they don’t care! Unfortunately we don’t have a legal dept but not a bad shout on the confidential parts…
If possible create local backups from before he let AI go loose. Likewise, save local copies of all of your commits and document all of your commits thoroughly. This way when things start breaking in the future you have documentation that shows that you didn’t submit faulty code, and if the AI changes your work you have proof of what you did. Additionally if it manages to truly break something you get to be the hero and save the project
If you want to go the extra mile I’d pay attention to what your boss submits and either clean it up behind him, or log all of the issues and errors. Option 1 keeps them happy without breaking anything, option 2 lets you make a presentation and argument that vibe coding is bad practice
Generally just add some more work into your general “cover your ass” activities. Alternatively you could gather evidence of the dangers of vibe coding, present your case to your boss, and hope he realizes it’s a bad idea. But this is lemmy and I know we’re not a confrontational bunch
I would save a local version of the code from before his AI bullshit, and get paid handsomely later to just copy and paste old unshitty code in to fix problems.
Assuming he owns the place, not much you can do. Definitely keep your code in version control, or at a bare minimum back it up with an automated script or something.
If he doesn’t own the place, going over their head is an option but a bad one for your longevity at the business.
I’d say let em do what they want and revert it if you don’t like it. You guys could talk about starting to enforce pull requests as the only mechanism of getting into prod, then your dev team will have a chance to review every line before they go into prod
Hopefully you backed it up.
Assuming he’s just a middle manager, just express your polite disagreement everytime it makes sense by writing in a way that will cover your butt when shit eventually hits the fan and higher ups step in. If he’s the head of the company, maybe you should spend teaching time with him to avoid losing your job when the company fails.
Unfortunately it’s a small agency, so him and the big boss work in tandem. They’ve both hauled me into meeting already about how I need to be more positive about AI 😂
“I am positive that AI will break shit.”
You have git, let him break it all and then just revert. Pain is a great teacher, it’s why I don’t touch fire as often as I’d like.
Do you have backups?
We’ve got it all on git
Good
