6 ms·

I am the person who approved this PR and would like to acknowledge and apologize for the mistake of turning this feature on by default without sufficient upfron

by dmitriv 5mo ago

I am the person who approved this PR and would like to acknowledge and apologize for the mistake of turning this feature on by default without sufficient upfront validation. There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. As folks mentioned here - many similar tools do this as well. Obviously, it should not be on when disableAIFeatures is on and it should not be reporting changes that were not done by AI. I'll work on fixing those and meanwhile revert default to off in 1.119 update. I am open to any (constructive) comments/suggestions - please feel free to reach me directly (my alias @microsoft.com) or open an issue on GitHub. Happy to answer anything here as well.

p-e-w 5mo ago
I appreciate you acknowledging that this was a mistake, but as you surely know from your own experience with other people’s mistakes, some mistakes are so egregious that they cast doubt on the intentions of the people involved even if they are corrected later. To me, “let’s add false attribution to every commit by default without informing the user” falls squarely into that category. I don’t think I’ve ever worked in an environment where something like that wouldn’t have been red-flagged in three seconds by anyone who took even a casual glance. I’d honestly be embarrassed if such a proposal even made it into a public pull request for my organization, nevermind that pull request getting merged.
- dmitriv 5mo ago
  If what you described would make it to our PR queue, it would definitely not pass the gates. The idea was to track AI-only changes and add the trailer when such changes were detected AND the setting was enabled. Obviously, we didn't want to attribute all changes to AI. There is a bug in change detection (which slipped through testing), which led to even non-AI changes being tracked. And thus we have this problem. The PR linked here wasn't even implementing the feature, it was changing the default for the setting.
  - detaro 5mo ago
    > (which slipped through testing) In another comment you say you caught it in testing and didn't think it needed fixing, which is it?
  - deleted 5mo ago
    [deleted]
  - fastasucan 5mo ago
    >If what you described would make it to our PR queue, it would definitely not pass the gates It just did though. Did you approve the PR without actually looking at the code?
deleted 5mo ago
[deleted]
somebehemoth 5mo ago
I think the constructive criticism is best directed at whatever process you are following. That process allowed a very visible user facing change in a widely used piece of software. How did this change make it to production without some process catching the impact of this change? Was there really no internal discussion from a code review at least? This seems hard for me to believe. I expect more from Microsoft.
- serial_dev 5mo ago
  > Was there really no internal discussion from a code review at least? This seems hard for me to believe. The outlined story feels unfortunately very believable to me. Teams need to push out the most number of features, and nobody stops even for a second to think about how a feature might affect other flows or other users not in the feature request. It might have been quickly reviewed to check if the code does what it needs to do (add the coauthor note). Do you think reviewers will think about unwanted effects, when they need get back to feeding their own poorly thought out and underspec’d features to their LLMs?
  - _doctor_love 5mo ago
    > Was there really no internal discussion from a code review at least? This seems hard for me to believe. >The outlined story feels unfortunately very believable to me. 100% agree here - we seem to forget that most developers hate code reviews. I actually laughed out loud at the use of the word "discussion," it's so rare people want to get together and talk about changes. By the time the PR is up anything that stands in the way of merging and shipping is seen as a nuisance. To my mind this whole debacle is not really the individuals fault or even the team's fault but the economic pressures that drive people into situations like this.
- dmitriv 5mo ago
  Fair point. We did catch it internally in testing (as we use VS Code for all our work, so some folks did stumble on it), but I think we underestimated the impact and should do a better job at that.
jamesbfb 5mo ago
I think there’s a few of us who appreciate you being up front. I’d question the intent and why it was a mistake, especially when the commit[0] message reverting said functionality states “widespread criticism” citing this very HN article makes it look seemingly like the revert is due to negative PR opposed to a mistake. [0]https://github.com/microsoft/vscode/pull/313725/commits/1e70c1a7d11c4a43a6b3d4fbaa18b8d64ef62982 https://github.com/microsoft/vscode/pull/313725/commits/1e70...
- l2dy 5mo ago
  Author of that PR doesn't seem to be a Microsoft employee. Keep in mind that anyone on GitHub can create PRs against VSCode.
  - lightdot 5mo ago
    Even if that would be so, the person who approved it certainly is.
    - asdfasgasdgasdg 5mo ago
      The PR linked to in https://news.ycombinator.com/item?id=47992431 https://news.ycombinator.com/item?id=47992431 is not yet approved as of May 3 4:08 GMT.
  - beardbandit 5mo ago
    Author is absolutely from Microsoft https://github.com/microsoft/vscode/pull/310226 https://github.com/microsoft/vscode/pull/310226 https://github.com/cwebster-99 https://github.com/cwebster-99
    - kllrnohj 5mo ago
      The linked revert PR is not from Microsoft (and also isn't merged)
      - 5mo ago
schwede 5mo ago
Why does the commit editor hide the coauthored message? Why not pre-populate the text field and users take or leave it when committing?
- jdlshore 5mo ago
  Co-Authored-By is normally a trailer, and trailers aren’t part of the commit message. It’s likely the commit editor isn’t set up to show trailers. They’re not exactly obscure, but it does seem that they’re relatively unknown.
  - mplanchard 5mo ago
    What do you mean they aren’t part of the commit message? Trailers like (signed off by) are absolutely part of the message. Tools can choose to treat them as special metadata, but they’re part of the commit. The docs for the function to interpret trailers even says this explicitly: https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers > Add or parse structured information in commit messages
    - jdlshore 5mo ago
      I mean that they’re not necessarily part of the --message parameter to `git commit`, but instead part of the --trailer parameter. I don’t know how VSCode is programmed, but it seems plausible that trailers are handled separately from the message parameter. https://git-scm.com/docs/git-commit https://git-scm.com/docs/git-commit
      - baobabKoodaa 5mo ago
        We're talking about Git here. The question is not "how VSCode is programmed", the question is "does Git have a special field for commit trailers". The answer is no. Git stores the trailer as part of the commit message.
        jdlshore 5mo ago
jibal 5mo ago
[dead]
lightdot 5mo ago
> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. What metric did Microsoft use to assess that VS Code users "expect" their commits to have unsolicited messages added to them? > Obviously, it should not be on when disableAIFeatures is on and it should not be reporting changes that were not done by AI. Did you discuss adding these messages with your legal department? What is Microsoft's position on adding such authorship statements to the code Microsoft did not author? Or is Microsoft stating that using LLM assistants makes Microsoft a co-author of the code? Does Microsoft have copyright claims on the code if LLM assistants are used at any time during its creation?
- jdenning 5mo ago
  I would also really like to see answers to these questions. This change explicitly claims that MS co-authored the commit.
nhinck2 5mo ago
> a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code Literally who?
- IAmGraydon 5mo ago
  No one, which is why he refuses to reply further to any of these inquiries.
  - dmitriv 5mo ago
    I don't refuse - what would you like to ask?
    - deleted 5mo ago
      [deleted]
  - gizzlon 5mo ago
    they do, at least to some degree, but their comments are dead. You'll see them if you turn on show-dead somewhere
- JoRyGu 5mo ago
  I could easily see companies, especially enterprise-level companies, expect code that was generated with AI to have some level of ownership attributed to that AI. Whether a simple "Co-Authored-by Copilot" byline on the commit is the right way to do that is another question though.
  - dmitriv 5mo ago
    Correct, this was the ask.
    - zvr 5mo ago
      And thank you for this. In my professional setting, this is a very valuable addition -- provided it works correctly, of course ;-). Now if we could also have comments inside the code ("BEGIN/END snippet by Copilot"), that would also be great!
