How Google Built a Unified Cloud IDE After a Decade of Editor Fragmentation

For most of its history, Google left IDE choice to individual engineers, with leaders like Jeff Dean arguing that mandating a common editor would only breed resentment. The cost showed up indirectly: every IDE needed its own integrations for Bazel, Starlark, code search, and formatters, and traditional editors strained against a monorepo too large to index locally. A dedicated IntelliJ integration team formed around 2015, but fragmentation persisted.

The shift came from an unexpected direction. Around 2013, engineers built Cider, a browser-based editor that initially appealed to technical writers fixing typos but gradually picked up developer features, most decisively LSP-powered code completion backed by a server-side index of the entire monorepo. That backend solved a Google-specific problem—serving each engineer a language graph synced to their workspace state across billions of files committed many times per second—but the web frontend remained thin. In 2020 the team rebuilt Cider on top of a forked VSCode, inheriting a mature editor and extension ecosystem while keeping the indexing backend.

By 2023, roughly 80% of google3 development ran through Cider V, and the convergence created a flywheel: with most engineers on one platform, internal teams shipped around 100 extensions tailored to their workflows, unlocking integrations that fragmented tooling had made impractical. The author notes that polish and parity battles—down to color schemes—consumed months, validating Joshua Bloch’s quip that editors inspire more religious fervor than programming languages.