← Back to context

Comment by somebehemoth

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

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

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?

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

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.

  • You underestimated the impact of altering commit messages of millions of users? I find that very hard to believe. Commit messages are sacred to many developers. This has been true for me with multiple teams and multiple developers for years.

    If you caught the bug in testing, how did the bug make it into production? Are you saying your process correctly identified the bug and your people decided to ship it anyways?

    With all due respect, your responses don't make sense unless we view both your team and its processes as inexperienced and lacking robustness.

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

    • don't call it a bug, they were intentionally aggressively pushing marketing copy into people's commits.

      this was malice or greed

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