mellosouls 5mo ago
Thanks for facing this head-on here; mistakes happen. I think the default to on should also be reconsidered regardless. The assessment (co-authored by AI) may be valid but the assumption the user wants that advertising is exactly that, an assumption, and a dubious one at that.
- dmitriv 5mo ago
  Thanks. Done here: https://github.com/microsoft/vscode/pull/313931 https://github.com/microsoft/vscode/pull/313931
aaaronic 5mo ago
Brave man. RIP your inbox.
- deleted 5mo ago
  [deleted]
alemanek 5mo ago
Changing the default behavior for all of your users with no notification is pretty unforgivable. Even if this feature worked correctly, it obviously doesn’t, this should at minimum be a prompt after upgrade to let the user confirm that this is what they want. But honestly should be opt in for those that want it. To have it silently just start adding marketing copy to git commit messages is pretty bad. To have that added text not be visible to the user in the UI so they can remove it before commit is just much worse. This kind of thing being released speaks to a greater disfunction over there. Not a good look at all and I am not a Microsoft or AI hater. But my commit messages are not where you move fast and break things
- imron 5mo ago
  > Changing the default behavior for all of your users with no notification is pretty unforgivable How else is a poor programmer gonna hit their KPIs and get that promo?
- dakolli 5mo ago
  [flagged]
- Aperocky 5mo ago
  Well, the good news is commit messages are some of the most visible thing, and there are no silent modifications that are really possible. The bad news is - where else have this happened in VS Code? - A happy user of (n)vim
  - echoangle 5mo ago
    > Well, the good news is commit messages are some of the most visible thing, and there are no silent modifications that are really possible. The problem is that it's only visible after committing, it doesn't seem to show in the integrated git view when you prepare the commit.
- someguynamedq 5mo ago
  "unforgivable" is a little melodramatic
teunispeters 5mo ago
Have it as an add-on said customers can add. Opt-in, not opt-out. No AI without consent.
- dmitriv 5mo ago
  Switched back to opt-in here: https://github.com/microsoft/vscode/pull/313931 https://github.com/microsoft/vscode/pull/313931
kgeist 5mo ago
Interesting case: - a project manager vibe-coded the change without thinking it through at all - the PR was reviewed by an LLM - an actual engineer gave LGTM without really reviewing the changes, trusting the LLM Did I get this right?
- teg4n_ 5mo ago
  The LLM actually points out the problem tho
  - isityettime 5mo ago
    Maybe the engineer's LLM agent's summary of the GitHub LLM bot's review omitted that warning.
    - herrherrmann 5mo ago
      Maybe the GitHub comments didn’t properly load due to the weekly partial outage.
- throwaway277432 5mo ago
  >a project manager vibe-coded the change without thinking it through at all The PMs vibe-coding and having no idea what they're doing isn't even the main issue (although it is pretty bad). The main issue is: how are the actual engineers supposed to "review" the slop? They probably report to the same PM or are at below in the org chart and might be evaluated by them. Not just at MS, but any company. Such a conflict of interest would be detrimental to quality anywhere. You wouldn't build a bridge like this, nor should you software.
- strix_varius 5mo ago
  You can't make this shit up.
- deleted 5mo ago
  [deleted]
- duskdozer 5mo ago
jbxntuehineoh 5mo ago
thank you for doing this, it gave me the push I needed to finally switch to zed. vscode has really been going downhill for a while now. it's sad to watch, it used to be a really nice editor
anvuong 5mo ago
Don't you understand that the default shouldn't be changed at all in this case? It improves nothing and affects every single user. If an org/project wants this behavior then it can enforce this flag for its contributions. The only valid reason for this change is someone's performance somewhere in Microsoft is dependent on VS Copilot usage metric.
- dmitriv 5mo ago
  Good feedback, there needs to be a more explicit opt-in into this for teams that want it. FWIW nobody's performance here will improve from having this metric :-)
  - allarm 5mo ago
    > FWIW nobody's performance here will improve from having this metric It's even more frightening if so. Meaning you really thought it's something users wanted.
deleted 5mo ago
[deleted]
LandoCalrissian 5mo ago
[flagged]
- deleted 5mo ago
  [deleted]
- dang 5mo ago
  "Please don't fulminate." Not saying you owe $BigCo better, but you owe this community better if you're participating in it. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
solid_fuel 5mo ago
> I am open to any (constructive) comments/suggestions Here's one: I think a senior sysadmin needs to sit you down in their office and have a very serious talk with you about the responsibility that comes with writing code other people run. I am serious. We used to have these talks with everyone who got sudo access. You shouldn't be shipping code if you don't understand the trust that is required of people in your position. This isn't just about this "feature" being active when AI features are disabled, the way you mis-implemented this has resulted in it modifying the commit message with the user even seeing it! That is malicious behavior, not an innocent little feature "to make life easier". I've fully switched off of VS Code to Kate now, which is faster and better behaved in most cases anyway. Bye.
- ATMLOTTOBEER 5mo ago
  He makes more money than you and you’re responding to his ai chatbot Seethe
  - solid_fuel 5mo ago
    There’s more to life than money, child.
- mplanchard 5mo ago
  To be fair, looks like a PM vibe coded it and this person “just” gave it an approval with no comments after an LLM review.
  - throwaway277432 5mo ago
    To be fair, that makes it worse for MS, not better. This should not be vibe-coded by someone who has absolutely no idea about any of these things.
    - mplanchard 5mo ago
      Oh yeah sorry, I was being sarcastic. I think it’s hilariously bad, but I also avoid MS products like the plague as a rule.
