Now I am far from an expert on monorepos but I want to know what you think of the next sentence:

> The first one is easy, ban these. You don’t need them in the blocking portion of your pipelines.

I don't think they mean ban integration testing. I think they are saying don't block merge requests on integration testing.

Is this still a problem? Perhaps they are doing some kind of trade off management. Isn't that basically what engineering is, like I remember when I was in high school the classic problem of engineering was do you want thicker heavier wires on electricity poles which means more poles and more expensive or thinner lighter wires so they are lighter but higher resistance and more "leakage". My understanding is there are no correct answers, only the least bad ones.

Imagine someone trying to change the background color of a button in css and waiting three hours for integration tests to finish before anyone can +2 it.

I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times.

If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.