For instance, when you send a message from the backend container to the database container during ordinary CRUD, the backend container will largely be waiting for the database to start processing. Something similar for most frontend requests - usually in dev work, you press a button, it sends an API request and awaits the response; the API request sends a message to the database and blocks on the response. The database sits around idly waiting till it receives a message, and sends something back. Then the backend postprocesses the reply and produces the response, and then the frontend postprocesses the response. There is some degree of joint action during the actual communication phases but it wouldn't put a huge load on the multithreading capacity of your CPU.

Something similar can be said for Gitlab/Slack/Email - in the background, they could easily be using the spare CPU time rather than competing for time, and you wouldn't actually notice it. But they also should spend most of their time waiting around doing nothing.

So I think the claim is specifically true for some stacks with poor test coverage.

But if you have compiled code, it should probably be compilable in parallel (and if it isn't, you should be complaining to the compiler writer and/or refactoring your code). Likewise, unit tests should in practice be runnable in parallel - if they are not, they're probably closer to integration tests. Even integration tests should be writable so that they can run in parallel, because you hope to have more than one user acting in parallel. And you generally shouldn't be testing your feature development manually. Even if you prefer to visualise your process, you can code it up in something like cypress so that you can run them later or check up why you missed this special case when the bug reports come in.

So I disagree with the original assertion, but I don't think you've provided an effective counterargument.

Vim is single threaded right?