nsagent 5mo ago
Just for any future mea culpa, I'd recommend not hedging with comments like this one: > As folks mentioned here - many similar tools do this as well. It's really doubtful they have the same behavior people are complaining about here: namely including the authored by Copilot statement when it wasn't used (or even enabled).
- sillysaurusx 5mo ago
  Anthropic does by default. I had to put “no co-authored by lines in commits, ever” into my global settings. That’s pretty close to “included when it wasn’t used (or even enabled)” since it’s opt-in by default and you have to explicitly say no. It’s not even clear where to turn it off, I just rely on the AI to figure out not to do it.
  - jstanley 5mo ago
    Maybe I misunderstand you, how is Claude doing commits where you don't use Claude? That is a very different case to VS Code which is something you can in fact use without Copilot.
    - lukan 5mo ago
      That is not what dmitriv claimed. He said this was a bug, the behavior should have been to add it only when AI was involved, which indeed, is what claude does by default. (Both is not fine with me)
captainepoch 5mo ago
> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. As folks mentioned here - many similar tools do this as well. Then make it an extension, not a IDE-behaviour thing. Is that so complicated, so difficult?
- dmitriv 5mo ago
  It would be tricky, yes, since it depends on core editor functionality which is not exposed through the API.
  - saghm 5mo ago
    So why did this feature get rushed out without proper testing? Are you claiming that not having this happen automatically for the commits where Copilot actually co-authored them is so urgent that it was necessary? I'd argue that this was extremely non-urgent and the fact that this got rushed so sloppily is a giant red flag about the priorities of you and your team. You asked about constructive criticism, and yet you're also acting like this is a one-off innocent mistake by only addressing what you've done to roll this back for now and address the immediate issue. I don't buy the premise that we could trust that this was a mistake made in good faith when it's something that you clearly should have known people would be so upset about if you got it wrong.
ares623 5mo ago
Just disable everything AI by default bro.
wren6991 5mo ago
> There was no ill intent by evil corporation I simply do not believe you
- dmitriv 5mo ago
  That's ok :-)
- nicbou 5mo ago
  It’s true. There was no ill intent, just a system of incentives that not only permitted but encouraged it.
freedomben 5mo ago
I just wanted to say, while I think this feature was a bad idea, I sincerely applaud your willingness to post here, knowing you'll get roasted. Seriously brave and commendable.
- galonk 5mo ago
  They pretended to be fronting up but didn’t respond to anything after that. Doesn’t seem very commendable to me.
  - freedomben 5mo ago
    That's a good point, let's see if they come back and respond. It is the middle of the night in the US so they may be sleeping
    - dmitriv 5mo ago
      It is the middle of the night and I am responding. Anything specific you'd like me to respond to?
      - jdenning 5mo ago
        https://news.ycombinator.com/item?id=47992781 https://news.ycombinator.com/item?id=47992781 https://news.ycombinator.com/item?id=47992568 https://news.ycombinator.com/item?id=47992568 https://news.ycombinator.com/item?id=47992475 https://news.ycombinator.com/item?id=47992475
        dmitriv 5mo ago
        First comment does not sound constructive - are you interested in my opinion on (n)vim? I am not a legal, so can't comment on legal things. However, I have already responded elsewhere here that this feature has nothing to do with licensing or ownership and was added for those that want the attribution. I understand the desire to see anything Microsoft as bad and evil, but we are really just trying to make a better experience. I'll respond to the third one, thanks!
PufPufPuf 5mo ago
My issue with this: if my intention is to never have these "co authored by <tool>" trailers in my commits, this is a sudden breaking change. What's worse, it is not immediately visible to the user. Now I could look like I use a not-company-approved AI. That's absolutely unacceptable, this could cost people their jobs. The "bug" (or "metrics boosting feature", as PMs call it?) that it claims all commits including ones never touched by Copilot are just icing on cake.
Gud 5mo ago
Nobody wants this shit. There is no timeline where developers want junk inserted into their commit messages.
nicbou 5mo ago
> There was no ill intent Only callous disregard for your users > many similar tools do this as well But since we have normalised that, it’s okay?
gib444 5mo ago
- A qualified sorry for one particular aspect of this - It wasn't our intention - Our users asked for it [you'll have to take our word for it] - Everyone else is doing it anyway - Statement that I am reasonable and will be co-operative with the community but with conditions That's a bingo!
croes 5mo ago
Rule of thumb, such features should always be Opt-In
rf15 5mo ago
You're an idiot. But I'm an idiot every day too, so I can relate. We can only learn from these mistakes, keep it up!
grey-area 5mo ago
First, revert the commit, then apologise.
- dmitriv 5mo ago
  I did both, didn't I? :-)
  - grey-area 5mo ago
    At the time of writing it wasn’t reverted, but thank you for replying.
  - deleted 5mo ago
    [deleted]
noir_lord 5mo ago
Changing a global default this way is hugely disrespectful to users. As a result I’ll be uninstalling vscode from all my machines, I’m tired of disabling things in vscode I didn’t ask for especially in regards to AI. There are open source tools that clearly respect users more and have a track record of not doing these kinds of stupid things. Be better.
macic 5mo ago
> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. Can you expand on this? Who "expects" their code editor to lie about using Copilot?
- yreg 5mo ago
  The supposedly expected functionality is very obviously that it marks copilot co-authored code as copilot co-authored, not the bug that is being reverted.
  - dmitriv 5mo ago
    Correct.
jdenning 5mo ago
What is the use-case where you expect users would be happy that you modify their commit messages with MS marketing? Do you think it would be ok to edit every commit to append “written with VS Code”?
- PunchyHamster 5mo ago
  MS would absolutely do that if they could get away with. Hell, you'd get azure promo code with it
