Live data from Hacker News

Ask HN: Client took over development by vibe coding. What to do?

news.ycombinator.com

41–50 of 57 posts

Re: Ask HN: Client took over development by vibe coding. What to do?

#42
I enjoyed reading this post, because it's a great little case study. A Large complicated project, a senior dev, and a nieve client. It's their project so they can push all the code they want, but they're responsible for it too. I'd be curious to learn of any updates.

Re: Ask HN: Client took over development by vibe coding. What to do?

#43
Honestly the leverage you have is the parts they can't vibe code. I mean DevOps, architecture decisions, anything that breaks quietly in production. i'd focus there and let them find out the hard way what happens when nobody understands the system they're shipping.

The joy thing is real, though. once a client stops trusting your judgment, the relationship is already broken. sometimes the right move is to document everything clearly, hand it over properly, and walk away before it becomes your reputation on the line. I'd like to know more opinions on this

Re: Ask HN: Client took over development by vibe coding. What to do?

#44
I think this is inevitable, and I'm trying to find ways to set up a controlled environment, in which we build a robust safe and isolated foundation, while clients can mess around and vibe-code their features on top of that. I'm still figuring it out so feel free to share ideas.

Re: Ask HN: Client took over development by vibe coding. What to do?

#45

I think this is inevitable, and I'm trying to find ways to set up a controlled environment, in which we build a robust safe and isolated foundation, while clients can mess around and vibe-code their features on top of that. I'm still figuring it out so feel free to share ideas.

Why would a standard git flow not work? They can vide code whatever they want, just review it before it is merged.

Re: Ask HN: Client took over development by vibe coding. What to do?

#46
Non-coders often think all engineers do is write code. They don't realize how much more hours are spent on making sure the code we write is correct, from many angles. Functional bugs? Easy to maintain? Cost optimized? Meets user expectations?

When they have a machine that cranks out code, and honestly pretty good code, they think it's the same thing.

Eventually though I suspect many people will discover what many studies over many decades have shown: the most expensive part of software is maintenance.

This will eventually be the problem for your client. If I were in your shoes, I'd probably start laying the foundation for that. If they're willing to bear the cost, then fine. If not, then ultimately you're set up for a clean exit when you can no longer get the software to run as they want in a timely fashion.

Re: Ask HN: Client took over development by vibe coding. What to do?

#47
I had a similar experience back when I was a web dev (in the early days of the web's growing popularity) and some clients would cancel a website project because their teen told them they could do it for them much cheaper with DreamWeaver or MS Word.

Several folks here suggest doing exactly what I did back then, and truth be told, it'll likely work today just as well as it did back then. Tell the customer straight up why it's a bad idea (just be honest and forthright here), and make clear that you'll be charging extra for the very much different skill of cleanup and debugging the "tag soup" garbage that DreamWeaver (or in this case "vibe coding") will produce when it inevitably fails to deliver the result they'd hoped for.

Then step back and find other work while you wait for the windfall as your prediction plays out exactly as you warned them it would. If it doesn't, then "good for them". Be happy for them that they're happy, and be happy for yourself that you found other (less stressful) work. Win-win, either way? Either way, you're working, they're happy with (or at least getting) their hoped-for result, and nobody's stuck with something they didn't really want (other than perhaps your inflated rate for blithely altering the scope of your task).

Fact is that they're paying you for your expertise, and if they choose to ignore that expertise when it really matters, it should cost them to access more valuable expertise when it comes time.

Post reply on HN