Notebooks programming has a flow of "execute a small bit of code, check the results, and iterate", and this fits perfectly with Copilot since you still need to check if the suggestions work.
Maybe this kind of programming is where Copilot finds a niche, maybe not. I don't know. I'm skeptical of its use in larger applications where you can't trivially check if the code you wrote (with its help) did what you want. I think there needs to be a lot more tooling built around that to really make it compelling for larger applications like that, likely in the form of more editor tooling integrations. But I think it's promising. I wrote about that a little more here: https://phillipcarter.dev/posts/four-dev-tools-areas-future/...
Instead, I would like a system telling me about obscure things, traps, vulnerabilities, performance issues, etc... like the machine learning linter. The way I could see it work is by matching my code with bugfix commits. For example if several commits replaces "printf(buffer)" with "printf("%s", buffer)" and I write "printf(buffer)", I want an AI to tell me "code like yours is often replaced in commits, it may be wrong", bonus points if it can extract the reason from commit messages ("format string vulnerability") and suggest a replacement ("printf("%s", buffer)"), mega-bonus if it can point me to good explanation of the problem.
Pissing lines of code is easy, I can do it, anyone with a couple weeks of training can do it, I don't need a bot to help me with that. Thinking about everything while I am pissing my lines is hard, and I will welcome a little help.
A nice thing about that approach is that it is unlikely to result in worse code than what I would have written by myself, because it will be designed to trigger only on bad code.
But linters work with hand crafted static rules, which is good and the idea is not to replace them. The idea is to used big data techniques to find unwritten rules based on commit histories, the idea being that we are more likely to remove bad code than good code. So if your code looks like code that is often removed, is is most likely bad, even if it doesn't match an explicitely written anti-pattern.
There are also other triggers of code removal and refactoring that are outside the code base, such as an organisation migrating to a different platform. An AI trained on a large public commit history could encourage a general shift towards already-established big players, punishing smaller organisations.