Think of GitHub copilot as StackOverflow on steroids -- a quick way to write code when you're not sure how to achieve what you're trying to do.
After all, "How to parse a CSV file in Python" is longer than "csv.reader(file)" but without knowing that "csv.reader" exists, you have no other way but to tell Google what you need.
> Think of GitHub copilot as StackOverflow on steroids
This is how I already think of co-pilot, but these steroids seem to be mostly for prototyping.
SO often have comments and context such as "this works with 98% of browsers", "this isn't recommended, try X instead", "this works but can break library code because it changes the global scope", "this stopped working in version X" etc etc. Context like this can be important to take into account depending on what you're building.
Soon we can all quit our programming jobs and become managers managing copilot by writing copious amount of comments to persuade copilot into generating our software products. Finally no coding required!
I think the point is if you cannot/do not know how to code you cannot confirm what co-pilot is doing. Especially when it comes to complex topics like drawing context from natural online language using machine learning.
Entering the programming field then becomes an iterative loop of you instructing an AI to generate code, generate tests and iterate / re-adjust until it does what you want.
"You" as in the next generations of programmers in a decade or two.
I adore copilot and use it daily, but I'm pretty sure if I had always depended on it, I wouldn't be able to properly parse correct from incorrect programs.
It's a really really cool tool and a lot of these comments are just shallow dismissals from people who haven't actually used it and like to be reactionary on the internet because that's the world we live in apparently. But I think it works best when it's used by people with experience.
Hopefully future models with higher accuracy and research in grounding can get us to that point however.