DavidVoid 5mo ago
Considering the size (and significance) of the VSCode user base, it feels like someone should be in charge of ensuring that default behavior doesn't change without good reason. Does anyone (or any team) have ownership of the extensions/git/package.json file?
saghm 5mo ago
> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. As folks mentioned here - many similar tools do this as well. Please elaborate on what "similar tools" claim that commits are co-authored by AI when the AI features are all turned off. You're trying to defend the theoretically correct version of this that you didn't make, not the actual version you did make. > I am open to any (constructive) comments/suggestions It's hard to take this seriously; you know exactly what you did wrong here and what you should have done instead. Testing that this doesn't happen when Copilot was not used is extremely trivial; if you're not lying about it being unintentional, the fact that it didn't occur to anyone to do it still says more than enough about what the priorities are here. At absolute best, the priorities of you and your team are so fundamentally wrong that it's impossible to trust any of you going forward.
deleted 5mo ago
[deleted]
snet0 5mo ago
Why are you taking the fall and not the PM who authored the change (and submitted a PR with an uninformative title and no comment) and, I'm assuming, plays a role in managing the project?
deleted 5mo ago
[deleted]
FeistySkink 5mo ago
I appreciate your willingness to come and try and salvage this situation. What I don't understand is why are you the one doing this here and on GH, during the weekend, and not the PM who created the original PR? Surely they have some input. And another thing is, why was there absolutely no pushback from your part on any of the issues with the original PR, and why it was merged within hours in that state?
- deleted 5mo ago
  [deleted]
outlore 5mo ago
I feel like many replies are missing that this is satire
- BatmanAoD 5mo ago
  What makes you say that?
4b11b4 5mo ago
At a hackathon for my school recently a MS employee was a judge. ALL he wanted to tell me was that I should give VSCode another shot: "It's good now". You can't blame the dog, only the environment surrounding the dog.
- NegativeK 5mo ago
  Calling people dogs by analogy is not great. That aside, corporations and groups don't make decisions. People do. We can understand and empathize with what led them to that decision (and sometimes we might be looking at the wrong person), but they're still responsible.
deleted 5mo ago
[deleted]
CosmicBagel 5mo ago
I rarely comment on HN threads, but in this case big respect for coming out and owning the mistake, keep that shit up. If more people from MS had the guts to actually talk to their users, I'd probably have a lot less to complain about at work ¯\_(ツ)_/¯ Hopefully there's some good lessons to improve the process, not just feedback for this single incident.
kevinmgranger 5mo ago
> a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code This isn't enough. What was the _full train of thought_ for this? Why would it be added when AI isn't used?
_doctor_love 5mo ago
Thank you for your honesty, this is pretty brave. On the other hand...this feels like a situation where possibly you should not have said anything at all? The fact that you're on HN responding feels ill-advised to me. So far this is what I've gleaned: - Microsoft has PMs vibe coding against VSCode (by itself not necessarily a big deal) - Microsoft PMs can vibe code against VSCode and get stuff shipped to production with only a single approval That second one is a huge deal in my book. What I've learned now is that VSCode, a product with an enormous deployment base, is trivially compromised if the calls are coming from inside the house. Apparently all that has to happen for all users to be affected is a PM requesting you to "please approve my PR real quick, trying to get it in." And now there's a massive change in the wild, visible to many users. Being familiar with big corp dynamics, this really worries me. This does feel like a not-well-thought-out mistake but I can easily imagine many other scenarios that would be far worse. How can I trust VSCode going forward? How can I reassure my employer and fellow colleagues that it's safe to use? This is really a terrible look for Microsoft and very damaging to the reputation. I feel bad for you the engineer and PM here because with the web being what it is, folks are casting blame onto you. That's missing the point since the issue is that MSFT even let this happen in the first place. Engineering processes need to be halted and re-evaluated basically yesterday. If something like this happens again it may not be possible to rebuild the trust at all. I hate to say it but for myself this issue makes me strongly consider switching away from VSCode permanently, something I had not seriously considered before yesterday. Best of luck to everyone on the VSCode team.
liendolucas 5mo ago
Under which circumstances can you ever approve something like this? This goes beyond incompetence. Either you do not understand what important information a commit holds or what seems way more plausible to me is that Microsoft simply decided to try this out and see how people would react. > There was no ill intent by evil corporation... I will ever in my life buy that from Microsoft.
benchwright 5mo ago
One of my customers actually requires attribution to agents if they're used, not only for tracking purposes but also for understanding potential vectors for slopcode. It's been useful and occasionally enforced. That being said, implementation without due consideration and warning should be frowned upon.
EnglishMobster 5mo ago
Respectfully - You are working for one of the largest companies on the planet. You push code that gets used by millions of people. How on earth are you not thoroughly testing your changes??? How can something like this slip into a real build? Like, this is egregious. I work somewhere that makes software for a lot of users (although not as many as Microsoft!). We also need to ship quickly. But we work on a 45-day cycle, with 15 of those days being dedicated to ensuring we didn't add any awful bugs (and fixing them ASAP before it goes to users - or reverting the change until it is ready). I would expect Microsoft to have AT LEAST that amount of care. We can't trust that you are shipping software that even works anymore! What other changes are going in that are broken in more subtle ways? It used to be that VS Code was rock solid, and any issues were likely third-party extensions - but now it's a crapshoot, and I can't be sure if crashes etc. are the fault of extensions or Microsoft themselves! The VS Code team needs to use this mistake as motivation to lead the charge on making a quality editor. Not an editor that gets half-baked, untested changes pushed weekly. An editor that is dogfooded and where a mistake like this going to prod is unacceptable. Because if you don't, people won't trust your editor anymore. Just like people have stopped trusting your OS, and now users are fleeing it in such numbers that the Windows team has recognized they have a problem and are changing course. That WILL happen to VS Code and GitHub soon unless you actually start owning mistakes internally and fixing them before users find them.
Kadecgos 5mo ago
Whether or not the intent is good, the optics are extremely bad. I assume you are keenly aware that Windows, Office, and by extension, all of MS's customer facing products are not exactly regarded particularly well. Windows 11 specifically is a laughing stock today, even among folks who don't necessarily know computers, and a lot of that resentment is driven by 2 things: • Pushing AI everywhere when no one asked for it. • Not reading the room and adding junk features that no one wants. This change is both of those, again, wrapped up in another package. The timing of this is extremely bad for VS Code as a project as it looks an awful lot like, 'Microsoft is just shoving my AI junk into my stuff and failing to work on the features we actually want'. I'm not taking a side on this either way as I will jam a fork into my eye before I use VS Code over VS proper and have no stake in this, but I'm just saying that the powers that be that are approving these kinds of changes are ~continuing~ to fail to read the room. I'll add as someone who may be forced to consider VS Code in the future (Depending on if Windows unfucks itself before something critical breaks for me on W10), I would read something like that and I think rightly assume bad intent. I know VS Code and VS and Office and Windows are not the same team, but again, MS as a whole has a very serious optics problems and my read of this on the surface level is: "Oh, they tried to sneak in more AI junk, and when called out on it, they pushed it to the back, probably to make it a default again in some future update that they can hide it in". It just looks very, very bad at a time when no MS products have negative social capital to spend on this kind of stuff.
deleted 5mo ago
[deleted]
dmitriv 5mo ago
FYI - we have posted update on the subject with more details, links and analysis here: https://github.com/microsoft/vscode/issues/314311 https://github.com/microsoft/vscode/issues/314311 Hopefully this answers some more of the questions raised here. It also incorporates a lot of feedback from this thread with respect to next steps (thank you!).

