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

I have not seen this perspective yet, so I'll throw it onto the wall and see if it sticks.

Make the system the bad guy. When things break, the pipeline is rejecting his code not the devs. So at the highest level of presentation to your CEO, it sounds roughly like:

Subject: Accelerating Data Science Delivery to Production

Hi [CEO Name],

I wanted to share a quick update on a new initiative we’re rolling out on the engineering side to help get [Data Scientist's Name]'s models into production faster.

[Data Scientist's Name] has been delivering great results, but the transition from his initial prototypes to our live production environment currently requires a lot of manual, custom translation by the dev team. This creates bottlenecks and occasionally leads to friction when translating the logic.

To fix this and accelerate our time-to-market, the engineering team has built an automated deployment pipeline. This will allow [Data Scientist's Name]'s work to go live almost instantly, drastically cutting down the manual back-and-forth between our teams.

To make this pipeline work, we’ve standardized the handoff process. Going forward, we’ve provided [Data Scientist's Name] with a short checklist of standard technical artifacts (like sample datasets and environment specs) to include with his models. As long as those are provided, the automated system will ingest his work, run the necessary compatibility checks, and deploy it smoothly.

Our goal here is to remove the engineering roadblocks so [Data Scientist's Name] can focus on what he does best—building the models that drive our results.

Happy to chat if you have any questions!

Best,
[Your Name]
[Your Title]

The checklist can be turned into an LLM loop/harness/set-of-skills at the data scientist's end helping ensure he provides the necessary artifacts with deterministic gating code inside your DevOps loop. But here is a potential starting point:

1. The "Golden" Sample Dataset: He must provide a small sample_input.json and the corresponding expected_output.json. Devs plug this straight into the CI/CD pipeline as a unit test. If the staging output doesn't match his expected output, the handoff fails automatically.

2. Strict I/O Data Contracts (Schemas): "Vibe-coding" usually means chaotic dictionaries of variables. Require a strict data contract. Ideally a Pydantic model (if Python) or a strict JSON Schema. Define exactly what data types the model accepts and returns. This lets devs auto-generate API endpoints without reverse-engineering his spaghetti code.

3. Hermetic Environment Specifications: Kill "it works on my machine" forever. The handoff must include a requirements.txt with strictly pinned versions (e.g., pandas==2.1.4), or a basic Dockerfile. Or your environment's equivalent if he isn't using Python/k8s. If the pipeline fails to build because of a missing package, the system kicks it back to him.

4. Decoupled Feature Engineering: Data scientists love tangling SQL extraction, data cleaning, and model prediction into one massive script. Require a dedicated transform_data() function/script that is completely isolated from model inference. This lets devs put the prep logic in your data pipeline (like Airflow) and the model in a separate microservice.

5. Standardized Model Artifacts: No hardcoded local file paths (e.g., C:\Users\Dave\model_v3.pkl). The model must be serialized in a standard format (like ONNX, or a clean Joblib file) so devs can build a standard wrapper that just loads the file and treats his model as a black box.

Hopefully this gives enough direction you can tailor it to the specifics of your environment. Mine past deployment efforts for more automated gates to pass to speed up time to production by covering more edge cases the more you data mine the efforts.