Skip to content
AG
Back to Blog

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

About the author

Amar Gupta

Amar Gupta

Senior Frontend Developer — AI & MCP

I build production frontends in React, Next.js and TypeScript — and the AI and MCP tooling behind them. 7+ years shipping web applications, from data modelling through to the deployed interface.

📍 Delhi, India · Open to Full-time

Read next