How Google Spent a Decade to Replace Developers' Favorite IDEs

Google engineers historically used a variety of IDEs—Vim, IntelliJ, VS Code, Eclipse—each requiring its own plugin support for internal tools such as the Bazel build system. A BUILD.bazel file, for example, is invisible to standard IDEs, forcing IntelliJ, VS Code, and Eclipse to develop custom plugins, and even Vim users to seek extensions.

src/
├── main.java
├── BUILD.bazel

This fragmentation created a massive maintenance burden: every new internal tool meant a full set of plugins for every supported IDE, an expense unsustainable for an organization with tens of thousands of engineers.

Google’s unique 20%‑time policy allowed engineers to work on side projects, spawning small improvements that grew into core infrastructure. One engineer enhanced IntelliJ’s Bazel support; another created MagicJar , a tool that packages Java dependencies into jars without full code‑tree analysis, later evolving into a formal team.

In 2013, the internal project Cider emerged as a browser‑based editor, aligning with Google’s long‑standing goal of moving computation to the cloud. Initially useful for documentation edits, Cider later added Language Server Protocol features for code completion and navigation.

The real power of Cider lies in its backend: it pre‑indexes the entire monorepo (tens of billions of lines of code) so that a “Find All References” query on a method like logger.LogWarning instantly reveals callers across Gmail, YouTube, Maps, and ad‑billing services—something a local IDE cannot achieve without downloading the whole repository.

However, Cider’s front‑end lacked the polish of mature IDEs. Building a full‑featured editor (cursor movement, syntax highlighting, shortcuts, multi‑window support) proved extremely labor‑intensive, and integrating new team‑specific tools required queuing the Cider team, creating a bottleneck.

To address this, Google launched Cider V , a platform where internal teams can write VS Code plugins that run on the Cider backend, allowing the Cider team to focus on the core platform. The VS Code front‑end had to be heavily modified to support Google’s Piper version‑control system, Critique code‑review workflow, internal plugin marketplace, and security/permission models.

Despite not being mandated, Cider V achieved 80% adoption across Google by 2023, driven by the superior developer experience it provided. The shift illustrates that unifying tools is not about eliminating personal IDE preferences but about enabling faster code understanding, safer modifications, and more efficient collaboration—especially in the AI era where cloud‑based IDEs are increasingly valuable.