by dmitriv 5mo ago

p-e-w 5mo ago

I appreciate you acknowledging that this was a mistake, but as you surely know from your own experience with other people’s mistakes, some mistakes are so egregious that they cast doubt on the intentions of the people involved even if they are corrected later. To me, “let’s add false attribution to every commit by default without informing the user” falls squarely into that category. I don’t think I’ve ever worked in an environment where something like that wouldn’t have been red-flagged in three seconds by anyone who took even a casual glance. I’d honestly be embarrassed if such a proposal even made it into a public pull request for my organization, nevermind that pull request getting merged.

dmitriv 5mo ago
If what you described would make it to our PR queue, it would definitely not pass the gates. The idea was to track AI-only changes and add the trailer when such changes were detected AND the setting was enabled. Obviously, we didn't want to attribute all changes to AI. There is a bug in change detection (which slipped through testing), which led to even non-AI changes being tracked. And thus we have this problem. The PR linked here wasn't even implementing the feature, it was changing the default for the setting.
- detaro 5mo ago
  > (which slipped through testing) In another comment you say you caught it in testing and didn't think it needed fixing, which is it?
- deleted 5mo ago
  [deleted]
- fastasucan 5mo ago
  >If what you described would make it to our PR queue, it would definitely not pass the gates It just did though. Did you approve the PR without actually looking at the code?

deleted 5mo ago

[deleted]

somebehemoth 5mo ago

I think the constructive criticism is best directed at whatever process you are following. That process allowed a very visible user facing change in a widely used piece of software. How did this change make it to production without some process catching the impact of this change? Was there really no internal discussion from a code review at least? This seems hard for me to believe. I expect more from Microsoft.

serial_dev 5mo ago
> Was there really no internal discussion from a code review at least? This seems hard for me to believe. The outlined story feels unfortunately very believable to me. Teams need to push out the most number of features, and nobody stops even for a second to think about how a feature might affect other flows or other users not in the feature request. It might have been quickly reviewed to check if the code does what it needs to do (add the coauthor note). Do you think reviewers will think about unwanted effects, when they need get back to feeding their own poorly thought out and underspec’d features to their LLMs?
- _doctor_love 5mo ago
  > Was there really no internal discussion from a code review at least? This seems hard for me to believe. >The outlined story feels unfortunately very believable to me. 100% agree here - we seem to forget that most developers hate code reviews. I actually laughed out loud at the use of the word "discussion," it's so rare people want to get together and talk about changes. By the time the PR is up anything that stands in the way of merging and shipping is seen as a nuisance. To my mind this whole debacle is not really the individuals fault or even the team's fault but the economic pressures that drive people into situations like this.
dmitriv 5mo ago
Fair point. We did catch it internally in testing (as we use VS Code for all our work, so some folks did stumble on it), but I think we underestimated the impact and should do a better job at that.

jamesbfb 5mo ago

I think there’s a few of us who appreciate you being up front. I’d question the intent and why it was a mistake, especially when the commit[0] message reverting said functionality states “widespread criticism” citing this very HN article makes it look seemingly like the revert is due to negative PR opposed to a mistake. [0]https://github.com/microsoft/vscode/pull/313725/commits/1e70c1a7d11c4a43a6b3d4fbaa18b8d64ef62982 https://github.com/microsoft/vscode/pull/313725/commits/1e70...

l2dy 5mo ago
Author of that PR doesn't seem to be a Microsoft employee. Keep in mind that anyone on GitHub can create PRs against VSCode.
- lightdot 5mo ago
  Even if that would be so, the person who approved it certainly is.
  - asdfasgasdgasdg 5mo ago
    The PR linked to in https://news.ycombinator.com/item?id=47992431 https://news.ycombinator.com/item?id=47992431 is not yet approved as of May 3 4:08 GMT.
- beardbandit 5mo ago
  Author is absolutely from Microsoft https://github.com/microsoft/vscode/pull/310226 https://github.com/microsoft/vscode/pull/310226 https://github.com/cwebster-99 https://github.com/cwebster-99
  - kllrnohj 5mo ago
    The linked revert PR is not from Microsoft (and also isn't merged)
    - 5mo ago

schwede 5mo ago

Why does the commit editor hide the coauthored message? Why not pre-populate the text field and users take or leave it when committing?

jdlshore 5mo ago
Co-Authored-By is normally a trailer, and trailers aren’t part of the commit message. It’s likely the commit editor isn’t set up to show trailers. They’re not exactly obscure, but it does seem that they’re relatively unknown.
- mplanchard 5mo ago
  What do you mean they aren’t part of the commit message? Trailers like (signed off by) are absolutely part of the message. Tools can choose to treat them as special metadata, but they’re part of the commit. The docs for the function to interpret trailers even says this explicitly: https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers > Add or parse structured information in commit messages
  - jdlshore 5mo ago
    I mean that they’re not necessarily part of the --message parameter to `git commit`, but instead part of the --trailer parameter. I don’t know how VSCode is programmed, but it seems plausible that trailers are handled separately from the message parameter. https://git-scm.com/docs/git-commit https://git-scm.com/docs/git-commit
    - baobabKoodaa 5mo ago
      We're talking about Git here. The question is not "how VSCode is programmed", the question is "does Git have a special field for commit trailers". The answer is no. Git stores the trailer as part of the commit message.
      - jdlshore 5mo ago

jibal 5mo ago

[dead]

lightdot 5mo ago

> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. What metric did Microsoft use to assess that VS Code users "expect" their commits to have unsolicited messages added to them? > Obviously, it should not be on when disableAIFeatures is on and it should not be reporting changes that were not done by AI. Did you discuss adding these messages with your legal department? What is Microsoft's position on adding such authorship statements to the code Microsoft did not author? Or is Microsoft stating that using LLM assistants makes Microsoft a co-author of the code? Does Microsoft have copyright claims on the code if LLM assistants are used at any time during its creation?

jdenning 5mo ago
I would also really like to see answers to these questions. This change explicitly claims that MS co-authored the commit.

nhinck2 5mo ago

> a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code Literally who?

IAmGraydon 5mo ago
No one, which is why he refuses to reply further to any of these inquiries.
- dmitriv 5mo ago
  I don't refuse - what would you like to ask?
  - deleted 5mo ago
    [deleted]
- gizzlon 5mo ago
  they do, at least to some degree, but their comments are dead. You'll see them if you turn on show-dead somewhere
JoRyGu 5mo ago
I could easily see companies, especially enterprise-level companies, expect code that was generated with AI to have some level of ownership attributed to that AI. Whether a simple "Co-Authored-by Copilot" byline on the commit is the right way to do that is another question though.
- dmitriv 5mo ago
  Correct, this was the ask.
  - zvr 5mo ago
    And thank you for this. In my professional setting, this is a very valuable addition -- provided it works correctly, of course ;-). Now if we could also have comments inside the code ("BEGIN/END snippet by Copilot"), that would also be great!

