A History of IDEs at Google: From Emacs to Cider and Cloud Dev Environments

A Reddit thread on r/programming surfaced a long-arc history of Google’s internal IDEs that’s worth your time if you’ve ever wondered why FAANG-scale teams build their own editors. We pulled it apart and mapped what’s transferable to your stack — and what isn’t.

The short version: Google moved from desktop power-user editors to a cloud-first web IDE not because Emacs got worse, but because the monorepo got bigger than any laptop could reasonably hold. That single constraint reshapes the whole tooling story.

The power-user era: when Emacs and Vim were the default

For most of Google’s first decade, the internal answer to “what IDE should I use?” was effectively “whichever one you can configure yourself.” Engineers ran Emacs or Vim against checkouts of the Piper monorepo on workstations, plugged into custom integrations for build, code review, and source control.

This worked because:

• The codebase, while large, still fit on a single dev machine if you were selective about what you checked out
• Senior engineers wrote and shared their own elisp and vimscript packages — internal Emacs and Vim configurations became cultural artifacts passed between teams
• Velocity came from terminal fluency and keyboard discipline, which selected for a specific kind of engineer

The cracks showed up gradually. As Piper crossed into multi-billion-line territory, full checkouts became impractical. Indexing for cross-references and refactoring choked on the size. New hires didn’t all arrive fluent in dotfile tuning. The implicit social contract — “configure your own tooling, share with peers” — turned into a tax on people who just wanted to ship code.

Why Cider exists: the monorepo problem you don’t have

Cider — first as an Eclipse-based desktop client, later as a fully web-based IDE — wasn’t an attempt to be cooler than Vim. It was an answer to questions that are uninteresting unless your codebase is enormous:

1. How do you open a file you don’t have locally? Cider runs against a cloud-resident view of the monorepo. CitC, short for “Clients in the Cloud,” is exposed as a FUSE filesystem. The IDE doesn’t sync the tree to your laptop — it talks to a remote that holds the whole thing and shows you a virtual view of your edits.
2. How do you do cross-repo refactors? A global semantic index, maintained centrally, lets you jump to definitions and find callers across the entire monorepo without your editor running a local indexer over billions of lines.
3. How do you onboard someone in an hour? A URL opens a working IDE with your project loaded, build tooling wired up, and code review integrated. No “install these 14 plugins and edit your dotfiles” runbook.

That third one is the part most cloud-IDE pitches miss. The point isn’t that the editor lives in the browser — JetBrains and VS Code already render to a remote — it’s that the environment lives in the cloud. Sources, build cache, indexes, lint, formatters, and review state are all centrally managed. Your laptop becomes a thin client.

The latest internal iteration, often referred to as Cider-V, is built on Monaco — the same editor engine that powers VS Code. That’s a tell: even Google, with more than a decade of investment in its own editor stack, eventually decided that editor surface is commodity and infrastructure underneath is the differentiator. Build on the open editor, keep the proprietary value below the file-tree line.

What this means for your team

You almost certainly don’t have Google’s monorepo problem. But you may have a smaller version of it, and the same logic applies:

• Onboarding time is a real cost. If a new engineer needs more than a day to get a working environment, you pay that price on every hire. Cloud dev environments — Codespaces, Gitpod, Coder, JetBrains remote — collapse that window to minutes when configured well.
• Local-machine drift is technical debt. “Works on my machine” is a tax. The further your team’s setups diverge, the more time gets spent debugging the toolchain instead of the product.
• The editor is becoming the least interesting layer. VS Code, Cursor, JetBrains Fleet, and Zed are converging on the same UI affordances. The interesting questions are about the layers underneath: indexing, codegen, build remoting, and AI agents that touch your code.

The Google story also reframes the AI-assisted-editor moment. Cider made it normal at Google to have a code intelligence layer that isn’t your laptop. That’s the same architectural shift that makes Copilot, Cursor, and similar tools work — remote inference against a server-side view of your codebase. Cider arrived at that architecture first, for different reasons.

The lesson under the lesson

If you read the history as “Google built a fancy IDE because they could afford to,” you’re missing the point. Cider exists because the alternative — every engineer running a full local environment — stopped working at Google’s scale. The web IDE was the cheapest way out, not the most ambitious.

For your team, the relevant question isn’t “should we build our own IDE?” The answer is no. The relevant question is: which of these forces — codebase scale, onboarding friction, environment drift, AI-assisted workflows — already costs you enough to justify moving one layer up the stack into a managed environment? If the honest answer is “none yet,” keep your VS Code setup and move on. If it’s even one, the next few years of your dev tooling are going to look more like Cider and less like a hand-rolled .emacs file.

FAQ