Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra.
> a team dedicated to the IntelliJ integration was formed around 2015
I don't know which team that was, but to add to that, official support for IntelliJ at Google started quite a bit earlier. I was the second person to join a team writing IntelliJ plugins. We wrote a Blaze plugin not too long after Blaze launched, as it was becoming more popular.
Google tells me that Blaze launched in 2006, so I think it must have been 2007 or 2008.
There's more history than this. Disclaimer: Xoogler (2010-2017).
When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse.
Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import binaries, specifically jars. In the outside world, these dependencies are managed via Ant (very early days), Maven/Gradle or the like.
At Google there's a mono-repo (Perforce/Piper) and you check out parts of it locally and rely on the rest via a network connection (to SrcFS IIRC, it's been awhile). This was neat because you could edit a file locally and the dependencies would just recompile (via Blaze).
So for Eclipse a whole lot of initialization had to be done and the IDE would fall over. A lot. It had a team of ~10 working on it at one point. Then somebody did a 20% project called magicjar. Magicjar took a Perforce client and built all the dependencies as jars that could be imported directly without parsing the entire source tree (which was usually huge). This made it possible, even preferred, to use IntelliJ, which is what I did. Magicjar was great.
Other people actually made CLion work reasonably well with C++ too. That was nice. This was a much bigger undertaking with many more corner cases just given how C++ works (ie headers and templates).
So checking out a client was relatively heavyweight, even with a minimal local tree. And, if you worked on Google3, you had to do this a lot. You might need to do a config file change. This was the real starting point for Cider because it was way nicer to do config file changes with it.
Obviously I don't know where all this went from there. VS Studio as a Cider frontend? Ok, that was news to me. Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.
Oh it's worth adding that in my time many people didn't use Perforce (P4) directly. They used somebody else's project, which was a Git frontend for it, called Git5. No idea if this is still a thing. But Git5 modelled a P4 change as a branch so you could play around with your Git commits locally and then squash them into a single P4 change. I actually liked this a lot.
The advantages of a single platform are as obvious as the disadvantages. In that they are often whatever you want to frame them as for a narrative.
I do think Google will continue to get results out of their tooling, as long as they are investing in the tooling. But that is not zero cost. Is it worth it for what they are doing? Largely seems to be.
But it isn't like they are that much more successful at software projects than any other company? They are still largely an ads company, no?
Google is an ads company with a large amount of infrastructure to back it up.
Sure, the money is mostly in ads, but serving searches, AI, youtube, and all the rest at the scale Google does it requires a technical tour-de-force. Does Google do it better than everyone? Absolutely not. But it does it better than many.
Certainly it isn't the _only_ way to do it--other companies also manage to do it. But not all that many at the same scale. It's an existence proof that you can.
Most of what they do really really well, though, is accomplished by massive amounts of spending. That isn't a knock on it.
Consider that they spend more on trying to build up and support this central IDE than most companies dream of losing in productivity to not having this.
The last year I’ve been doing all my dev on a vscode VM thingy my company set up. It’s just been getting better and better. It’s like local dev but, tbh, better. It’s at the point where I don’t even install dev tooling locally any more at all. My computer is just a thin client.
The aspect I miss is the distributed compilation hinted at in the article. I remember back at the end of 1990s using distcc and things, but that never seemed to happen in the Java world and the tooling like maven etc is structured to make everything one long dependent chain. Shame.
Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.
"the advantages of having a single, extensible platform become even more obvious"
-- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique!
The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.
The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.
I had to laugh we he said it took a dozen people a couple years. That's a terribly small investment relative to the leverage over developer productivity, and pales in comparison to what eBay, IBM et al spent in similar large but specialized developer populations for integrated tooling.
I'd like to hear the perspective of the developer/user; the IDE provider has some incentive to take credit and imply high utilization reflects success rather than Google policy.
I'm interested in how tooling conditions developer expectations more broadly. I'd love to see a comparison of Linux OS development (all local+open+git, open but contributor hierarchy) vs Google (monorepo+required tooling, pre-allocated authority) from someone who's done both.
That most engineers use the same IDE at Google allows the company to collect a huge amount of telemetry about what features they are using, how often, and how much. Quite similar to the entire codebase being in a single repo, it allows a certain visibility into what is happening that just isn't possible other places.
When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on. This is very good for your adoption metrics, but might not tell you exactly what you want to know about engineer happiness.
Such a dominant IDE also allows management to ignore the long-tail of users who aren't using it.
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good.
I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
Although the tool is internal, a lot of information about it is not confidential.
As the team had to collaborate with the VSCode team, we got clearance for sharing information about it.
The screenshots in the article were posted publicly on GitHub (in vscode issues). You can also find screenshots in https://research.google/blog/smart-paste-for-context-aware-a...
More generally, a lot has been communicated on developer infrastructure at Google.
The biggest question on my mind is how the use of Cider V is being affected by the officially ordained Antigravity.
Is the trendline starting to show that its adopting more Antigravity style tooling? or is this causing some sort of rift?
In my experience, antigravity IDE is much less seemless compared to Cider-V. I completely moved to using web-based antigravity for the agent and using cider-v to make manual changes and viewing code.
I was surprised to read that Chromebook use at Google was common for engineers. Even if developing remotely I had assumed they'd opt for the most powerful machine possible.
Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.)
You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on that machine. There is a huge, absolutely amazing distributed build system that everyone uses for everything. (Again, Android and Chromium are different.)
So you don't really need a powerful local machine. I held out for a long time--there were a lot of growing pains in the early days. But eventually it got really, really good.
It's a monorepo, which is a bunch of libraries (in this case, the code for most Google products) in a single repository. Those libraries can have dependencies on each other.
One is a framework called Wiz, which renders the frontend for a bunch of Google web apps. You can imagine that the Wiz team might want to refactor an API, but not have to worry about different apps using different versions. In a monorepo, they can just find all the callsites and update them in the same commit that makes the API change. There's no package.json in google3 - everything builds from HEAD. Therefore, the commit that makes a breaking change is also the commit that fixes the would-be breakage.
This architecture evolved. Google used to use Perforce, which was a common commercial version control system before Git. Google had to figure out how to express the dependencies between packages in the monorepo (which can be in different languages with different build tools). They eventually created Bazel, which expresses those dependencies and orchestrates their build tools.
Build orchestration took a few attempts. Google3 is the third version of the monorepo, that is, the one that uses Bazel for dependency management.
When I joined, I started with a MacBook and lost it within three months :(
Afterwards I was issued a 12" Pixelbook and it was surprisingly much more usable than I had expected! I could ssh into a Linux box for running builds and tests. Cider worked perfectly. It was snappy enough to serve as a thin client even on a 4K screen.
Chromebooks are pretty much only good as thin clients, so much so that when I have the money I plan on building a powerful rackmount workstation and connecting to it via chromebook/box
How common? I'd wager most people still use a mac, followed second, but far by regular goobuntu laptops. Chromebooks goes 3rd because Windows is practically banned.
From what I'd heard contractors get issued as little as a Pixel tab and dock? Everything else is in the cloud (either gLinux desktops or cloud shells) AFAIK.
I do most of my development on a MacBook air and a Chromebook. The ~only thing I do from my local machine is ssh into a beefy workstation and use chrome.
Was there 2009-2014 and then again 2020-2026. I think there are a lot of aspects of IDE use and culture at Google that this post omits.
My recollection from 2009-2011 is that emacs and vim were the dominant editors (just as the TV show Silicon Valley depicted), and there was a decent-sized minority using Eclipse and Intellij, both of which had official support for Google tooling. The command line still largely ruled though, even though the official Google developer workstation was Goobuntu, Google-flavored Ubuntu. This reflected the overall developer population of the time.
I think Cider actually was invented a little earlier than the article describes. I have vague memories of some engineers experimenting with web-based IDEs that would integrated directly with Critique (the code-review software) as early as 2013-2014. Its use was not widespread when I left in 2014; there was still the impression that it wasn't powerful enough for daily driving.
When I came back in 2020, emacs/vim use was much lower, again probably reflecting differences in the general population of developers. Many more of the developers had been trained in the post-2010 developer ecosystem of VSCode, IntelliJ, etc, and this was reflected in tool usage at Google too. I'd say IntelliJ was the dominant IDE, with Cider a close second and Cider-V just starting to take market share. You still had to pry emacs and vim from a grizzled old veteran's hands.
By 2022 I'd transferred to an Android team, and Android Studio with Blaze was the dominant IDE, even as general IntelliJ usage in the company was falling. Cider just didn't have the same Android-specific support. Company-wide Cider-V was growing the fastest, taking market share from both IntelliJ and Cider-V.
By 2024 Cider-V was dominant and there started to be a concerted push to standardize on it, particularly since new AI agent tools were coming out and they couldn't be supported on all editors that Googlers wanted to use.
As of my departure in 2026, the company-wide push was to standardize on Antigravity [1], which, as I understand it, won a turf war within the developer tools org and got blessed as the "official" Google AI coding agent. This also has the effect of concentrating developer time dogfooding Google's external AI coding offering, which hopefully should improve its quality. There's still significant Cider-V usage, but it's dropping, and execs are pushing Antigravity hard.
How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs
I've switched to emacs and I no longer use IDEs. This is because I do all my edits, as a personal policy, via LLM. I mostly use emacs for magit (I work on a git-on-borg repo).
Cider-V is very nice. It's VSCode so all the extensions just work - Vim mode, themes, etc.
It's also nice that it stores all my preferences in the cloud, so switching machines is seamless (helpful when my macbook broke a couple weeks ago and I had to use a loaner chromebook for a day).
It's also well integrated with google3 and codesearch, and seamlessly runs tests on remote machines with tmux integration and all.
Not all of google tooling is my favorite (like their source control), but the IDE is great.
Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra.
https://knowledge.workspace.google.com/admin/gemini/ai-ultra...
> a team dedicated to the IntelliJ integration was formed around 2015
I don't know which team that was, but to add to that, official support for IntelliJ at Google started quite a bit earlier. I was the second person to join a team writing IntelliJ plugins. We wrote a Blaze plugin not too long after Blaze launched, as it was becoming more popular.
Google tells me that Blaze launched in 2006, so I think it must have been 2007 or 2008.
There's more history than this. Disclaimer: Xoogler (2010-2017).
When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse.
Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import binaries, specifically jars. In the outside world, these dependencies are managed via Ant (very early days), Maven/Gradle or the like.
At Google there's a mono-repo (Perforce/Piper) and you check out parts of it locally and rely on the rest via a network connection (to SrcFS IIRC, it's been awhile). This was neat because you could edit a file locally and the dependencies would just recompile (via Blaze).
So for Eclipse a whole lot of initialization had to be done and the IDE would fall over. A lot. It had a team of ~10 working on it at one point. Then somebody did a 20% project called magicjar. Magicjar took a Perforce client and built all the dependencies as jars that could be imported directly without parsing the entire source tree (which was usually huge). This made it possible, even preferred, to use IntelliJ, which is what I did. Magicjar was great.
Other people actually made CLion work reasonably well with C++ too. That was nice. This was a much bigger undertaking with many more corner cases just given how C++ works (ie headers and templates).
So checking out a client was relatively heavyweight, even with a minimal local tree. And, if you worked on Google3, you had to do this a lot. You might need to do a config file change. This was the real starting point for Cider because it was way nicer to do config file changes with it.
Obviously I don't know where all this went from there. VS Studio as a Cider frontend? Ok, that was news to me. Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.
Oh it's worth adding that in my time many people didn't use Perforce (P4) directly. They used somebody else's project, which was a Git frontend for it, called Git5. No idea if this is still a thing. But Git5 modelled a P4 change as a branch so you could play around with your Git commits locally and then squash them into a single P4 change. I actually liked this a lot.
We've moved on from Git5. Although it was a pain, I kind of liked that Git5 made the monorepo less monolithic to my editor.
There are mercurial and jujutsu frontends now.
I still have nightmares about eclipse sometimes.
The advantages of a single platform are as obvious as the disadvantages. In that they are often whatever you want to frame them as for a narrative.
I do think Google will continue to get results out of their tooling, as long as they are investing in the tooling. But that is not zero cost. Is it worth it for what they are doing? Largely seems to be.
But it isn't like they are that much more successful at software projects than any other company? They are still largely an ads company, no?
> But it isn't like they are that much more successful at software projects than any other company? They are still largely an ads company, no?
They have a ton of other software in 2026. And they have a pretty diverse (and diversifying) income stream today. Like 30-40% from non-ads.
Is it worth it? That’s for them to say, but they can ramp up cloud services at scale pretty fast as a core competency.
Google is an ads company with a large amount of infrastructure to back it up.
Sure, the money is mostly in ads, but serving searches, AI, youtube, and all the rest at the scale Google does it requires a technical tour-de-force. Does Google do it better than everyone? Absolutely not. But it does it better than many.
Certainly it isn't the _only_ way to do it--other companies also manage to do it. But not all that many at the same scale. It's an existence proof that you can.
Most of what they do really really well, though, is accomplished by massive amounts of spending. That isn't a knock on it.
Consider that they spend more on trying to build up and support this central IDE than most companies dream of losing in productivity to not having this.
> But it isn't like [Google] are that much more successful at software projects than any other company?
I re-read this several times trying to figure out where the irony was hidden. But... it's not there?
The last year I’ve been doing all my dev on a vscode VM thingy my company set up. It’s just been getting better and better. It’s like local dev but, tbh, better. It’s at the point where I don’t even install dev tooling locally any more at all. My computer is just a thin client.
The aspect I miss is the distributed compilation hinted at in the article. I remember back at the end of 1990s using distcc and things, but that never seemed to happen in the Java world and the tooling like maven etc is structured to make everything one long dependent chain. Shame.
You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.
How do you internalize it?
Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.
"the advantages of having a single, extensible platform become even more obvious" -- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique!
The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.
The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.
It would be nice if they extended their external services the same behavior…
I had to laugh we he said it took a dozen people a couple years. That's a terribly small investment relative to the leverage over developer productivity, and pales in comparison to what eBay, IBM et al spent in similar large but specialized developer populations for integrated tooling.
I'd like to hear the perspective of the developer/user; the IDE provider has some incentive to take credit and imply high utilization reflects success rather than Google policy.
I'm interested in how tooling conditions developer expectations more broadly. I'd love to see a comparison of Linux OS development (all local+open+git, open but contributor hierarchy) vs Google (monorepo+required tooling, pre-allocated authority) from someone who's done both.
The name Cider is not from Cloud IDE, stems from Critique (the code review), which is addressed via cr/ - Cider is the IDE in Critique: cIDEr.
The thing I most love about Cider-V is that moving between it and (often remote) VSCode when working outside google3 becomes mostly painless.
That most engineers use the same IDE at Google allows the company to collect a huge amount of telemetry about what features they are using, how often, and how much. Quite similar to the entire codebase being in a single repo, it allows a certain visibility into what is happening that just isn't possible other places.
When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on. This is very good for your adoption metrics, but might not tell you exactly what you want to know about engineer happiness.
Such a dominant IDE also allows management to ignore the long-tail of users who aren't using it.
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good.
I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
I am very opinionated, but I really don't like Cider V. I have been using neovim at Google since 2017 and it's been great.
I can't say for sure because I never used it, but neovim is the jam.
same! how do you deal with cloudtop latency though? sometimes my neovim is very slow and laggy because of the remote connection / network file system
Ever tried SSH'ing via "Mosh"? https://mosh.org
I use a workstation specifically to improve latency. Needed to get approval at some point to get a refresh though.
like a workstation under your desk? is the latency bad when you remote access it not in the office?
Yeah, under my desk. I rarely remote which is a good excuse for me to disconnect from work anyways.
How can they post this obviously internal thing from Google? How can they get clearance from security/IP?
Although the tool is internal, a lot of information about it is not confidential.
As the team had to collaborate with the VSCode team, we got clearance for sharing information about it. The screenshots in the article were posted publicly on GitHub (in vscode issues). You can also find screenshots in https://research.google/blog/smart-paste-for-context-aware-a...
More generally, a lot has been communicated on developer infrastructure at Google.
OP is an ex-Googler
The biggest question on my mind is how the use of Cider V is being affected by the officially ordained Antigravity. Is the trendline starting to show that its adopting more Antigravity style tooling? or is this causing some sort of rift?
In my experience, antigravity IDE is much less seemless compared to Cider-V. I completely moved to using web-based antigravity for the agent and using cider-v to make manual changes and viewing code.
I was surprised to read that Chromebook use at Google was common for engineers. Even if developing remotely I had assumed they'd opt for the most powerful machine possible.
Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.)
You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on that machine. There is a huge, absolutely amazing distributed build system that everyone uses for everything. (Again, Android and Chromium are different.)
So you don't really need a powerful local machine. I held out for a long time--there were a lot of growing pains in the early days. But eventually it got really, really good.
Could you even put all of google3 on local disk if it were allowed?!? You'd need quite a RAID array. I suspect it'd be almost impossible in practice.
There's no reason to pull the entire repo just to build one project. Do you pull all of GitHub to your disk?
What is Google3?
It's a monorepo, which is a bunch of libraries (in this case, the code for most Google products) in a single repository. Those libraries can have dependencies on each other.
One is a framework called Wiz, which renders the frontend for a bunch of Google web apps. You can imagine that the Wiz team might want to refactor an API, but not have to worry about different apps using different versions. In a monorepo, they can just find all the callsites and update them in the same commit that makes the API change. There's no package.json in google3 - everything builds from HEAD. Therefore, the commit that makes a breaking change is also the commit that fixes the would-be breakage.
This architecture evolved. Google used to use Perforce, which was a common commercial version control system before Git. Google had to figure out how to express the dependencies between packages in the monorepo (which can be in different languages with different build tools). They eventually created Bazel, which expresses those dependencies and orchestrates their build tools.
Build orchestration took a few attempts. Google3 is the third version of the monorepo, that is, the one that uses Bazel for dependency management.
The mono repo that holds most source code (pronounced google-tree?) It's referenced in the OP.
I've never heard that pronunciation.
What did you think it was pronounced as?
"google-three" which it obviously is?
When I joined, I started with a MacBook and lost it within three months :(
Afterwards I was issued a 12" Pixelbook and it was surprisingly much more usable than I had expected! I could ssh into a Linux box for running builds and tests. Cider worked perfectly. It was snappy enough to serve as a thin client even on a 4K screen.
Chromebooks are pretty much only good as thin clients, so much so that when I have the money I plan on building a powerful rackmount workstation and connecting to it via chromebook/box
How common? I'd wager most people still use a mac, followed second, but far by regular goobuntu laptops. Chromebooks goes 3rd because Windows is practically banned.
Since it's mostly browser tabs, as long as you have ample memory (eg 16gb) it's good enough.
From what I'd heard contractors get issued as little as a Pixel tab and dock? Everything else is in the cloud (either gLinux desktops or cloud shells) AFAIK.
I do most of my development on a MacBook air and a Chromebook. The ~only thing I do from my local machine is ssh into a beefy workstation and use chrome.
Initially Cider was branded as a light client that opened much faster than traditional IDEs.
Now, ironically with so many extensions and LLM computing, users seem to forget that they chose Cider because of its lightweight.
Everything turns into the thing it was set out to replace.
Do Java engineer at Google not use IntelliJ?
Was there 2009-2014 and then again 2020-2026. I think there are a lot of aspects of IDE use and culture at Google that this post omits.
My recollection from 2009-2011 is that emacs and vim were the dominant editors (just as the TV show Silicon Valley depicted), and there was a decent-sized minority using Eclipse and Intellij, both of which had official support for Google tooling. The command line still largely ruled though, even though the official Google developer workstation was Goobuntu, Google-flavored Ubuntu. This reflected the overall developer population of the time.
I think Cider actually was invented a little earlier than the article describes. I have vague memories of some engineers experimenting with web-based IDEs that would integrated directly with Critique (the code-review software) as early as 2013-2014. Its use was not widespread when I left in 2014; there was still the impression that it wasn't powerful enough for daily driving.
When I came back in 2020, emacs/vim use was much lower, again probably reflecting differences in the general population of developers. Many more of the developers had been trained in the post-2010 developer ecosystem of VSCode, IntelliJ, etc, and this was reflected in tool usage at Google too. I'd say IntelliJ was the dominant IDE, with Cider a close second and Cider-V just starting to take market share. You still had to pry emacs and vim from a grizzled old veteran's hands.
By 2022 I'd transferred to an Android team, and Android Studio with Blaze was the dominant IDE, even as general IntelliJ usage in the company was falling. Cider just didn't have the same Android-specific support. Company-wide Cider-V was growing the fastest, taking market share from both IntelliJ and Cider-V.
By 2024 Cider-V was dominant and there started to be a concerted push to standardize on it, particularly since new AI agent tools were coming out and they couldn't be supported on all editors that Googlers wanted to use.
As of my departure in 2026, the company-wide push was to standardize on Antigravity [1], which, as I understand it, won a turf war within the developer tools org and got blessed as the "official" Google AI coding agent. This also has the effect of concentrating developer time dogfooding Google's external AI coding offering, which hopefully should improve its quality. There's still significant Cider-V usage, but it's dropping, and execs are pushing Antigravity hard.
[1] https://antigravity.google/
I joined in late 2015. Cider was well-known by then.
I'm a UXE, so I tend to use the same tools an external developer might. But I never got the impression that Cider was a recent development.
How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs
I've switched to emacs and I no longer use IDEs. This is because I do all my edits, as a personal policy, via LLM. I mostly use emacs for magit (I work on a git-on-borg repo).
Cider-V is very nice. It's VSCode so all the extensions just work - Vim mode, themes, etc.
It's also nice that it stores all my preferences in the cloud, so switching machines is seamless (helpful when my macbook broke a couple weeks ago and I had to use a loaner chromebook for a day).
It's also well integrated with google3 and codesearch, and seamlessly runs tests on remote machines with tmux integration and all.
Not all of google tooling is my favorite (like their source control), but the IDE is great.