mellosouls 5mo ago

Thanks for facing this head-on here; mistakes happen. I think the default to on should also be reconsidered regardless. The assessment (co-authored by AI) may be valid but the assumption the user wants that advertising is exactly that, an assumption, and a dubious one at that.

dmitriv 5mo ago
Thanks. Done here: https://github.com/microsoft/vscode/pull/313931 https://github.com/microsoft/vscode/pull/313931

aaaronic 5mo ago

Brave man. RIP your inbox.

deleted 5mo ago
[deleted]

alemanek 5mo ago

Changing the default behavior for all of your users with no notification is pretty unforgivable. Even if this feature worked correctly, it obviously doesn’t, this should at minimum be a prompt after upgrade to let the user confirm that this is what they want. But honestly should be opt in for those that want it. To have it silently just start adding marketing copy to git commit messages is pretty bad. To have that added text not be visible to the user in the UI so they can remove it before commit is just much worse. This kind of thing being released speaks to a greater disfunction over there. Not a good look at all and I am not a Microsoft or AI hater. But my commit messages are not where you move fast and break things

imron 5mo ago
> Changing the default behavior for all of your users with no notification is pretty unforgivable How else is a poor programmer gonna hit their KPIs and get that promo?
dakolli 5mo ago
[flagged]
Aperocky 5mo ago
Well, the good news is commit messages are some of the most visible thing, and there are no silent modifications that are really possible. The bad news is - where else have this happened in VS Code? - A happy user of (n)vim
- echoangle 5mo ago
  > Well, the good news is commit messages are some of the most visible thing, and there are no silent modifications that are really possible. The problem is that it's only visible after committing, it doesn't seem to show in the integrated git view when you prepare the commit.
someguynamedq 5mo ago
"unforgivable" is a little melodramatic

teunispeters 5mo ago

Have it as an add-on said customers can add. Opt-in, not opt-out. No AI without consent.

dmitriv 5mo ago
Switched back to opt-in here: https://github.com/microsoft/vscode/pull/313931 https://github.com/microsoft/vscode/pull/313931

kgeist 5mo ago

Interesting case: - a project manager vibe-coded the change without thinking it through at all - the PR was reviewed by an LLM - an actual engineer gave LGTM without really reviewing the changes, trusting the LLM Did I get this right?

teg4n_ 5mo ago
The LLM actually points out the problem tho
- isityettime 5mo ago
  Maybe the engineer's LLM agent's summary of the GitHub LLM bot's review omitted that warning.
  - herrherrmann 5mo ago
    Maybe the GitHub comments didn’t properly load due to the weekly partial outage.
throwaway277432 5mo ago
>a project manager vibe-coded the change without thinking it through at all The PMs vibe-coding and having no idea what they're doing isn't even the main issue (although it is pretty bad). The main issue is: how are the actual engineers supposed to "review" the slop? They probably report to the same PM or are at below in the org chart and might be evaluated by them. Not just at MS, but any company. Such a conflict of interest would be detrimental to quality anywhere. You wouldn't build a bridge like this, nor should you software.
strix_varius 5mo ago
You can't make this shit up.
deleted 5mo ago
[deleted]
duskdozer 5mo ago

jbxntuehineoh 5mo ago

thank you for doing this, it gave me the push I needed to finally switch to zed. vscode has really been going downhill for a while now. it's sad to watch, it used to be a really nice editor

anvuong 5mo ago

Don't you understand that the default shouldn't be changed at all in this case? It improves nothing and affects every single user. If an org/project wants this behavior then it can enforce this flag for its contributions. The only valid reason for this change is someone's performance somewhere in Microsoft is dependent on VS Copilot usage metric.

dmitriv 5mo ago
Good feedback, there needs to be a more explicit opt-in into this for teams that want it. FWIW nobody's performance here will improve from having this metric :-)
- allarm 5mo ago
  > FWIW nobody's performance here will improve from having this metric It's even more frightening if so. Meaning you really thought it's something users wanted.

deleted 5mo ago

[deleted]

LandoCalrissian 5mo ago

[flagged]

deleted 5mo ago
[deleted]
dang 5mo ago
"Please don't fulminate." Not saying you owe $BigCo better, but you owe this community better if you're participating in it. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

solid_fuel 5mo ago

> I am open to any (constructive) comments/suggestions Here's one: I think a senior sysadmin needs to sit you down in their office and have a very serious talk with you about the responsibility that comes with writing code other people run. I am serious. We used to have these talks with everyone who got sudo access. You shouldn't be shipping code if you don't understand the trust that is required of people in your position. This isn't just about this "feature" being active when AI features are disabled, the way you mis-implemented this has resulted in it modifying the commit message with the user even seeing it! That is malicious behavior, not an innocent little feature "to make life easier". I've fully switched off of VS Code to Kate now, which is faster and better behaved in most cases anyway. Bye.

ATMLOTTOBEER 5mo ago
He makes more money than you and you’re responding to his ai chatbot Seethe
- solid_fuel 5mo ago
  There’s more to life than money, child.
mplanchard 5mo ago
To be fair, looks like a PM vibe coded it and this person “just” gave it an approval with no comments after an LLM review.
- throwaway277432 5mo ago
  To be fair, that makes it worse for MS, not better. This should not be vibe-coded by someone who has absolutely no idea about any of these things.
  - mplanchard 5mo ago
    Oh yeah sorry, I was being sarcastic. I think it’s hilariously bad, but I also avoid MS products like the plague as a rule.

nsagent 5mo ago

