https://visualstudio.microsoft.com/services/intellicode/
I bet it's the same people, trying to push their crap into all sorts of successful products.
Edit: looks like I remembered incorrectly: https://docs.microsoft.com/en-us/visualstudio/intellicode/overview#telemetry
> No user-defined code is sent to Microsoft
Obviously a program that is able to write actual great code reliably would be spectacular, but we aren't there yet, I don't think Copilot presently is able to make me meaningfully more productive.
At the end of the day I think it boils down to this simple fact: you can't imperatively codify what makes the face of a person beautiful for you because that's too complicated, similarly you can't codify what makes for beautiful code to your eyes, it's something that must be learned from examples.
I don't doubt Copilot is also quite a problem to solve, most likely indeed harder, though in that case at least there's an abundance of training data.
I agree that something like that would be much easier to make in theory, hence why I'm suggesting it since maybe it could be made ~perfectly, which Codepilot isn't (we haven't unlocked AGI yet).
The danger here isn't with experienced developers (this is, obviously, a tool with great potential for productivity). It's with people who just blindly trust what the robot spits out.
Once code like that is implemented in a mission-critical system without discernment, all hell will break loose.
Edit: worth watching this for context https://www.youtube.com/watch?v=ZSRHeXYDLko
It's not Copilot's problem. Powerful tools can be misused by anyone.
Not hiring subpar developers, especially in a massive company isn't a matter of "if" but "when." And it only takes one screw up to crash an airplane because of software.
And guess who massive companies trust for their technology?
Microsoft.
What happens when people think their "self driving" cars are more capable than they actually are? Many times, you are better off in a dumb car, because your expectations are such that you have to pay attention to a continuous stream of events and respond in a stateful manner.
If you try to bootstrap a holistic understanding of your problem in between bursts of auto-generated code, I don't think you are going to have a fantastic time of it.
This kind of tooling is akin to the crossbow.
It will allow for less skilled folks to push out code that is like other code at great speed. A copy pasta accelerator if you will.
Adequately paid for value captured (hence why companies are willing to pay for them at this rate).
Not a moral statement, but this gives more tools to those in power.
What are your thoughts on that? I can lean that way just because I have a genius mechanical engineer friend who only makes 60k in his 30s.
Realistically, it just means that, rather than your coworker code-reviewing you and making a handful of comments, you get a machine to do that, and get two or so comments from your coworker about the business logic.
To answer your question: never.
There's a little demo about that here: https://copilot.github.com/
It's "just" an autocompletion system basically, if you write something that looks like the beginning of a test it should understand that and try to autocomplete that.
Naive autocomplete, as implemented in Excel since forever ago (and I'm sure long before that, I'm just familiar with being annoyed by Excel suggesting wrong entries from its simple and over-eager autocomplete system), merely matches a sequence of characters - if I typed "aut" again in this paragraph it will suggest "autocomplete" because I recently typed it. Implementing it is the kind of task you give to a first-year programming student to practice string matching data structures, similar to a spell checker that merely checks that a string exists in a dictionary.
There's a spectrum from 'just' autocomplete, to a syntax-aware system like VS Intellicode, to this, and eventually beyond this. As mobile predictive text is to a spell checker, so Github Copilot is to autocomplete. As mobile predictive text is to GPT3 [1], so Github Copilot is to...what next? GPT3 is not just a spell checker.
[1] Also by OpenAI: https://news.ycombinator.com/item?id=23345379
Here you go :)
"GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set. Here is an in-depth study[1] on the model’s behavior. Many of these cases happen when you don’t provide sufficient context (in particular, when editing an empty file), or when there is a common, perhaps even universal, solution to the problem. We are building an origin tracker to help detect the rare instances of code that is repeated from the training set, to help you make good real-time decisions about GitHub Copilot’s suggestions."
I think talking about exact text matches to existing code is a red herring. If you took GPL code and ran it through an obfuscator that changed every byte of the code to new code, that resulting code would be derivative and would need to be licensed under GPL too.
Thank you Microsoft for ushering in a new era of free software.
> I agree to these additional telemetry terms as part of the technical preview
Scott McNealy, CEO Sun Microsystems, 1999
Perhaps we should ask Scott if he is willing to share his browsing history, his personal photos and his passwords with the rest of us or maybe if I can come into his house?
After all, "You have zero privacy anyway"
I’m not sure how this would apply to secret keys or flat files with customer data/PII, but in any case that makes it a non-starter for me.
Their “Please do not share this URL publicly.” Banner at the top of the page which disclosed this info makes my skin crawl a bit…
If I were only working on public projects I would be on board right away, it looks like a big time saver.
Am I being to paranoid here?
No.
They already admitted that they send telemetry of the code you give it and its training set already has personal information in it anyway, despite what is being hyped up here by the fanatics, even when someone said that 'Copilot guesses the exact code I want to write about one in ten times' [0]
No thanks and certainly no deal.
I always ask whoever disagrees to have the courage to sit down and discuss, but they always run away and never explain themselves.
Look really suspicious of either bot behaviour or just some angry hater don't you think?
So everything generated also GPLv2?
How would we classify that legally when it comes to training and generating code? Would you argue the machine is just picking up best practices and patterns, or would you say it has gained specifically-licensed or proprietary knowledge?
More generally, keep in mind that the legal world, despite an apparent focus on definition is very bad at dealing with novelty, and most of it will end up justifying a posteriori existing practices.
Even a search engine is not merely a "compilation of facts". A trained model is the result of analysis and reasoning, albeit automated.
I believe you're referring to Clean Room Design[1].
I was wondering the same thing, especially with MS being behind both.
edited: or this? https://docs.microsoft.com/en-us/visualstudio/intellicode/custom-models
Take a look at https://karpathy.github.io/2015/05/21/rnn-effectiveness/
At the same time, I would not be surprised if there are outputs that do correspond to the source training data.
[1] https://en.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,_Inc.
edit: from https://copilot.github.com/
> What is my responsibility when I accept GitHub Copilot suggestions?
> You are responsible for the content you create with the assistance of GitHub Copilot. We recommend that you carefully test, review, and vet the code, as you would with any code you write yourself.
Well, that solves that question.
And yes, of course github is not going to take responsibility for things you do with their tools.
It's only infringement if the portion copied is significant either absolutely or relatively. A line here or there of the millions in the Linux kernel is okay. A couple of lines of a haiku is not. Copyright is not leprosy.
Wouldn't that imply that a person who learned to code on GPLv2 sources wrote writes some more code in that style (including "long strings of code", some of which are clearly not unique to GPL) is writing code that is "born GPLv2"?
I don't think it currently works that way.
"[...] the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set"
Anyways, GitHub is Microsoft, and Microsoft has really good lawyers so I guess they did everything necessary to make sur that you can use it the way they tell you so. The most obvious solution would be to filter by LICENSE.txt and only train the model with code under permissive licenses.
This line of thinking applies to the code generated by the model, but not necessarily to the model itself, or the training of it.
I suspect there could be issues on the training side, using copyrighted data for training without any form of licensing. Typically ML researchers have a pretty free-for-all attitude towards 'if I can find data, I can train models on it.'
Note also that it's not just a concern for copyright, but also privacy. If the training data is private, but the model can "recite" (reproduce) some of the input given an appropriate query, then it's a matter of finding the right adversarial inputs to reconstruct some training data. There are many papers on this topic.
> In 1994, the U.S. Supreme Court reviewed a case involving a rap group, 2 Live Crew, in the case Campbell v. Acuff-Rose Music, 510 U.S. 569 (1994)... It focused on one of the four fair use factors, the purpose and character of the use, and emphasized that the most important aspect of the fair use analysis was whether the purpose and character of the use was "transformative."
It has some neat examples and explanation.
[0] https://www.nolo.com/legal-encyclopedia/fair-use-what-transformative.html
There're definitely cases when devs avoid even looking at implementation before creating their own
Not a critique on your point, which a was just about yo bring up myself.
2) if I write a program that copies parts of other GPL licensed SW into my proprietary code, does that absolve me of GPL if the copying algorithm is complicated enough?
https://docs.github.com/en/github/site-policy/github-terms-of-service#d-user-generated-content
This is the same reason it doesn’t matter if you put up a license that forbids GitHub from including you in backups or the search index.
There is no such thing as "fair use" as we have in copyright law?
That said, copyright is typically generally assigned to the closest human to the activation process (it's unlikely that Github is going to try to claim the copyright to code generated by Copilot over the human/company pair-programming with it), but since copyleft in general is a pretty domain-specific to software, afaik the way that courts interpret the legality of using code licensed under those terms in training data for a non-copyleft-producing model is still up in the air.
Obligatory IANAL, and also happy to adjust this info if someone has sources demonstrating updates on the current state.
imagine if the output was ruled as being GPLv2, then having to go through a proprietary codebase trying to rip out these bits of code
it would be basically impossible
I think this is definitely a gray area and in some way iParadigms winning (compared to all the cases decided in favour of e.g. the music industry), shows the different yardsticks being used for individuals and companies.
I'm sure we will see more cases about this.
[1] https://www.plagiarismtoday.com/2008/03/25/iparadigms-wins-turnitin-lawsuit/
Almost certainly not everything.
But possibly things that were spit out verbatim from the training set, which the FAQ mentions does happen about .1% of the time [1]. Another comment in this thread indicated that the model outputs something that's verbatim usable about 10% of the time. So, taking those two numbers together, if you're using a whole generated function verbatim, a bit of caveat emptor re: licensing might not be the worst idea. At least until the origin tracker mentioned in the FAQ becomes available.
[1] https://docs.github.com/en/early-access/github/copilot/research-recitation
[2] "GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set. Here is an in-depth study on the model’s behavior. Many of these cases happen when you don’t provide sufficient context (in particular, when editing an empty file), or when there is a common, perhaps even universal, solution to the problem. We are building an origin tracker to help detect the rare instances of code that is repeated from the training set, to help you make good real-time decisions about GitHub Copilot’s suggestions."
I do hope they feature others at a later date, especially since they are planning to develop a commercial version.
We genuinely don’t know what it means for licenses or whatnot right now.
It's really like pair programming, even though I'm coding alone. I have a better understanding of my own code, and I tend to give better names and descriptions to my methods. I write better code, documentation, and tests.
Copilot has made me a better programmer. No kidding. This is a huge achievement. Kudos to the GitHub Copilot team!
In what, proportion roughly?
You can actually see all the code blocks Copilot is thinking about if you want to, but that is indeed a distraction.
Based on the FAQ, it looks like some information about how you interact with the suggestions is fed back to the Copilot service (and theoretically OpenAI) to better improve the model.
So, while it may not understand "how to make code better" on its own, it can learn a bit from seeing how actual devs do make code better and theoretically improve from usage.
Do you have examples of what the line ones can do? The site doesn't really provide any of those.
https://gist.github.com/berndverst/1db9bae37f3c809e5c3f56262c0a1092
https://github.com/HackerNews/API doesn't list this as a valid endpoint. Indeed, when I try to access it via curl, I get a HTTP 405 with a "Permission denied" error (same result when I try to access nonexistent-endpoint.json).
Based on the HN search on the website, I'd expect the correct autocomplete to involve hn.algolia.com [0].
[0] https://hn.algolia.com/api points at https://hn.algolia.com/api/v1/search?query=...
To me, this points at the need for human input with a system like this. There is a Firebase endpoint, yes, and Copilot found that correctly! But then it invented a new endpoint that doesn't exist.
Does it train a programmer for accepting less than ideal code because it was suggested? Similar to how some programmers blindly copy code from StackOverflow without modification.
Seems like there is a potential downside that's being ignored.
Maybe juniors, but I don't see this being likely for anyone else. I've been using TabNine for ages and it's closer to just a fancy autocomplete than a code assistant. Usually it writes what I would write, and if I don't see what I would write I just write it myself (until either I wrote the whole thing or it suggests the right thing). Of course, barring some variable names or whatever.
I don't have it "write code for me" - that happens in my head. It just does the typing.
Think of it as tab complete. If it's wrong, don't hit tab.
It suggests entire blocks of code - but not in every context.
Do you know in which "context" it suggests a block?
https://gist.github.com/berndverst/1db9bae37f3c809e5c3f56262c0a1092
Given that MS owns GitHub and how valuable this is - I imagine it will be coming soon.
- the review from my peers is faster (the code is more correct) - I come back less to the code (because I have thought about all the corner cases when checking the copilot code) - As I care more about naming & inline docs (it helps copilot), the code is actually cheaper to maintain.
I think hit the Tab key more than I hit any other key ;)
But nothing gets close to Copilot. It "understands" what you're trying to do, and writes the code for you. It makes type-based autocompletions useless.
also tabnine is useless in multi-lines completes. which is where co-pilot should be strong.
TabNine at times was magical, but I stopped using it after Codota started injecting ads directly into my editor[1]
[0] https://betakit.com/waterloo-startup-tabnine-acquired-by-israeli-startup-codota/ [1] https://github.com/codota/TabNine/issues/342
Edit: Check this screencast for instance: https://twitter.com/francoisz/status/1409908666166349831
I definitely see the utility in the linked screencast. But I am left to wonder whether this effectiveness is really a symptom of the extreme propensity for boilerplate code that seems to come with anything web-related.
Copilot is particularly helpful when working on React components where it makes eerily accurate predictions. I see technology like Copilot becoming an indispensable part of the programmer toolbelt similar to IDE autocomplete for many people.
I also see it changing the way that programmers document their code. With Copilot if you write a really good descriptive comment before jumping into the implementation, it does a much better job of suggesting the right code, sometimes even writing the entire function for you.
Edit: You are honestly downvoting me for saying something that might actually happen. If copilot lives up to the hype, but for a limited number of languages, this can have a profound affect on what languages people might decide to use in the future.
If Copilot is as good as it gets but only for some languages, won’t it influence what languages will be chosen by devs or companies?
(It's also conceivable I'm put out of a job, but I'm not worried yet. So far I can only imagine AI automates away the boring part, and I super-duper-want that.)
I'm sure there's at least a few relevant XKCD strips to insert here.
Thinking about generating 10 times the code you need, just because you can generate it instead of writing (perfomant?) code.
1. The AI suggestions were often less helpful than the type driven IDE autocompletions (using IntelliJ).
2. The AI plugins were very aggressive in pushing their completions to the top of the suggestions list, even when they were strictly less helpful than the defaults.
The result was it actually slowed me down.
Looking at the marketing materials for these services, they're often focused on dynamic languages like Python or JavaScript where there's far less information available for the IDE to help you with. If you've picked your language partly due to the excellent IDE support, it's probably harder for the AI to compete with hand-written logic and type system information.
Anyone want to hire me to teach your grandma how to use the internet?
"Prediction: AI will cause the price of work that can happen in front of a computer to decrease much faster than the price of work that happens in the physical world. This is the opposite of what most people (including me) expected, and will have strange effects"
And I was like yeah I gotta start preparing for next decade.
But over the coming decades AI could dominate coding. I now believe in my lifetime it will be possible for an AI to win almost all coding competitions!
They feed you all these algorithms in college and your brain suggests new algorithms based on those patterns.
An AI agent can interact with an environment and learn from its environment by reinforcement learning. It is important to remember that pattern matching is different from higher forms of learning, like reinforcement learning.
To summarize, I think there are real limitations with this AI, but these limitations are solvable problems, and I anticipate significant future progress
Also Generative Adversarial Networks original implementation was to pit neural networks against each other to train them , they don't need human intervention.
Some come from the other end of the process.
I want to solve that problem -> Functionally, it’d mean this and that -> How would it work? -> What algorithms / patterns are there out there that could help.
Usually people with less formal education and more hands on experience, I’d wager.
More prone to end up reinventing the wheel and spend more time searching for solutions too.
Which fits the pattern matching described by the grandparent.
A few people I know, most of which haven’t been to college, or done much learning at all, but are used to work outside of what they know (that’s an important part), tend to solve problems with things they didn’t know at the time they set out to solve said problems.
Which doesn’t really fit the pattern matching mentioned by the grandparent. At least not in the way it was meant.
(Some call me heterodox, I prefer 'original thinker'.)
This exists: https://en.wikipedia.org/wiki/Automated_theorem_proving
It's like saying that calculators can solve complex math problems; it's true in a sense, but it's not not strictly true. We solve the complex math problems using calculators.
I would very much like GPT-f for something like SMT, then it could actually make Dafny efficient to check (and probably avoid needing to help it out when it gets stuck!)
This looks like a clever example of supervised learning. But supervised learning doesn't get you cause and effect, it is just pattern matching.
To get at cause and effect, you need reinforcement learning, like AlphaGo. You can imagine an AI writing code that is then scored for performing correctly. Overtime the AI will learn to write code that performs as intended. I think coding can be used as a "playground" for AI to rapidly improve itself, like how AlphaGo could play Go over and over again
AlphaGo learns a game with fixed, well-defined, measurable objectives, by trying it a bazillion times. In this autocomplete idiom the AI's objective is constantly shifting, and conveyed by extremely partial information.
But you could imagine a different arrangement, where the coder expresses the problem in a more structured way -- hopefully involving dependent types, probably involving tests. That deeper encoding would enable a deeper AI understanding (if I can responsibly use that word). The human-provided spec would have to be extremely good, because AlphaGo needs to run a bazillion times, so you can't go the autocomplete route of expecting the human to actually read the code and determine what works.
Then we shall be reaching singularity.
I'm skeptical.
The envelope of "programming" will continue to shift as things get more and more complex. Your mother-in-law is not going to install Copilot and start knocking out web apps. Tools like this allow programmers to become more productive, which increases demand for the skills.
Reminds me of something I read that claimed when drum machines came out, the music industry thought it was the end of drummers. Until people realized that drummers tended to be the best people at programming cool beats on the drum machine.
Every single technological advancement meant to make technology more accessible and eliminate expertise has instead only redefined what expertise means. And the overall trend has been a lot more work opportunities created, not less.
So the winners were those that adapted earlier and the losers were those that didn't/couldn't adapt.
This translates to: If you're mindlessly doing the same thing over and over again, then it's a low value prop and is at risk. But if you're solving actual problems that require thought/expertise then the value prop is high and probably going to get higher.
We can automate the mundane but that’s usually the stuff that requires creativity, so the automated stuff becomes uninteresting in that realm. People will seek crafted experiences.
It's just concentrated into the hands of a very few super specialists, it's much harder to get to their level but their work is much much more important.
See: https://www.youtube.com/watch?v=ZSRHeXYDLko / Preventing the Collapse of Civilization / Jonathan Blow
So, during this period, a ~10% increase in population saw a 250% increase in drummers.
It does not appear that the drum kit killed the drummer.
Big caveats about what these surveys defined as "drummer" and that this doesn't reflect professional drummer gigs, just the number of drummers.
[2] https://www.quora.com/How-many-people-play-drums-in-the-US
By the same line of thinking, If you can get by with AI generated code did you really require a seasoned, experienced developer in the first place? If your product/company/service can get by with copy pasta to run your CRUD app (which has been happening for some time now sans the AI aspect) did you ever really need a high end dev?
I think its like anything else, 80% is easy and 20% is not easy. AI will handle the 80% with increasing effectiveness but the 20% will remain the domain of humans for the foreseeable future.
Worth considering maybe.
I think the analog to programming is a bit more direct in this sense; most companies aren't going to go with something like Copilot unless it's supplemental or they're on an entirely shoestring budget; it'll be the bigger companies wanting to squeeze out that extra 10% productivity that are betting hard on this - same with where larger bands would do this to have an extremely clean studio track for an album.
AI will be similar -- it will not just give more tools to people already in a given field (programming, writing, whatever), but also bring new people in, and also create new fields. (I personally can't wait for the gardening of AI art to catch on. It'll be so weird[1].)
Nowadays everyone can make professional looking photos so the demand for photographers has shrunk, as the supply has increased.
Why would an architect bother with sending some work overseas if tools like this would enable them to crank out the code faster than it would take to do a code review?
1) AI tools increase developer productivity, allowing projects to get completed faster; and
2) AI tools offset a nonzero amount of skill prerequisites, allowing developers to write "better" code, regardless of their skill level
With those in mind, it seems reasonable to conclude that the price to e.g. build an app or website will decrease, because it'll require either fewer man-hours 'til completion and/or less skill from the hired developers doing said work.
You do make a good point that "building an app" or "building a website" will likely shift in meaning to something more complex, wherein we get "better" outputs for the same amount of work/price though.
Yes, and this in turn increases demand as more people/companies/etc.. can afford it.
And even that could still be fine for programmers, as other firms will be enticed into buying the creation of software -- firms that didn't want to build software when programming was less efficient/more expensive.
And actually, I really don't see AI in the next decade making more of a difference than what Github did (making thousands of man-hour of works available for free). Around 2040 or 2050, maybe. But not soon, AI is still really far.
[systems] Designing data intensive applications - kleppman
[programming] SICP - sussman & abelson
Last one is an old scheme book. No other book (that I read) can even hold a candle to this one, in terms of actually developing my thought process around abstraction & composition of ideas in code. Things that library authors often need to deal with.
For example in react - what are the right concepts to that are powerful enough to represent a dynamic website & how should they compose together.
But on the other hand, it also can mean that.
programmers, on the other hand, are wage laborers, individually selling their labor to employers who profit by paying them less.
industry is sitting on the opposite side of the equation here. I wonder what will replace "learn to code". whatever it is, the irony will be almost as rich as the businesses that profit from all this.
There are exceptions -- fancy weapons don't widely raise standards of living -- but the trends are strong.
On the first though, we have little reason to think tech will systematically diminish the roles people can fill. In the broad, the opposite has tended to happen throughout history -- although the narrow exceptions, like factory workers losing their jobs to robots, are real, and deserve more of a response than almost every government in the world has provided. For political stability, let alone justice.
Replacement of programmers will follow these lines. New tools, like copilot (haven't tried, but will soon), new languages, libraries, better IDEs, stack overflows, Google, etc will make programming easier and more productive. One programmer will do the work that ten did. That a hundred did. You'll learn to become an effective programmer from a bootcamp (already possible - I know someone who went from bootcamp to Google), then from a few tutorials will.
Just like the secretary's role in the office was replaced by everyone managing their own calendars and communications the programmer will be replaced by one or two tremendously productive folks and your average business person being able to generate enough code to get the job done.
This would scale to support any number of economists. This would also be a simpler model and that simplicity might lead to a better product. In your model, the economists must explain to you, then you must write the code. That adds a layer where errors could happen - you misunderstand the economists or they explain poorly or you forget or whatever. If the economists could implement things themselves - less room for "telephone" type errors. This would also allow the economists to prototype, experiment, and iterate faster.
That doesn't mean anything. The last 20 years have seen an absurd chase of more and more stupidity in job titles to make people feel they are "executive assistants" instead of secretaries, "vice presidents" instead of whatever managerial role, etc, etc.
There are more "secretaries" than ever, and they get to do far more productive things than delivering phone messages.
Well like everything in life I guess it depends? The only iron rule I can always safely assume is supply and demand.
But for programming especially on the web, it seems everyone has a tendency of making things more difficult than it should be, that inherent system complexity isn't going to be solved by ML.
So in terms of squeezing out absolute efficiency from system cost, I think we have a very very long way to go.
Initially, they will appear more productive with CoPilot. Businesses will decide they do not need anybody other than those who want to work with CoPilot. This will lead to adverse selection on the quality of programmers that interact with CoPilot ... especially those who cannot judge the quality of the suggested code.
That can lead to various outcomes, but it is difficult to envision them being uniformly good.
I don't think software engineers will get much cheaper, they'll just do a lot more.
Otherwise I am struggling explaining why there is such a great demand for devs that short courses (3-6 months) are successful, the same courses that fail at teaching the fundamental of computing.
Maybe many. If the cost/benefit equation doesn't work, it makes no sense to do the project.
> I don't think software engineers will get much cheaper, they'll just do a lot more.
If they do more for the same cost, they are cheaper. You as a developer will be earning less in relation to the value you create.
Doesn't matter as long as I create 5x value and earn 2x for it. I still am earning double within the same time and effort.
Welcome to the definition of productivity increases, which is the only way an economy can increase standard of living without inflation.
It is certainly impressive to see how much the GPT models have improved. But the devil is in the last 10%. If you can create an AI that writes perfectly functional python code, but that same AI does not know how to upgrade an EC2 instance when the application starts hitting memory limits, then you haven't really replaced engineers, you have just given them more time to browse hacker news.
You're not replacing the engineer, but you're giving every engineer a tireless companion typing suggestions faster than you ever could, to be filled in when you feel it's going to add value. My experience with the alpha was eye opening: this was the first time I've interacted with an AI and felt like its not just a toy, but actually contributing.
But you are clearly more knowledgeable with your 0 drivers replaced comment.
https://blog.waymo.com/2020/10/waymo-is-opening-its-fully-driverless.html
I think full self driving is possible in the future, but it will likely require investments in infrastructure (smarter and safer roads), regulatory changes, and more technological progress. But for the last decade or so, we had "thought leaders" and VCs going on and on about how AI was going to put millions of drivers out of work in the next decade. I think it is safe to say that we are at least another decade away from that outcome, probably longer.
[1] https://finance.yahoo.com/news/number-american-taxi-drivers-tripled-152201870.html
That's exactly the kind of thing "serverless" hosting has done for a while now.
Helping devs go through "boring", repetitive code faster seems like a good way to increase our productivity and make us more valuable, not less.
Sure, if AI evolves to the point where it reaches human-level coding abilities we're in trouble, but that's the case this is going to revolutionize humanity as a whole (for better or worse), not merely our little niche.
The hard part has always been writing an API that models external behavior correctly.
I've been saying something like that for a while, but my form was "If everything you do goes in and out over a wire, you can be replaced." By a computer, a computer with AI, or some kind of outsourcing.
A question I've been asking for a few years, pre-pandemic, is, when do we reach "peak office"? Post-pandemic, we probably already have. This has huge implications for commercial real estate, and, indeed, cities.
Knowing what code to generate with the AI: 200k/yr
Or maybe I'm thinking of tech leads. I don't know, my org is flat.
This is the problem with things like Spreadsheets, dag-drop programming, code generators.
Its not easy to tell a program what to change and where to change.
But yes, getting some kind of legal opinion will probably be cheaper with an AI.
https://www.suls.org.au/citations-blog/2020/9/25/natural-language-processing
> I would
Well you're going to have a problem describing actual automation when you encounter it. What would you call it when NLP results are fed into an inference engine that then actually executes actions - instead of just providing summarized search results? Super-duper automation?
Over time it will certainly do more, but it's probably quite a long time before it can be completely unsupervised, and in the meantime it's increasing the output of programmers.
But I don't think AI will become capable of complex thought in the next one/two decades, so if you're training to be a software architect, project manager, data analyst I think you should be safe for some time.
I think I’ll side with his expectation, but then again, my salary depends on it.
1) AI makes really good code completion to make juniors way more productive. Senior devs benefit as well.
2) AI gets so good that it becomes increasingly hard to get a job as a junior--you just need senior devs to supervise the AI. This creates a talent pipeline shortage and screws over generations that want to become devs, but we find ways to deal with it.
3) Another major advance hits and AI becomes so good that the long promised "no code" future comes within reach. The line between BA and programmer blurs until everyone's basically a BA, telling the computer what kind of code it wants.
The thing though that many fail to recognize about technology is that while advances like this happen, sometimes technology seems to stall for DECADES. (E.g. the AI winter happened, but we're finally out of it.)
You'd definitely still need some seniors in this scenario, but it feels possible that tooling like this might reduce their value-per-cost (and have the opposite effect on a larger pool of juniors).
As another comment said here, "if you can generate great python code but can't upgrade the EC2 instance when it runs out of memory, you haven't replaced developers; you've just freed up more of their time" (paraphrased).
When a new language / framework / library comes around, GitHub copilot won't have any suggestions for when you write in it.
For context-specific questions it's even worse. The other day a stop owner that sells coffee beans insisted that we try out conversing with Google translate. I was trying to find the specific terms for natural, honey, and washed process. My Chinese is okay, but there's no way to know vocab like that unless you specifically look it up and learn it. Anyway, I felt pressured to go through with the Google translate charade even though I knew how the conversation would go. I said I wanted to know if this coffee was natural process. His reply was 'of course all of our coffees are natural with no added chemicals!' Turns out the word is 日曬, sun-exposed. AI is no replacement for learning the language.
State of the art image classification still classifies black people as gorillas [1].
I rue the day we end up with AI-generated operating systems that no one really understands how or why they do what they do, but when it gives you a weird result, you just jiggle a few things and let it try again. To me, that sounds like stage 4) in your list. We have black box devices that usually do what we want, but are completely opaque, may replicate glitchy or biased behaviors that it was trained on, and when it goes wrong it will be infuriating. But the 90% of the time that it works will be enough cost savings that it will become ubiquitous.
[1]: https://www.theverge.com/2018/1/12/16882408/google-racist-gorillas-photo-recognition-algorithm-ai
Does "natural process" have a Wikipedia page? I've found that for many concepts (especially multi-word ones), where the corresponding name in the other language isn't necessarily a literal translation of the word(s), the best way to find the actual correct term is to look it up on Wikipedia, then see if there is a link under "Other languages".
[0]https://en.wikipedia.org/wiki/Coffee_production#Dry_process
Automation is a force multiplier. AI is a cheaper way of doing what humans do.
And the AI doesn't even need to be "true" AI. It simply needs to be able to do stuff better than what humans do.
Like protein solving? /s
Do you have a source for this re the last 20 years? It seems to me automation has been shifting the demand recently towards more skilled cognitive work.
Only for the first time to train a model for that.
You assumption is that programming demand is finite, AND that all programmers are equal, both of those are false.
I must also say that actual programming is around 10-15 % of the programmer job, so the tool will make you around 10% more overall productive.
I don't know, cranking out some suggestion for a function is not the same as writing a complete module / application.
Take the job of a translator, you would say the job would go extinct with all the advances in autotranslation? here it says that 'employment of interpreters and translators is projected to grow 20 percent from 2019 to 2029, much faster than the average for all occupations' [1]. You still need a human being to clear up all of the ambiguities of languages.
Maybe the focus of the stuff we do will change, though; but on the other hand, we do tend to get a lots of changes in programming; it goes with the job. maybe we will get to do more code reviews of what was cranked out by some model.
However, within a decade it might be harder to get an entry level job as a programmer. I am not quite sure if i should suggest my profession to my kids, we might get a more competitive environment in some not so distant future.
[1] https://www.bls.gov/ooh/media-and-communication/interpreters-and-translators.htm
Repurposed Google-fu. We'll always have jobs :)
I wouldn't be surprised to see really good static analysis and automated code review tools coming out of these teams very soon.
wsl on windows 10 has been amazing to develop and work on.
Now imagine how amazing it would be just on Ubuntu ;-)
e.g. this is in my .bashrc in wsl, it writes stdout to my windows clipboard:
function cb () { powershell.exe -command "\$input | set-clipboard" }
Windows gets tons of hate in our community, but I gave it a chance a couple years ago after being frustrated with osx and it has been amazing and I think a lot of people would come around to it if they gave it a chance. I am biased towards linux though since I'm an sre, so maybe that is why I never could quite get comfortable on osx. I really disliked having to learn how to do something once on a mac, then do that same thing again on linux to get something into production.
I don't even remember the last time Windows got in my way, in fact.
But no matter how much work you put into your Windows install it will be just as slow/fast, uncustomizable, and unoptimizable as it was out of the box.
The real strength of Windows is backwards compatibility, especially dealing with proprietary software. Its messiness is a relic of the way things were done in the past, it is also the reason why my 20+ year old binary still runs. And it does without containers or full VMs.
I much prefer developing on Linux (I still miss the Visual Studio debugger), but different platform, different philosophy.
Note: I don't know much about mainframes. I heard they really are the champions of backwards compatibility. But I don't think the same principles are applicable to consumer machines.
It's good for our health, too!
I think of it as not needing juniors for boring work, all you need as a company is seniors and AI.
It's still insanely impressive (assuming the examples aren't more cherry picked than I'd expect).
For most backend programming jobs, the challenge is not in writing complex code but figuring out what the business wants, needs and should have in the first place and distinguishing between them. Figuring out how to integrate with existing systems, processes, fiefdoms and code. Knowing when to say yes and no, how to make code future proof, etc. This is a task fundamentally unfit for what we currently call "AI", because it's not actually intelligent or creative yet.
On the frontend, it becomes even more nebulous. Maybe Copilot can suggest common themes like Bootstrap classes for a form, CSS properties, the basic file structure and implementations for components in an SPA, etc. As I see it, the main challenge is in UX there, not the boilerplate, which again makes it about understanding the user, figuring out how to make UI feel intuitive, etc. Again: unfit for current AI.
I cannot offer any opinion on the utility for actually complex, FANG-level code, for lack of experience.
May or may not reduce the demand for programmers, though. We'll see.
> GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set.
1. https://news.ycombinator.com/item?id=23093911
2. https://www.reddit.com/r/HobbyDrama/comments/gfam2y/furries_creator_of_this_fursona_does_not_exist/
[1] https://docs.github.com/en/github/site-policy/github-terms-of-service
Probabilities are fun!
e.g. https://lwn.net/Articles/61292/ and most likely only one opinion.
on the other hand, it would be interesting to learn about what the copyright implications are of
a) creating a utility like copilot (it is a software program) and contains a corpus based on copyrighted material (the database that has been trained)
b) using it to create code based on the corpus and resulting in software as a work under copyright.
I say dumb because I am, perhaps chauvinistically, assuming that no brilliant algorithmic insights will be transferred via the AI copilot, only work that might have been conceptually hard to a beginner but feels routine to a day laborer.
Then again that assumption suggests there'd be nothing to sue over.
Also, Oracle v Google opens the possibility of a fair-use defense in the event that Copilot does regurgitate a small snippet of code.
https://twitter.com/natfriedman/status/1409883713786241032
Basically they are building a system to find explicit copying and warn developers when the output is verbatim.
I feel like the current generation of AI is bringing us close enough to something that works once in a while but requires constant human expertise ~50% of the time. The self-driving industry is in a similar situation of despair where millions have been spent in labelling and training but something fundamental is amiss in the ML models.
We live in a very small corner of the space of possible universes, which is why finding a prior in program space within it is a big deal.
[1] https://docs.github.com/en/early-access/github/copilot/research-recitation
OpenAI’s tech opens an ethical Pandora’s box:
1. It’s clear that the raw inputs to all of OpenAI’s outputs originated with real, human creativity.
2. So, in a sense, OpenAI is laundering creativity. It reads in creative works, does complicated (and, yes, groundbreaking) transformations, and produces an output that is hard to trace to any particular source.
3. Yet, isn’t that effectively what human brains do too? Perhaps OpenAI lacks the capacity for true invention, but I’d argue that most people live their whole lives without a meaningful creative contribution as well.
All told, I don’t have a good framework for thinking about the ethics here. So instead, I’ll simply say:
Wow.
Being put out of job by an AI trained on your own code?
It's really the same ethical problem of all automation ... and will be as long as we need a job to fulfill basic needs like food, housing and medical care.
But good point about the ambivalent result of eliminating busywork. Food, housing and medical care is available in most western countries for people who choose to not get a job... I think the social status problem and guilt of freeriding are also big factors preventing prople from living more leisurely lives in these countries.
But to my personal philosophy: if I'm not coding to put myself out of a job, I'm thinking about the problem wrong.
When there are no more lines of code to be written, I shall do something else, content that I have done my part to free humanity from the burden of human-machine interfacing. I hear dairy farming is a demanding and rewarding challenge.
https://www.thebullvine.com/wp-content/uploads/2014/03/Figure-1-Licensed-US-Dairy-farms.png
Also, human desire is a bottomless pit, where automation saves we spend even more.
Reads similarly :)
If I want to watch a bunch of movies, I have to pay the theater for each movie, or pay netflix, or whatever. The screenplay I write afterwards belongs to me, but the learning process involved me paying for access to others' work. That's what's often missing here. But at the same time, if you train on legally public data, there's no 'theater' to be paid.
(Often, people train on illegally public data though, like the eleuther folks. That's a whole extra can of worms I've ranted about plenty).
Maybe we'll start seeing licenses with a section saying "not for use as training data for commercial models."
Considering that the impact of a single example is extremely small in training a model, and that it is trained on an ungodly amount of examples, then I wonder if the effort of forbidding its use has any real benefits.
Benefits to me are clear: giving a developer choice over how their source code is used with for-profit, opaque, next generation ML models.
But yes, drop in the ocean in terms of the full data set. But that shouldn’t be an excuse to remove user choice.
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 started working at a healthcare company earlier this year, and my whole approach to software has needed to change. It's not about implementing features any more - every change to our embedded code requires significant unit testing, code review, and V&V.
Having a standards-compliant Copilot would be wonderful. If it could catch some of my mistakes before I embarrass myself to code-reviewing colleagues, the codebase would be better off for it and I'd be less discouraged to hear those corrections from a machine than a person.
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 will be an area of discussion in the US and around the world and we're eager to participate.
How does that apply to countries where Fair Use is not a thing? As in, if you train a model on a fair use basis in the US and I start using the model somewhere else?
To be honest, I doubt that. Maybe I am special, but if I am releasing some code under GPL, I really don't want it to be used in training a closed source model, which will be used in a closed source software generating code for closed source projects.
My understanding of the open problem here is whether the ML model is intelligently recommending entire fragments that are explicitly licensed under the GPL. That would be a licensing violation, if a human did it.
A model can do this as well. Getting the length of a substring match isn’t rocket science.
I fear the coming world of training machine learning models with my face just because it was published by someone somewhere (legally or not).
While I certainly appreciate the difference, is camera observation illegal anywhere where it isn't explicitly outlawed? Meaning, have courts ever decided that the difference of scale matters?
https://en.wikipedia.org/wiki/Cover_version#United_States_copyright_law
The clear difference is that a human's training regimen is to understand how and why code interacts. That is different from an engine that replicates other people's source code.
For example, if I am writing a criticism of an article, I can quote portions of that article in my criticism, or modify images from the article in order to add my own commentary. Fair use protects against authors who try to exert so much control over their works that it harms the public good.
It's no different from a human programmer reading code, learning from it, and using that experience to write new code. Somewhere in your head there is code that someone else wrote. And it's not infringing anybody's copyright for those memories to exist in your head.
Also, a human being that reproduces licensed code from memory - because they read that code - would constitute a license violation. The line between derivative work, and authentic new original creation is not a well defined one. This is why we still have human arbiters of these decisions and not formal differential definitions of it. This happens in music for example all the time.
I could feed the Linux kernel one function at a time into a ML model, then coerce its output to be exactly the same as the input
this is obviously copyright infringement
whereas in the github case where they've trained it on millions of projects maybe it isn't?
does the training set size become relevant legally?
Your argument would have some merit if something were created instead of assembled, but there is no new algorithm that is being created. That is not what is happening here.
On the one hand, you call this copying in fair use. On the other hand, you say this is creating new code. You can't have it both ways.
If you're going to set such a high standard for ML tools like this, I think you need to justify why it shouldn't apply to humans too.
When a human programmer who has read copyrighted code at some point in their life writes new code that is not a "new algorithm", are they in violation of the copyrights of every piece of code they've ever read that was remotely similar in any respect to the new work?
I mean, I hope not!
> On the one hand, you call this copying in fair use. On the other hand, you say this is creating new code. You can't have it both ways.
I'm not a lawyer, but this actually sounds very close to the "transformative" criterion under fair use. Elements of existing code in the training set are being synthesized into new code for a new application.
I assume there's no off-the-shelf precedent for this, but given the similarity with how human programmers learn and apply knowledge, it doesn't seem crazy to think this might be ruled as legitimate fair use. I'd guess it would come down to how willing the ML system is to suggest snippets that are both verbatim and highly non-generic.
On the same page is an image showing copilot in real-time adding the text of the famous python poem, The Zen of Python. See https://docs.github.com/assets/images/help/copilot/resources_recitation_example_zen.gif for a link directly to copilot doing this.
You are making arguments about what you read instead of objectively observing how copilot operates. Just because GH wrote that copilot synthesizes new code doesn't mean that it writes new code in the way that a human writes code. That is not what is happening here. It is replicating code. Even in the best case copilot is creating derivative works from code where GH is not the copyright owner.
Of course I am. We are both participating in a speculative discussion of how copyright law should handle ML code synthesis. I think this is really clear from the context, and it seems obvious to me that this product will not be able to move beyond the technical preview stage if it continues to make a habit of copying distinctive code and comments verbatim, so that scenario isn't really interesting to me. Github seems to agree (from the page on recitation that you linked):
> This investigation demonstrates that GitHub Copilot can quote a body of code verbatim, but that it rarely does so, and when it does, it mostly quotes code that everybody quotes, and mostly at the beginning of a file, as if to break the ice.
> But there’s still one big difference between GitHub Copilot reciting code and me reciting a poem: I know when I’m quoting. I would also like to know when Copilot is echoing existing code rather than coming up with its own ideas. That way, I’m able to look up background information about that code, and to include credit where credit is due.
> The answer is obvious: sharing the prefiltering solution we used in this analysis to detect overlap with the training set. When a suggestion contains snippets copied from the training set, the UI should simply tell you where it’s quoted from. You can then either include proper attribution or decide against using that code altogether.
> This duplication search is not yet integrated into the technical preview, but we plan to do so. And we will both continue to work on decreasing rates of recitation, and on making its detection more precise.
The arguments you've made here would seem to apply equally well to a version of Copilot hardened against "recitation", hence my reply.
> Even in the best case copilot is creating derivative works from code where GH is not the copyright owner.
It would be convenient for your argument(s) if it were decided legal fact that ML-synthesized code is derivative work, but it seems far from obvious to me (in fact, I would disagree) and you haven't articulated a real argument to that effect yourself. It has also definitely not been decided by any legal entity capable of establishing precedent.
And, again, if this is what you believe then I'm not sure how the work of human programmers is supposed to be any different in the eyes of copyright law.
No. We both aren't. I am discussing how copilot operates from the perspective of a user concerned about legal ramifications. I backed that concern up with specific factual quotes and animated images from github, where github unequivocally demonstrated how copilot copies code. You are speculating how copyright law should handle ML code synthesis.
You say I'm not ... but then you say, explicitly in so many words, that I am:
> You are speculating how copyright law should handle ML code synthesis.
I don't get it. Am I, or aren't I? Which is it? I mean, not that you get to tell me what I am talking about, but it seems like something we should get cleared up.
edit: Maybe you mean I am, and you aren't?
Beyond that, I skimmed the Github link, and my takeaway was that this is a small problem (statistically, in terms of occurrence rate) that they have concrete approaches to fixing before full launch. I never disputed that "recitation" is currently an issue, but honestly that link seems to back up my position more than it does yours (to the extent that yours is coherent, which (as above) I would dispute).
Now that five days have passed, there have been a number of examples of copilot doing just that, replicating code. Quake source code that even included comments, the famous python poem, etc. There are many examples of code that has been replicated - not synthesized but duplicated byte for byte from the originals.
Think what you will, but your lies about the GPLv3 can easily be tested. Can you point me to some GPLv3 software in the Apple tech stack?
We actually already know the answer.
Apple had to drop Samba (they were a MAJOR end user use of Samba) because of GPLv3
I think they also moved away from GCC for LLVM.
In fact - they've probably purged at least 15 packages I'm aware of and I'm aware of NO GPLv3 packages being included.
Not sure what their App Store story is - but I wouldn't be surprised if they were careful there too.
Oh - this is all lies and apple's lawyers are wrong? Come one - I'm aware of many other companies that absolutely will not ship GPLv3 software for this reason.
In fact, by 2011 even it was clear that GPLv3 is not really workable in a lot of contexts and alternatives like MIT became more popular.
https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F0s9jg93,%2Fm%2F04vpm
Apple geared up to fight DOJ over maintaining root control of devices (San Bernadino case).
Even Ubuntu has had to deal with this - SFLC made it clear that if some distributor messed things up ubuntu would have to release their keys, which is why they ended up with a MICROSOFT (!) solution.
"Ubuntu wishes to ensure that users can boot any operating system they like and run any software they want. Their concern is that the GPLv3 makes provisions by which the FSF could, in this case as the owner of GRUB2, deem that a machine that won't let them replace GRUB2 with something else is in violation of the GPLv3. At that point, they can demand that Ubuntu surrender its encryption keys used to provide secure bootloader verification--which then allows anyone to sign any bootloader they want, thus negating any security features you could leverage out of the bootloader (for example, intentionally instructing it to boot only signed code--keeping the chain trusted, rather than booting a foreign OS as is the option)." - commentator on this topic.
It's just interesting to me that rather than any substance the folks arguing for GPLv3 reach for name calling type responses.
Apple used to also interoperate wonderfully if you were using Samba SERVER side too because - well, they were using Samba client side. Those days were fantastic frankly. You would run Samba server side (on Linux), then Mac client side - and still have your windows machines kind of on -network (for accounting etc) too.
But the Samba folks are (or were) VERY hard core GPLv3 folks - so writing was on the wall.
GPLv3 shifted things really from preserving developer freedom for OTHERs to do what they wanted with the code, to requiring YOU to do stuff in various ways which was a big shift. I'd assumed that (under GPLv2) there would be natural convergences, but GPLv3 really blew that apart and we've had a bit of a license fracturing relatively.
AGPLv3 has also been a bit weaponized to do a sort of fake open source where you can only really use the software if you pay for a commercial license.
I can't dig it up right now but someone can probably find it.
But the BSD's used samba for a while as well.
Everything else you write is just anecdotes about how certain companies have chosen to do things.
If I sell an open source radio with firmware limiting broadcast power / bands etc to regulated limits and ranges - under GPLv3 I can lock down this device to prevent the buyer from modifying it? I'm not talking about making the software available (happy to do that, GPLv2 requires that). I'm talking about the actual devices I build and sell (physical ones).
I can build a Roku or Tivo and lock it down? Have you even read the GPLv3? It has what is commonly called the ANTI-tivoisation clause PRECISELY to block developers from locking devices down for products they sell / ship.
If I rent a device and build in a monthly activation check - I can use my keys to lock device and prevent buyer from bypassing my monthly activation check or other restrictions?
The problem I have with GPLv3 folks is they basically endlessly lie about what you can do with GPLv3 - when there is plenty of VERY CLEAR evidence that everyone from Ubuntu to Apple to many others who've looked at this (yes, with attorney's) says that no - GPLv3 can blow up in your face on this.
So no, I don't believe you. These aren't "just anecdotes" These care companies incurring VERY significant costs to move away / avoid GPLv3 products. AGPLv3 is even more poisonous - I'm not aware of any major players using it (other than those doing the fake open source game).
Now we can debate whether or not it's a good thing that the user gets full control of his device if he wants it. I think it is. You?
This is why SaaS/Cloud companies dislike them and fuel FUD campaigns.
1a) commercial
1b) non-transformative: in order to be useful, the produced code must have the same semantics as some code in the training set, so this does not add "a different character or purpose". Note that this is very different from a "clean room" implementation, where a high-level design is reproduced, because the AI is looking directly at the original code!
2) possibly creative?
3) probably not literally reproducing input code
4) competitive/displacing for the code that was used in the input set
So failing at least 3 out of 5 of the guidelines. https://www.copyright.gov/fair-use/index.html
1b) This is false. This is not literally taking snippets it has found and suggesting it to the user. That would be an intelligent search algorithm. This is writing novel code automatically based on what it has learned.
2) Definitely creative. It's creating novel code. At least it's creative if you consider a human programming to be a creative endeavor as well.
3) If it's reproducing input code it's just a search algorithm. This doesn't seem to be the case.
4) Most GPLed code doesn't cost any money. As such the market for it is non-existent. Besides copilot does not displace the original even if there were a market for it. As far as I know there is not anything even close to comparable in the world right now.
So from my reading it violates none of the guidelines.
Okay, but that's...not much of a counterargument (to be fair, the original claim was unsupported, though.)
> Maybe I am special, but if I am releasing some code under GPL, I really don't want it to be used in training a closed source model
That's really not a counterargument. “Fair use” is an exception to exclusive rights under copyright, and renders the copyright holder’s preferences moot to the extent it applies. The copyright holder not being likely to want it based on the circumstances is an argument against it being implicitly licensed use, but not against it being fair use.
It seems like some of the chatter around this is implying that the resultant code might still have some GPL still on it. But it seems to me that it's the trained model that Microsoft should have to make available on request.
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.
In this particular case, the output resembles the inputs, or there is no reason to use Github Copilot.
This just gives me a flashback to copying homework in school, “make sure you change some of the words around so it’s not obvious”
I’m sure you’re right Re: jurisprudence, but it never sat right with me that AI engineers get to produce these big, impressive models but the people who created the training data will never be compensated, let alone asked. So I posted my face on Flickr, how should I know I’m consenting to benefit someone’s killer robot facial recognition?
In what context? You are planning on commercializing Copilot and in that case the calculus on whether or not using copyright protected material for your own benefit changes drastically.
----> for purposes such as criticism, news reporting, teaching, and research <----, without the need for permission from or payment to the copyright holder.
Copilot is not criticizing, reporting, teaching, or researching anything. So claiming fair use is the result of total ignorance or disregard.
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).
Regardless, programmers would be hypocritical to decry having their jobs automated away.
If you're asking why do people respond the way they do to disparity, then I can only speculate that it has something to do with the meaning of life.
By your reasoning, maybe we don't need backhoes and should just hire a bunch of guys with spoons instead?
historically when has that sort of 'tit-for-tat' style of argument ever been helpful?
the correct approach would be "we've observed first hand the problems that we've cause for society, how can we avoid creating such problems for any person in the future?"
It might seem self-serving, and it is, but 'two wrongs don't make a right'. Let's try to fix such problems rather than serving our sentence as condemned individuals.
It's not tit-for-tat, it's a wake up call. As in, what exactly do you think we've been doing with our skills and time?
> ""we've observed first hand the problems that we've cause for society"...
But not everyone agrees that this is actually a problem. There was a time when being a blacksmith or a weaver was a very highly paid profession, and as technology improved and the workforce became larger, large wages could no longer be commanded. Of course the exact same thing is going to happen to developers, at least to some extent.
How many?
> I don't think it's controversial that we become fair game for that same automation process we've been leading.
This is not correct. A human (developer) displacing another human (business person) is entirely different than a tool (AI bot) replacing a human (developer).
Regardless, this is the Lump of Labour fallacy (https://en.wikipedia.org/wiki/Lump_of_labour_fallacy).
In this case, it is assumed that the global amount of development work is fixed, so that, if AI takes a part of it, the equivalent workforce in terms of developers, will be out of job. Especially in the field of SWE, this is obviously false.
It also needs to be seen what this technology will actually do. SWE is a complex field, way more than typing a few routines. In best case (technologically speaking) this will be an augmentation.
That's not what is happening though, a few developers replace thousands of business and industry people with automated tools. Say, automated route planning for package delivery, would take many thousands of humans if not for the AI bots that do the job instead.
> SWE is a complex field, way more than typing a few routines. In best case (technologically speaking) this will be an augmentation.
Of course there will always be some jobs for humans to do. Just like there are still jobs for humans loading thread into the automated looms and such.
But your arguments against automation displacing programming jobs ring hollow. People said the same thing about chess playing programs, they would never be able to understand the subtlety or complexity like a human could.
Without reading and understanding the lump of labour fallacy, it can't be understood the relation between the fallacy and the displacement of jobs. In short, the fallacy is not incompatible with the displacement argument; the difference is in the implications.
> But your arguments against automation displacing programming jobs ring hollow. People said the same thing about chess playing programs, they would never be able to understand the subtlety or complexity like a human could.
Chess is a finite problem, SWE isn't, so they can't be compared.
If there is a pathway to improving this AI assist efficiency say by restricting the language, methodology, UI paradigm and design principles, it will happen quick due to market incentives. The main reason SWE is complex is it's done manually in myriad subjectively preferred ways.
Only some software developers seem interested in replacing themselves in order to enrich their corporate masters (mains?) even further.
Just don't use this tool!
And one could argue that this means we all pay more for health and legal services than we otherwise would. You have to calculate both costs and benefits; what price does society pay for those few people having very high paying jobs?
The challenge in software development is understanding the real world processes and constraints and turning them into a design for a functional & resilient system that doesn't collapse as people add every little idea that pops into their head.
If the hard part was "typing in code" then programmers would have been replaced long ago. But most people can't even verbally explain what they do as a series of steps & decision points such that a coherent and robust process can be documented. Once you have that it's easy to turn into code.
The problems we spend our days solving may change. But there will always be problems for humans to solve.
It all boils down to who is capturing the value for the effort and time expended. If a mediocre software engineer can compete against senior engineers with such augmentation, that seems like a win. Less time on learning language incantations, more time spent delivering value to those who will pay for it.
Your own example of the CEO becoming a CTO can be used in every level and part of the business.
Now the receptionist is building office automation tools because they can describe what they want in plain English and have this thing spit out code.
Approximately nothing.
The average knowledge worker somewhat more, but lots of them are at the level of “I can consume a pivot table someone else set up”.
Sure, there are highly-productive, highly-skilled excel users that aren't traditional developers that can build great things, but they aren’t “your average person”.
https://news.ycombinator.com/item?id=26386419 (HN: Excel Never Dies)
https://news.ycombinator.com/item?id=20417967 (HN: I was wrong about spreadsheets)
https://mobile.twitter.com/amitranjan/status/1139449388072239104 (Excel is every #SAAS company's biggest competitor!)
We may not call them developers or programmers (or we might; I’ve been one of them as a fraction of my job at different times, both as a “fiscal analyst” by working title and as a “programmer analyst” by title), but effectively that's what they are, developers using (and possibly exclusively comfortable with) Excel as a platform.
Is it a coincidence that the same company that makes Excel is trying to… “democratize” and/or de-specialize programming?
I don’t really think so, but shrug.
And sure, we do now have tools like square space which fully automate making a basic business landing page and online store. But the bar has been raised and we now have far more complex websites without developer resources being wasted on making web stores.
I read Mythical Man Month many years ago and enjoyed it. Time for a re-read. Of course it won't cover the third wave very well though. Would love to see a blog post cover that.
Edit:
To expand a little and not sounds so completely negative towards AI, seems like there could be value in training models to predict whether a patch will be accepted, or whether it will cause a full build to fail.
It would be a "cool tool" if it inspected the code statically and dynamically. Testing the code to see if it actually does what the AI thinks it should do. From running small bits of code on unit level to integration and acceptance testing. Suggest corrections or receive them. _That_ will save time and I and companies will pay for.
Also you cannot call this the "third revolution" if it is a paid service.
It... couldn't, in net.
Tools which improve developer productivity increase the number of developers hired and the number of tasks for which it is worthwhile to employ them and the market clearing price for development work.
See, for examples, the whole history of the computing industry as we’ve added more layers of automation between “conceptual design for software” and “bit patterns in hardware implementing that conceptual design as concrete software”.
It might displace or disadvantage some developers in specific (though I doubt a large portion) by shifting the relative value of particular subskills within the set used in development, I suppose.
A tool which increases how rapidly we can output code—correct code—would allow for more time spent on hard tasks.
I can see the quality of some "commodity" software increasing as a result of tools in this realm.
Or, perhaps, lower unit costs of computing lead to far far greater demand for computing since it became practical to apply to more domains.
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'd like to see where it is one year from now when the wow factor has cooled down a bit.
While I think the AI generating your mainline code is interesting, I must certainly agree that generating test code would be the killer feature. I would like to see this showcased a little more on the copilot page.
Interesting point - it reminds me of the idea that it’s harder to debug code than to write it. Is it also harder to interpret code you didn’t write than to write it?
This isn't like skimming through a codebase to get a sense of what the code does. You'd have to thoroughly review each line to make sure it does what you want it to do, that there are no bugs. And even then, you'd feel left behind pretty quickly because your brain didn't create the paths to the solution to the problem you're trying to solve. It is like reading a solution to a problem on leetcode vs coming up with it yourself.
I love it. So often the code suggestions accurately anticipate what I planned to do next.
It's especially fun to write a comment or doc string and then see Copilot create a block of code perfectly matching your comment.
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.
An Isaac Asimov story about someone who didn't take to the program and, as a result, got picked to create new things because someone has to make them.
If you want to read the whole thing, it's here:
The first example parse_expenses.py uses a float for currency - that seems to be a pretty big error that's being overlooked along with other minor issues around no error handling.
I would say the quality of the generated code in parse_expenses.py is not very high, certainly not for the banner example.
EDIT - I just noticed Github reordered the examples on copilot.github.com in order to bury the issues with parse_expenses.py for now. I guess I got my answer.
The fact that you ask is a very good case in point though: Many programmers are not aware of this issue and would maybe not question the "wisdom" of the AI code generator. In that sense, it could have a similar effect to blindly copy-pasted answers from SO, just with even less friction.
[1] Exceptions may apply to e.g. finance mathematics where you need to work with statistics and you're not going to expect exact results anyway.
Of course, if you are willing to get incorrect results, such as in play money, this may be okay.
Over in payments, we use micros regularly, as documented here: https://developers.google.com/standard-payments/reference/glossary#micros
GCP on there other hand has standardized on unit + nano. They use this for money and time. So unit would 1 second or 1 dollar, then the nano field allows more precision. You can see an example here with the unitPrice field: https://cloud.google.com/billing/v1/how-tos/catalog-api#getting_the_list_of_skus_for_a_service
> For example, the non-representability of 0.1 and 0.01 (in binary) means that the result of attempting to square 0.1 is neither 0.01 nor the representable number closest to it.
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
The problem with float is that many people don't understand how they work to handle rounding errors correctly.
Now there are some cases where float don't cut it. And big ones. For example, summing a set of numbers (with decimal parts) will usually be screwed if you don't round it. And not many people expect to round the results of additions because they are "simple" operations. So you get errors in the end.
(I have written applications that handle billions of euros with floats and have found just as many rounding errors there as in any COBOL application)
>>> from decimal import Decimal
>>> Decimal(1000) * Decimal(16) / Decimal(31)
Decimal('516.1290322580645161290322581')
>>> 1000 * 16 / 31
516.1290322580645
The point is using Decimal allows control over precision and rounding rather than accepting ad-hoc approximations of a float.https://docs.python.org/3/library/decimal.html
If it were me, I wouldn't go around bragging about how much money my software manages while being willfully ignorant of the fundamentals.
Now for your example, I see that float and decimal just give the same result. Provided I'm doing financial computations of a final number, I'm ok with 2 decimals. And both your computations work fine.
Th decimal module in python gives you number of significant digits, not number of decimals. You'll end up using .quantize() to get to two decimals which is rounding (so, no advantage over floats).
As I said, as soon as you have division/multiplication you'll have to take care of rounding manually. But for addition/subtraction, then decimal doesn't need rounding (which is better).
The fact is that everybody say "floats are bad" because rounding is tricky. But rounding is always possible. And my point is that rounding is tricky even with the decimal module.
And about bragging, I can tell you one more thing : rounding errors were absolutely not the worse of our problems. The worse problem is to be able to explain to the accountant that your computation is right. That's the hard part 'cos some computations imply hundreds of business decisions. When you end up on a rounding error, you're actually happy 'cos it's easy to understand, explain and fix. And don't start me on how laws (yes, the texts) sometimes explain how rounding rules should work.
sum = 0
for i in range(0, 10000000):
sum += 0.1
print(round(sum*1000, 2))
what should this code print? what does it print?I mean, sure, this is a contrived example. But can you guarantee that your code doesn't do anything similarly bad? Maybe the chance is tiny, but still: wouldn't you like to know for sure?
from fractions import Fraction
# salary is $3210.55
salary = Fraction(321055,100)
monthlyRate = Fraction(16,31)
print(salary*monthlyRate)
This will give you an exact result. Now, at some point you'll have to round to the nearest cent (or whatever), true. However, you don't have to round between individual calculations, hence rounding errors cannot accumulate and propagate.The propagation of errors is the main challenge with floating point numbers (regardless of which base you use). The theory is well understood (in the sense that we can analyse an algorithm and predict upper bounds on the relative error), but not necessarily intuitive and easy to get wrong.
Decimal floating-point circumvents the issue by just not introducing errors at all: money can be represented exactly with decimal floating point (barring very exotic currencies), therefore errors also can't propagate. Exact arithmetic takes the other approach where computations are exact no matter what (but this comes at other costs, e.g. speed and the inability to use transcendental functions such as exp).
For binary floating point, that doesn't work. It introduces errors immediately since it can't represent money well and these errors may propagate easily.
Still, I'll take "verbose" over "error-prone and possibly wrong".
(Unclear to me yet whether the design takes advantage of this opportunity)
Well, yes, the wrong code would be used. However - the wrong code would then become more prevelant as an answer from gh, causing more people to blindly use it. It's a self-perpetuating cycle of finding and using bad and wrong code.
And again, I could argue that the opposite could happen too, people who would otherwise have written bad code could be given suggestions of better code that they would've written.
No, not quite. It also makes the cycle more permanent and its results deeply ingrained, which is what is actually relevant.
I have made this mistake without the help of any AI or copy/paste. It's still in the hands of the developer to test and review everything they commit.
- the generated code by AI belongs to me or GitHub?
- under what license the generated code falls under?
- if generated code becomes the reason for infringment, who gets the blame or legal action?
- how can anyone prove the code was actually generated by Copilot and not the project owner?
- if a project member does not agree with the usage of Copilot, what should we do as a team?
- can Copilot copy code from other projects and use that excerpt code?
- if yes, *WHY* ?!
- who is going to deal with legalese for something he or she was not responsible in the first place?
- what about conflicts of interest?
- can GitHub guarantee that Copilot won't use proprietary code excerpts in FOSS-ed projects that could lead to new "Google vs Oracle" API cases?
> You can use the code anywhere, but you do so at your own risk.
Something more explicit than this would be nice. Is there a specific license?
EDIT: also, there’s multiple sections to a FAQ, notice the drop down... under “Do I need to credit GitHub Copilot for helping me write code?”, the answer is also no.
Until a specific license (or explicit lack there-of) is provided, I can’t use this except to mess around.
Edit: you have to click the things on the left, I didn't realize they were tabs.
Read it all, and the questions still stand. Could you, or any on your team, point me on where the questions are answered?
In particular, the FAQ doesn't assure that the "training set from publicly available data" doesn't contain license or patent violations, nor if that code is considered tainted for a particular use.
> GitHub Copilot is a code synthesizer, not a search engine: the vast majority of the code that it suggests is uniquely generated and has never been seen before. We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set.
I'm guessing this covers it. I'm not sure if someone posting their code online, but explicitly saying you're not allowed to look at it, getting ingested into this system with billions of other inputs could somehow make you liable in court for some kind of infringement.
Does everyone in this thread contact their lawyers after cutting and pasting a mergesort example from Stackoverflow that they've modified to fit their needs? Seems folks are reaching a bit.
You are expanding the discussion, which is great, but that doesn't apply in answer to that specific question.
There are answers in response to your question, however. For example, many companies use software for scanning and composition analysis that determines the provenance and licensing requirements of software. Then, remediation steps are taken.
> How is it possible to determine if you've violated a random patent from somewhere on the internet via a small snippet of customized auto-generated code?
The only real answer is a patent search.
My answer described literally what many companies do today. It was not a theoretical pie in the sky answer or a discussion about patent IP.
To restate, the real-world answer I gave for, "How is it possible to determine if you've violated a random patent from somewhere on the internet via a small snippet of customized auto-generated code?" is often "Do not take code from the Internet."
0.1% is a lot when you use 100 suggestions a day.
Is it even copyrighted? Generally my understand is that to be copyrightable it has to be the output of a human creative process, this doesn't seem to qualify (I am not a lawyer).
See also, monkeys can't hold copyright: https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute#Naruto_et_al_v._David_Slater
Isn't it subject to the licenses the model was created from, as the learning is basically just an automated transformation of the code, which would be still the original license - as else I could just run some minifier, or some other, more elaborate, code transformation, on some FOSS project, for example the Linux kernel, and relicense it under whatever?
Does not sound right to me, but IANAL and I also did not really look at how this specific model/s is/are generated.
If I did some AI on existing code I'd be quite cautious and group by compatible licences classes, asking the user what their projects licence is and then only use the compatible parts of the models.-Anything else seems not really ethical and rather uncharted territory in law to me, which may not mean much as IANAL and just some random voice on the internet, but FWIW at least I tried to understand quite a few FOSS licences to decide what I can use in projects and what not.
Anybody knows of some relevant cases of AI and their input data the model was from, ideally in jurisdictions being the US or any European Country ones?
No, I don't believe it is, at least to the extent that the model isn't just copy and pasting code directly.
Creating the model implicates copyright law, that's creating a derivative work. It's probably fair use (transformative, not competing in the market place, etc), but whether or not it is fair use is github's problem and liability, and only if they didn't have a valid license (which they should have for any open source inputs, since they're not distributing the model).
I think the output of the model is just straight up not copyrighted though. A license is a grant of rights, you don't need to be granted rights to use code that is not copyrighted. Remember you don't sue for a license violation (that's not illegal), you sue for copyright infringement. You can't violate a copyright that doesn't exist in the first place.
Sometimes a "license" is interpreted as a contract rather than a license, in which you agreed to terms and conditions to use the code. But that didn't happen here, you didn't agree to terms and conditions, you weren't even told them, there was no meeting of minds, so that can't be held against you. The "worst case" here (which I doubt is the case - since I doubt this AI implicates any contract-like licenses), is that github violated a contract they agreed to, but I don't think that implicates you, you aren't a party to the contract, there was no meeting of minds, you have a code snippet free of copyright received from github...
Wouldn't GitHub potentially be responsible for the infringement by distributing the copyrighted material knowing that it would be published?
The functional parts of code are not copyrightable, only the non functional creative elements.
(Not a lawyer...)
1. Depends heavily on the jurisdiction (e.g., Software patents are a thing in America but not really in basically all European ones)
2. A change to a copyrightable work, creative or not, would still mean that you created a derived work where you'd hold some additional rights, depending on the original license, but not that it would now be only in your creative possession. E.g., check §5 of https://www.gnu.org/licenses/gpl-3.0.en.html
3. What do you think of when saying "functional parts"? Some basic code structure like an `if () {} else {}` -> sure, but anything algorithmic like can be seen as copyrightable, and whatever (creative or not) transformation you apply, in its basics it is a derived work, that's just a fact and the definition of derived work.
Now, would that matter in courts? That depends not only on 1., but additionally to that also very much on the specific case, and for most trivial like it probably would be ruled out, but if an org would invest enough lawyer power, or suing in a for its case favourable court (OLG Hamburg anyone). Most small stuff would be thrown out as not substantial enough, or die even before reaching any court.
But, that actually scares me a bit when thinking about that in this context, as for me, it seems like when assuming you'd be right, this all would significantly erodes the power of copyleft licenses like (A)GPL.
Especially if a non-transparent (e.g., AI), lets call it, code laundry would be deemed as a lawful way to strip out copyright. As it is non-transparent it wouldn't be immediately clear if creative change or not, to use the criteria for copyright you used. This would break basically the whole FOSS community, and with its all major projects (Linux, coreutils, ansible, git, word press, just to name a few) basically 80% of core infrastructure.
https://www.law.cornell.edu/uscode/text/17/101
(Not a lawyer...)
Is this not subject to the same concern, but at a much greater scale? What happens when a large entity with a legal department discovers an instance of Copilot-generated copyright infringement? Is the project owner liable, is GitHub/Microsoft liable, or would a court ultimately tell the infringee to deal with it and eat whatever losses occur as a result?
In any case, I hope that GitHub is at least limiting any training data to a sensible whitelist of licenses (MIT, BSD, Apache, and similar). Otherwise, I think it would probably be too much risk to use this for anything important/revenue-generating.
I'm going to assume that there is no sensible whitelist of licenses until someone at GitHub is willing to go on the record that this is the case.
Yes, and even those licences require preservation of the original copyright attribution and licence. MIT gives some wiggle room with the phrase "substantial portions", so it might just be MIT and WTFPL
https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute
This is not one lone developer with a passion promoting their cool side-project. It's GitHub, which is an established brand and therefore already has a leg up, promoting their new project for active use.
I think in this case, it's very relevant to post these kinds of questions here, since other people will very probably have similar questions.
The commenter isn't interrogating some indy programmer. This is a product of a subsidiary of Microsoft, who I guarantee has already had a lawyer, or several, consider these questions.
Can't companies write code that runs on customer's premises these days? Are they too afraid somebody will extract their deep learning model? I have no other explanation.
And the irony is that these companies are effectively transferring their own fears to their customers.
On the training question specifically, you can find OpenAI's position, as submitted to the USPTO here: https://www.uspto.gov/sites/default/files/documents/OpenAI_RFC-84-FR-58141.pdf
We expect that IP and AI will be an interesting policy discussion around the world in the coming years, and we're eager to participate!
Uh, I very much doubt that. Is there any actual precedent on this?
> We expect that IP and AI will be an interesting policy discussion around the world in the coming years, and we're eager to participate!
But apparently not eager enough to have this discussion with the community before deciding to train your proprietary for-profit system on billions of lines of code that undoubtedly are not all under CC0 or similar no-attribution-required licenses.
I don't see attribution anywhere. To me, this just looks like yet another case of appropriating the public commons.
(1) training ML systems on public data is fair use
This one is tricky considering that kNN is also a ML system.> [...] The GitHub Copilot editor extension sends your comments and code to the GitHub Copilot service, which then uses OpenAI Codex to synthesize and suggest individual lines and whole functions.
Edit: Github mentions the issue here: https://docs.github.com/en/github/copilot/research-recitation and here: https://copilot.github.com/#faq-does-github-copilot-recite-code-from-the-training-set though they neatly ignore the issue of licensing :)
Hash each function, store the hashes as a blacklist. Then you can ask the model to regenerate the function until it is copyright safe.
> We found that about 0.1% of the time, the suggestion may contain some snippets that are verbatim from the training set
That's kind of a useless stat when you consider that the code it generates makes use of your existing variable/class/function names when adapting the code it finds.
I'm not a lawyer, but I'm pretty sure I can't just bypass GPL by renaming some variables.
In the AI world, unless all GPL (etc.) code is excluded from the training data, it's inevitable that some will be "copied" into other code.
Where lawyers decide what "copy" means.
Then you have the issue of attribution with more permissive licenses.
I don't, but then I didn't go first look at the GPL code, memorize it completely, do some brain math, and then write it out character by character.
I for one wouldn't touch this with a 10000' pole until I know the answers to these (very reasonable) questions.
Another question is this: let's hypothesize I work solo on a project; I have decided to enable Copilot and have reached a 50%-50% development with it after a period of time. One day the "hit by a bus" factor takes place; who owns the project after this incident?
https://breckyunits.com/the-intellectual-freedom-amendment.html
Great achievements like this only hammer home the point more about how illogical copyright and patent laws are.
Ideas are always shared creations, by definition. If you have an “original idea”, all you really have is noise! If your idea means anything to anyone, then by definition it is built on other ideas, it is a shared creation.
We need to ditch the term “IP”, it’s a lie.
Hopefully we can do that before it’s too late.
No one will see the light at Microsoft. The "open" source babble is marketing and recruiting oriented, and some OSS projects infiltrated by Microsoft suffer and stagnate.
In general, what is IP and how it's enforced are two separate things. Just because we've used copyright and patents to "protect" an organization's unique advantages, doesn't mean we need to keep using them in the same way. Or maybe it's the best we can do for now. That's why BSD style licences are so great.
Copyright doesn't protect "ideas" it protects "works". If an artist spends a decade of his life painting a masterpiece, and then some asshole sells it on printed T-shirts, then copyright law protects the artist.
Likewise, an engineer who writes code should not have to worry about some asshole (or some for-profit AI) copy and pasting it into other peoples' projects. No copyright protections for code will just disincentivize open source.
Software patents are completely bullshit though, because they monopolize ideas which 99.999% of the time are derived from the ideas other people freely contributed to society (aka "standing on the shoulders of giants"). Those have to go, and I do not feel bad at all about labeling all patent-holders greedy assholes.
But copyright is fine and very important. Nothing is perfect, but it does work very well.
Same goes for an engineer. Binary notation is at the root of all code, and in the intermediate nodes you have Boolean logic and microcode and ISAa and assembly and compilers and high level Lang’s and character sets. The engineer who assembles some leaf nodes that are copy and pasteable is by definition building a shared creation of which they’ve contributed the least.
And they went to the store and paid money for those things.
No it really is not that easy, as with compilers it depends on who owned the source and which license(s) they applied on it.
Or would you say I can compile the Linux kernel and the output belongs to me, as compiler operator, and I can do whatever I want with it without worrying about the GPL at all?
So, to be clear, I am allowed to take leaked Windows source code and train an ML model on it?
So your point (1) is a distraction, and quite an offensive one to thousands of open source developers, who trusted GitHub with their creations.
Looking at the four factors for fair use looks like Copilot will have these issues: - The model developed will be for a proprietary, commercial product - Even if it's a small part of the model, the all training data for that model are fully incorporated into the model - There is a substantial likelihood of money loss ("I can just use Copilot to recreate what a top tier programmer could generate; why should I pay them?")
I have no doubt that Microsoft has enough lawyers to keep any litigation tied up for years, if not decades. But your contention that this is "okay because it's fair use" based on a position paper by an organization supported by your employer... I find that reasoning dubious at best.
You can get past GPL, LGPL and other licenses this way. Microsoft can finally copy the linux kernel and get around GPL :-).
For a seasoned veteran writing the code was never really the hard part in the first place.
Yes, to most coders this Copilot software is just a fancy keyboard.
Or, I guess a sentinel phrase that the scraper could explicitly check: `github-copilot-optout: true`
Neither in practice (because it doesn't look for it) nor legally in the US, if Microsoft’s contention that such use is “fair use” under US copyright law.
That “fair use” is an Americanism and not a general feature of copyright law might create some interesting international wrinkles, though.
> Why was GitHub Copilot trained on data from publicly available sources?
> Training machine learning models on publicly available data is now common practice across the machine learning community. The models gain insight and accuracy from the public collective intelligence. But this is a new space, and we are keen to engage in a discussion with developers on these topics and lead the industry in setting appropriate standards for training AI models.
Personally, I'd prefer this to be like any other software license. If you want to use my IP for training, you need a license. If I use MIT license or something that lets you use my code however you want, then have at it. If I don't, then you can't just use it because it's public.
Then you'd see a lot more open models. Like a GPL model whose code and weights must be shared because the bulk of the easily accessible training data says it has to be open, or something like that.
I realize, however, that I'm in the minority of the ML community feeling this way, and that it certainly is standard practice to just use data wherever you can get it.
I don't see any attribution here.
MIT may say "substantial portions" but BSD just says "must retain".
would MS position then be different?
If its publicly available than its fair game to use it to learn and base ideas on.
A couple weeks ago I ran a few experiments with AI-based code generation (https://news.ycombinator.com/item?id=27621114 ) from a GPT model more suitable for code generation: it sounds like this new "Codex" model is something similar.
If anyone from GitHub is reading this, please give me access to the Alpha so I can see what happens when I give it a should_terminate() function. :P
I'll note that we weren't trying to build "code auto-complete" but instead a automated "rubber duck debugger" which would function enough like another contextually-ignorant but intelligent programmer that you could explain your issues to and illuminate the solution yourself. But we did a poor job of cleaning the data and we found that English questions started returning Python code blocks, sometimes contextually relevant. It was neat. This GitHub/OpenAI project is neater.
I would be curious what the cost of developing and running this model is though.
But I'm worried these kinds of AI-assist tools will lead to "code spam" that may increase developer productivity even more, yet we no longer have Moore's law to absorb the additional inefficiency in performance these tools may introduce.
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 experience of writing code.
Much like learning an instrument, improvisation, or say physics, a lot of people learn by doing it, even if it's grunt work. IMO this is necessary for any professional.
Maybe it will be seen as a crutch, maybe I'm getting old? I have tons of code snippets, but it's usually stuff I've written and understood and battle tested, even if it was initially sourced from SO. Having it in the text editor and appear out of nowhere with no context seems like it'd need some adjustment in apprehension.
Edit: I should have been clear, I'm not against others using Copilot and will try it out myself. I can see it being useful in replacing one-line libs like in nodejs, i.e., copying a useful well-known and needed snippet vs installing yet another lib that could be a sec issue.
Also the industry is the real gatekeeper—we have tools that don't require us to repeat prior-art, yet have to go through hurdles of leetcode-style interviews for a job. Maybe in the future the hardest part of being a (AI-driven) developer will be getting a job?
And for those with experience, this will be obvious when reviewing their code. There's only two possibilities -- either copilot will get so good that it won't matter, or code written by copilot will have obvious tells and when someone is over-relying on it to cover up for a lack of knowledge, that will be very clear from repetition of the same sorts of mistakes.
Even something as simple as copying from the docs, it's usually a good place to signal deprecation, use-case applicability, API updates etc. you lose all that with the automation.
Oftentimes there's also discussion around a solution, and in many ways can swing one's decision on whether to use the code or not.
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 enough of the time.
Honestly I don't even see how that's possible. Writing code, you're thinking about all the different ways to do it, eliminating the ones that won't work, evaluating the pros and cons of the ones that seem like they'll work, you start writing one and then realize it actually won't work, then start writing it a different way, try to decide what the best approach will be to make sure you're not committing an off-by-one error, and so on...
Whereas when you're reading code for correctness, you're just following the logic that's already there. If it works, it works. How could it possibly take longer than the whole creative process of coming up with it...?
Sure, maybe most people don't read code for correctness well. But then the code they write is surely even worse.
That's exactly the problem. If you "just follow the logic" you can miss important details or edge cases that you would be forced to deal with by coding it yourself.
I wouldn't mind using something like this for mundane tasks, but I would be very careful with these tools while developing high performance code intended to run on specific hardware.
If I'm reading code, I can give 100% of my attention to the logic and details and edge cases, so I'm more likely to pick them up.
While as I'm writing, I'm busy doing all of the stuff that writing code involves, so I'm more distracted and more likely to make mistakes.
This gets proved to me time and time again when I run something for the first time and have to debug it. I look at the offending line, and think -- how could I have made a mistake so obvious that it's immediately apparent? Well, because I was busy/distracted thinking of 20 different things while writing it. But it's immediately obvious when reading it, because it has my full attention now.
"recursively list all the files in a directory C#"
https://stackoverflow.com/questions/929276/how-to-recursively-list-all-the-files-in-a-directory-in-c
I imagine an AI copilot could streamline this, instead of searching, reading and verifying, copy pasting, and changing the variable names to my needs, I could now just type the method name, arguments, and documentation and it would similarly fill out the code for me. Then I have to check it (as I normally would).
I can _just_ read the code of course, and understand what it does - but just reading isn't analyzing it to the degree you do when you review/write the code. In that level of analysis you're looking for edge cases, bugs, etc. Reasons you'd write it differently. Which i suspect is functionally similar, if not identical, to writing it.
what? so people just write code and never read it back?
There was a simple function in java standard library which was wrong for years because of this phenomenon.
https://dev.to/matheusgomes062/a-bug-was-found-in-java-after-almost-9-years-of-hiding-2d4k
Edit: In fact, people in this thread are finding exactly those problems in the example code, which you would assume had been checked fairly carefully.
That said, I can't wait to read the first postmortem where someone deployed code generated via Copilot that has a bug. I just hope it's not on a rocketship or missile guidance system.
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.
The difficulty with high flexibility is that the expressions become very domain-specific very quickly, creating the challenge of learning the new abstractions. So one isn't just a LISP developer, one knows how to write in the specific forest of macros that have been built up around one specific problem domain. The end result is code that means nothing to a reader who doesn't have a dense forest of macro definitions in their brain (at least in this era, their IDE will likely helpfully pull up the macro definitions with a mouse-over or cursor-over gesture!).
Contrast with this approach, where the complexity of abstraction is being baked into the lower-flexibility language. The code is less dense, and that's a tradeoff... But grab any 10 developers off the street with experience in that language and have them read it and 8 of them will likely be able to tell you with some accuracy what the code is doing. Not a trick I've seen possible with even very experienced LISP developers on a codebase they've never seen before.
... and, of course, being able to grab a random 10 developers off the street and have 8 of them up-to-speed in no time at all is crack cocaine to big businesses with large and complex systems maintained by dozens, hundreds, or thousands of people.
Smart programmers are are not coding thousands of lines of code every day. There's so much more to in software engineering other than coding, that's why senior engineers spend less time writing code than juniors.
If a slow typer is using a auto-completer, he's not learning to type faster.
If auto complete fails, then the slow programmer will need to invalidate the code first, and then type it anyway.
All in all - maybe it's impressive AI research project, but I don't see it as a useful product.
Do you think there's a risk that a tool like this could lead to an explosion of the size of codebases written in these languages? It's great that programmers can be freed from the need to write boilerplate but I fear that burden will shift to the need to read it.
It is no different from a code review of another perhaps junior dev and only doing adding finishing touches.
There is plenty of boilerplate you have to write, Intellisense/ Auotfill only goes so far, this is next step in the evolution. Sure it is not perfect but if i can express my ideas faster, why not.
Also It is a very probably poor tool for new devs, they won't know that suggestion maybe not the best and probably won't ignore it when it is wrong as they won't know any better.
Code completion might be the new "junior dev."
While sure purist view is not wrong that average quality of outcome has dropped since 70s-80s, the quantum of throughput meant that impact has been positive and immense.
Similarly I am expecting this kind of tooling would open up to more types of new developers.
[1] all the mathematicans thought similarly perhaps during 50s and 60s.
- You only need code relevant to your language.
- The amount of unique code in your language is going to be relatively small in compared to say, the entire history of internet comment.
- Training a model also shouldn't take long.
I personally would never use an online version feeding all my code back to a home server somewhere, and leaving breadcrumbs that might suggest I'm violating the GPL.
Now, how about you use that to implement a non-horrible search experience?
Also, this tool will enable more cheap LOC churn for those gaming performance reviews (not that this is currently difficult, but it will be even easier).
What this really displaces is StackOverflow (or some of its users...)
maybe sooner than we think?
- 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.
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?
I don't. Very often I run into an outdated accepted response with much better and more recent replies below it.
AI for maintaining, upgrading, improving, and fixing code.
After all, devs spend 80%+ of their time doing those things and they’re WAY more painful than writing code imo.
How did you construct the Copilot? Did you use a learning approach based on data from actual pair-programming sessions? Or did you take tons of code as your input and use that to suggest next methods based on input code?
I learned a ton whenever I pair programmed, but now I'm at a small company so I'm looking for fun ways to learn new methods :)
And yeah that's a niche example, maybe this is super helpful for writing a react app or something very library heavy. But gut feeling without trying it is that there's no way this could actually work on anything but the most common tasks that you can google and find solutions for already, just made easier so you don't actually have to google for it.
When I used tabnine which learned from you as you edit, it was fairly helpful for very repetitive code within the same project. But it was no where near "read english and write the code I meant for it". I'm curious to know how well this actually performs for non-common tasks, and whether it can understand ideas in your codebase that you come up with. If I make a WorldAbstractionOverEntities thing in my code, and then later use it in the project, will the AI be able to help me out? Or is it going to go "sorry, no one on github has used this thing you came up with an hour ago, I can't help you". An AI that could understand your own codebase and the abstractions you make and not just popular libraries would be infinitely more useful imo.
That said, I haven't tried this, maybe it'll turn out really good.
Because you write code using a bunch of patterns: iterating over data, destructing an object, calling functions etc. If you can generalize the usage of these patterns in such a way that it understands the context where you want to use them you're essentially doing this Copilot thing.
I agree that it'll be hard to have it understand fully the context and paradigms behind your existing project, but if it can help me automate some things in such a way that I can just let it run its thing and than have me "poke around it to get it right" then this is still amazing.
This is explained in more detail in the article below; see the first section titled "Deep Learning: the geometric view":
https://blog.keras.io/the-limitations-of-deep-learning.html
In other words, Copilot should work well for boilerplate code and allow for many variations, but for anything more original it should be hit-and-miss. In principle. In practice, we'll know in a year or two, once enough people have used it. Or not even then.
Well, isn't GitHub part of Microsoft now? No wonder it has gained telemetry...
I'm a bit worried that this thing will lead to even more bugs like the typical StackOverflow copy&paste which compiles fine, runs OK, but completely doesn't understand the context and thereby introduces subtle difficult to find issues.
My personal take on autocomplete has always been that I only use it so that I can use longAndDescriptiveFunctionNames. Apart from that, if your source code is so verbose that you wish you didn't have to type all of it, something else probably already went wrong.
While they may be useful in propaganda, state or commercial, I'm not sure why Microsoft GitHub would find it useful to generate volumes of bullshit source code.
Although if a license can permit or prohibit use in training commercial models, does that mean that the lack of permission implies a prohibition on it?
def strip_suffix(filename):
"""
Removes the suffix from a filename
"""
return filename[:filename.rfind('.')]
import unittest
def test_strip_suffix():
"""
Tests for the strip_suffix function
"""
assert strip_suffix('notes.txt') == 'notes'
assert strip_suffix('notes.txt.gz') == 'notes.txt'
Because just like when they copy-paste the top answer on SO, at the end of the day they are responsible for the code they ship.
I remember over a decade ago seeing a grad student project with a very straightforward and very clever idea: extending JavaDocs based on code snippets of actual use (to address the common pattern problem in Java code that you often get an instance of an object not by direct construction, but by calling a factory function or singleton getter somewhere). Kicking myself that I didn't see this day coming.
Obviously, there's some core algorithmic work that needs to occur, but that's always been done by a very small number of people anyway. The rest is still glueing.
Maybe the first generation of this sort of completion will be bad, but I have full faith it will be better than the average human at avoiding security issues as early as the next generation.
As FAQ mentions, They are planning to launch a commercial product so likely not I guess.
https://copilot.github.com/#faqs
>> How does GitHub Copilot work?
>> OpenAI Codex was trained on publicly available source code and natural language, so it understands both programming and human languages.
I want to propose a new Bingo style game where you get points when AI researchers (or rather their marketing teams) throw around big words that nobody understands, like, er "understands" with abandon. But I can't be bothered.
An AI researcher called Drew McDermot warned against this kind of thing in a paper titled "AI meets natural stupidity":
http://www.cs.yorku.ca/~jarek/courses/ai/F11/naturalstupidity.pdf
In 1976.
Why doesn't anybody ever learn from the mistakes of the past?
(Yes that’s an HN-frowned-upon joke comment, but that is my dev environment)
You basically just explained why your worry is unfounded yourself. This is already the status quo. People already write buggy code and copy buggy code from SO all the time.
The goal of this isn't to write perfect code, that's still up to the programmer to do. This won't make a bad programmer not write buggy code magically.
Or to put it another way: you know you can't trust the AI-generated code w/o convincing yourself it's correct. You think you can trust the code you wrote yourself, but you're probably wrong! :-)
- Could someone deliberately publish poor code to reduce the overall performance of the model?
- Could someone target a specific use case or trigger word by publishing deliberately poor code under similar function definitions?
In that case? Are those who don't control the AI needed? What about when those optimizations can be made by the AI itself also?
And even if you're okay with sending your code, what about hardcoded secrets? What's to prevent Copilot clients from sending things that should never leave the user's computer? Heuristics? Will we be able to tell what part of the code is about to be sent? And is the data stored?
I suspect that for drudgery or work stuff I would happily take some help with typing, but I am not sure (beta access please!) if I would want if for my novel, or my sales copy.
I am (optimistically) hoping that my novel has my voice - my unique fingerprint of tone and vocab.
And I wonder if my software has similar tone. A much more restricted syntax of course, but my choice to use meta programming here, an API design there. I may be over thinking it.
As you say typing code is not a bottleneck for problem solving
Then I feel like useful code produced by this tool will have to be treated in the exact same way as a rigorous code review: going through every part of the logic and ensuring it is correct. This seems like just as much or even more work than writing it yourself (if it is written in an unfamiliar way, you might need more time to wrap your head around it).
The absolute gall of Microsoft claiming fair use to gate keep knowledge of millions of minds...
As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain.
We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it because they make it easier to manage. I can only imagine what kinds of codebases a product like this could lead to. Someone will produce 5000 lines of code in a day for a new feature, but only read 2000 of those lines. Folks that still expect you to only check in code you understand and can explain will become a minority.
I wonder how long it will be until someone sets up the rest of the feedback loop and starts putting up github projects made of nothing but code from this tool, and it can start to feed on itself.
Cargo-cult programming has always been a problem, but now we're explicitly building tools for it.
The biggest place I think it is frustrating to write code is for ML pipelines where you know what you need, but it takes a few hours to wrangle files and pandas until you can run your idea/experiment.
Most codebases already majorly contain unread code; the libraries (node_modules, etc). I am sure we can figure out a pattern to separate human vs machine code in similar way.
If the code you are about to write is already written by someone else on the internet, that's probably not the most innovative part of your codebase anyway, so why waste time?
I don't think I really agree with this sentiment. "More programmers" or "faster programmers" is meaningless (or even actively detrimental) if the quality of their output is lower. It's even worse if their output is plagued by subtle bugs, as AI systems are likely to produce.
The one paying for these jobs can decide what level of quality they want, and hire/pay accordingly. How does that sound?
I don't think your concerns are well grounded.
writing the programs is definitely boring garbage work. Typing is so slow and annoying - hence autocomplete being a standard tool. This is, to me, just fancy autocomplete.
> to an increase in boilerplate and the acceptance of it because they make it easier to manage.
Boilerplate optimizes for the right things - code that's easier to read and analyze, but takes longer to write. IDEs and tools like this cut the cost of writing, giving us easier to read code and easier to analyze code for free.
IDEs have supported templates forever. I never write out a full unit test, I type `tmod` and `tfn` and then fill in the blanks. This is basically the same thing to me.
> Folks that still expect you to only check in code you understand and can explain will become a minority.
This isn't true at all. Having used TabNine I don't have it write code for me, it just autocompletes code that's already in my head, give or take some symbol names maybe being different.
All this is is a fancy autocomplete with a really cool demo.
We'll need more IDE enhancements, to highlight interesting pieces and desaturate standard boilerplate...
The context almost always exists in the writers head. We all have a specification of our program based on our expectations, and we type out code to turn that model into an implementation. We only spend so much time conveying that model though - most of us don't write formal proofs, but many of us will write out type annotations or doc comments.
The cost is usually as simple as expressing and typing out the model in our head as code. Languages that are famous for boilerplate, like Java, enforce this - and it makes writing Java slower, but can also make Java code quite explicit (I'm sure someone will respond talking about confusing Java code, that's not the point).
Reducing the cost of conveying context from writer to reader means we can convey more of that context in more places. That's a huge win, in my opinion, because I've personally found that so much implicit context gets lost over time, but it can be hard to always take the time to convey it.
Think about how many programs you've read with single character variable names, or no type annotations, or no comments. The more of that we can fix, the better, imo.
Tools like this do that. TabNine autocompletes full method type signatures for me in rust, meaning that the cost of actually writing out the types is gone. That's one less cost to pay for having clearer, faster code.
This is wrong and the same retarded logic Java used to defend not introducing var and similar features for ages. Boilerplate is usually noise around the actual logic - it's a result of limited abstractions. When you're repeating same code over and over you raise that segment to a separate concept, that's how abstraction and high level programming works - it increases readability and maintainability. Being easier to type has nothing to do with it.
The rest of your post doesn't really have to do with mine. Yeah, you can cut down on boilerplate with changes to languages... duh. But in terms of conveying context there's always a tradeoff of explicit vs implicit, and one of those costs is taking the time to actually turn your mental model into a written implementation - this eases that burden.
As I said, it's a fancy autocomplete.
Exactly - if a tool let's you write it explicitly too easily you're making that the default, and it ignores the readability/maintainability side of the tradeoff.
Maybe it gets good enough to recognise when things can be factored out for better readability as well. But in my experience code generators rarely result in maintainable code.
What's the carbon displacement for wasted time on those tasks? It might be brow raising.
I'd love to know what Donald Knuth thinks given the history of literate programming.
The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can just happen automatically without me having to leave my IDE.
The enjoyable part of programming for me is not typing the Ajax post boilerplate bullcrap for the millionth time, it's the high-level design and abstract reasoning.
Maybe that warrants a library, but then you also have to hook that up with the ever so slightly different boilerplate code.
If this 90% of the easy stuff is done for you, that gives you more time to focus on the 10% that matter.
I like abstractions as much as the next person, but oftentimes you can just make due with the exact thing.
I think there is a pro and a con to that approach.
The pro is that there is a meaningful and familiar intermediate representation --- the output of the C pre-processor is still C code. Another example is https://doc.qt.io/qt-5/metaobjects.html
The con is that, well, it introduces a meta layer, and these meta layers are more often than not ad-hoc and ultimately became quite unwieldy. It's a design pattern that suggests that there is a feature missing from the language.
The disadvantage is that making sweeping changes is more work. The advantage is that making sweeping changes can be done incrementally. But the big win with code generators is that all you need to understand what's happening is right in front of you instead of having to mentally unwind a clunky abstraction.
Don't get me wrong if you have a good abstraction that reduces the use of mental registers do it! But you would and should do that regardless of boilerplate.
This is the part where I’ve been entertaining the idea of solving things at a language level (transpiler). It’s a dangerous idea because if we get better tools to extend the language and everyone does it, we’re all going to be fucked.
But I can’t shake the idea that some of our frameworks, if incorporated at a language level, could entirely eliminate the boilerplate.
Check out the memoize example. That fails as soon as you pass anything non-primitive but there’s no one documenting that.
What? It's not anonymous, it's still committed by a dev. It can be non-checked and untested, that's true. But it's not any less untested than any other code. If you choose not to write tests for your code, this won't change anything.
The only issue I see with this is it being potentially unchecked. And the solution to that is reading all the code you commit, even though it's generated by AI.
Testing doesn't even enter the picture here, we're at the level of automating the stereotypical StackOverflow-driven development - except with SO, you at least get some context, there's a discussion, competing solutions, code gets some corrections. Here? You get a black-box oracle divining code snippets from function names and comments.
> the solution to that is reading all the code you commit, even though it's generated by AI
Relying on programmer discipline doesn't scale. Also, in my experience, copy-pasting a snippet and then checking it for subtle bugs is harder than just reading it, getting the gist of it, and writing it yourself.
Thank you for putting this so eloquently. This has basically been the sole tenet of my programming philosophy for several years, but I’ve never been able to put it into words before.
It synthesizes new code based on a corpus of existing code.
It looks to me like they're suggesting you use Copilot to write the tests.
There will still be plenty of low level systems programming work. The field is growing, not shrinking.
One impact this may have is that it may make tasks easier and more accessible, which could bring lots of new talent and could also apply downward force on wages. But the counter to that is that there is so much more work to be done.
I'm all for new tools.
Perhaps AI should work on simplifying the existing stack first, without breaking the functionality. What about that?
In the examples, I wish the auto-generated code came with comments or an explanation like SO does. The code I need help with the most is the code that's a stretch for me to write without Googling. The code I can write in my sleep I'd rather just write without a tool like this.
It would be like if I said plumbing or auto repair is just watching youtube videos and going to lowes. Just because I've managed to do a few simple things, doesn't mean I'm in a position to belittle an entire profession.
That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.
Me too, then I understood that code and programming is commoditized. As long as it works and looks pretty on the outside and it can be sold, it's fair game.
"There'll be bugs anyway, we can solve these problems somehow" they probably think.
Heck even containers and K8S is promoted with "Developers are unreliable in documenting what they've done. Let's make things immutable so, they can't monkey around on running systems, and make undocumented changes" motto.
I still run perf on my code and look for IPC and cache trashing ratio numbers and try to optimize things, thinking "How can I make this more efficient so it can run faster on this". I don't regret that.
I then modify the majority of the answer to fit any special criteria outside of the general case I asked, or more frequently, modify the code beyond the minimum viable answer to fit in the test suite/logging framework/performance monitoring/etc that is involved in my platform
Still call it copy and pasting in casual conversation even if there’s not a single line that’s recognizable between where I started in stack overflow vs where I ended up
Own code would be bad but libraries? That's kinda the idea of an abstraction layer.
The idea of an abstraction layer is to make it easier to read and write code that is at a different layer. Many of us write our own abstractions, it's not because we don't understand what its doing.
That's a dog whistle to find a better company/location.
So many STLs are fucking unreadable. Golang's is the only one where I've actually enjoyed it a bit.
I can think about people who can do this happily. Some of them are professional programmers. Some are self-taught. Some have CS education. Seriously.
OTOH, I'm similar to you. I either re-use my own snippets or read SO or similar sites to get an idea generally how a problem is solved and adapt it to my code unless I find the concept I'm looking for inside the language docs or books I have.
Yes, I'm a RTFM type of programmer.
That said I would probably not look to a third party library to just to simple data transformation stuff. Probably the only thing I do copy almost verbatim from SO are things like Awk/Sed commands that are easy/low risk to test but would take hours to derive myself.
Once we have multiple proven technologies that handle each of the functional areas that we collectively need, then we'll start to find greater benefit in maintenance, bugfixes, and performance improvements for those existing technologies and their dependencies than we find writing additional code and libraries.
I spend a probably half my coding time testing and digging into those libraries because I don't understand them and because they cause performance issues because nobody on the team understands them sufficiently to make their "high level design and abstract reasoning" accurate.
One problem with the current world of programming tools is that there's no good way to know which libraries are suitable for use when correctness and performance and reliability really matters, and which are only really meant for less rigorous projects.
> The advantage [...] without me having to leave my IDE.
You're arguing for the convenience, my point was that that convenience creates a moral hazard, or if you prefer, a perverse incentive, to increase the number of lines of code, amount of boilerplate, code duplication, and to accept horrible, programmer-hostile interfaces because you have tied yourself to a tool that is needed to make them usable.
> Ajax post boilerplate
This is an argument for choosing the most appropriate abstractions. The problem with boilerplate isn't that you have to type it, it's that it makes the code worse: longer, almost certainly buggier, harder to read and understand, and probably even slower to compile and run. You could have made an editor macro 20 years ago to solve the typing boilerplate problem, but it wasn't the best answer then and it isn't now.
(Now... you may argue that apis are often badly designed and implemented... but at least they are trying).
You might be right (I haven't met the majority, I have no idea) about "the majority of programmers", but it seems a little rude to assume the person you are responding to is some talentless hack that can only import things off the internet they don't understand.
Sure there will be some codebases out there that are plastered together using this tool, but when it comes to delivering software that is well written, performant and maintainable over the course of several years, you're still going to need a lot of skilled engineers to pull that off.
I would augment that to "billions of lines of code that may or may not be safe and secure"
If they could tie in CodeQL into Copilot to ensure the training set only came from code with no known security concerns, that would be a big improvement.
At this point it doesn't, and we can't, because Copilot is just a fancy autocomplete. The code is there, first class, in your file. It doesn't introduce new concepts for you, it just tries to guess what you mean by function signature + descriptive comments, and generates that code for you.
With every new layer of abstraction there’s more power.
The long term benefit of a tool that can do this well far exceeds what humans can do by hand, but that may not be true in the very short term.
Either way, I suspect the benefits to be big.
Unlike an additional abstraction layer, the readibility is not increased.
"Write a standard sign up page" -> Generated HTML
"Write a unit test to test for X" -> Unit Test.
It's more than just syntax completion - I'd argue that's the beginning of a new layer of abstraction similar to previous new abstraction layers. The demo on their main page is more than syntax completion - it writes a method to check for positive sentiment automatically using a web service based on standard english.
This is extremely powerful and it's still super early.
I saw one example that converted english phrases into bash commands, "Search all text files for the word X" -> the correct grep command.
That is a big deal for giving massive leverage to people writing software and using tools. We'll be able to learn way faster with that kind of AI assisted feedback loop.
Similarly to compilers, the end result can also be better than what humans can do eventually because the AI can optimize things humans can't easily, by training for performance. Often the optimal layout can be weird.
It makes boilerplate cheaper to churn out.
Whether you’re working in a new language or framework, or just learning to code, GitHub Copilot can help you find your way. Tackle a bug, or learn how to use a new framework without spending most of your time spelunking through the docs or searching the web.
May be I'm just unprofessional, I don't know. I get my stuff done, may be not as fast, but at least I understand every bit of my code and I rarely have unexpected surprises. I understand that there are other approaches, but I just don't enjoy that way, so I follow mine as long as I can find work. And I actually like things that other people find boring, according to this thread. Withing "business code" - hate it, writing "auth layer" - love it.
"The real hero of programming is the one who writes negative code." -- Douglas McIllroy
"One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
But unfortunately, we've come to a situation where SLOC and innovation for the sake of innovation is more important than code quality.
There’s a huge difference between:
1. Writing the core logic for an algorithm from scratch
2. “Connecting things”: e.g. writing the “click” handler for a button press, adding an auth middleware to a HTTP request handler
The latter consists mostly of boilerplate code: code that thousands of developers have already written. Copilot is useless for the former, and great for the latter. It has no idea what algorithm you want to implement, since you may be the first to write it, but it has seen the code of countless other individuals who needed to write the same boilerplate.
This is my actual hoped-for endgame for the ad based internet. At some point Twitter, FB, etc will be exclusively populated by bots that post ads, and bots that simulate engagement with those ads to drive up perceived value of advertising. They'll use AI to post comments that are really just ads or inflammatory keyword strings to drive further "engagement." The tech companies will rake in billions and billions of dollars in ad revenue, we'll tax all of it and use it to create flying cars, high speed rail, and an ad-free internet closed off to all non-humans. Occasionally a brave ML researcher may venture out into the "internet" to take field notes on the evolution of the adbot and spambot ecosystem.
No tax, no flying cars, eventually not even humans around - just AI-driven companies endlessly trading with each other, in a fully-automated, self-contained, circular economy, from which sentient beings were optimized away.
More than that, you misunderstand how advertisers prioritise their money. They pay for outcomes. If they notice that over the past couple of months they’ve been receiving mostly bot traffic, they stop advertising. Not everyone all at once, but enough that revenue begins to decline. An ad based business that cares about the long term will do it’s best to weed out the inauthentic engagement.
How they verify those outcomes, however, gets interesting. See, for example, College Humour going under due to inflated engagement metrics fed to them by Facebook video.
Yes, naive attempts at manipulation will be detected these days on big platforms. 5+ years ago such naive attempts were successful, though. A few years ago I made a proof of concept to show how easy it is to make new Reddit accounts and automate them, and had registered hundreds of accounts. Those logins still work even though Reddit has cracked down on naive automation attempts.
Today, that's why many firms buy real users' accounts. They'll hire people to manually login to the accounts and post. There's also the perpetual cat and mouse game between bot creators and platform owners, and the platform owners who benefit from the appearance of increased growth and engagement that's actually just bot activity.
I use programming as one of the examples of intrinsically human work.
You have a (general computing) machine that can do anything(), it only has meaning and utility from humans thinking about problems they have and how to solve them.
The hard part of programming is analysing what problems you have, and what you want to do about them.
This is why one of the distinguishing features between junior and senior programmers is that seniors tend to think about the (human) problem they’re solving a lot more.
Tools like copilot help with the physical interfacing between programmer and machine, but they don’t eliminate programming.
But a recurring worry people are expressing in this thread is: some people think they _do_, and how insidious that idea is.
The tool is great, the managers deciding that time spent thinking about its output, or developing their staff’s skills, is a waste because “just use what the AI says”, are the danger.
As long as people and computers exist, there will be programming.
not actually “anything”
There will always be a place for meticulous consideration of exactly what's being done, and many levels of that as well. For the same reason people reach for python to mock up a proof of concept or throw something together that is non-essential but useful to have quickly, even meticulous programmers might use this to good effect for small things they don't care to spend a lot of time on because it's not as important as something else, or the language they're using for this small task isn't one they feel as proficient in.
Absolutely true.
If your code is so repetitive that can be correctly predicted by an AI, you are either using a language that lacks expressiveness or have poor abstraction.
The biggest problem in the software world is excessive complexity, excessive amounts of (poor) code and reinventing the wheel.
A few rungs up on the ladder we still have programmers but now the kind whose job it is to write as little code as possible, where their worth comes from knowing exactly how little code glue is needed to, necessarily and sufficiently, make other people's libraries work together to functionality that is larger than the sum of its parts. These folks aren't solving unique problems, they make things work with as little code as possible, and copy-pasting from SO for problems that have been solved countless times already by others is 100% fine: their expertise is in knowing how to judge other people's code to determine whether that's the code they need to copy-paste.
And then, of course, there all the folks in between those two levels of abstraction.
The biggest mistake would be to hear "programming" and think "only my job is real programming, all those other people are just giving me a bad name". Different horses and different courses, and different courses for different horses.
I get what you're saying, but I'm not worried. At the end of the day, the programmer has to understand the code they're submitting, both the fine grain and the holistic context. If they don't know how to, or can't be bothered at least curate the suggestions the tool is making... then your organization has much bigger problems than can be helped by reading a Dijkstra paper or two.
Shouldn't the one who has produced this code be responsible for making sure the integrity of it? 5k LOC in a day without test cases, then that is no code, it is a disaster.
I think the marketing here is about right. This is no AI programmer, but Copilot. It is an intelligent assistant that does some mundane things for you with probability of failing some of that even, but when the stars align, you are in luck.
I see this as INCREDIBLY useful for certain niche of programming:
1. Front end. Some components are really trivial but still requires some manual rewiring and stuff, this could be the life saver.
2. Templates for devops. Those are as soul crushing as possible, and I couldn't think of a better domain to apply Copilot to it.
Overall, this is a huge win for programmer productivity, with reasonable compromises.
- Copilot suggests me a snippet of code
- It's almost what I wanted. I fix the code
- Copilot sends back the fixed code to GitHub
- Copilot gets better at guessing my (and others) wishes
Unless Copilot is running locally, I won't use it.
#!/bin/bash
# List all python source files which are more than 1KB and contain the word "copilot".
find . \
-name "*.py" \
-size +1000 \
-exec grep -n copilot {}\;
"-exec grep -n copilot {}\;" needs to have a space before the semicolon otherwise find fails with "find: missing argument to '-exec'".The "1000" in "-size +1000" has a unit of 512 byte blocks so it is looking for files that are greater than 512000 bytes, not 1KB. This would be very easy to miss in a code review and is one of those terrible bugs that causes the code to mostly work, but not quite.
If anything, I see copilot generating more work for existing, senior programmers - so there you have it.
I could see it being useful maybe for testing. Even if it straight up copies code from the Linux kernel, you don't usually ship tests to customers so the GPL (probably) isn't a problem.
But the problem with testing is that you need to be 100% sure about how it behaves, and an AI generated test might not be reliable enough to be useful.
Sometimes resources like these are used as references and the solution is used as is. Sometimes they are used as a survey, and it's more like asking a librarian "I want to learn more about how to X" and having them give a short exposition and point out some sources to study. It's important not to let you view of it's usefulness as one type of resource bleed into your view of how useful it might be for the other.
As a learning resource, this is very interesting.
#!/bin/bash
For increased portability, respect users' PATH environment variable using: #!/usr/bin/env bash
Using #!/bin/bash could lead to subtle bugs on systems with more than one version of bash installed, or outright breakage on systems where bash isn't installed at /bin/bash. (OpenBSD is known to use /usr/local/bin/bash, for example.)Just kidding... writing imperative code is fundamentally different than most AI recognition tasks, ie you can have GPT-4 produce consistently nice HTML but not C++
For foss ones it could be great though.
I think the best part for me is that how it's going to introduce even more low code devs to the worker pool, which means I will be able to raise my price again. Last time this happens, when designers got to the backend, I got +30% in a year once my clients figured out the difference in output.
One example of where this can be a problem is numerics - most software developers don't understand it and routinely do questionable things. I'm curious what effort the authors have put in to mitigate this problem.
Downvoters: I hope you read the 'Availability' Section of the FAQ. GitHub literally admitted this.
> Can I use it in another IDE than Visual Studio Code?
Not yet. For now, we’re focused on delivering the best experience in Visual Studio Code only.
> Will there be a paid version?
If the technical preview is successful, our plan is to build a commercial version of GitHub Copilot in the future. We want to use the preview to learn how people use GitHub Copilot and what it takes to operate it at scale.
That is a translation to a proprietary lock-in service tied to VSCode, GitHub and OpenAI which is all Microsoft exclusive and it admittedly unavailable on other editors. The extension does NOT work on Atom editor for example.
If that is not a strong case for the 'Extend' phase, I don't know what is.
It would be nice if github made this tool publicly available in a good spirit of open-source instead of straight up monetizing it.
I get that github is not a non-profit but still.
Personally I think this whole class of feature only offers trivial short-term efficiency gains at the expense of long-term professional development and deeper understanding of your field.
> Choose library.js for your next secure project!
> * Military-grade encryption!
> * Industry best-practices!
> * Extensively-tested codebase!
> * No Github Copilot!
This seems to me like someone had a cool idea for using GPT and wanted to experiment with it, but then Microsoft threw money at the marketing people and forced it to become a commercial product.
Sure, you might say "it's all marketing and if AP exists nobody would buy CP", but I don't think it's that simple. Customers understand when their expectations are being met, exceeded, or let down.
Other than that single issue, which is really a set of issues, it seems to work really well from the videos I've seen.
To some extent, it seems like this could suggest code chunks found somewhere else verbatim, which sounds like a copyright issue, but I also don't know if open-source licenses inherently allow you to train on their code in the first place?
I really like thar Tabnine train against your own codebase and suggest things based on it. It’s crazy accurate and smart a surprising amount of time.
It uses Open Source as its input but, as far as I can tell (and I would be pleasantly surprised if I was wrong), CoPilot itself is not Open Source.
It is also tied to Visual Studio, making Visual Studio, a Microsoft Product and on its way to monopoly position even more up the power law curve to monopoly status.
This would be much more interesting and less concerning if CoPilot was Open Source and designed to plug in to other Editors / IDEs like via lsp or something similar.
VSCode followed the classic big tech recipe : 1) make it open source to look like the good guys & get adoption and contributions 2) close-source many key components & add spyware.
Story of Android too pretty much
Now there are only three questions left: how will this be monetized? Will it recoup the purchasing price of Github? And how can vendor lock in be achieved with this or sny follow up products?
I think AI in software development will save us a lot of time, so we can focus on more interesting things. It may replace a few humans in the long term, but as software developers we shouldn't be hypocrite because we work hard to replace humans by software.
However, I find the process of writing these sorts of functions cathartic and part of the process to get into zen-mode for coding. I think I'd feel less joy in programming if all of this was just done by glorified commenting and then code-review of the robot.
I like to think of coding in terms of athletic training, which usually is comprised of difficult tasks that are interspersed with lighter ones that keep you moving (but are giving you a bit of a break). Training for soccer teams often involved lots of sprinting and aerobic exercise - and in between those activities we would do some stretching or jogging to keep our body moving. These sorts of small functions (write a function to fetch a resource, parse an input payload, etc.) are when my brain is still moving but getting ready for the next difficult task.
That may be true for individual contributors, but if you're trying to build a company from scratch, any help you can get to move faster is a good thing, cathartic or not.
The value proposition here is clear: "This tool will make it harder for your engineers to do time theft. What used to be an hour's long effort of painstakingly hand-coding boilerplate as a way of 'taking a break' will now be at most 5 minutes worth of easy code review."
Until this is fixed, good luck but not thank you Microsoft.
2 security thoughts that I couldn't find answers to:
1. how does the input fed into OpenAI codex filter out malicious code pollution? or even benign but incorrect code pollution (relevant research on stackoverflow for example - https://stackoverflow.blog/2019/11/26/copying-code-from-stack-overflow-you-might-be-spreading-security-vulnerabilities/)
2. In an enterprise setting, what does the feedback loop look like? How do you secure internal code that is being fed back to the model? Does it use some localized model? HE, etc?
Autocompleting code in general? Sounds like a bad idea, imho.
Has anyone seen anything about this system? Are others able to build upon it?
I think it would make the most sense as a really advanced static-analysis tool/linter/etc. Imagine writing something like C where whole classes of errors can't be checked statically in a mechanical way, but they could be found by a fuzzy ML system automatically looking over your shoulder. Imagine your editor saying "I'm not sure, but that feels like a memory error". And of course you can dismiss it "no, good thought, but I really meant to do that". Imagine an editor that can automatically sniff out code-smells. But the human, at the end of the day, still makes the call about what code to write and not write; they're just assisted with extra perspective while doing so
This product seems to encourage the complete opposite - hack together stuff without thinking about how it could fit into your accumulated Baukasten of components.
of course I guess copilot won't be perfectly accurate right now or even maybe for a long time but it is interesting to imagine a future where the programmer can think and get code written without lifting a finger.
- I write GPL'ed code.
- Someone uses this tool to develop a proprietary solution.
- I later prove that the tool generated code that is equal to mine.
Now the code of the proprietary solution must be GPL licensed! Cool!How I'd defend myself? I'd only use such a tool if there are guarantees of the licenses of the code it was trained on. Without such guarantees, it is just too risky.
1. A lot of people on this thread are concerned about licensing issues with GPL etc. I am sure Github will restrict the beta until it figures out that stuff.
2. I wonder if eventually our corrections to the code suggested by the model would be used to feedback to the model, and if that'll lead to a differential pricing - If I let it see my code, I get charged lesser.
3. I believe a mini-GPT-3 model is where it's at. GPT-3 (and similar) models look to be to too big to run locally. I've been using TabNine for past year or so & it gives me anywhere between 5-10% productivity boost. But one of the main reasons why it works so well is because it trains on my repo as well. TabNine is based off GPT-2 from what i've heard.
4. prediction: Microsoft is probably going to milk GPT-3. Expect a bumpy ride.
5. In all likeliness, this would be a great tool to make developers productive, rather than take their jobs - at least at levels that are more than just code-coolie.
6. Eventually all tasks with enough data around it will see automation using AI.
Isn't that the wrong way around? I'd like to start by writing the tests, and for GitHub Copilot to please implement the function that makes them pass.
(dang please don't ban me for a low-quality comment :) i couldn't resist but will not make it a habit!)
A lot of the time, I'm thinking pretty deeply about the code I'm writing, and as I'm writing code I'll also be thinking about how it applies in context.
Having some external agent inject new code into my editor would shatter my thought flow, since I'd then have to grok whatever it just spit out instead of continuing on with whatever thought I was pursuing at the time.
I assume companies that were fine with providing you functionality for free may think about this twice because with that they're giving away knowledge of how to build functionality.
It’s a pretty bad feedback loop that robs us of our independent thought by way of falling victim to laziness, a fundamental human weakness. You can imagine something where in this case the code autocomplete is so large that you really want to make that autocompletion work, even if you know it’s not elegant or possibly even correct code… or maybe it’s just repetitive and not abstracted well, but here it is autocompleted and done so why would you fight that?
If we continue abstracting more and more of this way, based upon datasets that are averaged across everyone, we lose the individual in favor of the masses, bringing us all down to a common denominator.
If we must lose our humanity to the machine, I’d at least like to see an autocomplete from Peter Norvig’s code, or writing from particularly effective communicators or famous authors.
This was my first thought when I saw this. I intentionally don't use predictive text whenever I can to preserve whatever originality I have left.
Gmail offers a way to reduce the "prose at length" to a few buttons. And it adds the pleasantries for you.
You can think of it as a workflow automation tool. Your email chains are tickets and you're moving them through different statuses.
Notwithstanding, personal/intimate email is different and spending time writing a beautiful letter is a thing of its own.
If I'm sending to a relative or family member for example, or even a professional contact, then I'm not going to be lazy and auto-complete. But when someone says "Does that sound good to you?" it's great to push a button that replies "Sounds great, thank you!"
Maybe I would have naturally written "That sounds great, thank you [name]", but what's the difference?
Social graces?
A company ingesting an entire GPL codebase without warning or any way to opt-out in order to create a closed-source feature that they and only they will profit off of is clearly not the same as an individual reading the code and getting a job based on those ideas.
- if you reproduce GPL code verbatim, you're in violation*
- no warning that somebody/something is ingesting the repo
- no way for the repo to have opted out
- closed source (you can't get the source from somebody's brain)
- private profit
* Do we even know if the machine is more or less likely to do this? Humans are certainly capable of it.
> no warning that somebody/something is ingesting the repo
An individual reading code on their own time is not the same as ingesting terabytes to train a machine. No matter how much you believe in AI working similar to the human learning (it doesn't), they are not comparable.
> private profit
Again, the difference between an individual reading code to work for a salary is orders of magnitude different from ingesting terabytes of code so a company can create a new feature. Claiming these things are the same only makes sense if you ignore the massive differences in scale and the differences between how humans and machines learn.
Is software doing something at scale unethical? Is it unethical to use software for profit? I'm afraid almost all programmers are guilty of both.
How can one signed up? This could make one programmer an army.
I don't know if Copilot does it already but I would love if there was a tool that does exactly the opposite — convert code to comments and documentation.
Then we can run it overnight each night, knock back whatever rubbish it generates before breakfast now that there's nobody left to complain and schedule 6 hours of meetings to "fix" it, and instead we have the whole day to just build it quickly and properly the first time.
We just increased productivity on the average enterprise project by 50%. Good stuff.
However, the elephant in the room is definitely a tool that can auto fix bugs - the type of bug that is usually given to a junior developer because the team doesn’t want them building features yet.
Like… a bubble of developing code from yesterday’s code (plenty flawed itself) and with exponential growth based on feedback loops of self-fulfilling prophecy —— I’m assuming copilot (and every openai variant to come) will essentially retrain itself on new code developed,which overtime might all be code it wrote itself.
Did we just create a hamster wheel for the industry, or high-rise elevator?
From the examples:
body: text=${text}
`text` isn't properly encoded, what if it has a `=`? rows, err := db.Query("SELECT category, COUNT(category), AVG(value) FROM tasks GROUP BY category")
if err != nil {
return nil, err
}
defer rows.Close()
shouldn't we want to cleanly `rows.Close()` even if there was an error? float(value)
where `value` is a currency. Doesn't Python have a Decimal class for this? create_table :shipping_addresses do |t|
that's an auto-generated table, that one's debatable but for starters a `zip` fields makes it American only. And doesn't the customer have an e-mail address instead of a shipping address? var date1InMillis = date1.getTime();
But what about the time-zone offset?I could go on, but literally the first five examples I looked at are buggy in some way.
Edit:
const markers: { [language:string]: CommentMarker } = {
javascript: { start: '//', end: ''},
Wow.Edit 2:
function collaborators_map(json: any): Map<string, Set<string>> {
Not exactly buggy, but 8 lines of tedium.What about
new Map(json.map(({name, collaborators}) => [name, new Set(collaborators)]))
instead?Edit 3:
const images = document.querySelectorAll('img');
for (let i = 0; i < images.length; i++) {
if (!images[i].hasAttribute('alt')) {
I mean, I get it, it's auto-generate code. Maybe in the future they can narrow it down to auto-generating good code. document.querySelectorAll('img:not([alt])').forEach(
(or) img:not([alt]) { border: 1px solid red; }
(or) eslint-plugin-jsx-a11y because that maybe that img was rendered through react.
(or) it should really be an `outline` because we don't want this to reflow the page and we can. And maybe a will-change.
Another extra work for code reviewer. However on the right hand it will be very powerful!
To be fair, “beat on it until it seems to work” without AI assistance or copy-pasting code also frequently involves a fair amount of “using something they don’t understand”.
OTOH, copy pasta and AI assisted code are less likely to get “I don’t know why this works” or “I don't know why this is necessary” comments to highlight that to the reviewer.
If this improves developer efficiency by 10%, 10% fewer developers are required.
Where we're going is assisted AI; obviously not a full on replacement as the scare stories created by the AI hype squad in this thread after the first reactions of this tool.
I am looking forward to AI testing the programs I write though. That would be awesome.
Wouldn’t work in this case with the overlays and styling tho.
https://news.ycombinator.com/item?id=27676266&p=2
https://news.ycombinator.com/item?id=27676266&p=3
https://news.ycombinator.com/item?id=27676266&p=4
https://news.ycombinator.com/item?id=27676266&p=5
(Comments like this will go away when we turn off pagination. I know it's annoying. Sorry.)
This may be the first time that a proprietary coding tool offers such a great value preposition that I am actually interested in trying it out and potentially even paying for it. It's also a bit concerning that this will probably be extremely hard, if not impossible, to create an FOSS version of this technology, just because of the immense amount of computing power, and by extension money, needed to create GPT3.
I'm not that comfortable with the idea of a future where proprietary AI-based solutions and libraries (e.g. automatic testing libraries, which have been mentioned here a few times) are so powerful that I'll be forced to use them if I don't want to waste my time.
GPT-3 will take way less time to make a good substitute that costs the power of compute than other historical time saving technologies. Unlike other historic technologies, they pretty much spell out exactly how to do it, and own no patents related to its creation. I have trouble seeing the downside.
Seems like you came up with the perfect word to describe your view on this. :P
I defintiely do think there is reason to worry about the future you're imagining happening, but as someone who has read through the papers on gpt, this is in no way going to end up being an exclusive proprietary API, so it'll very soon have open source and likely free or at compute cost options.
And well, if it doesn't make us better, no one will use it. If it does, you'll have to adjust to remain competitive, just like millions of professionals for going back millenia who encounter new technology in their chose and vocation. Ultimately, if it makes us better, and doesn't enslave us to the whims of a monopolistic holder (which the point of my post was to conjecture that it likely wouldn't) then it'll probably (though not defintiely) be better for us long term.
Hopefully it doesn't erode programmers abilities like spell check seems to have eroded people's spelling abilities but I fear that's a likely side effect.
SETI@home achieved 50 times the computing power of the world's largest supercomputer [0], so it might actually be the only way to train the future GPT4 or GPT5.
I'm picturing the StackOverflow problem where the accepted answer is actually wrong, and actively pushing it into more peoples code is just proliferating the problem into more places. Making people faster at building mostly the write but sometimes the subtly wrong thing.
- Intentional poisoning the model with difficult to recognize and exploitable faults - Unintentional poisoning from flawed generation habits which are further reinforced by the usage being eventually fed back into the model
I don’t know how it maps to code, but in my experiments generating text with GPT-3, I have started to get a feel for its ‘opinions’ and tendencies in various situations. These severely limit its potential output.
Your move, AI.
nope, it’s not April 1
I don’t see this going anywhere.
If it’s really good and we can actually have 1 developer instead of 2 now why would any developer want to do this? this would basically be a piece of automation that diminishes the value we are creating.
If it’s crap it’s going to create mountains of verbosity and code written to pump up the LOC numbers. It’s terrible. After that you’re gonna end up maintaining and enhancing what an “ai” spew out.
I’m not buying the argument this is a problem that needs solving. It’s in the same vein with self driving cars. It looks impressive, it’s good PR, it’s absolutely insanely hard to get right and the benefits (even if we get it right) are questionable.
the way it was introduced is also disingenuous.
I am skeptical and against the hype of this "replacing" programmers which it certainly won't as the AI engine that it uses (GPT-3) is limited and the code itself can also generate garbage or introduce insecure and vulnerable code as well. This is why it will always be 'assistive' rather than going to 'replace' anything. 10 years later, self-driving cars are still unsafe and immature.
The hype squad of this tool know it is limited but they want to capitalise on the 'AI' automation narrative to those who don't know any better.
You can see this today in most places where you can walk on water, but you still need to be in your pay band.
Currently consulting for a bank who takes their security very seriously. Would there be extra hurdles here to make sure there's no calls or requests being made using our data?
AI tools like this will be force multipliers, the same way that IDEs are. SWEs 20 years ago decried the rise of the IDE the same way that some are moaning about this. "It'll lead to a generation of know-nothing programmers." Instead, SWEs are more productive today than they ever have been before.
Software engineers should welcome the day that an AI makes it possible to describe what you want instead of telling the machine exactly what to do. That's where I see this technology going in 20 years. That said, it will likely never be good enough to replace an engineer completely because the value of an engineer is in deciding what to build and how to build it. Not in determining exactly which lines of code to write. SWE will be more enjoyable as a field in 20 years because we won't have to wrangle compilers, or deal with fundamental limitations of how computers express ideas versus how humans express concepts. Instead, we'll let the AI translate for us and deal with all those problems automatically.
In the short term, I see lots of potential for this technology to make something like the ultimate cross-compiler. If you can take someone's code, convert it to some kind of universal representation (embedding), and then convert that to another language (and get working code that verifiably produces the same results) you would make a ton of money.
I mean, I understand (I think) how Bert/gpt works, but I can’t quite see how you would train this.
I don't use autocomplete nor syntax highlighting, this thing feels almost hostile to my ways.
(the only non linear help I love, is jump to definition)
https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
What you didn't write or deleted does not contain errors and you do not need to support or fix it.
This must be easy to measure, over the entire open source corpus.
How about two lines?
Never realised they'll read my code to make something like this and maybe even make profit from it.