How Google Replaced Fragmented IDEs with a Unified Cloud‑Based Development Environment

Google engineers historically used a variety of IDEs (Vim, IntelliJ, Eclipse, VS Code), each requiring separate plugins to understand Google‑specific files such as BUILD.bazel. Maintaining a full plugin ecosystem for tens of thousands of engineers was costly.

Google’s 20 % time policy allowed engineers to create small internal tools. Examples include MagicJar, which packages Java dependencies as pre‑built JARs to avoid full repository parsing, and the early Cider project, a browser‑based editor that leveraged the company’s monorepo and LSP to provide code navigation across the entire codebase.

Cider’s backend indexed the whole monorepo, enabling features like “Find All References” to instantly show calls from Gmail, YouTube, Maps, and ad‑billing services, turning a billions‑line codebase into a navigable graph. However, its front‑end lacked the polish of mature IDEs, and extending it required the Cider team to write custom plugins for each product team.

To address this, Google built Cider V, a platform that lets product teams develop VS Code plugins that run inside the internal Cider environment, while the core team maintains only the underlying platform. The platform was heavily modified to support Google’s Piper version‑control system, Critique code‑review workflow, and an internal plugin marketplace, handling security, permissions, and distribution.

Despite not being mandated, Cider V reached about 80 % adoption across Google by 2023, driven by the superior developer experience it offered for a massive monorepo. The shift illustrates that unifying tooling is not about eliminating personal IDE preferences but about enabling faster code understanding, safer modifications, and more efficient collaboration, especially in the AI era.