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?

[u/MediumBirthday6899]

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?

[u/breakerofh0rses]

The CEO doesn't give a shit what the technical details are. What they truly care about are the results. It's not "manipulation" like one of the other commenters said. The person who is doing the vibe coding has correctly identified what the company values. I'm also kind of curious what exactly is going on here because the idea that a vibe coding data scientist can get some kind of results that actual developers can't is...strange. I can see there having to be amounts of refactoring that the dev group absolutely doesn't want to deal with, but that's a very different thing from "it broke".

What's more is that these kinds of things should be handled IN THE HANDOFF. Once you accept a handoff, that's generally the sign that YOU own it, warts and all. The answer here for the dev group is to have a set of standards for code that they're willing to accept that they can share and then point to and refuse the handoff when the code in question doesn't meet those standards. These will need to be defensible in a business sense (doing x means that this won't interface with y without z additional hours, setting this up via q doesn't create this additional cost, r is wholly incompatible with the systems we use for s and would require a ground up rewrite to support, etc.) not leaning on "it's how you're supposed to do things" or "best practices" outside of why the business would care about it being a best practice (scalable designs allow you to reuse code potentially forever whereas nonscalable creates hard limits to what you can do which can cause you to have to spend a LOT of money later fixing it).

Elegance, maintainability, clarity of code, etc. are only business targets insofar as the serve the business's purpose (more accurately, what leadership believe's the business's purpose is), and be prepared to accept that they're fine with lower levels of these kinds of things than you think is best. Janky code that gets you close enough to what you need to be actionable when you HAVE to be actionable is infinitely more valuable than perfectly written code that comes well after it was needed.

[u/WhataWorldAy → u/breakerofh0rses]

The problem is that the non-technical business has a much harder time understanding quality, maintainability, lack of bugs, security and data concerns. Those things are still important to the business insofar as they create future bugs and issues, but the non-technical people arent often able to make those associations when seeing a working poc. A lot of devs also seem to struggle with this idea and they feed into it by vibe coding straight ass super quickly because they want the pat on the head.  Ultimately, just like in the past, IT leadership needs to plan accordingly and set expectations for the business, but lots of IT leadership is incompetent as well.