For any use case for which this could be good, simply factoring the code into normal files / modules / packages, put it through code review in a version control system, and enable on-demand reproducible execution through normal means like a task queue that writes output artifacts like plots somewhere for you.
Relying on interactive, possibly out of order execution of notebook cells, relying on the notebook for embedding assets like plots or interactive widgets, or collaborative changes (instead of documented change requests as in a true code review) are all just from-first-principles very bad ways of working that have cheap, easily available long-standing best practice alternatives.
If you find you need to layer in visual diffing, locking notebooks, notebook “code review,” realtime edits from multiple authors, or embedding long-lived business artifacts like charts or images in notebooks - you should see these as significant bad practices and code smells that your understanding of what it’s appropriate to use notebooks for is totally off and you need a major reset and huge change to your approach.