You’re way quicker manually reviewing code compared to setting up everything just so that an LLM agent could do that.
Not only that, you're better off reviewing the code manually so you understand how everything works.
If you understand how things work, you can plan things out.
If you don't, you'll end up painting yourself into a corner.
If you are scared of that, commercial products are your choice.
Commercial products are not a panacea for bad software quality.
Code openness and code quality are independent, orthogonal axes.
Why not find a way to automate every single change that the vscode team makes that may break something?
Ultimately, users can do whatever.
But when they need help, they come to me.
I have a recommended list of settings for things that should already be defaults, to guide them away from footguns, and to prevent themselves from needing my help in the first place. But I also sometimes need to go around with a critical (usually temporary) list of changes for when a vscode update truly borks something up.
My concern was potentially needing to go around the office once a month for those critical fixes to once a week.
This is why I suggested multiple release channels. Have a weekly release for developers who are okay with the trade-off of more frequently broken setups for newer features faster, and have a monthly release for developers who want more stable environments.
It'd be a lot easier for me to run the weekly channel to be kept abreast of any changes, and I can support other coworkers on a monthly cycle.