Just for any future mea culpa, I'd recommend not hedging with comments like this one: > As folks mentioned here - many similar tools do this as well. It's really doubtful they have the same behavior people are complaining about here: namely including the authored by Copilot statement when it wasn't used (or even enabled).

sillysaurusx 5mo ago
Anthropic does by default. I had to put “no co-authored by lines in commits, ever” into my global settings. That’s pretty close to “included when it wasn’t used (or even enabled)” since it’s opt-in by default and you have to explicitly say no. It’s not even clear where to turn it off, I just rely on the AI to figure out not to do it.
- jstanley 5mo ago
  Maybe I misunderstand you, how is Claude doing commits where you don't use Claude? That is a very different case to VS Code which is something you can in fact use without Copilot.
  - lukan 5mo ago
    That is not what dmitriv claimed. He said this was a bug, the behavior should have been to add it only when AI was involved, which indeed, is what claude does by default. (Both is not fine with me)

captainepoch 5mo ago

dmitriv 5mo ago
It would be tricky, yes, since it depends on core editor functionality which is not exposed through the API.
- saghm 5mo ago
  So why did this feature get rushed out without proper testing? Are you claiming that not having this happen automatically for the commits where Copilot actually co-authored them is so urgent that it was necessary? I'd argue that this was extremely non-urgent and the fact that this got rushed so sloppily is a giant red flag about the priorities of you and your team. You asked about constructive criticism, and yet you're also acting like this is a one-off innocent mistake by only addressing what you've done to roll this back for now and address the immediate issue. I don't buy the premise that we could trust that this was a mistake made in good faith when it's something that you clearly should have known people would be so upset about if you got it wrong.

ares623 5mo ago

Just disable everything AI by default bro.

wren6991 5mo ago

> There was no ill intent by evil corporation I simply do not believe you

dmitriv 5mo ago
That's ok :-)
nicbou 5mo ago
It’s true. There was no ill intent, just a system of incentives that not only permitted but encouraged it.

freedomben 5mo ago

I just wanted to say, while I think this feature was a bad idea, I sincerely applaud your willingness to post here, knowing you'll get roasted. Seriously brave and commendable.

galonk 5mo ago
They pretended to be fronting up but didn’t respond to anything after that. Doesn’t seem very commendable to me.
- freedomben 5mo ago
  That's a good point, let's see if they come back and respond. It is the middle of the night in the US so they may be sleeping
  - dmitriv 5mo ago
    It is the middle of the night and I am responding. Anything specific you'd like me to respond to?
    - jdenning 5mo ago
      https://news.ycombinator.com/item?id=47992781 https://news.ycombinator.com/item?id=47992781 https://news.ycombinator.com/item?id=47992568 https://news.ycombinator.com/item?id=47992568 https://news.ycombinator.com/item?id=47992475 https://news.ycombinator.com/item?id=47992475
      - dmitriv 5mo ago
        First comment does not sound constructive - are you interested in my opinion on (n)vim? I am not a legal, so can't comment on legal things. However, I have already responded elsewhere here that this feature has nothing to do with licensing or ownership and was added for those that want the attribution. I understand the desire to see anything Microsoft as bad and evil, but we are really just trying to make a better experience. I'll respond to the third one, thanks!

PufPufPuf 5mo ago

My issue with this: if my intention is to never have these "co authored by <tool>" trailers in my commits, this is a sudden breaking change. What's worse, it is not immediately visible to the user. Now I could look like I use a not-company-approved AI. That's absolutely unacceptable, this could cost people their jobs. The "bug" (or "metrics boosting feature", as PMs call it?) that it claims all commits including ones never touched by Copilot are just icing on cake.

Gud 5mo ago

Nobody wants this shit. There is no timeline where developers want junk inserted into their commit messages.

nicbou 5mo ago

> There was no ill intent Only callous disregard for your users > many similar tools do this as well But since we have normalised that, it’s okay?

gib444 5mo ago

- A qualified sorry for one particular aspect of this - It wasn't our intention - Our users asked for it [you'll have to take our word for it] - Everyone else is doing it anyway - Statement that I am reasonable and will be co-operative with the community but with conditions That's a bingo!

croes 5mo ago

Rule of thumb, such features should always be Opt-In

rf15 5mo ago

You're an idiot. But I'm an idiot every day too, so I can relate. We can only learn from these mistakes, keep it up!

grey-area 5mo ago

First, revert the commit, then apologise.

dmitriv 5mo ago
I did both, didn't I? :-)
- grey-area 5mo ago
  At the time of writing it wasn’t reverted, but thank you for replying.
- deleted 5mo ago
  [deleted]

noir_lord 5mo ago

Changing a global default this way is hugely disrespectful to users. As a result I’ll be uninstalling vscode from all my machines, I’m tired of disabling things in vscode I didn’t ask for especially in regards to AI. There are open source tools that clearly respect users more and have a track record of not doing these kinds of stupid things. Be better.

macic 5mo ago

> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. Can you expand on this? Who "expects" their code editor to lie about using Copilot?

yreg 5mo ago
The supposedly expected functionality is very obviously that it marks copilot co-authored code as copilot co-authored, not the bug that is being reverted.
- dmitriv 5mo ago
  Correct.

jdenning 5mo ago

What is the use-case where you expect users would be happy that you modify their commit messages with MS marketing? Do you think it would be ok to edit every commit to append “written with VS Code”?

PunchyHamster 5mo ago
MS would absolutely do that if they could get away with. Hell, you'd get azure promo code with it

DavidVoid 5mo ago

Considering the size (and significance) of the VSCode user base, it feels like someone should be in charge of ensuring that default behavior doesn't change without good reason. Does anyone (or any team) have ownership of the extensions/git/package.json file?

saghm 5mo ago

> There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. As folks mentioned here - many similar tools do this as well. Please elaborate on what "similar tools" claim that commits are co-authored by AI when the AI features are all turned off. You're trying to defend the theoretically correct version of this that you didn't make, not the actual version you did make. > I am open to any (constructive) comments/suggestions It's hard to take this seriously; you know exactly what you did wrong here and what you should have done instead. Testing that this doesn't happen when Copilot was not used is extremely trivial; if you're not lying about it being unintentional, the fact that it didn't occur to anyone to do it still says more than enough about what the priorities are here. At absolute best, the priorities of you and your team are so fundamentally wrong that it's impossible to trust any of you going forward.

deleted 5mo ago

[deleted]

snet0 5mo ago

Why are you taking the fall and not the PM who authored the change (and submitted a PR with an uninformative title and no comment) and, I'm assuming, plays a role in managing the project?

