zlacker

>>namany+(OP)
It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.

>>bandra+s01
sorry, what do you mean?

>>misiti+011
1. Enthusiastic employee (vibe-)codes a replacement for a turnkey SaaS product that the company uses.

2. Company uses it, maybe even starts to rely on it for important business operations, and for a time the employee supports that app.

3. Bugs creep in, feature request pile up.

4. Employee either leaves the company or moves on to another project.

5. Pain

>>sbarre+F11
I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.

>>pverhe+c91
The thing about lower barriers is that it makes it easier for e.g. Salesforce to raise the level of expectations. And that's the moving target. New employees will come from elsewhere and wonder how a company is operating using tools from 2020 when X, Y, Z are becoming industry standard.

The key here is that the moving target will _never_ be "what can 1-2 people vibe code without any expectation of being the best at what it does?"

(Also: training people on bespoke tools takes much longer than training on configurations of standard tools. Imagine if you had to learn a new source control system at every job, like in the '80s.)