Salesforce has this model of development and it's horrible. They won't let you run the code locally since the environment is proprietary. Even to run the tests, the code has to be uploaded and run on their servers.
Same in the semiconductor sector. You run everything remotely off a centralized on-prem mainframe and your laptop is just a thin client to a X11 session on the server. At least that's how it was 8 or so years ago. Maybe now they started to move to the cloud.
But that's understandable. You need powerful machines to run simulations and stuff. And we could collaborate with colleagues over phone, with a shared VNC session, etc.
Ah yes, the joys of developing in Salesforce "Apex" At a previous company, we had some crazy "build scripts" that would sync a local filesystem into SF, but I recall it being pretty fragile. Also, there were annoying name spacing issues...
This was a long time ago, but I had a similar experience with Blackbaud (A Salesforce competitor). The suite of APIs required was only installed on a server so you could not run the code locally. You could either perform code edits locally and copy the files before building, or simply do all development while remoted into the dev server.
With all the time/effort Salesforce has put in to SFDX and the VSCode plugins releasing an APEX compiler must just be completely off the table. I do a lot of Salesforce work and introducing new developers to the SF way of doing things results in a lot of "wut." facial expressions.
In a previous company, we'd have people making direct edits in Salesforce. We'd then export the edits with the Salesforce CLI "force" utility, bring it into a local git repo, run some rather buggy scripts that would change the object namespaces/prefixes to a generic prefix. Then you could finally do a diff and a PR in a normal way.
We then had other scripts that would take the "generic" code and change the namespaces/prefixes for upload into QA or prod environments. It was quite painful.