Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Copilot

copilot.github.com

Post reply on HN
Print view View original

181–190 of 1001 posts

Re: GitHub Copilot

#181

Post by layla5alive »

crazygringo wrote: post #150
theden wrote: post #88

Calling it now, there will be a "Copilot considered harmful" post. If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? If you glance at it and it looks about right, you can potentially overlook bugs or edge cases, you'll lose confidence in your own code since you didn't properly conceptualise it yourself. Potentially for newer developers it robs them of active exper…

> If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? Not really. People are generally far faster at reading something and evaluating whether it's correct, than at writing something. In the same way it's faster to read a book than to write one. Not to mention the time it takes typing, fixing typos, etc. So this could genuinely be a huge timesaver if it helpful enoug…

I completely disagree with you. Reading code for correctness is difficult and not something most people do well at all. Reading code and reading for correctness are not the same, and most developers can write code a lot faster than they can verify it.

Re: GitHub Copilot

#182

Post by onion2k »

GitHub Copilot may suggest old or deprecated uses of libraries and languages

This raises two questions.

- is there a way (right now or planned for the future) for library maintainers to mark suggestions to be removed from the suggestions? I can foresee Copilot being used as a source of 'truth' among less experienced developers, and getting people turning up in the Issues or Discord asking why the suggestion doesn't work might be a bit jarring if the maintainers have to argue that "Github was wrong."

- if a library is hosted on Github is there a way to mark some examples as Copilot training data? Maybe by having a 'gh-copilot' branch in the repo that represents high quality, known-good examples of usage?

Re: GitHub Copilot

#183

Post by foobarbazetc »

natfriedman wrote: post #60

Hi HN, we've been building GitHub Copilot together with the incredibly talented team at OpenAI for the last year, and we're so excited to be able to show it off today. Hundreds of developers are using it every day internally, and the most common reaction has been the head exploding emoji. If the technical preview goes well, we'll plan to scale this up as a paid product at some point in the future.

Are those developers worried about having their jobs replaced by a code-writing AI? :)

I mean... why would 95% of developer jobs exist with this tech available?

You just need that 5% of devs who actually write novel code for this thing to learn from.

Re: GitHub Copilot

#184

Post by acid__ »

ffggvv wrote: post #134

wow surprised not one comment that’s scared of this being the step to automate away our jobs. maybe sooner than we think?

It’s one step closer, but still a good ways away.

- you still need to understand the code that copilot is writing, it just turns it from a recall/synthesis problem into a recognition problem

- most of the work above the level of a junior engineer isn’t about writing the actual code, it’s the systems design, architecture, communicating with external stakeholders, addressing edge cases, tech debt management, etc.

Re: GitHub Copilot

#185

Post by gugagore »

AnIdiotOnTheNet wrote: post #131
tux1968 wrote: post #125

Earlier quoted context omitted.

How many jobs have developers helped displace in business and industry? I don't think it's controversial that we become fair game for that same automation process we've been leading.

Indeed. It should be the goal of society to automate away as much work as possible. If there are perverse incentives working against this then we should correct them.

1. How do you define work differently from "that which should be automated"?

2. While I agree with your stance, it is not by itself sufficient. If you provide the automation but you do not correct the perverse incentives (or you worry about correcting them only later) that you mention, then you are contributing to widening the disparity between a category of workers (who have now lost their leverage) and those with assets and capital (who have a reduced need for workers).

Re: GitHub Copilot

#186

Post by dekhn »

6gvONxR4sf7o wrote: post #179
dekhn wrote: post #48

Earlier quoted context omitted.

No, a model trained on text covered by a license is not itself covered by the license, unless it explicitly copies the text (you cannot copyright a "style").

> you cannot copyright a "style" This line of thinking applies to the code generated by the model, but not necessarily to the model itself, or the training of it.

Thanks- in retrospect, I shoudl have explicitly said "code generated by the model".

Re: GitHub Copilot

#187

Post by ec109685 »

kif wrote: post #132
natfriedman wrote: post #60

Hi HN, we've been building GitHub Copilot together with the incredibly talented team at OpenAI for the last year, and we're so excited to be able to show it off today. Hundreds of developers are using it every day internally, and the most common reaction has been the head exploding emoji. If the technical preview goes well, we'll plan to scale this up as a paid product at some point in the future.

I visited https://copilot.github.com/ , and I don't know how to feel. Obviously it's a nice achievement, not gonna lie. But I have a feeling it will end up causing more work. e.g. the `averageRuntimeInSeconds` example, I had to spend a bit of time to see if it was actually correct. It has to be, since it's on the front page, but then I realized I'd need to spend time reviewing the AI's code. It's cool as a toy, but I…

It has the ability to generate unit tests as well, which will help cut down some on the verification side if you feed it enough cases.

Re: GitHub Copilot

#188

Post by dgb23 »

theden wrote: post #88

Calling it now, there will be a "Copilot considered harmful" post. If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? If you glance at it and it looks about right, you can potentially overlook bugs or edge cases, you'll lose confidence in your own code since you didn't properly conceptualise it yourself. Potentially for newer developers it robs them of active exper…

I honestly think this is solving a real problem with commonly used languages and their lack of syntax abstraction and expressiveness.

I can imagine this being very useful in helping to type out what I consider to be „mechanical noise“: Things that you have to type out to satisfy an expression rather than to convey semantics.

A good example of how this type of noise manifests:

Observe two programmers, both being similarly strong in terms of many concepts except for mechanical expertise. One uses the editor as an extension of their body, it’s beautiful to watch, the other stumbles awkwardly over the code until it’s finished. You can observe the latter in programmers who are very smart and productive, but they either didn’t train their mechanics deliberately or maybe they lack that kind of baseline eye hand coordination.

Re: GitHub Copilot

#189

Post by darepublic »

I knew this day was coming but it still stings. What I'm interested in is making copilot the main pilot.. i.e. for web development, why not just let this thing go on its own and have a separate module that attempts to compile the code + observe the differences in a web page functionality? No longer so crazy to say that shit like that is on the horizon. Then the middle managers can have their dream come true, they are the true benefactors! They can 'code' with copilot, and just endlessly iterate with it while figuring out what they want until they get a result they're happy with.

Re: GitHub Copilot

#190

Post by npteljes »

natfriedman wrote: post #107
Asmod4n wrote: post #89

Earlier quoted context omitted.

Might this end up putting GPL code into projects with an incompatible license?

It shouldn't do that, and we are taking steps to avoid reciting training data in the output: https://copilot.github.com/#faq-does-github-copilot-recite-c... https://docs.github.com/en/early-access/github/copilot/resea... In terms of the permissibility of training on public code, the jurisprudence here – broadly relied upon by the machine learning community – is that training ML models is fair use. We are certain this…

> ...the jurisprudence here – broadly relied upon by the machine learning community – is that training ML models is fair use.

If you train az ML model on GPL code, and then make it output some code, would that not make the result a derivative of the GPL licensed inputs?

But I guess this could be similar to musical composition. If the output doesn't resemble any of the inputs, or contains significant continous portions of them, then it's not a derivative.

Post reply on HN