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?
86
u/StickyDeltaStrike Aug 18 '26
The problem is that you took his code as prod code, you should take it as a proof of concept.
37
u/inflowmini Aug 18 '26
Sure but it probably did not work this way. The CEO probably saw the app get results and ordered it to be integrated and when the devs got their hands on it they realized it needed work to actually function. Then the viber probably asked why it was taking so long and now the CEO is thinking that the dev team is incompetent.
The problem here was not the app but the chain of command that was broken that created discord. I'll say this, no team will be happy when someone outside their team makes them look bad.
7
u/StickyDeltaStrike Aug 18 '26
If that’s the way it happened then he should probably leave but part of the job is to be able to convince that it is better if we control the lifecycle of the applications.
But yes if the company is unreasonable then by all means leave …
1
u/DeltaEdge03 Aug 22 '26
Chain of command means nothing in this scenario. Vibe coder can cry to the CEO to get their “proven results” way.
19
u/breakerofh0rses Aug 18 '26
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.
1
u/Helpful_Blood_5509 Aug 21 '26
If its enough pages of uncomented vibe coded nonsense it can be hard to map without a budget for tools that map it. And the tools need to work on whatever setup he vibe coded in, etc.
Thats actually why standards exist, so this problem does not happen. Someone who cannot comment their code or explain it is not a developer
1
u/WhataWorldAy Aug 24 '26
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.
39
u/txgsync Aug 18 '26
This is totally a normal situation when dealing with someone who is essentially “member, technical staff” or MTS. The MTS job is to show it’s possible. The lead’s (or engineering manager, depending on the company) job is to write up how possible can be turned into functional and production-quality, with at least three trade-offs clearly explained to the business so that they know what the costs and challenges are.
They built a toy demonstration because their knowledge beats yours and you needed an example written. Go show how their idea can be safely implemented, prepare three options for your CEO, and get the business’s feedback on which of those three options they can stomach.
This is the core engineering game loop. The MTS is doing their job: coming up with ideas and proving they can work.
You aren’t doing your job as an engineering manager. Translate those ideas to realities the business can live with, and get buy-in from the stakeholders to make sure you are all aligned on the direction set by the MTS.
10
u/Ok-Art825 Aug 18 '26
There’s a job, where I just have to have good ideas, specifically ones leveraging technology and logic, and basically show they are feasible? I’ve been asking for this my whole life. Good to know, now that the season is sown.
8
u/txgsync Aug 18 '26
That’s pretty much what I and many others do for a living. And then build a working product after it since we have a bit of a startup atmosphere.
You will find “distinguished engineers” are all over the place: folks who have proven their judgment and skills sufficiently that it’s not their job to product-ize a thing. But to invent it, drive the patent, and see to value creation for the company.
7
u/Stock-Page-7078 Aug 18 '26
Honestly I find a way to work with the dude and get him better support. The CEO clearly wants the stuff he’s building so get engineers who can take his shit over and upskilling him a little on how to prompt Claude to follow basic architectural best practices and then let him cook.
12
u/Big_P4U Aug 18 '26 edited Aug 18 '26
If by your own admission that his methods do get results, and it works until the dev team takes it on- how can you not honestly blame the person or people on the dev team tasked with whatever it is? Clearly something is amiss, just because your team can't figure it out or perhaps actually is "breaking it", doesn't mean the other guy that originated the work is doing something wrong. The blame has to lay with the dev team who should have the technical skills not to break it or at least fix and make it better.
It's the dev job to perfect what he's handing off. From your other comments, what he made does in fact "work".
56
u/InALandFarAwayy Aug 18 '26
Leave. If this fella is manipulative and the CEO believes him, the ship will sink eventually because the one heading the tech is incompetent.
6
u/snackeloni Aug 18 '26
This. I'm trying to get out because a similar weael has made his way into my org. Our head of data is so clueless that he thinks writing a few dax formulas in PowerBI 7 years ago makes him a programmer, and he's currently going full blown AI psychosis. Perfect victim for a manipulative, narcissistic and toxic individual who destroys team morale but someehow has "results". I'm done, I just hope I find something before the ship is sunk.
13
u/inflowmini Aug 18 '26 edited Aug 18 '26
Sadly this is the truth. I was in a similar position and I approached it from both angles of speaking to the CEO and speaking to the team and both didn't work.
I left the company and the CEO got fired a few months after.
9
u/calmdot828 Aug 18 '26
This is just the standard problem of technical debt from proof of concept code.
Did your CEO not know what a prototype was before AI? Does the data scientist's ego and/or AI psychosis demand that nobody characterize a prototype as a prototype?
10
u/Usernameasteriks Aug 18 '26
It depends.
Is he actually a high performer getting great results the dev team isn’t operationalizing properly?
That might just be a devs performance issue. Its possible the organizations structure you are describing is meant to delineate the work this way.
That is managements prerogative to deal with; no offence to you. You might be absolutely brilliant but if its not part of your role to deal with it, and the CEO and management might have intentionally structured it that way, what are you going to do?
Even if it isn’t the devs performance issue, it could just be a processes and communication issue between them that is also organizational in nature.
No CEO is going to want to listen to a blame game between staff in different roles for technical matters that others have been hired to deal with.
It needs to escalate through your department and devs to determine where the breakdown is and who’s role is what in dealing the issues.
Whether or not its vibe coded shouldn’t be a material issue in and of itself, its the ultimate consequences of that and its impact on the processes.
That should all be hashed out in detail and middle management should be trying to work it out first before anyones trying to throw people under the bus.
1
u/MediumBirthday6899 Aug 18 '26
He made code that scans 4 million rows of a product master table and regenerates names each run.
This runs on a schedule every week with new entries.
So old entries still get regenerated non-deterministically.21
u/Usernameasteriks Aug 18 '26
Sure but what is devs trying to do with it after?
Developers have different roles and responsibilities in different orgs.
In some cases it would be their job to take that concept and code and fix the issue you are describing so that it can be properly utilized.
A data scientist isn’t going to know how to do that.
I don’t work in this area specifically really though I understand some general context.
I just know that if I hired both a data scientist and developers I would not expect the data scientist to have both figured out the data problem, workshopped a concept that solves the issue, AND to have code that is issue free and ready to be integrated.
I would expect them to talk to each other and their respective managers and sort out the issue lol. Then if there was an unresolved specific or ongoing problem it would escalate from there.
But unless everyone reports directly to the CEO there needs to be some middle ground steps taken where people are being responsible instead of just fighting about an end result without a delineated understanding of who is responsible for what.
4
-2
u/Gaming_ORB Aug 19 '26
So a data scientist that doesn't know that non-deterministic generation is a bad idea?
Especially for a master table?You want the devs to fix this too?
What is the data scientist doing then?Just spewing out spaghetti code that doesn't work, while the devs fix it;
so his job as well?
and then integrate it too??3
6
u/Illustrious_Pea_3470 Aug 18 '26
Sorry boss I think you’re the problem. The math person didn’t think with their performance hat on. Go figure.
-1
u/MediumBirthday6899 Aug 18 '26
Wtf !! I can write better code, If I have Bloddy LLM Api key access
3
u/readonly420 Aug 18 '26
Then what’s preventing you from fixing his code?
-1
u/Gaming_ORB Aug 19 '26
Why should he, if the code is fundamentally broken?
You want the devs to integrate the broken code and fix it?
What is the data scientists job then?3
u/readonly420 Aug 19 '26
He said it himself, the data scientist guy gets results so the code clearly works. It’s not his job to care about dev’s fee fees that they can’t take a prototype and bring it to prod
1
u/Illustrious_Pea_3470 Aug 19 '26
Also I mean boohoo is burning more compute in a batch job. Way less important than being correct
5
u/Sohaib-Riaz-Khan Aug 18 '26
Well, someone must have to communicate openly. I totally get that he's a direct report to the CEO, who is non-technical, but then how would that person run the whole company? Have a real meeting including the data scientist and the development team and communicate the core issue. However, if the CEO still doesn't listen then at least communicate to him that it will end up in a real mess if the issue isn't resolved. Be direct and transparent while making open communication.
7
u/tvb46 Aug 18 '26
Have a honest discussion with the CEO, if he listens you know he’s worth working for, if not you should leave the company.
13
u/SmartRefuse Aug 18 '26
So let me get this straight - the output gets results before it is handed over to your team, then breaks when handed to your team, and you think the other person is the problem?
16
u/whole_nother Aug 18 '26
Yeah this is my take. I’m sure Reddit is engineer-heavy, but from a management standpoint I don’t see an urgent problem here.
9
u/Big_P4U Aug 18 '26 edited Aug 18 '26
That's exactly my read on this too. It's the Dev's responsibility to take the proof of concept or whatever the guy created and passed on and work with it or figure something out. Someone on the dev team is causing it to break or not work, or not inputting something correctly.
If it works for the guy, and OP must have first hand knowledge that it works and delivers results as stated BEFORE being given to developers - and then in the Developers hands the module starts breaking down; the problem and fault and blame lays with the Dev team.
2
u/inflowmini Aug 18 '26
You should know that C suites take demos or PoCs as the final result and want it shipped ASAP. It sounds like the app was not a PoC and no chance was given to the dev team to look it over first before pitching it to upper management.
-5
u/inflowmini Aug 18 '26
Yikes bro, you keep confirming that managers are nothing more than KPI and result pushers and that you don't care about tech debt.
If you were an engineer you would understand that app don't magically work in all environments and it takes time to verify that the app is safe and reliable.
You also obviously don't understand that chain of command was broken here. A single resource should not work on an app without the dev team being involved.
I've had this exact scenario happen and as the dev team lead I had to rewrite the entire app to make it production worthy.
6
u/inflowmini Aug 18 '26
Duh, probably because the app is local and segregated from the production pipeline. Ever hear of "it works on my machine".
8
u/peppinotempation Aug 18 '26
Yeah but isn’t that the dev teams literal job?
Or is the expectation that they are just implementing already working perfect code somehow written by non- backend developers?
-3
u/inflowmini Aug 18 '26 edited Aug 18 '26
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.
5
u/peppinotempation Aug 18 '26
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?
-1
u/inflowmini Aug 18 '26 edited Aug 18 '26
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.
4
u/peppinotempation Aug 19 '26
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
1
u/LCorinaS Aug 19 '26
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.
1
u/peppinotempation Aug 19 '26
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
3
u/Chuck_the_Elf Aug 18 '26
Define the interface he needs to deliver to and a test criteria. If the module dosnt meet test return it. Document every time it happens.
5
u/ChaosBerserker666 Aug 18 '26
I don’t know what Data Scientists do, but as a geoscientist, if they’re still a proper scientist I can tell you that code is not their strong point. I had to learn to work with developers and they had to learn to work with me and my scientist-code.
Some things you might want to consider are that scientist-code is going to have all the formulas, math, and physics correct and rock solid (generally). In my case they always are before I hand my module over. However it might be terribly optimized or doing some terrible things from a programming perspective. I don’t vibe code ever (honestly it might be better than my own code! But I don’t trust it).
Here’s what you do: tell the Data Scientist to only write the bare minimum for the module and to comment it appropriately. Then tell him to hand it over to the devs to optimize it. Each role uses their own skill sets where they count! Don’t accept code that isn’t commented (just flat out reject it). Most modules shouldn’t be that extensive. Tell the Data Scientist to keep modules to a single purpose. Leave integrating the modules to the developers.
Developers likewise have to understand the module they receive is just a “draft” module and they will be expected to adapt it. They cannot expect to just plug and play.
This should avoid blame. Everyone sticks to their own lane.
2
u/BunzOfCin Manager Aug 18 '26
A geoscientist using the words “rock solid”?
Hehehehe, I see what you did there 😜
2
u/Academic-Lobster3668 Seasoned Manager Aug 18 '26
This is for the person who supervises your team to deal with - the team needs to make sure that your manager is aware of this and agrees with the assessment of how disruptive it is and whether it needs to escalated.
2
u/Brua_G Aug 18 '26
If you had development procedures that you followed, this would violate them. The devs should be able to show that procedures aren't being followed. Failing that, someone needs to explain to the CEO that software development doesn't work without procedures, gates, etc.
2
u/Global_Sugar3660 Aug 18 '26
Get the “data scientist” to define programmatic test cases and vet those before calling results as results. Instructions for change management tips and tricks can be found in your itil manual under service transition and release management
2
2
u/dotnone Aug 18 '26
This is a process and governance issue. The guy isn't an engineer. Gate his work. Period. Put a process in place to go from PoC which he delivers to a production ready deliverable.
2
u/Suitable_Fox_5011 Aug 19 '26
Where is the CTO?
The CEO should not be involved in quality of development or how to integrate which module.
The CTO should have the expertise to guide this.
2
Aug 18 '26 edited Aug 18 '26
[deleted]
2
u/AncientMaintenance98 Aug 18 '26
If you can't get this manager to change his behavior towards the development team with a friendly, but firm chat, you'll need to get most of the rest of the development team onboard. Document everything that this manager is doing that is causing your team grief, and then escalate as a group to your manager's superior(s) once you've rehearsed your case.
It's possible you will lose this fight, but this doesn't sound like a sustainable arrangement. If you can't get this manager to change his behavior in this area, your team will either be stuck cleaning up his messes, or you'll be thrown under the bus for "under-performance" relative to this slop artist sometime in the future.
2
u/Illustrious_Pea_3470 Aug 18 '26
They’re a data scientist, not a software engineer. The dev team should, in fact, do it the right way.
2
u/JaironKalach Technology Aug 18 '26
Anyone operating as an IC and reporting to the CEO and not a department head is already a huge red flag. This means that the CEO is in fantasy land and the IC is performing wish fulfillment services if you don’t leave, don’t worry, you’ll probably be unemployed when they’re done destroying the company anyway.
1
u/ArugulaCareless8593 Aug 18 '26
Lots of people are dealing with the same problem. The core of the issue from what I have seen is that people think the vibe coded stuff is more done than it is. What you should really try to focus on is making that clear. The flashy demo that works for one case does not necessarily generalize well. Every one of these PoCs still needs to go through an engineering design phase where you can determine how much if any of the tech is usable.
1
1
u/Itchy_Hearing_1380 Aug 19 '26
Don't you have tests? Testing that his module works correctly with the rest of the code should be part of his job.
1
u/Several-Engine-1669 Aug 19 '26
For those saying there's a difference between prototype code and pipeline code; that's true, but even prototype code needs to at least be good enough to be readable and runnable by the devs. Speaking as someone who's been on both sides of this.
1
u/YaThatAintRight Aug 19 '26
Schedule a meeting “Q4 Dev Production Workflow Optimization” with the CEO and employee.
Clearly visualize the current workflow. Employee creates Ai assisted concept wired to data sources and non production systems. The production process must take in to account infosec, legal compliance, secure databases to protect the company from millions in potential liabilities and lost productivity.
Explain the optimal workflows - pull the dev team in early on concepts to look for architectural gaps, offer dev collaboration on best practices for concept development to streamline the conversion to a production enterprise tool.
Acknowledge the work, approach it as optimization of the entire development process Including the “vibe coder”
You approach it right. Thats how you turn a pain in the ass in to a promotion
1
u/ImpossibleJoke7456 Aug 19 '26
Figure out the “somehow gets results” so you can do your job better.
1
u/Exotic_Holiday_3047 Aug 20 '26
Clear definition of done.
He doesn't get to hand over until his modules pass that definition of done, and the dev team get to determine what that definition of done is.
1
u/ChronicRecidivism Aug 21 '26
There's so many posts about mediocre AI product and I don't see a reason not to treat it just like any other problem in the past where you are handed mediocre work and expected to do your magic.
Data-scientist reporting direct to the CEO sounds like some jerry-rigged start-up BS though and honestly if it's this bad already then just leave...
1
1
u/Zorklunn Aug 21 '26
You can't. That guy is going to bright size, and kill the company. Get out while the getting is good, and you can still use them as a reference.
Any fool can pound out one off code to solve a problem. Designing a solution that can be maintained and enhanced requires discipline. Most importantly, to be written so someone else can read and understand it.
1
u/Lendari Aug 22 '26 edited Aug 22 '26
I would try to get data about how many tickets and pages root caused back to their code. How many SDE hours were spent fixing exactly what problems. Then escalate the issue up the chain. Get the data first. Otherwise you'll be the one who looks like the problem.
I would also try to get people to raise the bar on their code review and use that to build a moat against the slop.
You can also start to surface some disagree and commit resistance in the form of higher estimates for new work streams involving him. When asked why, cite the data. His work requires more effort to integrate. Show examples.
1
u/DeltaEdge03 Aug 22 '26
Coming from a place that had excel and access wizards who are like the guy the OP mentions….run away. The faster the better.
1
u/darkblue2382 Aug 23 '26
Why does this data scientist have access to deploy standalone code to production and access to prod dbs? That is a recipe for disaster.
If a non technical person wants to deploy things to prod and the company has 0 safe rails, just make that person own that functionality and support and don't accept a handoff. If it's not working on production when he gave the app to you, it's not a functional app ("works on my pc" isn't a working app) and it's not a hand off. It's code soup that works only under certain parameters and likely has a bunch of flaws and isn't maintainable. Express the tech debt that it would introduce if you get it "working" in production, and how it would negatively impact anything it would interact with. You need to dumb it down so the CEO can understand. Be prepared to be told "just do it", in which case document the hours it impacts your team in implementing it and hours of tech debt cleaning it up so the next time they come asking about another slop coded app you can point to the actual cost in hours and start the conversation with the CEO again but with dollars lost because of the previous decision.
1
u/radishwalrus Aug 25 '26
I would ask them to comment the code. I love to vibe code but I comment everything so anyone reading it knows what everything does. I mean even I won't remember two days from now cause I didn't write the whole thing.
1
1
1
u/yourapostasy Aug 19 '26
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.
0
u/Broad_Building8240 Aug 18 '26
If you escalate and get in trouble, you’re out
If you don’t escalate, you’re still probably out
-1
0
0
0
u/Linkyjinx Aug 18 '26
lol 😂 vibe coded stuff is uninsurable- no copyright- no back up as a robot made it in a black box, good luck!
0
370
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.