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

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.

> 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?

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/1e70...

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?

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

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

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.

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

Literally who?

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

Brave man. RIP your inbox.

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.

[dead]