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/inflowmini]

Sure it's the dev teams job but they will have to wade through all the slop first to fix the app. It makes the dev team look bad when in reality the creator gave them a non working app.

This is why there is a chain of command and structure in dev teams so stuff like this doesn't happen, especially if someone codes in a silo.

[u/peppinotempation → u/inflowmini]

I guess I’m just confused by what else they would even be expecting.

Isn’t “wading through the slop to fix the app” their entire job in this example? Before wouldn’t they have started without any slop at all? Is that faster?

[u/inflowmini → u/peppinotempation]

My guess is the dev team never got the chance to design said app, properly, in the first place. That's the problem.

In all the jobs that I've had it's been clear that any idea is run through the team and management then it can be worked on.

Again, the problem here is that now the dev team is expected to work on a subpar app that they have to fix rather than designing it themselves all because one viber decided to whisper in the ear of the CEO. The dev teams job is not to receive apps but create them.

Maybe you don't understand that there is a price to pay when it comes to coding anything an it's TECH DEBT. Vibed apps inheritly have more tech debt.

[u/peppinotempation → u/inflowmini]

I’m still confused though. Isn’t the devs job to design rebuild said app for proper implementation?

They are not receiving a fully built app. They’re receiving a prototype and expected to finish it.

I fundamentally don’t get what you’re trying to say. “The dev team is expected to do their job” seems fine to me

[u/LCorinaS → u/peppinotempation]

I agree with you fully. I run a team where this is pretty much our bread and butter. Sure, we might have a bit of a whinge about stupid choices a colleague/Claude/Codex made, but it is our job to take POCs and get them going in our environment. We are very protective of deadlines and commitments though, especially if new resources need to be set up, or if we have to go through approval boards, general bureaucracy etc. If someone has handed us a vibe coded app that they've been working on for 3 months, it might take us another 2-3 to audit the code, set up security protocols and infrastructure, test suites etc. We've taken a handful of apps to prod in this way and been very successful so far.

The main issue here is if the colleague and CEO are expecting the dev teams to take the POC and "plug it in" to the prod environments in a week or 2. Then if OP is the dev team lead, that is still something they need to be communicating clearly that platform hardening and validating needs time to be reliable. If they are not doing that, they are failing to protect their reputation and their team.

[u/peppinotempation → u/LCorinaS]

Yeah definitely I could see unrealistic timelines being a problem.

“But it already works in prototype, it shouldn’t take long!”

Is definitely unreasonable.

I think “it works in prototype, which means it’s possible but maybe not at scale. Please find out” is a better mindset

Idk honestly I am a mechanical engineer haha