Microsoft, in a recent update to its Visual Studio IDE, has forced Copilot AI onto developers. It's not an obvious change, in fact, it affects a rarely-used corner of the IDE: the profiler.
A profiler is a useful if not often used tool. Most of the time a programmer is editing the code. Somewhat less time is spent compiling and linking the source code into executable files. Depending on the developer and the quality of the code (which may have been written by others) some amount of time is spent debugging the code - running the code in 'slow motion' and observing which lines are executed and which are not.
The profiler is a tool to measure the code, specifically as it runs. Different profilers (or different parts of a large profiler) measure the time to execute functions (to identify which functions are slow), the amount of memory used, file operations, and "code coverage" (to identify code that is not tested).
Microsoft's Visual Studio has a profiler built as one of its tools. (And it's a nice, capable profiler.)
But Microsoft's latest version of Visual Studio adds Copilot to the profiler, and adds it in such a way that you cannot use the profiler without using Copilot. (You don't seem to have to pay for this specific use of Copilot, though.)
It so happens that a client has decided to disable Copilot in their organization. (Exactly how is not important.) They have their reasons to do so, and while I may not agree with their reasons I do agree with their goal of disabling Copilot. (I think Copilot and the other programming AIs are not quite ready for prime time.)
Working in this environment it is obvious that the new version of Visual Studio is dependent on Copilot: the profiler refuses to run. (It's not quite obvious; it took a few seasoned hands to identify the connection.)
A few observations about this change:
First, Microsoft, rather than allowing developers to enable Copilot, is forcing Copilot upon them. That's not going to win them many friends. Selling a new feature ("See this new feature! It's shiny!") tends to keep people on your team. Forcing a change makes people angry -- possibly angry enough to leave your team.
Second, Microsoft has built a new profiler that requires Copilot and cannot work without it. This is a poor design choice. Good design of systems allows components to work even when parts of them are not available. (And as the profiler worked just fine without Copilot two weeks ago, I don't see how Copilot is such a necessary part of the profiler.)
Third, if Microsoft is willing to force Copilot onto developers for the profiling tool, they may be planning to force Copilot onto developers for other parts of Visual Studio. Auto-completion, for example. Or syntax coloring. Or debugging. Or maybe even code optimization by the compiler. I'm not sure Copilot is ready for such tasks.
Fourth, if Microsoft is willing to force Copilot onto developers, they may be planning to force Copilot onto other users -- in Microsoft tools such a as Word, Excel, Powerpoint, Access, and maybe even things like Maps. (I'm not talking about making Copilot available to these tools; I'm suggesting that Microsoft make Copilot mandatory in these tools.)
The bundling of Copilot into the Visual Studio profiler is a small change for a small audience. I don't see people in significant numbers moving away from Microsoft because of it. A few might, but nothing significant.
But it doesn't increase the appeal of Visual Studio. Developers like control over their tools. I don't see people joining Microsoft's team because they are forced to use Copilot.
One could interpret this change (for Visual Studio) as an experiment: Will users work with Copilot? Or as an act of desperation: We need to get higher usage numbers for Copilot. In either case, it's an internal issue. Microsoft is not boosting its appeal to developers, and not setting a higher standard for its competitors to meet. As an internal issue, the rating of success (or failure) will be determined by internal numbers. I don't expect we'll see more about this change.
