I hear you. But I see this as a horrible thing. Now people are going to be further absolved of responsibility of thinking through the problem first and then implementing it after.
Won’t this result in more junk code?
Won’t this result in more junk code?
I am honestly pleased I am not using a Microsoft IDE and won't be part of all this crap. I have already started creating new projects on GitLab from now on.
It's a catch-22. If you can express accurately your need (the problem), then you're likely to be able to implement a solution to that need without an AI helper. In fact, you may find the AI helper to be a greater time cost than if you had just done it yourself. But if you are inexperienced such that you need the AI to help, then you probably aren't going to accurately expresss the need. And as such, you'll end up with "a solution", but perhaps to a problem that is different enough that there will be a net loss in time. Or worse, your AI "solution" ends up in production, and the damage comes later and at higher cost.
I fear hordes of inexperienced developers, mindlessly clicking accept on the first suggestion, and then on the second, third, and so on, until one seems to work. And the more advanced tools like this get, the harder it'll be to review the code and make sure nothing's messed up.
I guess we'll have to think long and hard about what safeguards to build against these risks.
> One challenge researchers should consider is that as capabilities improve, it may become increasingly difficult to guard against “automation bias.”
If anything this just makes that easier to do wrongly. It wants to offer you code that’s not yours that you didn’t conceive of thoughtfully.
[1] https://gist.github.com/0xabad1dea/be18e11beb2e12433d93475d7...
[2] Two quotes from the article: "Oh, and they're both wrong." and "Both look plausibly correct at a glance". If the entire selling point is to write code faster, are we really going to give the code more than a glance? Personally, I find figuring out code I didn't write a lot harder than writing it from scratch, in most cases, because I understand my intent, while I don't understand the intent of others without some deep thinking.
(this what hiring in ML is like)
No, but not because there's a second person writing code, rather because there's a second person to think about it and think through how it works and interacts with the rest of the system.
As I said in another comment, actually writing code is only a small part of my work as a programmer, with pair programming, there is someone else who can do all the other things with me. Copilot cannot help with those things, certainly not in its current form.
The problem with Copilot as a fancy tab completion is that it can generate quite complex code, and, if code reviews are anything to go by, understanding other people's badly documented code is usually harder than writing your own. If its non-trivial, there's a strong urge to just accept it without really understanding all the details, because it appears to work. Or to just get a shallow grasp of it before deciding its good enough. Copilot will not help here, if anything, it makes it worse if it generates subtly broken code that otherwise looks correct and is too complex to really scrutinize and understand.
A better approach, I think, would be if you write unit tests and Copilot were to take them as input and write code to pass them. At least then it would be grounded in tests.
Right now, it seems Copilot shines for boilerplate code, but is possibly a net negative for anything actually complex (which it will still happily attempt to generate without warning you). A disciplined programmer will likely benefit from Copilot, but I shudder to think about what code a lazy, overworked or too-beginner-to-spot-problems one might let slip through (based on this recent article about copilot: https://gist.github.com/0xabad1dea/be18e11beb2e12433d93475d7...)