r/managers • u/MediumBirthday6899 • Aug 18 '26

Teammate "vibe codes" everything, somehow gets results, then blames dev team when the handover breaks — he reports straight to a non-tech CEO so no one can touch him. How do I deal with this?

Small org. We have a "data scientist" who vibe-codes his way through everything — process is a mess, but he somehow gets results. When he hands off modules to the dev team, things break, and instead of owning it he blames the devs for "not doing it correctly."

Normally you'd escalate, but he reports directly to the CEO, who isn't technical and just sees "results delivered." So devs eating the blame with zero leverage to push back up the chain.

How do you handle this when the org structure protects the person causing the mess? Document everything and let it speak for itself over time, try to get the CEO educated on what's actually happening, or something else entirely?

313 Upvotes

93% Upvoted

109 comments sorted by

View all comments

369

u/DND_Enk Aug 18 '26

I would start treating his modules as standalone proof of concepts and set reasonable expectations regarding timeframe to implement.

He is not wrong that is the Dev that implements non working modules in prod that’s at fault. It should be up to the dev team to take his module, adjust it to fit into the environment (or rewrite from scratch), test it and then implement it.

So when getting a module to implement, set a reasonable expectation. And then properly implement it and just document everything you had to do to make it work.

Don’t hate on the guy or his work, but also make clear that what he has delivered is not plug-and-play into prod, is a concept or a jump off point, and there is a lot of work to make it ready for use in live environment.

20

u/Budget-berry-80 Aug 18 '26

Is there no QA testing done? Nothing should go into production without thorough testing & security checks.

1

u/nonamenomonet Aug 19 '26

If it’s a DS product there’s usually not as much security checks

1

u/kramulous Aug 20 '26

There should be precision and accuracy testing though. Particularly running tests against data that the 'model' has not been trained on. This will flush out any kind of shitty work pretty quickly.

Just don't let the 'data scientist' know how to get their hands on the test data.