Suggestions/autocomplete are force multipliers that can also go <1. When they are accurate, they save you a lot of typing/work. When they are inaccurate, you waste time processing the noise and have to do the work anyways.
Here's the problem (and why I personally hate overly smart IDEs) - my job is a creative one where most of the time I'm thinking and want my hands to be on autopilot. Writing out a skeleton class definition is something I can do blindfolded it takes almost no effort - an autocompleter getting that skeleton wrong (or writing a skeleton for a class with no interfaces and requiring me to backtrack through its garbled crap) takes effort. Reacting to things (observing the world and acting in response) will always take more mental effort than mindlessly slamming out some rote BS.
IDEs optimize a part of my job that I honestly could care less about (writing massive amounts of green field code) at the expense of making occasional mistakes when I'm doing my actual job (examining and tweaking existing code). This trade off is not worth it.
I'll uh - I'll keep function autocompletion though. Trying to remember whether my coworker called it `getWidget()` or `WidgetRegistry::get()` is something I don't need to waste brain cells on.
The history of useless code-automation tools is long. Back in the day, it was generating boilerplate API code for Windows etc. Write an app in a day!
But the lie was, in an app development schedule of 2000 hours, the tool made the 6-hour window definition effort into a 1-hour effort.
So what? It was good for demo-ware showing what an app might look like. But pointless for real work. Popular among the vaporware crowd, marketing and pitching etc. But not for software engineers.
CoPilot is interesting and I'm excited to see what happens with it but... IMO, if CoPilot is that valuable to us I think we've actually just failed (as an industry) to build a sufficiently high level language.
In my day job I produce a lot of infrastructural/lib tools for other developers to make use of and good syntax sugaring is worth it's weight in gold. Being able to write concise and powerful expressions without rote overhead can drastically increase dev productivity while reducing ongoing maintenance cost. If you've got a noise ratio near 50% you could probably benefit from some refactoring to kill a big chunk of whatever you're repeating so often.
Ah - and that's where it's really useful to have a set of eyes in the company watching for things your infrastructure needs to make everyone else more productive. The business specific rote stuff is usually a good idea to abstract away as well since it's so often highly critical and needs to be replicated often across the codebase and it absolutely must be consistent.
