News for hackers. Stuff that matters.
Re:Risk Assessment of GitHub Copilot by ohazi on Monday July 12, 2021 @01:55PM (#27813095)
I'm surprised that so much of the discussion around Copilot has centered around licensing rather than this.

You're basically asking a robot that stayed up all night reading a billion lines of questionable source code to go on a massive LSD trip and then use the resulting fever dream to fill in your for loops.

Coming from a hardware background where you often spend 2-8x of your time and money on verification vs. on the actual design, it seems obvious to me that Copilot as implemented today will either not provide any value (best case), will be a net negative (middling case), or will be a net negative, but you won't realize that you've surrounded yourself with a minefield for a few years (worst case).

Having an "autocomplete" that can suggest more lines of code isn't better, it's worse. You still have to read the result, figure out what it's doing, and figure out why it will or will not work. Figuring out that it won't work could be relatively straightforward, as it is today with normal "here's a list of methods" autocomplete. Or it could be spectacularly difficult, as it would be when Copilot decides to regurgitate "fast inverse square root" but with different constants. Do you really think you're going to be able to decipher and debug code like that repeatedly when you're tired? When it's a subtly broken block of code rather than a famous example?

That Easter example looks horrific, but I can absolutely see a tired developer saying "fuck it" and committing it at the end of the day, fully intending to check it later, and then either forgetting or hoping that it won't be a problem rather than ruining the next morning by attempting to look at it again.

I can't imagine ever using it, but I worry about new grads and junior developers thinking that they need to use crap like this because some thought leader praises it as the newest best practice. We already have too much modern development methodology bullshit that takes endless effort to stomp out, but this has the potential to be exceptionally disastrous.

I can't help but think that the product itself must be a PSYOP-like attempt to gaslight the entire industry. It seems so obvious to me that people are going to commit more broken code via Copilot than ever before.

Re:Risk Assessment of GitHub Copilot by qbasic_forever on Monday July 12, 2021 @02:49PM (#27813639)
IMHO they built the opposite of what's actually useful for real-world use. Copilot should have been trained to describe what a selected block of code does, not write a block of code from a description. It could be extremely useful when looking at new or under-documented codebases to have an AI that gives you a rough hint as to what some code might be doing. For example if you select some heinous spaghetti code function, press a button, and get a prompt back that says "This code looks like it's parsing HTML using regex (74.2% confidence)" it could be much easier for folks to be productive on big codebases.
Re:Risk Assessment of GitHub Copilot by heavyset_go on Monday July 12, 2021 @06:15PM (#27815756)
But that would require hiring tons of software engineers to label training data accurately.

Why do that when you can just train a GPT-3 model on public repositories and call it a day?

Re:Risk Assessment of GitHub Copilot by qbasic_forever on Monday July 12, 2021 @06:40PM (#27815943)
No presumably copilot skirted that need by just analyzing the AST of code they host and using the nearby comments to identify what a section of code is meant to do. This would use the same dataset but solve the opposite problem, generate a description from a block of code AST as input.
Re:Risk Assessment of GitHub Copilot by patchguard on Tuesday July 13, 2021 @02:44AM (#27818195)
> copilot skirted that need by just analyzing the AST of code they host and using the nearby comments to identify what a section of code is meant to do.

I'm curious what it spills out for things like "Todo", or "this is probably broken", etc.

Re:Risk Assessment of GitHub Copilot by gspr on Monday July 12, 2021 @04:29PM (#27814697)
Sorry for adding just noise, but I think this is the most insightful comment I've read on HN this year. Excellent analysis and idea!
Re:Risk Assessment of GitHub Copilot by moralestapia on Monday July 12, 2021 @06:39PM (#27815940)
Something like this would be amazing, particularly for poorly written, obfuscated or even disassembled/decompiled code!
Re:Risk Assessment of GitHub Copilot by dkersten on Monday July 12, 2021 @03:04PM (#27813780)
Now that is a damn good idea!
Re:Risk Assessment of GitHub Copilot by rantwasp on Monday July 12, 2021 @03:09PM (#27813826)
it’s a good idea. depending on how “smart” it is it can be extremely hard to pull off
Re:Risk Assessment of GitHub Copilot by toomuchtodo on Monday July 12, 2021 @03:19PM (#27813904)
Ideally, you'd train/teach it using PR code reviews. Human labeling and all that jazz.
Re:Risk Assessment of GitHub Copilot by JetSpiegel on Thursday July 15, 2021 @05:09PM (#27850168)
> Ideally, you'd train/teach it using PR code reviews.

Which is why, based on Windows state, it will never come out of Microsoft.

Re:Risk Assessment of GitHub Copilot by randallsquared on Monday July 12, 2021 @06:01PM (#27815616)
I'm not sure I understand how you envision this working, given the underlying technology. You'd have to have a pretty large cache of such analyses to train on, right?
Re:Risk Assessment of GitHub Copilot by qbasic_forever on Monday July 12, 2021 @06:41PM (#27815955)
Github has a huge amount of source code and likely for copilot they already had to transform it into an AST to look at comments and nearby code. This would use the same dataset but build the opposite model--input a block of code AST and get a guess as to what the description (i.e. comment) should be for it.
Re:Risk Assessment of GitHub Copilot by randallsquared on Monday July 12, 2021 @09:07PM (#27816779)
My naive assumption is that they don't have nearly that level of control. I'd be surprised if they have an AST step before the tokenizer, or in it.
Re:Risk Assessment of GitHub Copilot by im_down_w_otp on Monday July 12, 2021 @02:17PM (#27813325)
This is the thing that made no sense to me about it as a premise. Doing correct program synthesis is really hard even when you have really opinionated and well-defined models of the domain (e.g. the Termite project for generating Linux device drivers). The domain model for Copilot is somewhere between non-existent to so open-ended (i.e. all the diverse code on Github, et al.) as to be functionally non-existent.

A bare minimum baseline validation check for Copilot would be to see if it provides you code which won't compile in-context. If it will, then that means it's not even taking into account well-specified domain model of your chosen programming language's semantics. Which, upon satisfaction, is still miles away from taking into account the domain of your actual problem that you're using software to solve.

The only place where the approach taken, as-is, makes sense to me is for truly rote boilerplate code. However, that then begs the question... how is this machine learning approach more effective than a targeted heuristic approach already taken by existing IDE tooling, etc.?

FWIW, I don't think any of this is lost on GitHub. I think Copilot is more likely a tremendously marketable half-step and small piece of a larger longer-term strategy unfolding at Microsoft/GitHub to leverage an incredible asset they're holding, i.e... practically everybody's source code. The combination of detailed changelogs, CI results (e.g. GitHub actions), Copilot, and a couple other key pieces makes for a pretty incredible basis for reinforcement learning to multiple ends.

Re:Risk Assessment of GitHub Copilot by juped on Monday July 12, 2021 @02:44PM (#27813589)
I'd like to think that it's because Copilot is so obviously useless that that part of it doesn't need discussion.
Re:Risk Assessment of GitHub Copilot by bryanrasmussen on Monday July 12, 2021 @02:07PM (#27813225)
>It seems so obvious to me that people are going to commit more broken code via Copilot than ever before.

Maybe we should use Copilot to commit more open source code meaning that Copilot becomes more and more corrupted and unusable!

of course then we end up with a bunch of bad open source code that will turn people off of using open source.

Gee, I don't think Microsoft really thought this one through.