Hacker News new | ask | show | jobs
by somebehemoth 54 days 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.
4 comments

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

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

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.
This is honestly the most concerning part of all of this. You're saying you knew that this exact bug was present up front and still decided to release it?

This basically invalidates the entire premise that it was an innocent mistake. It's impossible for me to believe that you actually thought that people wouldn't care about 100% of their commits being attributed to Copilot even when it was never used. Either you're misconstruing what you caught with the testing beforehand or your entire development process is tainted, because there's no way that a non-evil corporation would see this default behavior and think that people would be fine with it. It seems far more likely you just thought you could get away with it.

Agreed, this approach feels like folks at Microsoft still feel they have enough karma to burn. It's way past that.
I think there is a "ship fast" component here that should be adjusted. Product Management introduced weekly "stable" releases in March, no matter the content.
don't call it a bug, they were intentionally aggressively pushing marketing copy into people's commits.

this was malice or greed

I think so too, but my point is that even according to their own words about what happened, the best possible interpretation is that they didn't mean to do it but knowingly let it happen. I agree that a worse version is more likely, but it's pretty damning when even the ceiling for what they can plausibly claim is "we intentionally didn't bother stopping it once it happened accidentally".
Seems that they released it only in some internal / alpha version.
Thank you. My personal opinion is the idea of weekly releases should be discarded. It's too easy to release broken stuff in non-insiders updates.

I think many people agree here.

A generous read of this comment might be that you did catch it internally in testing AFTER it shipped but shrugged it off as something you'd patch in the next release in a week or two. Is that what you meant here?

Or that it was caught but didn't surface fully before release?

A helpful governance policy here might be that anything that mutates user content without opt-in consent requires a distinct sign-off or a double sign-off. If the goal is to prevent this from happening in future.

You say in another comment this slipped through testing. Can you elaborate on exactly what was caught in internal testing?
I don't really understand this. There was a known bug and it was shipped anyway? I must be misunderstanding
It got to production because they wanted it.

> This seems hard for me to believe. I expect more from Microsoft.

Those are some baseless expectations given the entire company's history

Expecting more from Microsoft is the new showing-my-age: of being born in this century.
I saw a lot of "they made a game I like (Halo), therefore they must not be that bad" from the gaming cloud that only experienced the console side of it
Also, who/what group is pushing for this change internally and what is the opinion of the team implementing it? What is the road map and vision for AI in VSCode?