It’s not just an IDE: building the developer cloud is hard

Last year, I wrote a blog post titled Why I Left Google, because a lot of people asked me that question. The other question I got a lot, but didn’t answer then, is why I chose Replit.

For most of my career, I’ve worked on developer tooling. This includes the almost 11 years that I spent at Google. There, I mostly worked on build, test, and debugging tools for other engineers. Depending on the project, tools I built were used by tens, hundreds, or thousands of developers.

Google has incredible developer infrastructure. Part of that comes from paying teams like mine to go deep on specific teams’ problems. But the truly great tools were the ones used by most of the nearly 100,000 engineers at the company.

For more than two decades, Google has been building the best cloud development platform in the industry. Much of it goes back to their early years. While the outside world saw the papers explaining GFS, MapReduce, and Bigtable, very few knew about CitC, ObjFS, CodeSearch, or TAP. It kept evolving during my time there as Piper, Cider, and Cloudtop were built out¹.

Cider, the cloud IDE, arrived comparatively late. Google always let developers pick their own editors. I knew I should try using Cider when I realized that new hires had basically stopped setting up vim/emacs/JetBrains. Cider itself wasn’t particularly special, but it was well integrated and standing on the shoulders of a developer infrastructure giant. And that made it great.

There were lots of reasons users loved a fully integrated developer cloud. Just a few:

• Users share a remote build cluster, so they’re constantly filling the build cache for each other and speeding up builds.
• “Works on my machine” goes away when development/testing/production are all running on the same fleet of managed machines.
• When a user gets code for review, they can one-click hop into a fork of the author’s client and explore/test as part of review.
• The local test environment a user is already running can instantly become a shareable demo for others to give feedback on.
• Standardized testing workflows run tests more efficiently, find bugs sooner, and proactively monitor test health.
• Forgot your laptop at home? Grab a loaner Chromebook and you’re good to go.

The company has a bunch of reasons to love it, too:

• Development hardware becoming slow? Provision some bigger VMs instead of figuring out hardware refresh cycles.
• Worried about source code security? It’s never downloaded to end user devices.
• Users can be provisioned faster and on simpler hardware using Chromebooks.
• Small teams making tooling improvements can help nearly every engineer at the company have faster builds or tests.
• Every new employee gets a standard onboarding workflow and is productive sooner.

Only a handful of other companies, like Facebook, have invested in their own versions that can compare².

Many Googlers miss this tech stack when they leave³. So why doesn’t the developer cloud exist outside a few select companies?

—

The early Google team that chose to invest in this were world class, but the idea wasn’t new…

Everybody’s favorite dev tools startup of 2009 had the idea. Heroku originally built a Cloud IDE to go with their hosting platform⁴. But at the time, before AWS and Google Cloud, it was too hard to do both.

Paul Graham frequently Tweets about Replit. Cynical people complain about him talking his book. But if you pay attention, you’d know it’s because Replit is the company he wanted to build after leaving Viacom/Yahoo in 1999⁵. Instead, he started Y Combinator. Probably the right move.

Go back further and remote development was the default. Before the PC era, most computing was done on terminals connected to a mainframe computer. The PC and early Internet eras decentralized computing, but the Cloud era and ubiquitous internet connections have brought us full circle.

—

So we’ve established that the idea isn’t new. We’ve also seen dozens of companies successfully take Google/Facebook’s internal tooling ideas and build billion dollar B2B SaaS companies⁶. So where is my developer cloud?

It doesn’t exist because it’s really fucking hard.

Google can’t make theirs available because they can’t disentangle from their internal architecture without damaging their internal productivity. I know because I was there when they tried. It’s hard.

Startups or open source historically focused on one piece of the puzzle. Sourcegraph has been working hard for a decade just to get the CodeSearch piece right⁷. Bazel might be open source, but it has a “batteries not included” feel. The full experience requires putting many pieces together. It’s hard.

But I really want the developer cloud to exist. And I want to help build it. That’s why I chose Replit.

Replit is doing the hard work. It’s the only company that was investing in enough pieces while also building the distribution to pull it off. Since joining it’s clear they’ve learned all kinds of things I never considered:

• Most coders in the world are new to the craft and open to new ways of doing things. You don’t need full backwards compatibility.
• Users are building entire applications on a phone, because a phone is the only computer they know. You can’t just be a desktop experience.
• Collaborative features force you to rethink all your design decisions. You can’t bolt it on later.

Most importantly, Replit saw the impact of LLMs on coding as early as 2015 and were prepared.

Other companies have noticed the opportunity. Every week a new online IDE product pops up. Microsoft, never afraid to weaponize their distribution, keeps investing in Codespaces and Copilot. Google is an AI giant and just announced IDX. Maybe Amazon will finally bring Cloud9 off life support after launching CodeWhisperer.

It’s good validation.

The race is on.