História das IDEs no Google culmina no Cider
O problema da fragmentação
Por anos, o Google manteve uma postura de laissez-faire em relação a IDEs: cada engenheiro escolhia a sua. Jeff Dean resumiu o consenso em 2011 ao dizer que tentar unificar editores era "receita para infelicidade". Na prática, porém, a fragmentação gerava retrabalho - integrações com Bazel, Starlark, formatadores de código e code search precisavam ser reimplementadas para cada editor. Além disso, o tamanho do monorepo (google3) quebrava as premissas de IDEs tradicionais, que assumem que indexação e análise acontecem localmente.
Cider: a Cloud IDE
Por volta de 2013, surgiu o Cider (referência a "Cloud IDE" com um "r" para soar memorável). Inicialmente voltado a escritores técnicos que queriam editar markdown sem lidar com versionamento, o editor web ganhou tração ao adicionar code completion via language-server protocol. O diferencial era a arquitetura: um cliente leve que abria rápido, com um backend que indexava o codebase inteiro e mantinha um grafo de linguagem atualizado a cada commit - incluindo dados históricos por data de sync do usuário.
Cider V: VSCode como frontend
Em 2020, quando Laurent Le Brun (autor do post, ex-engenheiro do Google entre 2011 e 2024) entrou como tech lead, a decisão foi migrar o frontend para VSCode. A lógica: herdar um editor maduro, ecossistema de extensões e anos de features já resolvidas. O open beta em 2021 tinha 5.000 usuários, mas a integração completa (controle de versão, code review inline, extensões, refactoring) levou mais dois anos de iteração. O polish foi crítico - até esquemas de cores geravam discussões acaloradas.
Resultado: 80% do desenvolvimento em uma IDE
Em 2023, 80% do desenvolvimento no google3 acontecia no Cider V. A uniformidade trouxe efeitos de rede: mais investimento justificado, times internos desenvolvendo extensões próprias (cerca de 100 após dois anos) e integração de features de IA como resolução de comentários de code review com ML e "Smart Paste" para ajustes contextuais de código colado. A conclusão do autor: tooling padronizado cria alavancagem - embora o custo seja alto e poucas empresas consigam justificar esse tipo de investimento.