For coding I agree, with the exception of PowerApps (I've tested that twice for a client and it's a horror show, the worst part is probably the assisted database design, which is a productivity drain, while in the UI in "manual mode" it's been pretty awful too.)

For the "helpful assistant" implementation in Office 365 - where most usage of CoPilot happens - it only performs well in the places it's most sloppy: Outlook email drafting and Word doc generation, for straightforward things. In structured documents like Excel and PowerPoint you'll spend more time correcting the bot than you would just doing the work. At least it was last time I did a run through it myself, back in August. So I guess there's the caveat that I could be outdated - I'd love to hear from someone that uses CoPilot in Excel in their day-to-day.

The feeling I have with these CoPilot implementations is that it is molded into the larger MS framework, which has not been without friction ever, imho. I suspect that the reason for this is that it must respect the RBAC environment, what is now called the Microsoft Graph, so it has no choice but to integrate tightly with the underlying MS frameworks. You can't just add simple calls to it because then you'd need to separately authenticate the bot every time?