A former Google engineer has detailed the company's 20-year journey through development environments, from Eclipse plugins to custom cloud-based IDEs. It's a rare inside look at how one of the world's largest codebases handles developer tooling at scale. Google builds tools that millions of developers use. Understanding how they build tools for themselves reveals what they think actually matters. This is the difference between the IDE marketing pitch and what works at scale.
Laurent Le Brun, writing on his blog, chronicles the evolution from 2011 through 2024. The story starts with what most companies face: fragmentation. For years, Google let engineers choose their preferred IDE. When senior leaders were asked in 2011 if a uniform IDE was feasible, the consensus was negative. Jeff Dean famously stated that achieving developer agreement on a common editor would be counterproductive, noting that "the advantages and disadvantages of different systems are weighed differently by different people."
But fragmentation had costs. Engineers repeatedly reimplemented the same integrations across multiple editors - Bazel support, Starlark tooling, code formatters, code search connectivity. Every tool had to support Emacs, Vim, Eclipse, IntelliJ, and whatever else developers were using. The duplication was expensive.
Around 2013, a web-based editor called Cider emerged. The name cleverly referenced "Cloud IDE" with an added "r" for memorability. In an organization where engineers already worked in browsers for code reviews and codebase navigation, a web-based editor wasn't as radical as it might seem elsewhere.
Cider initially attracted technical writers seeking quick file edits without version control friction. Its breakthrough came with language-server protocol support for code completion. The backend indexed Google's entire codebase - billions of files - enabling code intelligence that traditional local IDEs couldn't match at that scale. When your codebase is too large to fit on a laptop, cloud-based tooling stops being optional.
By 2020, Cider dominated company-wide IDE usage, prompting strategic reconsideration. Leadership decided to integrate VSCode as the frontend, preserving Cider's sophisticated backend while leveraging VSCode's maturity, extensibility, and web-native architecture. The project was called Cider V.
The transition proved complex. A frontend team of roughly a dozen engineers spent years integrating version control, code review tools, completion features, and refactoring capabilities. The 2021 open beta reached 5,000 engineers, though substantial polish work remained. User feedback proved intense - even color schemes generated extensive discussion. As Joshua Bloch observed, editors inspire passionate debate rivaling programming language preferences.
By 2023, approximately 80% of development in Google's main codebase occurred within Cider V. The standardization unlocked significant benefits: concentrated investment became more impactful, and roughly 100 internal extensions emerged as teams customized workflows for specific needs. The unified platform facilitated advanced AI integration, including machine-learning-powered code review comment resolution and context-aware code pasting.
Le Brun concludes that standardized tooling, while expensive and rare, creates substantial organizational leverage. But the real lesson is about scale. At Google's size, the traditional approach - local IDEs, individual tool choices, distributed implementation - doesn't work. The codebase is too large. The coordination costs are too high. Cloud-based, standardized tooling becomes the only viable option.
Most companies aren't Google. They don't have billions of lines of code or tens of thousands of engineers. But the principles translate: tool fragmentation is expensive, standardization enables better investment, and at sufficient scale, cloud-based development stops being a choice and becomes a necessity. The industry is heading in that direction whether individual developers like it or not. Google just got there first because they hit the scaling problems first.
