That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immedia

That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immediate group / team. Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer! And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer. The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise. And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in. And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.