No meu caso a produtividade despencou, ele cometia muitos erros e escrevia muita coisa desnecessária. Eu tinha basicamente que escrever o código duas vezes, uma pra criar e outra para consertar o que o Copilot fazia.
Das duas uma, ou eu estava fazendo tudo errado, ou o copilot tava. Enfim, acredito que a primeira opção seja a realidade.
Eu tive a mesma impressão, detonou minha produtividade, atrapalhando o desenvolvimento, os códigos que sugeria, no final eu teria que ajustar eles de qualquer forma.
No questito de coisas manuais como instânciar estados, useEffect simples (atualmente trabalho com React) ele se ia bem, mas com lógicas moderadas/complexas se tornava mais um problema do que solução.
Minha experiência pessoal com o copilot:
Normalmente quando vou implementar algo que quero produtividade, abro uma classe parecida e deixo lado a lado. O copilot simplesmente entende tudo por assimilar o contexto da outra aba aberta no editor, assim evito muitas digitações enfadonhas e ele deixa a implementação no mesmo estilo da outra.
Para criação de lógicas complexas ele falha quando tento fazer que ele escreva tudo de uma vez. Escrevendo esse texto aqui tive a idéia de tentar particionar o "raciocínio" dele da mesma maneira que particionamos uma função grande em funções menores pra ter mais contexto do que está acontecendo. Pensei isso por que quando crio uma função e nomeio ela exatamente com o que ela deveria fazer, o copilot entende e escreve o código corretamente.
Vou tentar essa abordagem pra funções com lógica complexa, e quem sabe escrever um artigo aqui para falar como foi.