There's three systems an org can (and should) have in place to prevent this: - Dev-time analysis. This is, types, linters and tests that will throw errors and

There's three systems an org can (and should) have in place to prevent this: - Dev-time analysis. This is, types, linters and tests that will throw errors and block merges before they happen. - A good code-review environment. Not one that's so tedious that everyone just seeks the stamp to move on, but also no one that's so lax there's no code review at all. One in which code-review is really an opportunity to improve the code before it's merged, people are committing to unblocking others, and everyone assumes their responsibility in having the right people look at changes. - A better team structure. One where ownership of the code is shared, and code quality goals are present. Usually if computer systems, peers and the org at large all agree in creating a good dev environment, dev environments tend to not be bad. In my experience not having a monorepo doesn't fix the issue, it just hides it away. Repos don't have the same code-quality, and overall everyone tries to stay in their little island and not deal with problems and disagreements outside of it. You lose the opportunity to talk about these issues. There isn't that learning and teaching dynamic in the wider org, and the whole company is worse off as a consequence. Plus, of course, there's a lot of extra-overhead in developing with APIs between each component.