Buried at the bottom of the article is a link to this github issue that explains VS Code’s policy, which is apparently to make beta-quality APIs available to one or two extensions first to get feedback, then make it publicly available later. The extension author gets access to the API early but accepts that it’s non-final and subject to changes or breakages. This appears to be what happened with InlineCompletionProvider which is one of the APIs Codeium complains about.

Sure, it’s very convenient for Microsoft to give early access to another Microsoft product but it’s not the worst policy ever to get feedback before everyone in the world starts developing against API and it becomes harder to fix design problems.

I wonder if Codeium has requested their extension to be selected for this status.

I think the title is a bit misleading… vscode was made as a light weight script text editor, and it wasn’t even used that much internally at microsoft when it first came out. most people were using something like notepad++ / sublime for config file edits and stuff… it wasn’t until like 2018/2019 that it started to see wide usage internally. Most of this was due to C# being the language of choice, and the fat visual studio had a lot better integration for C# and azure development… though as teams started to use other languages, and the C# dev tools improved, you saw gradual shifts to people using vscode (mostly due to its much faster startup times)

the funny thing is, the vscode team released their github integrations internally to dogfood before the acquisition of github was announced, and due to regulatory stuff, the team behind the project wasn’t even aware of the acquisition until it went public.

While it makes sense that msft integrated co-pilot into vscode due to its popularity, its a far stretch to assume that it was planned out in some long road map. It was most likely a small team that implemented it, and it gained traction, then fell onto a roadmap for vscode (though, thats a guess, i havent worked at msft for quite a few years). I say this due to the workplace interoperability and the anecdotal things i saw while there (like the github bit above)

I’m a JetBrains person. I like vim, but I also heavily use IDE features and VSCode just never scratched the right itches. I’ve worked with many people who use VC but when I pair with them and watch their workflows, they simply aren’t as efficient, as if they’re unaware of what a proper IDE can actually do. They also complain when VC extensions get mature and become paid extensions, which hasn’t been a problem with JB.

I use Copilot with JetBrains, but it’s only “cool”, not “awesome”. When I really need help with some code Copilot rarely does the right thing, and JB’s code completion already works really well. I know Copilot for VC is better than for JB and they claim they’re going to bring parity to JB at some point, but this article makes me suspect they’re lying. If they don’t I’m going to start shopping for competitors.