Yesterday at GitHub Satellite — this year held as an online event for obvious reasons — the biggest announcement wasn’t another feature for Actions or an enhancement to code review. It was Codespaces: a full Visual Studio Code environment running in the cloud, accessible from your browser, integrated directly into GitHub repositories. Click a button, get a dev environment. It’s the kind of demo that makes you say “that’s cool” and then immediately start thinking about all the reasons it won’t work in practice.
But I’ve been thinking about it for a day now, and I’m less dismissive than I expected to be.
What Codespaces Actually Is#
Codespaces is built on top of Visual Studio Online, which Microsoft launched last year. The underlying technology is a containerized VS Code server running on Azure, streamed to your browser (or to a local VS Code instance via a remote extension). Each codespace is a Linux container with configurable specs — you can choose your CPU, memory, and storage.
The GitHub integration is the interesting part. Repositories can include a .devcontainer folder with a devcontainer.json configuration file and an optional Dockerfile. This defines the development environment: which runtime versions to install, which VS Code extensions to pre-load, which ports to forward, which shell to use. When someone clicks “Open with Codespaces,” they get that exact environment, pre-configured, with the repository already cloned.
The demo showed someone opening a repository, making changes, running tests, and submitting a pull request — all from a browser tab. No local installation, no dependency management, no “it works on my machine” conversations. The time from clicking the button to having a working environment was about 30 seconds.
Why This Time Might Be Different#
Cloud-based development environments have been attempted before. Cloud9 (now owned by AWS), Eclipse Che, Gitpod, Theia — the graveyard of almost-good-enough cloud IDEs stretches back years. I’ve tried most of them at one point or another, and they always hit the same wall: latency makes typing feel wrong, the environment is too constrained, or the configuration is too complex to justify the convenience.
Codespaces has a few advantages that previous attempts lacked. First, it’s VS Code — the most popular editor among web developers by a significant margin. The extensions work, the keybindings work, the muscle memory transfers. This isn’t a web-based editor pretending to be an IDE; it’s the actual IDE, running remotely.
Second, the .devcontainer specification means the environment configuration lives with the code. This is the same “infrastructure as code” principle that made Docker successful for deployment. When a new contributor opens the repository, they don’t need to read a README with seventeen steps for setting up their local environment. They don’t need the right version of Python, the right version of Node, the right native dependencies. The container handles all of it.
Third, GitHub’s reach matters. If Codespaces is a first-class feature in the world’s largest code hosting platform, it gets adopted by default. Open source projects can provide contributor-ready environments. Companies can standardize development setups. The network effects are powerful.
The Problems That Remain#
Let’s not get carried away. There are real constraints.
Latency is still a factor. Even with a fast connection, there’s a perceptible delay when typing in a browser-based editor that doesn’t exist locally. It’s subtle — maybe 50-100ms — but for touch typists, it’s distracting. The VS Code remote extension (where you run VS Code locally but connect to a remote server) mitigates this significantly, but then you’re back to requiring a local installation.
Cost is unclear. The beta is free, but this will eventually be a paid service. If it’s priced per hour of compute time (like VS Code Online), the economics for full-time development are questionable. A developer working 8 hours a day on a 4-core, 8GB machine would likely spend more per month than buying a capable laptop. The sweet spot might be occasional use: onboarding, code reviews, quick fixes, open source contributions.
Offline development is impossible. If your internet goes down, your development environment is gone. For those of us who occasionally code on trains, planes, or in locations with unreliable connectivity, this is a non-starter as a primary environment.
And then there’s the elephant in the room: not everyone develops in VS Code. Vim users, Emacs devotees, JetBrains customers — Codespaces doesn’t speak to them. The .devcontainer spec is VS Code-specific, which limits its potential as a universal standard for development environments.
The Bigger Picture#
What excites me about Codespaces isn’t the product itself — it’s the forcing function it creates. The .devcontainer specification is open, and it pushes the industry toward treating development environments as configuration rather than tribal knowledge.
How much time do teams waste on environment setup? In my experience, it’s measured in days per new hire and hours per week for ongoing maintenance. “Works on my machine” is a meme because it’s universally true. Docker addressed part of this for runtime environments, but the development environment — the IDE configuration, the linters, the debugger setup, the test runner integration — has remained stubbornly manual.
If .devcontainer becomes a standard that every repository includes, even developers who never use Codespaces benefit. You’d have a machine-readable specification of what the development environment should look like, which local tools could consume just as well as cloud tools.
My Take#
I won’t be switching to Codespaces as my primary development environment. I have a well-tuned local setup that I’ve refined over decades, and I’m not ready to introduce a hard dependency on internet connectivity for my core workflow.
But I’m genuinely excited about what this means for a few specific use cases. Contributing to open source projects you’ve never worked on before? Enormous improvement. Onboarding new team members? Transformative. Running a workshop or training session? No more “let’s spend the first hour making sure everyone’s environment works.”
The real question is whether this is the beginning of a fundamental shift or a niche convenience. My gut says it’s somewhere in between — cloud development won’t replace local development for serious daily work, but it will become a standard supplement. Like many tools, its value lies not in replacing what works, but in eliminating what’s painful.
I’ve signed up for the beta. I’ll report back once I’ve put it through its paces on a real project.