Awesome summary and thanks for trying it for the rest of us!
Copilot sounded terrible in the press release. The idea that a computer is going to pick the right code for you (from comments, no less) is really just completely nuts. The belief that it could be better than human-picked code is really way off.
You bring up a really important point. When you use a tool like Copilot (or copypasta of any kind), you are introducing the additional burden of understanding that other person's code -- which is worse than trying to understand your own code or write something correct from scratch.
I think you've hit the nail on the head. Stuff like Copilot makes programming worse and more difficult, not better and easier.
While I accept most of the concerns, it's better than your comment suggests. I see some promise for it as a tool for reminding you of a technique or inspiring you to a different approach than you've seen before.
For example, I wrote a comment along the lines of "Find the middle point of two 2D positions stored in x, y vectors" and it came up with two totally different approaches in Ruby - one of which I wouldn't have considered. I did some similar things with SQL, and some people might find huge value in it suggesting regexes, too, because so many devs forget the syntax and a reminder may be all it takes to get out of a jam.
I'm getting old enough now to see where these sorts of prompts will be a game changer, especially when dabbling in languages I'm not very proficient in. For example, I barely know any Python, so I just created a simple list of numbers, wrote a "Sort the numbers into reverse order" comment, and it immediately gave me the right syntax that I'd otherwise have had to Google, taking much longer.
Maybe to alleviate the concerns it could be sandboxed into a search engine or a separate app of its own rather than sitting constantly in my main editor - I would find that a fair compromise which would still provide value but require users to engage in more reflection as to what they're using (at least to a level that they would with using SO answers, say).
Yeah, but... I mean, I guess we all agree that copying code from, let's say StackOverflow without checking if it really does what you want it to do is a bad thing? Now here we have a tool that basically automates that (except it's copying from GitHub, not StackOverflow), and that's supposed to be a good thing? Even if its AI is smarter, you would still have to check the code it suggests, and that can actually be harder than writing it yourself...
The big boost, that I think parent is alluding to, is for rusty (not Rust!) languages in the toolbox, where you may not have the standard library and syntax loaded into your working memory.
As a nudge, it's a great idea. As a substitute for vigilance, it's a terrible idea.
I suspect that's why they named it Copilot instead of Autopilot, but it's unfortunately more likely to be used as the latter, humans being humans.
Right, so it might occasionally be useful as a search tool for divergent ideas of different approaches to a problem, and your suggestion to sandbox it in a separate area works for that.
But that does not seem to be it's advertised or configured purpose, sitting in your main editor.
This is good stuff. As a search engine, it could very well be useful. As another poster pointed out, if some context or explanation were provided along with the source suggestions, its utility as a reference would really grow.
I totally agree with you that prompted help is a big deal and just going to get bigger. We have developed a language for fact checking called MSL that works exactly this way in practice -- suggesting multiple options rather than just inserting things.
One of the things that interests me about this thread is the whole topic of UI vs. AI and how much help really comes from giving the user options (and a good UI to discover them) vs how much is "AI" or really intelligence. I think the intelligence has to belong to the user, but a computer can certainly sift through a bunch of code to find a search engine result and, those results could be better than you get now from Google &Co.
If they're using something like GPT-3 on the backend, which they probably are, it probably can't provide any explanations or context (unless the output is memorized training data, like this); the output can be somewhat novel code not from any particular source, and while it might be possible to find relevant information on similar code, this would be a hard problem too.
It's really weird for software engineers to judge something by its current state and not by its potential state.
To me, it's clearly solvable by Copilot filtering the input code by that repository's license. It should only be certain open source licenses, maybe even user-choosable, or code-creators can optionally sublicense their code to Copilot in a very permissable way.
Secondly, a way for the crowd to code review suggestions would be a start.
I've been in the business a long time and I just don't believe in generalized AI at all. Writing code requires general (not artificial) intelligence. All of these "code helping" tools break down quickly because they may be searching for and finding relevant code blocks (the "imperative hell" referred to by another commenter), but they don't understand the context or the overall behavior and goals of the program.
Writing to overall goals and debugging actual behavior are the real work of programmers. Coming up with syntax or algorithms are 3rd and 4th on the priority list because, lets face it, it's not that hard to find a reference for correct syntax or the overall recipe implied by an algorithm. Once you understand those, you can write the correct code for your project.
I do think Copilot has potential as a search engine and reference tool -- if it can be presented that way. But the idea of a computer actually coming up with the right code in the full context of the program seems like fantasy.
If we're coming up with potential uses, I think they got the direction wrong.
Don't tell me what to do, tell me what not to do. "this line doesn't look like something that belongs in a code base", "this looks like a line of code that will be changed before the PR is merged". Etc.
That would be fantastic! Imagine if it could catch common errors before you make them. So many things in loops and tests that we mess up all the time. My favorite is to confuse iterating through an array vs an object in JS. I'd love to have Gazoo step in and say, "Don't you mean, this, David?"
> It's really weird for software engineers to judge something by its current state and not by its potential state.
No, we're not afraid of Copilot replacing us. The thought is ridiculous, anyway. If it actually worked, we would be enabled to work in higher abstractions. We'd end up in even higher demand because the output of a single engineer would be so great that even small businesses would be able to afford us.
Yes, we are afraid of Copilot making the entire industry worse, the same way that "low-code" and "no-code" solutions have enabled generations of novices to produce volumes of garbage that we eventually have to clean up.
Practically every open source license requires attribution, if copilot has a licensing issue, training a model on only repositories with the same license won't fix it except for the extremely rare licenses which do not require attribution.
Could they handle this by generating a collective attribution file that covers every (permissively licensed) repository that Copilot learned from?
Of course this would be massive, so from a practical consideration the attribution file that Copilot generates in the local repository would have to just link to the full file, but I don't think that would be an issue in and of itself.
Maybe? Might depend on the license, I doubt the courts would be amused.
Almost certainly a link would not suffice, basically every license requires that the attribution be directly included with the modified material. Links can rot, can be inaccessible if you don't have internet access, can change out from underneath you, etc.
Makes sense. Maybe something like git-lfs/git-annex would be sufficient to address the linking issue, but it seems like the bigger concern is whether a court would accept this as valid attribution. In a sense it reminds me of the LavaBit stunt with the printed key.
I think a judge could be persuaded that a list of every known human does not constitute a valid attribution of the actual author, even though their name is on the list. The purpose of an attribution is to acknowledge the creator of the work, and such a list fails at that.
Makes sense. That's probably the best interpretation here. Any other decision would make attribution lists optional in general for all practical purposes.
Stuff like Copilot makes programming worse and more difficult, not better and easier.
Copilot makes programming worse and more difficult if you're aiming for a specific set of coding values and style that Copilot doesn't generate (yet?). If Copilot generates the sort of code that you would write, and it does for a lot of people, then it's definitely no worse (or better) than copying something from SO.
The author of a declarative, functional C# framework likely has very different ideas to what code should be than some PHP developer just trying to do their day-to-day job. We shouldn't abandon tools like Copilot just because they don't work out at the more rigorous ends of the development spectrum.
>If Copilot generates the sort of code that you would write, and it does for a lot of people, then it's definitely no worse (or better) than copying something from SO.
Disagree.
Most SO copy-paste must be integrated into your project -- maybe it expects different inputs, maybe it expects or works with different variables -- whatever, it must be partially modified to work with the existing code-base that you're working with.
Copilot does the integration tasks for you. When one might have had to read through the code from SO to understand it enough to integrate it, the person using Copilot need not even invest that much understanding.
Because of these workflow differences, it seems to me as if Copilot enables an even more low-quality workflow than offered by copy-pasting from SO and patching together multiple code-styles and paradigms while hoping for the best; Copilot does that without even the wisdom that an SO user might have that 'this is a bad idea.'
I'm not firmly for or against the concept of Copilot, but it's fascinating to me that it will introduce an entirely new class of bugs. Rather than specific mistakes in certain blocks of code and edge case errors in handling certain inputs, now we're going to have lazy/overworked/junior developers getting complacent and committing code they haven't reviewed that isn't even close to their intent. Like you could have a backend method that was supposed to run a database query, but instead it sends the content of an arbitrary variable in a POST request to a third-party API or invokes a shell to run `rm -rf /`.
To me, the most interesting aspect is the new class of supply chain security vulnerabilities it will create. How people will act to exploit or protect¹ against those will be very interesting.
1 - I don't expect "not using a tool that generates bad code" to be the top option.
The arguments that the GP makes are not based on a specific style or value of coding. Instead, they're based on the simple truth that it is harder to understand code that somebody else wrote.
In some cases the benefits of doing so outweigh the costs (such as using a stack overflow answer that's stood the test of time for something you don't know how to do), but with Copilot you don't even get the benefit of upvotes, human intent, or crowdsourced peer review.
I don't think they work out past trivial applications. Any non trivial app requires an understanding of a much larger part of the codebase than a tool like Copilot is looking at at any one time.
Copilot does not understand the code in toto and is therefore really useless for debugging (70% of all coding) and probably useless for anything other than very simple parts of an app.
Any non trivial app requires an understanding of a much larger part of the codebase than a tool like Copilot is looking at at any one time.
I don't think that's important. Copilot, at least as it's been demo'd so far judging by the examples, is to help you write small, standalone functions. It shouldn't need to know about the rest of the application. Just as the functions that you write yourself shouldn't need to know about the rest of the application either.
If your functions need a broad understanding of the codebase as a whole how the heck do you write tests that don't fail the instant anything changes?
The reality of code is that stuff breaks when connected to other stuff, as it eventually must be for real work to happen. There's no getting around that.
Since that's where the work of programming is, debugging connected applications (not writing fresh, unencumbered code, a rare luxury), a tool that offers no help for that is, well, not much help.
Copilot sounded terrible in the press release. The idea that a computer is going to pick the right code for you (from comments, no less) is really just completely nuts. The belief that it could be better than human-picked code is really way off.
You bring up a really important point. When you use a tool like Copilot (or copypasta of any kind), you are introducing the additional burden of understanding that other person's code -- which is worse than trying to understand your own code or write something correct from scratch.
I think you've hit the nail on the head. Stuff like Copilot makes programming worse and more difficult, not better and easier.