deleted 5mo ago

[deleted]

FeistySkink 5mo ago

I appreciate your willingness to come and try and salvage this situation. What I don't understand is why are you the one doing this here and on GH, during the weekend, and not the PM who created the original PR? Surely they have some input. And another thing is, why was there absolutely no pushback from your part on any of the issues with the original PR, and why it was merged within hours in that state?

deleted 5mo ago
[deleted]

outlore 5mo ago

I feel like many replies are missing that this is satire

BatmanAoD 5mo ago
What makes you say that?

4b11b4 5mo ago

At a hackathon for my school recently a MS employee was a judge. ALL he wanted to tell me was that I should give VSCode another shot: "It's good now". You can't blame the dog, only the environment surrounding the dog.

NegativeK 5mo ago
Calling people dogs by analogy is not great. That aside, corporations and groups don't make decisions. People do. We can understand and empathize with what led them to that decision (and sometimes we might be looking at the wrong person), but they're still responsible.

deleted 5mo ago

[deleted]

CosmicBagel 5mo ago

I rarely comment on HN threads, but in this case big respect for coming out and owning the mistake, keep that shit up. If more people from MS had the guts to actually talk to their users, I'd probably have a lot less to complain about at work ¯\_(ツ)_/¯ Hopefully there's some good lessons to improve the process, not just feedback for this single incident.

kevinmgranger 5mo ago

> a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code This isn't enough. What was the _full train of thought_ for this? Why would it be added when AI isn't used?

_doctor_love 5mo ago

Thank you for your honesty, this is pretty brave. On the other hand...this feels like a situation where possibly you should not have said anything at all? The fact that you're on HN responding feels ill-advised to me. So far this is what I've gleaned: - Microsoft has PMs vibe coding against VSCode (by itself not necessarily a big deal) - Microsoft PMs can vibe code against VSCode and get stuff shipped to production with only a single approval That second one is a huge deal in my book. What I've learned now is that VSCode, a product with an enormous deployment base, is trivially compromised if the calls are coming from inside the house. Apparently all that has to happen for all users to be affected is a PM requesting you to "please approve my PR real quick, trying to get it in." And now there's a massive change in the wild, visible to many users. Being familiar with big corp dynamics, this really worries me. This does feel like a not-well-thought-out mistake but I can easily imagine many other scenarios that would be far worse. How can I trust VSCode going forward? How can I reassure my employer and fellow colleagues that it's safe to use? This is really a terrible look for Microsoft and very damaging to the reputation. I feel bad for you the engineer and PM here because with the web being what it is, folks are casting blame onto you. That's missing the point since the issue is that MSFT even let this happen in the first place. Engineering processes need to be halted and re-evaluated basically yesterday. If something like this happens again it may not be possible to rebuild the trust at all. I hate to say it but for myself this issue makes me strongly consider switching away from VSCode permanently, something I had not seriously considered before yesterday. Best of luck to everyone on the VSCode team.

liendolucas 5mo ago

Under which circumstances can you ever approve something like this? This goes beyond incompetence. Either you do not understand what important information a commit holds or what seems way more plausible to me is that Microsoft simply decided to try this out and see how people would react. > There was no ill intent by evil corporation... I will ever in my life buy that from Microsoft.

benchwright 5mo ago

One of my customers actually requires attribution to agents if they're used, not only for tracking purposes but also for understanding potential vectors for slopcode. It's been useful and occasionally enforced. That being said, implementation without due consideration and warning should be frowned upon.

EnglishMobster 5mo ago

Respectfully - You are working for one of the largest companies on the planet. You push code that gets used by millions of people. How on earth are you not thoroughly testing your changes??? How can something like this slip into a real build? Like, this is egregious. I work somewhere that makes software for a lot of users (although not as many as Microsoft!). We also need to ship quickly. But we work on a 45-day cycle, with 15 of those days being dedicated to ensuring we didn't add any awful bugs (and fixing them ASAP before it goes to users - or reverting the change until it is ready). I would expect Microsoft to have AT LEAST that amount of care. We can't trust that you are shipping software that even works anymore! What other changes are going in that are broken in more subtle ways? It used to be that VS Code was rock solid, and any issues were likely third-party extensions - but now it's a crapshoot, and I can't be sure if crashes etc. are the fault of extensions or Microsoft themselves! The VS Code team needs to use this mistake as motivation to lead the charge on making a quality editor. Not an editor that gets half-baked, untested changes pushed weekly. An editor that is dogfooded and where a mistake like this going to prod is unacceptable. Because if you don't, people won't trust your editor anymore. Just like people have stopped trusting your OS, and now users are fleeing it in such numbers that the Windows team has recognized they have a problem and are changing course. That WILL happen to VS Code and GitHub soon unless you actually start owning mistakes internally and fixing them before users find them.

Kadecgos 5mo ago

Whether or not the intent is good, the optics are extremely bad. I assume you are keenly aware that Windows, Office, and by extension, all of MS's customer facing products are not exactly regarded particularly well. Windows 11 specifically is a laughing stock today, even among folks who don't necessarily know computers, and a lot of that resentment is driven by 2 things: • Pushing AI everywhere when no one asked for it. • Not reading the room and adding junk features that no one wants. This change is both of those, again, wrapped up in another package. The timing of this is extremely bad for VS Code as a project as it looks an awful lot like, 'Microsoft is just shoving my AI junk into my stuff and failing to work on the features we actually want'. I'm not taking a side on this either way as I will jam a fork into my eye before I use VS Code over VS proper and have no stake in this, but I'm just saying that the powers that be that are approving these kinds of changes are ~continuing~ to fail to read the room. I'll add as someone who may be forced to consider VS Code in the future (Depending on if Windows unfucks itself before something critical breaks for me on W10), I would read something like that and I think rightly assume bad intent. I know VS Code and VS and Office and Windows are not the same team, but again, MS as a whole has a very serious optics problems and my read of this on the surface level is: "Oh, they tried to sneak in more AI junk, and when called out on it, they pushed it to the back, probably to make it a default again in some future update that they can hide it in". It just looks very, very bad at a time when no MS products have negative social capital to spend on this kind of stuff.

deleted 5mo ago

[deleted]

dmitriv 5mo ago

FYI - we have posted update on the subject with more details, links and analysis here: https://github.com/microsoft/vscode/issues/314311 https://github.com/microsoft/vscode/issues/314311 Hopefully this answers some more of the questions raised here. It also incorporates a lot of feedback from this thread with respect to next steps (thank you!).