What Google's IDE History Tells Us About Dev Tools at Scale
May 14, 2026·1 min read
Laurent Le Brun just published a fascinating insider look at how Google built and rebuilt its developer environments over two decades. From Cider to Cider-V to the current Cider-G (with AI baked in), it's a rare peek at what happens when yo
Laurent Le Brun just published a fascinating insider look at how Google built and rebuilt its developer environments over two decades. From Cider to Cider-V to the current Cider-G (with AI baked in), it's a rare peek at what happens when you have a monorepo the size of a small country and tens of thousands of engineers hitting it daily.
The headline lesson for me: Google kept losing the battle against IDEs they didn't control. They tried Eclipse plugins, then a homegrown web IDE, then VS Code forks. Every time, the gravitational pull of what engineers actually wanted at home — IntelliJ, VS Code — kept dragging the strategy back. Building your own IDE is a tax most companies can't pay.
The AI angle is where it gets spicy. Cider-G isn't just VS Code with Copilot stapled on; it's designed around the idea that an LLM is a first-class user of the editor. Code search, build, review, refactor — all of it has to be machine-legible, not just human-legible. That reframes a lot of internal tooling work.
If you build dev tools, this is essential reading. The short version: meet developers where they are, invest in the boring plumbing (indexing, build, code intelligence), and assume your next big user isn't human. [source](https://laurent.le-brun.eu/blog/a-history-of-ides-at-google)