It is massively improving my productivity, things I couldn’t be bothered to write it does for me.
The thing I find really good is it can predict what I will do next. Say if I have a list of columns in some text somewhere in the project when I write one “df = df.withColumn(“OneItemInList”)”
Copilot will then add the same for all the other items - is really nice
Tried it out for a while, and it's clear that it's trying to get people to be faster at writing boilerplate, not get people to write better code.
I'm a bit scared for what this means as I don't think being able to faster write boilerplate is something worthwhile. The example ed_elliott_asc made is one of those examples where instead of fixing things so you don't have to repeat yourself, copilot makes it easy to just live with the boilerplate instead.
In my experience whenever someone tries to "innovate" away boilerplate they end up creating shitty abstractions that are inflexible, poorly documented, and unmaintained.
Boilerplate generally exists for a reason, and it's not because the creator likes typing.
Possibly yes, if you're only contrasting it with being able to be faster.
I mean, it's sort of a false dichotomy -- it's omitting a "default speed" for writing boilerplate that is neither enhanced nor impeded.
the potential issue with an enhanced speed for writing boilerplate is that it means that there'll just be more and more boilerplate to maintain over time, and it's not clear what that cost over time will be.
How much more effort will be expended to replace things in multiple places? It exacerbates existing issues of "these two things look almost the same, but someone manually modified one copy...should that change be propagated?"
Meaning, it's essentially an ad-hoc code generator. Code generation can be a very useful technique (see protobufs), but without the ability to re-generate from a source?
Perhaps a possible enhancement might be for copilot to keep track of all blurbs it generated and propose refactoring/modifying all copies?
> I mean, it's sort of a false dichotomy -- it's omitting a "default speed" for writing boilerplate that is neither enhanced nor impeded.
I'm not sure. I think that understanding is omitting a "default amount" of boilerplate that will have to be written regardless of one's individual preference that is really a function of the language / framework of choice, the existing codebase and the problem at hand.
Removing that boilerplate would be ideal but is not always possible given limited resources, time constraints and the usual inability to make sweeping changes to the codebase
So we settle for the second best solution which is to automate away that tedious process (or short of that provide developers with tools to get it out of the way faster) so we can all focus on "real work"
Writing a slightly abstracted library to handle populating a list isn't necessarily "fixing" something. It might be, for sure, but is going to be very use case dependent, and there are a lot of instances where it's better to have 5, 10, or yes even 15-20+ nearly-identical lines and be done in a minute or two (or 5 seconds with Copilot IME) than spend half a day tweaking test coverage on your one-off library.
> Writing a slightly abstracted library to handle populating a list
> than spend half a day tweaking test coverage on your one-off library
If you need to write a library and spend half a day to populate a list, you have bigger problems than boilerplate.
Nothing wrong with having duplicate lines. The problem becomes when writing those lines become automated so you start spewing those all over the place.
It's going to be great for exploratory data science. You don't really need stellar, maintainable or extensible code for that, the early stage is largely about iteration speed.
Iteration speed also depends on code being well written and performance code, you need to get results faster to iterate faster.
Also if your don't fully understand your code( when generated or copied from SO) as not uncommon with junior developers and data science practitioners, then they struggle to make even small change for the next iteration, because they don't fully understand what their code is doing and how.
When your code is composable or modifiable easily then iterations become faster because you understand what you have written. One of the reasons why analysts prefer Excel if data size is within limits.
Boilerplate is exclusively what I use AI-powered code completion for (currently Tabnine).
In a perfect world we’d all have excellent comprehensive metaprogramming facilities in our programming languages and no incidence of RSI (e.g. carpal tunnel syndrome). Code completion is a good tool to deal with these realities.
I only played around with it on OpenAI but it's the same model as far as I know. It's pretty good at regurgitating algorithms it's seen before. It's not good at all at coming up with new algorithms.
It's very good at translating between programming languages, including pseudocode.
It can write a lot more valid code much quicker than any human, and in a whole slew of languages.
I haven't had the urge to use it much after playing around with it constantly for a few days, but it was pretty mind-blowing.
Your response makes me wonder if poisoning the well is possible by submitting code to Github with multiple languages and coding styles. A single file with a function signature written in Javascript and the body written in Python + Ruby. Enough code would surely break the AI model behind it. Unless Copilot has some sort of ingestion validation which wouldn’t surprise.
In any training with code I've done, we've written a parser that validates against tree sitter grammars to make sure it's at least syntactically valid against some known subset of languages we're training on.
I’m which case shifting strategies toward code that looks correct but isn’t using shared syntax between languages as well as language specific gotchas.
Yeah but if malicious intent is a concern you can just spin up a sandboxed instance to run the code to check first.
Really the thing is there's not way to ascribe correctness to a piece of code right, like humans fail at this even. The only "correct" code is like rote algorithmic code that has a well defined method of operation. And there's likely a lot more correct examples of that, like way more than you'd ever be able to poison.
You may be able to be misleading though by using names that say one thing but do another, but again you'd be fighting against the tide of correctly named things.
Probably but you would have to submit an absurdly large amount of code to make a dent. Practically unreasonable considering their training corpus is also increasing per lines of public code submitted on github.
So not only would you have to submit a insanely large amount of code but you're also racing against literally millions of users writing legitimate code at any period of time.
I don't know if this is true, but I would assume that the tokenizers they used for Codex use actual language parsers which would drop invalid files like this and make this attack infeasible.
When I was playing around a couple years ago with the Fastai courses in language modeling I used the Python tokenize module to feed my model, and with excellent parser libraries like Lark[0] out there it wouldn't take that long to build real quality parsers.
Of course I could be totally wrong and they might just be dumping pure text in, shutter.
It can generate the body of test cases well, especially in BDD frameworks where you write the high-level scenario first to prime it with context. Less tedium encourages me to write more tests.
More verbose languages like C++ become less obnoxious to write in. I know RSI has been mentioned and any tool which cuts down on excessive typing will help with that.
It sometimes reveals bits of the standard library I wasn't aware of in unfamiliar languages. I can write my intent as a comment and then it may pull out a one-liner to replace what I would have normally done using a for loop.
The main downside I've observed is that if I'm not trying to reign it in, it can result in a lot of WET code since it can pattern match other areas of the surrounding code but can't actually rewrite anything that has already been written. It is important to go back and refactor the stuff it produces to avoid this.
What I like most about Copilot is seeing different programming styles suggested to me
For example, I didn't know about self.fail() in unittests and had never used it, but Copilot suggested it and it produced the most readable version of the unit test
If I want to throw an exception if an object is null or undefined, Co-pilot will do the if and the exception throw using the right error class, and a more meaningful error message that what I usually came up with.
If want to map some random technical data table to something useful in my programming language, I can copy paste the data from the documentation in pdf or html into a comment block, give an example, and co-pilot will write everything in the format I want.
If I want to slightly refactor some code, I can do it once or twice and co-pilot can help me a lot to refactor the remaining.
If I want to have a quick http server in nodejs, I don't have to Google anything.
This is the kind of thing I would need to see in real time, because I simply can't believe that it does any of these things in a way that is reliable and doesn't involve having to search through and make sure it hasn't made any mistakes, taking just as much time as if you did it by hand.
Likewise skeptical, but I have been super impressed with it. I just got in to the technical preview, and worked through a specific task I needed to do (involving mongoose, a mongo aggregate query, a few loops, some date functions) and started by adding a comment above each line. It helped a lot actually, felt like a collab.
I'll reproduce a generic example I sent a friend.
Prompt:
const redis = require('redis');
// Create a redis client
Copilot suggested:
const client = redis.createClient();
I accepted it and moved 2 lines down, prompt:
// Get the current count from redis
Copilot suggested a start to the operation:
client.get('count', (err, count) => {
I accepted it, and Copilot continued:
if (err) {
console.log(err);
return;
}
// If there is no count, set it to 0
if (!count) {
count = 0;
}
// Increment the count
count++;
// Set the new count in redis
client.set('count', count);
// Log the new count
console.log(count);
}
Redis has the INCR command that does this in redis without the additional round-trips (and race conditions). It also sets the value to 0 if the key doesn't exist.
So, I actually consider this to be exactly the bad behavior that people accuse Copilot of.
This was just one of its suggestions, but you're right of course.. it's all based on the training data and idioms used there. If it doesn't weight more modern code higher, if it's not aware of new versions and methods, it isn't going to be super intelligent.. but it can still give you some ideas.
Writing that probably takes a longer time than just doing it with the IDE help in jetbrains, though?
Press "r", press "." to autocomplete so it now says "redis.", then write "cC" and it suggests createClient (or write "create" or "client" if you're not sure what you're looking for). Now it says "redis.createClient()". Press ctrl+alt+v to extract a variable or write ".const" and press tab to apply the const live template. Ending up with your result in two seconds.
The power of something like Copilot is in building out stuff you're not familiar with or don't have templates set up. It's probably not as helpful when you already have a clear idea of what you want to do and just need it rather than think about it.
+1 for the variable extraction thing, I've been using their IDE for ages and it never occurred to me to look for such a thing.
I use it especially much when writing old school java. Instead of writing "MyClass myclass = new MyClass()", I just write "new MyClass()" and get the typing for free. Even better when you do longer expressions and don't want to think about the type up front. Like working with streams or so.
Yeah this would be quite helpful for me as I tend to just experiment with things in the console (cleaning up messy datasets and the like) and then copy or rewrite into something more structured later. I feel like I'm only using about 20% of what Pycharm can do.
It's _very_ good at "learn by example" with some twists. It _does_ make mistakes, and I do double check it, but it still definitely saves time. I used it to write the bulk of a new implementation of a new audio backend for a game engine yesterday - it filled out a lot of the "boilerplate" integration work (e.g. generating all the functions like "set volume/pan/3D audio position" that map over 1:1 to functions in the other library).
I will say, though, that it's also good at making up code that looks very believably real but doesn't actually work.
The ethics involved in Copilot are a bit strange, and I'm not sure I'll keep using it for those reasons, but it does a good job.
I was working on some internationalization stuff, translating some phrases from english to portuguese and Copilot just did it for me, does not seem like much but for me that is amazing.
I was able to write {"Settings":...} and Copilot completed with {"Settings": "Configurações"} that tool is simply amazing.
I've actually found it helpful as an API autocomplete, but... also not helpful at the same time.
So for example I was working with processing an image to extract features and a few variants of docstrings for the method got me a pretty close to working function which converted the image to gray scale, detected edges, and computed the result I wanted.
The helpful thing here was that there were certain APIs that were useful as a part of doing this that it knew but which I would have to do look up. I had to go through and modify the proposed solution: it got the conditional in the right place, but I wanted a broader classification so switched from a (255, 255, 255) check to a nearBlack(pixel) function which it then autocompleted successfully. I also had to modify the cropping.
When doing a similar task in the past I spent a lot more time on it, because I went down a route in which I was doing color classification based on the k nearest neighbors. Later I found that the AI I was working on was learning to exploit the opacity of the section of the screen I was extracting a feature from in order to maximize its reward, because it kept finding edge cases in the color classifier. I ended up switching to a different color space to make color difference distance functions more meaningful, but it wasn't good enough to beat the RL agent that was trying to exploit mistakes in the classifier.
Anyway, what I'm getting at here is that it is pretty easy to spend a lot of time doing similar things to what I'm doing and not get a great solution at the end. In this case though it only took a few minutes to get a working solution. CoPilot didn't code the solution for me, but it helped me get the coding done faster because it knew the APIs and the basic structure of what I needed to do. To be clear, its solutions were all broken in a ton of ways, but it didn't matter it still saved me time.
To give another example let's say you have a keyboard key event press and you weren't sure about how to translate that into the key that was pressed. key.char? key.key? str(key)? key.symbol? A former method of figuring out what the right key might be is looking up the code, but with CoPilot you type '# Get the key associated with the key press' then hit tab and it gives you code that is broken but looks perfect and you gain a false sense of confidence that you actually know the API. You later realize after being amazed that it knew the API so well that you didn't have to look it up that actually the key press event handles symbols differently and so it errors on anything that is used as a modifier key.
My general impression is something like: Wow, this is amazing. It understood exactly what I wanted and it knew the APIs and coded up the solution... Wait, no. Hold on a second. This and that are wrong.
I am in the same boat with you. I am simultaneously wowed and underwhelmed to some degree.
Yes it is amazing when it gets right, it feels like cheating. But at the same time, it many times, does ... too much? To read a huge chuck of code and figuring out where it goes wrong is not a thing for me. Also Copilot doesn't really know the API, so yes, the amount of mental tax isn't less to make sure your program really behaves.
But again, I see the idea of Copilot is already huge win. I hate writing those manual scripts just offer people an entrance to some utility behind. Copilot does those things, surprisingly well and with accuracy.
Let it improve in the future, and we will see changes that quite fundamental to the idea of programming itself.
I wrote a test recently for a simple "echo"-style server: clients writes a name to a socket, server replies with "Hello, " + name. Nothing crazy.
In the test body, I wrote "foo" to the socket. Copilot immediately filled in the rest of the test: read from the socket, check that the result is "Hello, foo", and fail the test with a descriptive error otherwise.
wtf? How did it figure out that the correct result was "Hello, foo"? I changed "Hello" to "Flarbnax", and sure enough, Copilot suggested "Flarbnax, foo". I added a "!" to the end, and it suggested that too. After pushing a bit further, the suggestions started to lose accuracy: it would check for "???" instead of "??" for example, or it would check for a newline where there was none. But overall I came away very impressed.
If I have an if else case, a switch statement or something similar, it can often predict the next branch exactly how I would write it. That‘s probably 80% of the suggestions I accept, the rest is single line autocompletes. I have never accepted a whole function implementation, and they are actually rather annoying because they make the document jump.
It‘s useful enough for me, as a magic autocomplete.
It's truly amazing, almost felt magical the first few autocomplete results I got.
There's the benefits that a lot of people mentioned, but to me the biggest benefit is I can avoid procrastination. Usually when I'm blocked on something I'll run a search in the browser, but very quickly I end up going off the trail and just browsing the web and losing a lot of time. Now when I'm blocked I simply type the comment of what I'm trying to do and the autocomplete suggestion is pretty damn good and unblocks me very quickly. More surprising of all, it somehow understands my code style by looking at the context.
As other pointed out, it makes boring or repetitive tasks a breeze.
Also, it’s like a more clever auto complete most of the time, even when it’s wrong in calling a function you can use it as foundation code to go faster.
And you don’t need to think too much about it, it really keeps you in the flow.
I find it works well when my intent is clear. For example, I might want to log a value I just computed for debugging purposes. I type LOG, wait a second, and it completes a zephyr logging macro, complete with a sensible message and the value I just computed.
It sort of feels like pair programming with an undergraduate, except copilot never learns. That isn't to say it's bad, more that it is just a tool you can hand simple stuff off to, except the handoff is zero-effort.
EDIT: I will say that there are times when it makes up fantasy constants or variable names, that seem plausible but don't exist. An eventual version of Copilot that includes more normal autocompletion information, so it only suggests symbols that exist, will be a stronger tool.
Useful to say, write a python script, doing some mandane things, like generate all the argparse lines for you, read the files, etc.
In a way, it does the dirty pipes surprisingly well. But when it comes to implement the core of the algorithm, it is not there yet, but the potential is huge.
I've been getting a lot more misses than hits with Github Copilot, even when writing elementary math or utility functions; but despite its error I am nevertheless astonished at its approximation of intent.
Very eager to see Github Copilot catchup to some bright line of signal v noise.
I would say the reverse, I’m getting so many hits that I’m mindblown. And when it missed, I can generally still use that and fix the suggestion, as it’s faster.
It's a glorified autocomplete to me. It seems like it feeds me mostly things I'd get from searching Stack Overflow. The first day was pretty interesting but the novelty wore off quickly. You still need to grok what it spews out and see if it's correct.
And the worst thing about that is that you don't get the context of the Stack Overflow threads, where people discuss the impact of the given solution and alternatives. So after a week, off it went for me.
I'm constantly blown away with what it spits out even when its wrong. When it pulls in the greater context of the app and generates comments from scratch using the context of the file, its just incredible.
QuickcCheck-type tools (generators for tests that know about the edge cases of a domain - e. g. for the domain of numbers considering things like 0, the infinities, various almost-and-just-over powers of two, NaN and mantissas for floats, etc.):
Fuzz testing tools (tools which mutate the inputs to a program in order to find interesting / failing states in that program). Generally paired with code coverage:
Mutation / Fault based test tools (review your existing unit coverage and try to introduce changes to your _production_ code that none of your tests catch)
Writing tests for the sake of coverage is already practically useless which is what a lot of orgs do, This could maybe generate such tests. However it doesn't materially impact quality now, so not much difference if automated.
One of the main value props for writing meaningful unit tests, is it helps the developer think differently about the code he is writing tests for, and that improves quality of the code composition.
I feel the opposite of codebases where having high coverage has been a priority:
* The tests doesn't actually test functionality, edge cases etc, just that things doesn't crash in a happy-path.
* Any changes to an implementation breaks a test needlessly, because the test tests specifics of the implementation, not correctness. Thus it makes refactoring actually harder, since your test said you broke something, but you probably didn't, and now you have to double the work of writing a new test.
* In codebases for dynamic languages, most of what these tests end up catching is stuff a compiler would catch in a statically typed language.
No, as a sibling comment to mine shows, it's actually easy to make 100% coverage with bad tests, since one doesn't challenge the implementation to handle edge cases.
It's easy to achieve 100% coverage with happy-path code and low quality shallow tests, agreed.
AFAIK, «high coverage» may have different meaning for different people. For me, it's «high quality», for others it's «high percentage», e.g. «full coverage» or «80% coverage», which is easy to OKR.
It's the fact this could even have a different meaning that makes this a useless metric - defining 'quality' or 'coverage' is subjective. The majority of tests written are meaningless noise, and serve mainly to distract from covering 'critical' failures. Again, a subjective measure, in the sense that was is critical to you and me may not be the same thing.
Which is what makes this whole concept of code coverage so much toxic nonsense...
Not to argue against writing 'quality' tests, but high 'coverage' actually decreases quality, objectively speaking, since erroneous coverage of code serves negative purposes such as obscuring important testing, enshrinig bugs within testing.
I would make my case here CodePilot and all such 'AI' tools should be banned from production, at least until they solve the above problem, since as it stands they will serve to shovel piles of useless or worse, incorrect testing.
It is also important to remember what AI does, i.e. produce networks which create results based upon desired metrics - if the metrics were wrong or incomplete, you produce and propagate bad design.
So yes people use it now as a learning tool (fine) and it will get 'better' (sure), but as a tool, when it gets better, it will constrain more, not less, along whatever lines have been deemed better, and it will become harder, not easier, to adjust.
The example i usually give [1] in javascript is say you have function
(x,y) => x + y
Orgs targeting code coverage write a test for 1,2 => 3 and get 100% coverage and then stop as there is no incentive to go further. They don't write tests for say
(1,null)
(null,null)
('x',1)
(NaN, Infinity)
and so on.. these additional tests will improve coverage of scenarios and code coverage will not move.
I have seen projects where a test will have sequence of steps which trigger the code but the assertion is effectively true === true, or they will replicate the same function in the test instead of generating proper mock data or myriad different absurd testing approaches. This comes from twin pressure of showing coverage and having tests pass.
Coverage is also a challenge in code which uses AI/ML libraries or that use third party services. These really need statistical testing with large volume of diverse well maintained samples and results need statistical analysis for error rates not different from how manufacturing does it, I don't see that often. For code using face detection for example a single face getting detected or not is hardly an adequate test.
Finally, it is easier to improve coverage by testing simpler code than improve coverage/ refactor a function which has say 10 nested branches, so it is not uncommon to see 90% coverage and 10% of the most used / most error prone code poorly or not tested at all.
There are some methods to address these like mutation testing, do retros for failure of tests to capture production bugs, it is not easy to measure and coverage driven orgs will not see their metrics moving by doing these.
Well written test suites will also have good coverage, but not necessarily other way around. Developers who care and understand what they are doing and why they are doing it, will use coverage as only the first step to see where there are gaps in their tests.
Tests are also code that need peer reviewed and maintained, if the tests depend on implementation and constantly break or contains improper mocks or assert poorly. A lot of not well written tests is hindrance to development than aid it.
[1] Yes, most of these are not applicable in a strongly typed language, but it is far easier as a illustration .
So one argument against code coverage requirements is that poor engineers won't test correctly. Without the code coverage requirements you're in the same situation.
Problem is with 100% code coverage of badly guarded / implemented code you'll have a fall sense of security if you're just looking at coverage as the metric of quality. Anytime I've worked with a company who had a required code coverage percent, they never actually cared what the code being covered looked like only that it was covered in some test.
If you are using floating point numbers implemented in hardware, then infinity is absolutely a valid value and one that your code will encounter. This is true regardless of language, as long as the language requires or allows IEEE-754 semantics.
I am not aware of any language (outside of intentionally-minimalist esolangs) that doesn't support floating point numbers. In some languages (like JavaScript) that's the only kind of number you get.
If you are seeking a minimum value within some complicated iteration, it’s easier to start your min accumulator as Inf than null with extra null checks.
I saw a cool study recently (summarized well here[1]) with an empirical experiment on how well code coverage predicts how well a test suite catches bugs. They found that the number of test cases correlated well with the test suite's effectiveness, but, when controlling for the number of tests, code coverage didn't.
It was a pretty thorough study:
> Our study is the largest to date in the literature: we generated 31,000 test suites for five systems consisting of up to 724,000 lines of source code. We measured the statement coverage, decision coverage, and modified condition coverage of these suites and used mutation testing to evaluate their fault detection effectiveness. We found that there is a low to moderate correlation between coverage and effectiveness when the number of test cases in the suite is controlled for.
Given their data, their conclusion seems pretty plausible:
> Our results suggest that coverage, while useful for identifying under-tested parts of a program, should not be used as a quality target because it is not a good indicator of test suite effectiveness.
That's certainly how I approach testing: I value having a thorough test suite, but I do not treat coverage as a target or use it as a requirement for other people working on the same project.
I've found that for large codebases of dynamic typed interpreted languages Test Coverage is very useful at preventing typos or subtle bugs that wouldn't be caught otherwise.
I think replies mentioning automatic unit test generation miss the point.
To me, the value of copilot helping to write tests is that we, the engineers, come up with the test cases, and copilot helps write the code for that case.
I think humans will still be more imaginative in the test cases they can dream up (although I’ve never used an automatic generator, maybe they’re better than I think), but almost all test code is boilerplate, either in the setup or the assertions.
If I don’t have to write that repetitious, yet slightly different boilerplate for each test case, that frees me up to design other interesting test cases (as opposed to getting tired of the activity by the time I cover the happy path) or move on to the next bug/feature work.
Presumably they are tree-sitter grammars for those languages. I think these grammars are open source so should be available (assuming they were unmodified).
Yesterday, I was disgusted to see framers putting up a house that clearly plagiarized the entire internal structure of my own. Same joint interfaces, same structural idioms when dealing with things like staircases, windows, and rafters, same fasteners, same adhesives, even the building materials! Aside from the most general aspects of the layout, it was exactly the same right down to the inch! People have no professional integrity these days.
copilot's won't suggest anything worth calling plagiarism, just mundane plumbing and maybe textbook algorithm implementations. have you seen it generate anything more glorified than StackOverflow-esque code snippets?
They would also have to exclude virtually all code that isn't public domain, too. MIT and Apache-2.0 and BSD all require that the copyright notice and license text is preserved in downstream use.
They had to blacklist Q_sort because they couldn't stop copilot from copying the complete function with comments (not just the algorithm) from the quake source, however it did not autocomplete the correct license for it.
I signed up for the copilot technical preview right after it was announced a few months ago, but I haven't gotten an invite yet while all my friends who signed up later did (I feel a bit left out). Is there any way to get an invite sooner? What am I doing wrong?
I singed up in the first week and got my invite on Monday. I don't have anything "linked" with my github via vscode or anything so I doubt IDE or program usage was a deciding factor. I do regularly commit small stuff.
I suppose this thing upload your code to Microsoft servers then run some deep learning algos on it and get back to you with suggestions?
It also probably keep your code to feed it to the algos.
If big tech was trustworthy I would use this with glee. But when I see how the world is turning, I'll continue to type boilerplate by hand (as long I'm allowed).
> I suppose this thing upload your code to Microsoft servers then run some deep learning algos on it and get back to you with suggestions? It also probably keep your code to feed it to the algos.
Be sure you don't commit your code to github...as that's literally uploading your code to Microsoft servers, I mean if you just don't trust them for being 'Microsoft'.
I would be even more concerned about licensing and copyright at this point. We might see some interesting legal discussions around this, given you probably (I did not check the terms) give consent to Github using your code for other purposes beyond querying their model.
I've been using Copilot in VS Code and it's been surprisingly useful. It makes suggestions pretty rarely, but when it does I accept about 50% of them. Generally these are few-line functions and it just gives me what I would have written after thinking about it a moment.
There tends to be a lot of repetitive code in the world. I primarily write JS, Py, and Rust. Sometimes, I might declare something like a function table, and Copilot will automatically fill in the class definition with everything I defined.
I'm not using Copilot to write new algorithms or solve library-specific problems, but it sure is next-level in picking up patterns in a file and predicting where you want to go next. Obviously, good code is succinct (not repetitive), but it sure is helpful when in that early prototyping stage. I admire it's ability to infer a correct assertion when writing Unit Tests - it made it much easier for me to write tests recently and helped me recognize a few bugs.
Same experience here. I think a lot of prime are being a little too philosophical about it. Where it shines is small helper functions and predictive boilerplate. It’s more like emmet imo then a pair programmer.
this has been "inevitable" for three decades now. The difference is, walled gardens making participation non-optional; commercial intent over "fairness"; elevating the trivial for the pleasure of management .. what could go wrong?!
overall, a new forms generator with a somewhat terrifying amount of horsepower.. zero trust of microsoft here, basically
What if I - a human - read your code, learn from it, and then use that knowledge to write my own code? Am I stripping your license off and ignoring it?
It is. Machines are running algorithms, which, by definition, are not creative.
Of course, people may argue that people are not creative, but considering that for a recent court case, it was decided that AI cannot be an inventor, it does matter to that court at least.
It's not. The legal system doesn't have the consistency or dependability of code. A lot of legal 'results' (judicial decisions) are somewhat arbitrary, balancing abstractions with practicality and so on, but get attention because they include clear explanations of the basic issues. Other lawyers then treat those decisions as 'legal facts' by echoing the language and (basically) challenging other lawyers to come up with a more impressive explanation than the decision that they are citing.
Look into a famous recent copyright case, Cariou v Prince. Cariou is a photographer, who made a series of photographs of people in Jamaica an dpublished them in a book. Prince, an artist, liked them, and then treated them as raw material, basically printing them up large, adjusting them, and slapping some paint on top, and declaring it original art - indeed, he called it 'appropriation art' saying 'this is mine now.'
Cariou was upset (very understandably) and sued. The judge found for Cariou, said that Prince was a bullshit rather than a visual artist, and ordered the infringing work to be collected and set fire. Prince appealed, and his appeal succeeded, with the 2nd circuit saying it was "transformative" from the point of view of a "reasonable observer" and therefore fair use, because Prince had added a different aesthetic by turning the portrait photos into oversize graffiti-collage mashups. Cariou gave up at that point as he didn't have the resources or will to fight the case further, and eventually the two artists settled.
Look up the art and see for yourself. I think Prince does have his own aesthetic, but it's a very shallow one that just surfs on other people's work, not very different from drawing glasses and a mustache on top of an existing portrait and saying you made an original work. In many ways, what he's selling is his taste, and the modifications he makes to the picture are just a sort of signature that's semantically equivalent to saying 'I, Richard Prince, approve of this image' - the artist as curator-critic of others' work, if you like.
Back in the computing context, this decision substantially loosens the boundaries of copyright. Found some code you wish you had written and want to put out your own thing, but feel stymied by the license? Just refactor it, add a bunch of sassy comments, and make the interface (whether, CUI, CLI, or API) aggressively different - not necessarily better, just distinctive. If it's fun and whimsical, make it corporate and bog-like. If it's scientific and functional, make it silly and juvenile. Just futz with it a bit until you can plausibly say you either made it better or easier to read or more accessible/intercompatible in some way. Hell, slow it down a bit and say your code smells better because it cooks the JSON longer, and generates a bunch of 'useful' statistics that might seem superfluous to the original designers but are essentially interesting to you. You'll probably get away with it.
All of that completely ignores the fact that a court just basically said that a machine cannot invent, which is a small step away from saying a machine cannot copyright, which would mean that Copilot is not transformative.
The copyright case you cited involves humans. We are talking about machines.
Copilot is used by human programmers. It's not cloning entire programs, little bits of programs that are curated and assembled into something new are easily going to past the test of transformativity. You go into court with that argument, and the other side will just point out that you have no way of showing the entire program you're complaining about was written by machine.
You seem to be arguing that if it includes any copyright code at all, the whole program is thus an infringement. You will be laughed out of court with that. I'm sorry, but I really don't think you've thought your argument through.
I'm sorry, but I think you have not thought my argument through.
First, I'm well aware that a whole program is not an infringement. It doesn't have to be for there to be infringement by some piece of code in the program, which would be what I was arguing.
When I go into court, what I will say is, "This piece of code infringes, here is my original." The court will rule on whether that piece infringes.
At that point, I have not argued at all about machines, and I don't have to. All I have to do is argue that the code infringes because then, if I win, the company or entity that is infringing on my code has some options:
1) They can claim it came from Copilot, and thus, that they are not at fault, at which point the court will laugh them out of court, as you say, and I collect my damages.
2) They can sue Microsoft for stripping the license from the code and making them unable to find the provenance of the code, and I still collect my damages.
If Microsoft is successfully sued, they will have to ensure Copilot does not strip licenses and gives the programmer information about where the code came from. That would be a win for me because all I want is for my code to be used according to the licenses.
If Microsoft is not successfully sued, then companies will realize that using Copilot is a bad idea because they could be held liable for code that they do not know the provenance of, which is a bad business risk, one which companies will not take, even big companies like Google, which does not use any AGPL code.
Regardless of which option they choose, that initial victory for me in court means that companies now know that using Copilot can lead them into a copyright minefield unless licenses are passed through, so I win against Copilot without ever arguing against it in court.
tl;dr: I'm not going to be directly suing Microsoft. Instead, I'm going to exercise my rights under copyright and my licenses as I should and let the dominoes fall toward making Copilot a dead product.
Frankly, I think it's on you to lay out your argument in full rather than assume everyone is privy to your thought process.
You seem to coming at this as if the law is a purely mechanistic thing that can quickly resolve disputes, overlooking how these things play out in the real world, like Oracle v google going on for a decade or the even longer litigation involving SCO and IBM.
I mean, what makes you so sure the court is going to give you a quick judgment on the infringement, or that it's going to agree with you about the size of code fragment that that is sufficient to infringe? Perhaps if they do verbatim copies of some unusually original algorithm you have developed, but given the fact that Copilot enthusiasts mostly laud it for it's ability to generate decent boilerplate/housekeeping code, a court might well find that the similarity to your code isn't infringing because the code in question doesn't do anything very distinctive. Commercial code shops are risk averse, it is true, but they also tend to have house styles on everything from variable naming to formatting that would further muddy the waters.
I feel a lot of your argument is begging the question (in the legal sense of assuming your conclusion) without considering whether the court will agree your code was infringed upon. Surely you can can agree that sufficiently small code fragments won't meet this threshold because they're too basic or obvious. Because your whole argument here rests upon that assumption, it comes off as a wish fulfillment scenario where Copilot disappears because nobody likes the risk calculus; your stated goal of 'making Copilot a dead product' seems more emotional than rational.
In reality it will take you a long time to get a result, and if enough people find Copilot useful (which I suspect they will), legal departments will adapt to that risk calculus and just figure out the cost of blowing or buying you off in the event that their developers carelessly infringe. If it sufficiently improves industrial productivity, it will become established while you're trying to litigate and afterwards people will just avoid crossing the threshold of infringement.
Honestly, this exchange makes me glad that I don't publish software and thus don't care about license conditions on a day to day basis.
> Frankly, I think it's on you to lay out your argument in full rather than assume everyone is privy to your thought process.
No, it's on you to not assume you know everything about my thought process before I show you otherwise.
Could I have communicated better? Yes. But I didn't assume you knew everything about my thought process. I thought it wasn't necessary for you too until you assumed that you knew my argument better than I did.
> You seem to coming at this as if the law is a purely mechanistic thing that can quickly resolve disputes, overlooking how these things play out in the real world, like Oracle v google going on for a decade or the even longer litigation involving SCO and IBM.
Once again, you are assuming. Yes, I know law is not mechanistic. Yes, I know going to court would take a long time.
Going to court is not the only thing I am doing. I also created new licenses, which I would not have if I only cared about what happened in court.
Going to court would be to attempt to argue for and enforce my viewpoint (indirectly). It would be a last-ditch attempt.
The first thing I am doing is creating new licenses specifically meant to "poison the well" for machine learning on code in general and Copilot in particular. [1]
With those licenses, I hope to make companies nervous about using Copilot for anything that might be using my licenses. This hesitation may only apply to code with my licenses, but the FAQ for those licenses ([2] is an example) are also designed to make lawyers nervous about the GPL and other licenses.
If I succeed in making the hesitation big enough, then Copilot as a paid service would be dead, and hopefully enough companies will prohibit the use of Copilot, as is already being done. [3]
Going to court, then, would only happen if I found someone infringing.
This will be especially helped by the fact that the vast majority of the code under those licenses will be in a language I'm building right now. If there's open source code in the language, then I can search that code for infringements caused by Copilot.
> I mean, what makes you so sure the court is going to give you a quick judgment on the infringement, or that it's going to agree with you about the size of code fragment that that is sufficient to infringe?
Do you think I would be stupid enough to pick an example to bring before court that would not be obviously infringing?
Winning in court is not just about being right, it's also about picking your battles, and I would be very choosy.
> Surely you can can agree that sufficiently small code fragments won't meet this threshold because they're too basic or obvious.
Yes, and as I said above, I won't use any of those.
> Because your whole argument here rests upon that assumption, it comes off as a wish fulfillment scenario where Copilot disappears because nobody likes the risk calculus;
You realize that this is the entire basis for the cybersecurity industry? The entire point is to make it economically infeasible for bad guys to do bad things in cyber space; it's to make the "risk[/reward] calculus" skew in favor of the good guys so much so that bad guys just stop operating.
Making the risk calculus riskier for your opponent is how wars and legal cases are fought too, but such tactics are not confined to the warroom or courtroom. That's why my opening salvo is licenses to sow doubt, to change the perception of the risk calculus. Battles like this are won by "winning minds," which in this case means convincing enough people to be nervous about it.
> your stated goal of 'making Copilot a dead product' seems more emotional than rational.
This is something where you are partially right. There is a lot of emotion behind it, not because I'm an emotional person (I'm actually on the spectrum and less emotional than the average person), but because I objectively considered the ramifications of wh...
If Microsoft noticed that a substantial number of contributors were putting in these "Poisoned Well license restrictions" in their repositories, it would be relatively trivial to automatically filter out those code bases using some basic heuristics to determine if the license was biased against systems like copilot.
> It depends how much you "learn from it" and then write your own code vs how much you copy/paste.
I think this is the crux. It doesn't matter that they used GPL code for training. It only matters if someone uses CoPilot to make a close copy of that code.
Fortunately Copilot is actually not commonly just copy/pasting. They did a study on that if you search for it (admittedly not an independent study but it's the only one we have).
> Why include that?
Because so many people are making the assumption that the law agrees with their overly simple interpretation before it's even been decided. It's a bit tedious.
Legally, it needs to be opt-in in order to protect downstream consumers of code written by Copilot.
Copilot sometimes reproduces code verbatim. You can't use open source code except under the terms of the license. Authors whose code may be reproduced by Copilot need to grant a license to downstream consumers, and republishers of Copilot-generated code need to adhere to the terms of that license.
Copilot is inserting ticking time-bombs into its users' codebases.
If it is relevant at all, the threshold of originality applies to the allegedly-copyrighted source consumed by Copilot (as regards bare infringement, not wilfull infringement). If that doesn't meet the threshold, it is not copyrightable. If it is, unauthorized copying not within a copyright exception (e.g., fair use) is infringement.
I can't see any case where originality of the snippet presented by Copilit matters (if Copilot were a person, it would matter to determining if the snippet on its own was copyrightable by Copilot, but still wouldn't be relevant to whether to original copyright was violated.)
Nope. Copilot users are inserting "ticking time-bombs" into their own codebases.
The buck stops with the user, when they use code from any source at all, whether it's their head, the internet, some internal library, lecture notes, a coworker, a random dude of the street, or who knows what else, it their own responsibility to ensure the code they're using has been released under a license they can use. They don't get to go back and point fingers just because they didn't do their own due-diligence.
The exception would be if a vendor provides code under a legal contract providing liability and an agreed license, that has not happened in this case so there's no reason to expect any legal protections.
We agree that downstream users who redistribute copyrighted code regurgitated by Copilot are in violation of copyright.
It doesn't seem to me as though the distinction between "Copilot reproduced the code and the engineer copy/pasted/saved it" versus "Copilot inserted the code" is crucial.
There's a separate question about Microsoft's own liability. When Copilot reproduces open source code without adhering to the terms of the license, that's redistribution and thus copyright infringement. A copyright owner might not be able to get substantial monetary damages, but they ought to be able to get a copyright injunction.
I wonder what happens to Copilot should a Github user secure injunctive relief, forcing Microsoft to exclude their code from Copilot.
> It doesn't seem to me as though the distinction between "Copilot reproduced the code and the engineer copy/pasted/saved it" versus "Copilot inserted the code" is crucial.
Yes, the only thing that matters is who authorized the code to be published, which is never Copilot (an automated system that takes tickets, has copilot craft patches from them, then publishes them with no human review would be a) very cool and b) an incomprehensibly terrible idea; but even then there is still a human authorizing the code to be published, just residing a level of abstraction removed from the process itself)
> It doesn't seem to me as though the distinction between "Copilot reproduced the code and the engineer copy/pasted/saved it" versus "Copilot inserted the code" is crucial.
I think that could be crucial.
If I read a computer science book, and from that produce a unique piece of code which was not present in the book, I have created a new work which I hold copyright over.
If I train a machine learning algorithm on a computer science book, and that ML algorithm produces some output, that output does not have a new copyright.
Similarly, if copilot synthesizes a bunch of MIT code and produces a suggestion, that may be MIT still, while if a human does the exact same reading and writing, if it is an original enough derivative, it may be free of the original MIT license.
The way I'm reading your reply seems like sophistry, so I expect I'm misunderstanding you.
Scenario 1: Copilot, operating as an IDE plugin, placed the suggestion directly into the text. To accept the suggestion, the engineer hit save.
Scenario 2: Copilot, placed its suggestion in an external file. The engineer copy/pasted the suggestion verbatim into their IDE, then hit save.
These don't seem as though they materially affect the situation. Regardless, the downstream user who somehow brought the copyrighted code into their codebase (which they subsequently redistribute) is infringing.
This theoretical case where Copilot is not involved and the user synthesizes something on their own is not germane. Copilot is involved.
What are you folks getting at? That Microsoft is in the clear? That the end user is in the clear? That "I'm just making suggestions" is akin to "I'm just asking questions" and absolves the suggester of liability? I don't get it.
Thanks for giving me the benefit of the doubt, but I do not deserve it in this case. I misread what I was responding to and my response was off the mark.
You're right to be confused, and my reply can be ignored as off-topic for the thread i'm in.
That's generous of you, since you were not alone. It seems as though I could have done a better job of emphasizing from the get-go that I thought infringement by the end user was the key point, rather than infringement by Microsoft.
>It doesn't seem to me as though the distinction between "Copilot reproduced the code and the engineer copy/pasted/saved it" versus "Copilot inserted the code" is crucial.
Is Google responsible when they index licensed code, then others steal it? It's surely the liability of the programmer to "check" (Not really sure how this would work, either).
What matters is that users of Copilot (the "others" who "steal it" in your scenario) are liable for infringement. That renders Copilot impractical as a tool for production use, regardless of whether Microsoft has any liability.
How much of the code needs to be "unique" across a single codebase for copilot to be illegally pasting it downstream ?
For a great deal of copilot insertions, it's like the equivalent of me writing the sentence, "the man gasped in surprise" in a novel I'm working on. Yeah maybe that sentence came from somebody else's novel, but you can find the same damn sentence in a thousand other books/papers/etc as well.
This reaction is why we can’t have nice things :( after trying copilot I’m convinced that this kind of feature is going to bring the world to a next phase. Open source was part 1, this is part 2.
I would seriously consider opting in so long as my authorship was acknowledged and my license was upheld. FWIW I tend to release things under permissive licenses (although I think if I was copyleft-inclined I might feel the same way: just match my license).
But stripping my copyright, copying my work without my permission and presenting it to users on terms I did not agree to, all of that is unacceptable.
Another comment said "don't open source your code", which I would agree with. If you don't want people reusing your code, just don't open source it. What's the point otherwise?
I’m not sure I understand that point of view though. Copilot just suggests relatively short snippets, it’s not copying large chunks of your library or products. If you truly have an innovative algorithm and you don’t want people to use it like that, you’ll have to go the patent route
Understandable, but my comments are legitimate "I'm a shocked at how copilot can do this" reactions. I'm not a Github fanboy, just someone who has been using that new feature for a few weeks. It's just that insane.
A friend of a friend, told me he is furiously adding code to Github, with subtle security bugs. He can't wait for it to show up in the proper places...Courtesy of Copilot ;-)
I wonder if that could be a nice money maker. Introduce a lot of generic functions with common names, add security bugs. Maybe add a README entry telling people to not trust the code because you're using it to demonstrate what insecure code looks like, and then wait for some big company with a bug bounty to introduce it to their code base. License your code proprietary of AGPL to make sure the company is the one who gets in trouble if they admit the code comes from you.
With enough nearly-working functions spread across multiple projects in every language known to man, you could practically automate your way into a steady stream of hacker bounties.
People would probably call it unethical, but if Copilot's massive IP violations are okay then who cares. As long as the project's security flaws are recognisable by humans it doesn't matter IMO.
Copilot has been super fun! Here is a small website I generated via only comments - in the HTML and JS. The CSS needed a bit more massaging but it also auto generated.
EDIT2: Looks like you can force the plugin to work by editing the plugin.xml contained in github-copilot-intellij-1.0.1.jar within the plugin archive. Just remove the line that includes Rider as incompatible. The same should work for CLion.
I’ve been using this for weeks and it blooooows my mind. It comes up with crazy recommendations, just yesterday I wrote this big ass logic to do something, then I wanted to move that code to a function so I wrote the function name and I kid you not copilot suggested a one-liner that worked… the thing is so useful and I’m not writing simple code (writing cryptographic code). And when it’s not doing that at the very least it provides auto-completion to lists where a counter has to increase and things like that. It’s just baffling, I don’t think I’m that directly impacted by AI, or at least this is the first time where I’m like “wow, AI really is changing the world RIGHT NOW”. Half-joking: can’t wait for it to just write my code.
Also if this feature would be paid tomorrow, I think I would pay for it. It’s really noticeable when I don’t have copilot enabled now.
Oh and, autocompletion doesn’t work with markdown files because of markdown plugins I think? But this is another level of insanity: when I’m writing english it figures a lot of the sentences I want to write. Makes me question if I’m just a deterministic individual with no choice.
I was experimenting with it over the weekend and basically got it to build out a simulation of schooling/flocking boidfish swimming around a tank. That was fun! I certainly wasn't expecting it to create the whole darn thing, but it did. I just added an occasional comment to nudge it toward doing exactly what I wanted.
Delegating the implementation of something that you are notoriously never supposed to roll your own, to a text generator AI.... What could possibly go wrong?
I think you got the wrong idea on how people use copilot. You don't just accept everything it throws at you. Think about it as an auto-complete on steroid, would you say that auto-complete is dangerous to use? If not, then this is the same. The suggestions of copilot don't always compile, but they sometimes manage to find the right function to use, or the right combination of functions, or even the right comment (if you're writing a comment).
The problem with copilot is that other than the most basic boilerplate generation. It takes just as much effort to verify its output is correct than to come up with a correct answer.
I disagree, from my usage it sets up a lot of the boilerplate code, the types, etc. and will also find the correct functions and all without having me look up the doc again.
Copilot is crazy. The other day, I was writing a Python function that would call a Wikipedia API. I pulled from the internet an example of a GET request, and pasted it as a comment in my code.
Then, like magic, Copilot suggested all the remaining keys that would go in the query params. It even knew which params were to be kept as-is, and which ones would come from my previous code:
action = "query" # action=query
format = "json" # or xml
lat = str(latitude.value) # 37.7891838
lon = str(longitude.value) # -122.4033522
gscoord = lat + "%7C" + lon
...
api_path = base_url + "action=" + action + "&format=" + format + ... + "&gscoord=" + gscoord
As a guy who gets easily distracted while programming, Copilot saves me a lot of time and keeps me engaged with my work. I can only imagine what it'll look like 10 years from now.
Concatenating strings for example. As shown, it's the query string equivalent of sql injection.
Use something like URLBuilder, or URIParams, or whatever your platform supports. Don't use string concatenation ever, if at all possible, and if not possible (wtf?), then at least escape strings.
the "nice" way of doing this would would be to create a list of your stringified arguments, mapped urlencoding over them, and then join them with the parameter separator. this ends up being resilient to someone adding something that ends up being incorrect, and makes explicit in the code what you're trying to do.
I usually try to avoid working with URLs as bare strings like this, both for readability and correctness (URL encoding is tricky). With ‘requests’ you can do something like pass a dictionary of your query params and it takes care of forming the actual request URL.
It's much safer (i.e. fewer degrees of freedom for bugs to appear) to use f-strings in situations like this one.
One correlated but ancillary benefit, is that there are fewer variables to simulate the state for in your brain, while you're reading the code. You don't have to wonder if a variable is going to change on you, in-between when it is initialized and when it is used.
It's safer still to use a library (e.g. urllib3) that does encoding for you (allowing you to omit magic strings like `"%7C"` from the logic of this function alltogther).
Like GP said, very handy for one-off scripts or areas of your codebase where quality is "less important". I may be pedantic, but I wouldn't give this a pass on code review.
I'm not against "copying" code. I just looked up "python build url query" The first link describes the `urllib.parse. urlencode` function which takes a dict.
def search_wikipedia(lat, lon):
"""
use "requests" to do a geosearch on Wikipedia and pretty-print the resulting JSON
"""
And it completed it with:
r = requests.get('https://en.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=10000&gscoord={0}|{1}&gslimit=20&format=json'.format(lat, lon))
pprint.pprint(r.json())
It's like a junior dev who doesn't quit unnecessary code golfing. Somehow the AI is more comfortable with string-based URL manipulation, which is a straight anti-pattern.
Presumably because that's what it's seen in the training data. Remember, it doesn't care about what the code does, it's just doing a search for similar looking code.
That's what the rest of the thread is complaining about, it's still slapping the strings in there with basic formatting. No different than the top level approach.
Even for a quick script this worries me about copilot; if it suggests this, then more people use it and think this is right, commit it, and then copilot suggests this more - that’s a bad feedback loop. At least in StackOverflow you get someone commenting why it’s bad and showing how to use a dictionary instead
How so? I'd prefer a proper structured library, is that what you mean? If so, the Copilot code actually seems not dodgy - because the author _started_ with `base = ...` , indicating that they were string formatting the params.
Speaking as a former pentester, this is a fine way to form query params in this specific case, if lat and long are floats.
They're the only data you can control, and unless they're strings, it's useless for exploitation. Even denormal floats / INF / NAN won't help achieve an objective.
I broadly agree with you, but people are pummeling Copilot for writing code that I saw hundreds of times. Yes, sometimes I was able to exploit some of that code. But the details matter.
If the example code is everything that Copilot generated, there's no guarantee that lat or long are floats and that seems to be an implementation detail left to the user.
Isn't that a pretty big risk though? Specifically, that people will use co-pilot recommendations "as-is" and give little thought to the actual workings of the recommendation?
After all, if you have to intimately understand the code it's recommending are you really saving that much time over vetting a Googled solution yourself?
But I would still never not escape the params because you don’t know how that code will change one day or where it will end up, and chances are that you won’t remember to fix it later if you don’t fix it now.
We just had a major failure at work recently because someone decided to not decode URL params and their code worked fine for years because it never mattered… until it did.
Just do it right. It’s so easy. Why risk yourself a ton of headache in the future to save you a few seconds?
It's harder to read than other methods, and it doesn't encode the URL parameters, which means it potentially produces an invalid URL, and in some cases could lead to security problems (similar to SQL injection).
For me APIs are actually one of the places it performs the worst. Copilot is like having an inexperienced yet annoyingly optimistic pair programmer. The code it generates appears conceivable in some hypothetical universe. No guarantee it's this one though.
Remember it doesn't actually know an API or how it should be used: it's putting things together to look like typical code. For me that has meant difficult to spot bugs like linking up incorrect variables from the rest of my code.
I wish it could integrate the first SO answer to a generated question, because I always end up there anyway having to fix things.
That's a bummer. I just got whitelisted and was hoping it could save me time with some APIs where they only have code in X language or curl and I have to work backwards if I run into any issues.
I think my experience has been sort of between you two. Maybe 1/3 times it's spot on. The rest of the time, there is some minor tweak I need to make (it gets a parameter or variable name wrong). I've yet to hit cases where the code it generates looks right but doesn't run as expected, thankfully.
I've only had it for about a week now but overall I'm happy with it. None of the code I'm writing is crazy cutting-edge stuff and in aggregate I'm sure it saves me more time than takes, including the time I spend reviewing and potentially changing the generated code.
Now we just need to train it to make a dictionary for that info instead of forming a long url. But if it has to use a long url to use urljoin and/or string formatting.
The next version of Copilot will submit its answers to HN and return the highest-voted comment that compiles, after stripping out the well actually spurious tokens. Just look how well it worked this time?
That's impressive. Discoverability and the varying quality of documentation is a big headache for new programmers or people engaging with a an unfamiliar framework/API/library. I really like the comments pointing out alternatives (json or xml) and the static lat-long values.
One reason I've championed the development of visual programming (flow-based, node diagrams, etc) is that while you don't want to compress a big complex program down into a single layer and become unreadable in the process, graphical methods are a great way for people to see what options they have available and just point at things they want to try out.
Instead of struggling with syntax at the same time as trying to find out what they can do with a new API, they can engage in trial-and-error to find out the capabilities and what makes it worth using, then build up their competency once they are clear about their objectives.
I'm looking forward to trying this now that it's available for my favorite IDE, but I'll probably want to set up a hotkey to switch it on and off as I need it. Once I get fully comfortable with something I often find code completion tools get in the way of my flow.
In a way it is impressive codepilot knew how to separate the query string while still being correct. However this is a fairly naive way to build a url that I wouldn't encourage committing. If I saw this in code in a review I would recommend using a dict and `urlencode` or one of the various other URL builders available (either in the stdlib or through another library like `yarl`/etc.).
Yesterday I tried to convert the representation of a number into another representation/type in Rust:
let coeff = BigUint::from_str(x).unwrap();
let coeff: <<G1Affine as AffineCurve>::ScalarField as PrimeField>::BigInt =
coeff.try_into().unwrap();
let x: <G1Affine as AffineCurve>::ScalarField = coeff.into();
I wrote that, then I wanted to move that code in a function so I wrote:
fn string_int_to_field_el(s: &str)
copilot suggested the following one-liner that did exactly the same thing:
fn string_int_to_field_el(s: &str) -> <G1Affine as AffineCurve>::ScalarField {
let x: <G1Affine as AffineCurve>::ScalarField = s.parse().unwrap();
x
}
I still don't understand how some heuristics could produce this code. It's mind blowing.
This comment is accidentally the perfect example of why copilot is a horrific idea.
The old "just copy-paste from Stack Overflow" approach to development is satirised and ridiculed these days (despite being still in common practice I'm certain), because as we all know so well by now, an accepted answer on SO does not always equate to a correct answer. Yes, the SO guys & community do do their best to improve answer quality iteratively (wiki answers, etc.), but there's still a lot of bad answers, and even many of the "good" ones become outdated or don't keep up with modern best-practice (especially when it comes to security).
Omitting urlencoding isn't the biggest crime, but it is a pretty standard URL-building step, and the fact that a tool released this year is spitting out code that omits something so simple is fairly damning. It's also a micro-example of much larger errors Copilot will surely be responsible for. Missing url encoding can be an injection vector in many applications, even if it's not the most common risk, but miss encoding in other string-building ops and you've made your way into the OWASP Top 10.
The big difference between copilot and SO is there's no community engaging in an open & transparent iterative process to improve the quality of answers.
+1. URL encoding is also very relevant on the backend and has security implications, e.g., you want to be sure you are protecting against double encoded URLs. If you elide details like URL encoding using copilot that's dangerous.
I tried it on IntelliJ recently. The examples I tested blew my mind. Yet, I think there are two things that need to improve to get me to use it regularly (it will get there!):
- less than perfect import/types/var suggestions that LSP in typed languages would've made perfect suggestions for (e.g named import in go would use the package name instead).
- latency feels a bit high and my thoughts would get interrupted waiting for a suggestion to come.
For the former, I wonder hard feasible it would be to give structured suggestions to the LSPs that it would swap for correct var names and imports and such. Or test each suggestion with the LSP for error counts and offer the least erroring suggestion.
It does seem a bit controversial to develop a relationship with neovim without approaching emacs. I wonder if they even asked on emacs-devel, I’m sure they’ll have got a friendly response …oh hang on…
That’s what stood out to me too! His plugins are always so thoughtful and idiomatic Vim, they really ought to be default. I guess except this one should remain opt in.
Any word on if they will ever make Copilot free software? It sounds interesting, but I avoid using proprietary software in my development stack. Plus it looks like it be fun to play with.
I used it for about a week but found I could type faster than it could suggest, even if it suggested the right thing. I have been coding for about 25 years but maybe it will help people new to whatever language they are using.
445 comments
[ 4.4 ms ] story [ 350 ms ] threadThe thing I find really good is it can predict what I will do next. Say if I have a list of columns in some text somewhere in the project when I write one “df = df.withColumn(“OneItemInList”)”
Copilot will then add the same for all the other items - is really nice
I'm a bit scared for what this means as I don't think being able to faster write boilerplate is something worthwhile. The example ed_elliott_asc made is one of those examples where instead of fixing things so you don't have to repeat yourself, copilot makes it easy to just live with the boilerplate instead.
But do you believe people being slower at writing boilerplate is undesirable?
Boilerplate generally exists for a reason, and it's not because the creator likes typing.
I mean, it's sort of a false dichotomy -- it's omitting a "default speed" for writing boilerplate that is neither enhanced nor impeded.
the potential issue with an enhanced speed for writing boilerplate is that it means that there'll just be more and more boilerplate to maintain over time, and it's not clear what that cost over time will be.
How much more effort will be expended to replace things in multiple places? It exacerbates existing issues of "these two things look almost the same, but someone manually modified one copy...should that change be propagated?"
Meaning, it's essentially an ad-hoc code generator. Code generation can be a very useful technique (see protobufs), but without the ability to re-generate from a source?
Perhaps a possible enhancement might be for copilot to keep track of all blurbs it generated and propose refactoring/modifying all copies?
I'm not sure. I think that understanding is omitting a "default amount" of boilerplate that will have to be written regardless of one's individual preference that is really a function of the language / framework of choice, the existing codebase and the problem at hand.
Removing that boilerplate would be ideal but is not always possible given limited resources, time constraints and the usual inability to make sweeping changes to the codebase
So we settle for the second best solution which is to automate away that tedious process (or short of that provide developers with tools to get it out of the way faster) so we can all focus on "real work"
An impedance would be something to adjust the status quo in a negative direction e.g., a hardware failure
> than spend half a day tweaking test coverage on your one-off library
If you need to write a library and spend half a day to populate a list, you have bigger problems than boilerplate.
Nothing wrong with having duplicate lines. The problem becomes when writing those lines become automated so you start spewing those all over the place.
Also if your don't fully understand your code( when generated or copied from SO) as not uncommon with junior developers and data science practitioners, then they struggle to make even small change for the next iteration, because they don't fully understand what their code is doing and how.
When your code is composable or modifiable easily then iterations become faster because you understand what you have written. One of the reasons why analysts prefer Excel if data size is within limits.
In a perfect world we’d all have excellent comprehensive metaprogramming facilities in our programming languages and no incidence of RSI (e.g. carpal tunnel syndrome). Code completion is a good tool to deal with these realities.
It's very good at translating between programming languages, including pseudocode.
It can write a lot more valid code much quicker than any human, and in a whole slew of languages.
I haven't had the urge to use it much after playing around with it constantly for a few days, but it was pretty mind-blowing.
Really the thing is there's not way to ascribe correctness to a piece of code right, like humans fail at this even. The only "correct" code is like rote algorithmic code that has a well defined method of operation. And there's likely a lot more correct examples of that, like way more than you'd ever be able to poison.
You may be able to be misleading though by using names that say one thing but do another, but again you'd be fighting against the tide of correctly named things.
So not only would you have to submit a insanely large amount of code but you're also racing against literally millions of users writing legitimate code at any period of time.
So how about an already poisoned well. How up to date is the average Github project on encryption standards?
When I was playing around a couple years ago with the Fastai courses in language modeling I used the Python tokenize module to feed my model, and with excellent parser libraries like Lark[0] out there it wouldn't take that long to build real quality parsers.
Of course I could be totally wrong and they might just be dumping pure text in, shutter.
[0]: https://github.com/lark-parser/lark
More verbose languages like C++ become less obnoxious to write in. I know RSI has been mentioned and any tool which cuts down on excessive typing will help with that.
It sometimes reveals bits of the standard library I wasn't aware of in unfamiliar languages. I can write my intent as a comment and then it may pull out a one-liner to replace what I would have normally done using a for loop.
The main downside I've observed is that if I'm not trying to reign it in, it can result in a lot of WET code since it can pattern match other areas of the surrounding code but can't actually rewrite anything that has already been written. It is important to go back and refactor the stuff it produces to avoid this.
For example, I didn't know about self.fail() in unittests and had never used it, but Copilot suggested it and it produced the most readable version of the unit test
If I want to throw an exception if an object is null or undefined, Co-pilot will do the if and the exception throw using the right error class, and a more meaningful error message that what I usually came up with.
If want to map some random technical data table to something useful in my programming language, I can copy paste the data from the documentation in pdf or html into a comment block, give an example, and co-pilot will write everything in the format I want.
If I want to slightly refactor some code, I can do it once or twice and co-pilot can help me a lot to refactor the remaining.
If I want to have a quick http server in nodejs, I don't have to Google anything.
It's a lot of tiny things like this.
I'll reproduce a generic example I sent a friend.
Prompt:
Copilot suggested: I accepted it and moved 2 lines down, prompt: Copilot suggested a start to the operation: I accepted it, and Copilot continued:So, I actually consider this to be exactly the bad behavior that people accuse Copilot of.
Press "r", press "." to autocomplete so it now says "redis.", then write "cC" and it suggests createClient (or write "create" or "client" if you're not sure what you're looking for). Now it says "redis.createClient()". Press ctrl+alt+v to extract a variable or write ".const" and press tab to apply the const live template. Ending up with your result in two seconds.
+1 for the variable extraction thing, I've been using their IDE for ages and it never occurred to me to look for such a thing.
I will say, though, that it's also good at making up code that looks very believably real but doesn't actually work.
The ethics involved in Copilot are a bit strange, and I'm not sure I'll keep using it for those reasons, but it does a good job.
https://twitter.com/ridiculous_fish/status/14527512360594513...
I was able to write {"Settings":...} and Copilot completed with {"Settings": "Configurações"} that tool is simply amazing.
So for example I was working with processing an image to extract features and a few variants of docstrings for the method got me a pretty close to working function which converted the image to gray scale, detected edges, and computed the result I wanted.
The helpful thing here was that there were certain APIs that were useful as a part of doing this that it knew but which I would have to do look up. I had to go through and modify the proposed solution: it got the conditional in the right place, but I wanted a broader classification so switched from a (255, 255, 255) check to a nearBlack(pixel) function which it then autocompleted successfully. I also had to modify the cropping.
When doing a similar task in the past I spent a lot more time on it, because I went down a route in which I was doing color classification based on the k nearest neighbors. Later I found that the AI I was working on was learning to exploit the opacity of the section of the screen I was extracting a feature from in order to maximize its reward, because it kept finding edge cases in the color classifier. I ended up switching to a different color space to make color difference distance functions more meaningful, but it wasn't good enough to beat the RL agent that was trying to exploit mistakes in the classifier.
Anyway, what I'm getting at here is that it is pretty easy to spend a lot of time doing similar things to what I'm doing and not get a great solution at the end. In this case though it only took a few minutes to get a working solution. CoPilot didn't code the solution for me, but it helped me get the coding done faster because it knew the APIs and the basic structure of what I needed to do. To be clear, its solutions were all broken in a ton of ways, but it didn't matter it still saved me time.
To give another example let's say you have a keyboard key event press and you weren't sure about how to translate that into the key that was pressed. key.char? key.key? str(key)? key.symbol? A former method of figuring out what the right key might be is looking up the code, but with CoPilot you type '# Get the key associated with the key press' then hit tab and it gives you code that is broken but looks perfect and you gain a false sense of confidence that you actually know the API. You later realize after being amazed that it knew the API so well that you didn't have to look it up that actually the key press event handles symbols differently and so it errors on anything that is used as a modifier key.
My general impression is something like: Wow, this is amazing. It understood exactly what I wanted and it knew the APIs and coded up the solution... Wait, no. Hold on a second. This and that are wrong.
I am in the same boat with you. I am simultaneously wowed and underwhelmed to some degree.
Yes it is amazing when it gets right, it feels like cheating. But at the same time, it many times, does ... too much? To read a huge chuck of code and figuring out where it goes wrong is not a thing for me. Also Copilot doesn't really know the API, so yes, the amount of mental tax isn't less to make sure your program really behaves.
But again, I see the idea of Copilot is already huge win. I hate writing those manual scripts just offer people an entrance to some utility behind. Copilot does those things, surprisingly well and with accuracy.
Let it improve in the future, and we will see changes that quite fundamental to the idea of programming itself.
In the test body, I wrote "foo" to the socket. Copilot immediately filled in the rest of the test: read from the socket, check that the result is "Hello, foo", and fail the test with a descriptive error otherwise.
wtf? How did it figure out that the correct result was "Hello, foo"? I changed "Hello" to "Flarbnax", and sure enough, Copilot suggested "Flarbnax, foo". I added a "!" to the end, and it suggested that too. After pushing a bit further, the suggestions started to lose accuracy: it would check for "???" instead of "??" for example, or it would check for a newline where there was none. But overall I came away very impressed.
It‘s useful enough for me, as a magic autocomplete.
There's the benefits that a lot of people mentioned, but to me the biggest benefit is I can avoid procrastination. Usually when I'm blocked on something I'll run a search in the browser, but very quickly I end up going off the trail and just browsing the web and losing a lot of time. Now when I'm blocked I simply type the comment of what I'm trying to do and the autocomplete suggestion is pretty damn good and unblocks me very quickly. More surprising of all, it somehow understands my code style by looking at the context.
Also, it’s like a more clever auto complete most of the time, even when it’s wrong in calling a function you can use it as foundation code to go faster.
And you don’t need to think too much about it, it really keeps you in the flow.
It sort of feels like pair programming with an undergraduate, except copilot never learns. That isn't to say it's bad, more that it is just a tool you can hand simple stuff off to, except the handoff is zero-effort.
EDIT: I will say that there are times when it makes up fantasy constants or variable names, that seem plausible but don't exist. An eventual version of Copilot that includes more normal autocompletion information, so it only suggests symbols that exist, will be a stronger tool.
In a way, it does the dirty pipes surprisingly well. But when it comes to implement the core of the algorithm, it is not there yet, but the potential is huge.
Very eager to see Github Copilot catchup to some bright line of signal v noise.
And the worst thing about that is that you don't get the context of the Stack Overflow threads, where people discuss the impact of the given solution and alternatives. So after a week, off it went for me.
Schemathesis builds on Hypothesis and generates tests from OpenAPI specs.
* QuickCheck: https://hackage.haskell.org/package/QuickCheck
* Hypothesis: https://hypothesis.readthedocs.io/en/latest/
* JUnit QuickCheck: https://github.com/pholser/junit-quickcheck
Fuzz testing tools (tools which mutate the inputs to a program in order to find interesting / failing states in that program). Generally paired with code coverage:
* American Fuzzy Lop (AFL): https://github.com/google/AFL
* JQF: https://github.com/rohanpadhye/JQF
Mutation / Fault based test tools (review your existing unit coverage and try to introduce changes to your _production_ code that none of your tests catch)
* PITest: https://pitest.org/
One of the main value props for writing meaningful unit tests, is it helps the developer think differently about the code he is writing tests for, and that improves quality of the code composition.
* It promotes actually looking at the code before considering it done
* It promotes refactoring
* It helps to prevent breaking changes for stuff that wasn't supposed to change
* The tests doesn't actually test functionality, edge cases etc, just that things doesn't crash in a happy-path.
* Any changes to an implementation breaks a test needlessly, because the test tests specifics of the implementation, not correctness. Thus it makes refactoring actually harder, since your test said you broke something, but you probably didn't, and now you have to double the work of writing a new test.
* In codebases for dynamic languages, most of what these tests end up catching is stuff a compiler would catch in a statically typed language.
This is low coverage.
> Any changes to an implementation breaks a test needlessly, because the test tests specifics of the implementation, not correctness.
This is bad design.
> In codebases for dynamic languages, most of what these tests end up catching is stuff a compiler would catch in a statically typed language.
So they are not useless.
No, as a sibling comment to mine shows, it's actually easy to make 100% coverage with bad tests, since one doesn't challenge the implementation to handle edge cases.
AFAIK, «high coverage» may have different meaning for different people. For me, it's «high quality», for others it's «high percentage», e.g. «full coverage» or «80% coverage», which is easy to OKR.
Which is what makes this whole concept of code coverage so much toxic nonsense...
Not to argue against writing 'quality' tests, but high 'coverage' actually decreases quality, objectively speaking, since erroneous coverage of code serves negative purposes such as obscuring important testing, enshrinig bugs within testing.
I would make my case here CodePilot and all such 'AI' tools should be banned from production, at least until they solve the above problem, since as it stands they will serve to shovel piles of useless or worse, incorrect testing.
It is also important to remember what AI does, i.e. produce networks which create results based upon desired metrics - if the metrics were wrong or incomplete, you produce and propagate bad design.
So yes people use it now as a learning tool (fine) and it will get 'better' (sure), but as a tool, when it gets better, it will constrain more, not less, along whatever lines have been deemed better, and it will become harder, not easier, to adjust.
I have seen projects where a test will have sequence of steps which trigger the code but the assertion is effectively true === true, or they will replicate the same function in the test instead of generating proper mock data or myriad different absurd testing approaches. This comes from twin pressure of showing coverage and having tests pass.
Coverage is also a challenge in code which uses AI/ML libraries or that use third party services. These really need statistical testing with large volume of diverse well maintained samples and results need statistical analysis for error rates not different from how manufacturing does it, I don't see that often. For code using face detection for example a single face getting detected or not is hardly an adequate test.
Finally, it is easier to improve coverage by testing simpler code than improve coverage/ refactor a function which has say 10 nested branches, so it is not uncommon to see 90% coverage and 10% of the most used / most error prone code poorly or not tested at all.
There are some methods to address these like mutation testing, do retros for failure of tests to capture production bugs, it is not easy to measure and coverage driven orgs will not see their metrics moving by doing these.
Well written test suites will also have good coverage, but not necessarily other way around. Developers who care and understand what they are doing and why they are doing it, will use coverage as only the first step to see where there are gaps in their tests.
Tests are also code that need peer reviewed and maintained, if the tests depend on implementation and constantly break or contains improper mocks or assert poorly. A lot of not well written tests is hindrance to development than aid it.
[1] Yes, most of these are not applicable in a strongly typed language, but it is far easier as a illustration .
I am not aware of any language (outside of intentionally-minimalist esolangs) that doesn't support floating point numbers. In some languages (like JavaScript) that's the only kind of number you get.
Never encountered it before (and I'm ashamed to say C# is my main language since 2009).
It was a pretty thorough study:
> Our study is the largest to date in the literature: we generated 31,000 test suites for five systems consisting of up to 724,000 lines of source code. We measured the statement coverage, decision coverage, and modified condition coverage of these suites and used mutation testing to evaluate their fault detection effectiveness. We found that there is a low to moderate correlation between coverage and effectiveness when the number of test cases in the suite is controlled for.
Given their data, their conclusion seems pretty plausible:
> Our results suggest that coverage, while useful for identifying under-tested parts of a program, should not be used as a quality target because it is not a good indicator of test suite effectiveness.
That's certainly how I approach testing: I value having a thorough test suite, but I do not treat coverage as a target or use it as a requirement for other people working on the same project.
[1]: https://neverworkintheory.org/2021/09/24/coverage-is-not-str...
To me, the value of copilot helping to write tests is that we, the engineers, come up with the test cases, and copilot helps write the code for that case.
I think humans will still be more imaginative in the test cases they can dream up (although I’ve never used an automatic generator, maybe they’re better than I think), but almost all test code is boilerplate, either in the setup or the assertions.
If I don’t have to write that repetitious, yet slightly different boilerplate for each test case, that frees me up to design other interesting test cases (as opposed to getting tired of the activity by the time I cover the happy path) or move on to the next bug/feature work.
This could have been prevented very simply: GitHub avoiding training Copilot on GPL code.
What they can still do is offer a new model excluding GPL code for people who care about it.
[1] - https://www.gnu.org/licenses/gpl-faq.en.html#SourceCodeInDoc...
If big tech was trustworthy I would use this with glee. But when I see how the world is turning, I'll continue to type boilerplate by hand (as long I'm allowed).
Be sure you don't commit your code to github...as that's literally uploading your code to Microsoft servers, I mean if you just don't trust them for being 'Microsoft'.
There tends to be a lot of repetitive code in the world. I primarily write JS, Py, and Rust. Sometimes, I might declare something like a function table, and Copilot will automatically fill in the class definition with everything I defined.
I'm not using Copilot to write new algorithms or solve library-specific problems, but it sure is next-level in picking up patterns in a file and predicting where you want to go next. Obviously, good code is succinct (not repetitive), but it sure is helpful when in that early prototyping stage. I admire it's ability to infer a correct assertion when writing Unit Tests - it made it much easier for me to write tests recently and helped me recognize a few bugs.
overall, a new forms generator with a somewhat terrifying amount of horsepower.. zero trust of microsoft here, basically
Disgusting.
Clearly it's not as simple as you imagine.
Of course, people may argue that people are not creative, but considering that for a recent court case, it was decided that AI cannot be an inventor, it does matter to that court at least.
Look into a famous recent copyright case, Cariou v Prince. Cariou is a photographer, who made a series of photographs of people in Jamaica an dpublished them in a book. Prince, an artist, liked them, and then treated them as raw material, basically printing them up large, adjusting them, and slapping some paint on top, and declaring it original art - indeed, he called it 'appropriation art' saying 'this is mine now.'
Cariou was upset (very understandably) and sued. The judge found for Cariou, said that Prince was a bullshit rather than a visual artist, and ordered the infringing work to be collected and set fire. Prince appealed, and his appeal succeeded, with the 2nd circuit saying it was "transformative" from the point of view of a "reasonable observer" and therefore fair use, because Prince had added a different aesthetic by turning the portrait photos into oversize graffiti-collage mashups. Cariou gave up at that point as he didn't have the resources or will to fight the case further, and eventually the two artists settled.
Look up the art and see for yourself. I think Prince does have his own aesthetic, but it's a very shallow one that just surfs on other people's work, not very different from drawing glasses and a mustache on top of an existing portrait and saying you made an original work. In many ways, what he's selling is his taste, and the modifications he makes to the picture are just a sort of signature that's semantically equivalent to saying 'I, Richard Prince, approve of this image' - the artist as curator-critic of others' work, if you like.
Back in the computing context, this decision substantially loosens the boundaries of copyright. Found some code you wish you had written and want to put out your own thing, but feel stymied by the license? Just refactor it, add a bunch of sassy comments, and make the interface (whether, CUI, CLI, or API) aggressively different - not necessarily better, just distinctive. If it's fun and whimsical, make it corporate and bog-like. If it's scientific and functional, make it silly and juvenile. Just futz with it a bit until you can plausibly say you either made it better or easier to read or more accessible/intercompatible in some way. Hell, slow it down a bit and say your code smells better because it cooks the JSON longer, and generates a bunch of 'useful' statistics that might seem superfluous to the original designers but are essentially interesting to you. You'll probably get away with it.
The copyright case you cited involves humans. We are talking about machines.
You seem to be arguing that if it includes any copyright code at all, the whole program is thus an infringement. You will be laughed out of court with that. I'm sorry, but I really don't think you've thought your argument through.
First, I'm well aware that a whole program is not an infringement. It doesn't have to be for there to be infringement by some piece of code in the program, which would be what I was arguing.
When I go into court, what I will say is, "This piece of code infringes, here is my original." The court will rule on whether that piece infringes.
At that point, I have not argued at all about machines, and I don't have to. All I have to do is argue that the code infringes because then, if I win, the company or entity that is infringing on my code has some options:
1) They can claim it came from Copilot, and thus, that they are not at fault, at which point the court will laugh them out of court, as you say, and I collect my damages.
2) They can sue Microsoft for stripping the license from the code and making them unable to find the provenance of the code, and I still collect my damages.
If Microsoft is successfully sued, they will have to ensure Copilot does not strip licenses and gives the programmer information about where the code came from. That would be a win for me because all I want is for my code to be used according to the licenses.
If Microsoft is not successfully sued, then companies will realize that using Copilot is a bad idea because they could be held liable for code that they do not know the provenance of, which is a bad business risk, one which companies will not take, even big companies like Google, which does not use any AGPL code.
Regardless of which option they choose, that initial victory for me in court means that companies now know that using Copilot can lead them into a copyright minefield unless licenses are passed through, so I win against Copilot without ever arguing against it in court.
tl;dr: I'm not going to be directly suing Microsoft. Instead, I'm going to exercise my rights under copyright and my licenses as I should and let the dominoes fall toward making Copilot a dead product.
You seem to coming at this as if the law is a purely mechanistic thing that can quickly resolve disputes, overlooking how these things play out in the real world, like Oracle v google going on for a decade or the even longer litigation involving SCO and IBM.
I mean, what makes you so sure the court is going to give you a quick judgment on the infringement, or that it's going to agree with you about the size of code fragment that that is sufficient to infringe? Perhaps if they do verbatim copies of some unusually original algorithm you have developed, but given the fact that Copilot enthusiasts mostly laud it for it's ability to generate decent boilerplate/housekeeping code, a court might well find that the similarity to your code isn't infringing because the code in question doesn't do anything very distinctive. Commercial code shops are risk averse, it is true, but they also tend to have house styles on everything from variable naming to formatting that would further muddy the waters.
I feel a lot of your argument is begging the question (in the legal sense of assuming your conclusion) without considering whether the court will agree your code was infringed upon. Surely you can can agree that sufficiently small code fragments won't meet this threshold because they're too basic or obvious. Because your whole argument here rests upon that assumption, it comes off as a wish fulfillment scenario where Copilot disappears because nobody likes the risk calculus; your stated goal of 'making Copilot a dead product' seems more emotional than rational.
In reality it will take you a long time to get a result, and if enough people find Copilot useful (which I suspect they will), legal departments will adapt to that risk calculus and just figure out the cost of blowing or buying you off in the event that their developers carelessly infringe. If it sufficiently improves industrial productivity, it will become established while you're trying to litigate and afterwards people will just avoid crossing the threshold of infringement.
Honestly, this exchange makes me glad that I don't publish software and thus don't care about license conditions on a day to day basis.
No, it's on you to not assume you know everything about my thought process before I show you otherwise.
Could I have communicated better? Yes. But I didn't assume you knew everything about my thought process. I thought it wasn't necessary for you too until you assumed that you knew my argument better than I did.
> You seem to coming at this as if the law is a purely mechanistic thing that can quickly resolve disputes, overlooking how these things play out in the real world, like Oracle v google going on for a decade or the even longer litigation involving SCO and IBM.
Once again, you are assuming. Yes, I know law is not mechanistic. Yes, I know going to court would take a long time.
Going to court is not the only thing I am doing. I also created new licenses, which I would not have if I only cared about what happened in court.
Going to court would be to attempt to argue for and enforce my viewpoint (indirectly). It would be a last-ditch attempt.
The first thing I am doing is creating new licenses specifically meant to "poison the well" for machine learning on code in general and Copilot in particular. [1]
With those licenses, I hope to make companies nervous about using Copilot for anything that might be using my licenses. This hesitation may only apply to code with my licenses, but the FAQ for those licenses ([2] is an example) are also designed to make lawyers nervous about the GPL and other licenses.
If I succeed in making the hesitation big enough, then Copilot as a paid service would be dead, and hopefully enough companies will prohibit the use of Copilot, as is already being done. [3]
Going to court, then, would only happen if I found someone infringing.
This will be especially helped by the fact that the vast majority of the code under those licenses will be in a language I'm building right now. If there's open source code in the language, then I can search that code for infringements caused by Copilot.
> I mean, what makes you so sure the court is going to give you a quick judgment on the infringement, or that it's going to agree with you about the size of code fragment that that is sufficient to infringe?
Do you think I would be stupid enough to pick an example to bring before court that would not be obviously infringing?
Winning in court is not just about being right, it's also about picking your battles, and I would be very choosy.
> Surely you can can agree that sufficiently small code fragments won't meet this threshold because they're too basic or obvious.
Yes, and as I said above, I won't use any of those.
> Because your whole argument here rests upon that assumption, it comes off as a wish fulfillment scenario where Copilot disappears because nobody likes the risk calculus;
You realize that this is the entire basis for the cybersecurity industry? The entire point is to make it economically infeasible for bad guys to do bad things in cyber space; it's to make the "risk[/reward] calculus" skew in favor of the good guys so much so that bad guys just stop operating.
Making the risk calculus riskier for your opponent is how wars and legal cases are fought too, but such tactics are not confined to the warroom or courtroom. That's why my opening salvo is licenses to sow doubt, to change the perception of the risk calculus. Battles like this are won by "winning minds," which in this case means convincing enough people to be nervous about it.
> your stated goal of 'making Copilot a dead product' seems more emotional than rational.
This is something where you are partially right. There is a lot of emotion behind it, not because I'm an emotional person (I'm actually on the spectrum and less emotional than the average person), but because I objectively considered the ramifications of wh...
In fact, I'm really just trying to put them between a rock and a hard place so that I win no matter what.
Of course, if that does happen, I expect more people would want to use my licenses...
Copilot is pretty commonly just copy/pasting. You can get it to spit out exact copied code, including comments.
p.s. "it's not as simple as you imagine" is pretty dickish. Why include that?
I think this is the crux. It doesn't matter that they used GPL code for training. It only matters if someone uses CoPilot to make a close copy of that code.
Fortunately Copilot is actually not commonly just copy/pasting. They did a study on that if you search for it (admittedly not an independent study but it's the only one we have).
> Why include that?
Because so many people are making the assumption that the law agrees with their overly simple interpretation before it's even been decided. It's a bit tedious.
Copilot sometimes reproduces code verbatim. You can't use open source code except under the terms of the license. Authors whose code may be reproduced by Copilot need to grant a license to downstream consumers, and republishers of Copilot-generated code need to adhere to the terms of that license.
Copilot is inserting ticking time-bombs into its users' codebases.
https://en.wikipedia.org/wiki/Threshold_of_originality
> Copilot regurgitating Quake code, including sweary comments (twitter.com/mitsuhiko)
https://news.ycombinator.com/item?id=27710287
I can't see any case where originality of the snippet presented by Copilit matters (if Copilot were a person, it would matter to determining if the snippet on its own was copyrightable by Copilot, but still wouldn't be relevant to whether to original copyright was violated.)
The buck stops with the user, when they use code from any source at all, whether it's their head, the internet, some internal library, lecture notes, a coworker, a random dude of the street, or who knows what else, it their own responsibility to ensure the code they're using has been released under a license they can use. They don't get to go back and point fingers just because they didn't do their own due-diligence.
The exception would be if a vendor provides code under a legal contract providing liability and an agreed license, that has not happened in this case so there's no reason to expect any legal protections.
It doesn't seem to me as though the distinction between "Copilot reproduced the code and the engineer copy/pasted/saved it" versus "Copilot inserted the code" is crucial.
There's a separate question about Microsoft's own liability. When Copilot reproduces open source code without adhering to the terms of the license, that's redistribution and thus copyright infringement. A copyright owner might not be able to get substantial monetary damages, but they ought to be able to get a copyright injunction.
I wonder what happens to Copilot should a Github user secure injunctive relief, forcing Microsoft to exclude their code from Copilot.
Yes, the only thing that matters is who authorized the code to be published, which is never Copilot (an automated system that takes tickets, has copilot craft patches from them, then publishes them with no human review would be a) very cool and b) an incomprehensibly terrible idea; but even then there is still a human authorizing the code to be published, just residing a level of abstraction removed from the process itself)
I think that could be crucial.
If I read a computer science book, and from that produce a unique piece of code which was not present in the book, I have created a new work which I hold copyright over.
If I train a machine learning algorithm on a computer science book, and that ML algorithm produces some output, that output does not have a new copyright.
In essence, there must be originality for a work to be under a new copyright, and that is likely a requirement that it must be a human author. See this wikipedia page: https://en.wikipedia.org/wiki/Threshold_of_originality#Mecha...
Similarly, if copilot synthesizes a bunch of MIT code and produces a suggestion, that may be MIT still, while if a human does the exact same reading and writing, if it is an original enough derivative, it may be free of the original MIT license.
Scenario 1: Copilot, operating as an IDE plugin, placed the suggestion directly into the text. To accept the suggestion, the engineer hit save.
Scenario 2: Copilot, placed its suggestion in an external file. The engineer copy/pasted the suggestion verbatim into their IDE, then hit save.
These don't seem as though they materially affect the situation. Regardless, the downstream user who somehow brought the copyrighted code into their codebase (which they subsequently redistribute) is infringing.
This theoretical case where Copilot is not involved and the user synthesizes something on their own is not germane. Copilot is involved.
What are you folks getting at? That Microsoft is in the clear? That the end user is in the clear? That "I'm just making suggestions" is akin to "I'm just asking questions" and absolves the suggester of liability? I don't get it.
You're right to be confused, and my reply can be ignored as off-topic for the thread i'm in.
Is Google responsible when they index licensed code, then others steal it? It's surely the liability of the programmer to "check" (Not really sure how this would work, either).
For a great deal of copilot insertions, it's like the equivalent of me writing the sentence, "the man gasped in surprise" in a novel I'm working on. Yeah maybe that sentence came from somebody else's novel, but you can find the same damn sentence in a thousand other books/papers/etc as well.
There's still no good reason I cannot opt my code out of it.
But stripping my copyright, copying my work without my permission and presenting it to users on terms I did not agree to, all of that is unacceptable.
Letting people see the code doesn't mean they can ignore the license and do whatever the hell they want with it.
I am quite reasonable. I favor the MIT license. I still do not want my code in Copilot, which pretty much dismisses my rights entirely.
It is basic human decency, and copilot would still be possible even if some of us opted our projects out.
In the 90's we would kick these "brogrammers" out in a breeze.
With enough nearly-working functions spread across multiple projects in every language known to man, you could practically automate your way into a steady stream of hacker bounties.
People would probably call it unethical, but if Copilot's massive IP violations are okay then who cares. As long as the project's security flaws are recognisable by humans it doesn't matter IMO.
https://arxiv.org/abs/2007.02220
Although our own work shows Copilot is pretty good at adding security flaws on its own:
https://arxiv.org/abs/2108.09293
https://spencer0.github.io/copilot-tests/
https://plugins.jetbrains.com/plugin/17718-github-copilot/re...
https://plugins.jetbrains.com/plugin/17718-github-copilot/ve...
EDIT: Hmm, it installed but it refuses to run.
EDIT2: Looks like you can force the plugin to work by editing the plugin.xml contained in github-copilot-intellij-1.0.1.jar within the plugin archive. Just remove the line that includes Rider as incompatible. The same should work for CLion.
Also if this feature would be paid tomorrow, I think I would pay for it. It’s really noticeable when I don’t have copilot enabled now.
Oh and, autocompletion doesn’t work with markdown files because of markdown plugins I think? But this is another level of insanity: when I’m writing english it figures a lot of the sentences I want to write. Makes me question if I’m just a deterministic individual with no choice.
Delegating the implementation of something that you are notoriously never supposed to roll your own, to a text generator AI.... What could possibly go wrong?
Mantra: when inserting data into a context (like an url) escape the data for that context.
Use something like URLBuilder, or URIParams, or whatever your platform supports. Don't use string concatenation ever, if at all possible, and if not possible (wtf?), then at least escape strings.
https://docs.python-requests.org/en/latest/user/quickstart/#...
One correlated but ancillary benefit, is that there are fewer variables to simulate the state for in your brain, while you're reading the code. You don't have to wonder if a variable is going to change on you, in-between when it is initialized and when it is used.
It's safer still to use a library (e.g. urllib3) that does encoding for you (allowing you to omit magic strings like `"%7C"` from the logic of this function alltogther).
Like GP said, very handy for one-off scripts or areas of your codebase where quality is "less important". I may be pedantic, but I wouldn't give this a pass on code review.
So I would build the query like so:
I think this is orders of magnitude clearer code. But that's a parameter that's subjective that CoPilot can't adjust for (although it can be better).I typed the following prompt:
And it completed it with:Or did you mean something else?
They're the only data you can control, and unless they're strings, it's useless for exploitation. Even denormal floats / INF / NAN won't help achieve an objective.
I broadly agree with you, but people are pummeling Copilot for writing code that I saw hundreds of times. Yes, sometimes I was able to exploit some of that code. But the details matter.
Isn't that a pretty big risk though? Specifically, that people will use co-pilot recommendations "as-is" and give little thought to the actual workings of the recommendation?
After all, if you have to intimately understand the code it's recommending are you really saving that much time over vetting a Googled solution yourself?
We just had a major failure at work recently because someone decided to not decode URL params and their code worked fine for years because it never mattered… until it did.
Just do it right. It’s so easy. Why risk yourself a ton of headache in the future to save you a few seconds?
Oxford English Dictionary, for example, is a human version of defining language and a thesaurus is a completion engine.
Human language didn't suffer by having a dictionary and thesaurus. Computer language doesn't suffer either.
Remember it doesn't actually know an API or how it should be used: it's putting things together to look like typical code. For me that has meant difficult to spot bugs like linking up incorrect variables from the rest of my code.
I wish it could integrate the first SO answer to a generated question, because I always end up there anyway having to fix things.
I've only had it for about a week now but overall I'm happy with it. None of the code I'm writing is crazy cutting-edge stuff and in aggregate I'm sure it saves me more time than takes, including the time I spend reviewing and potentially changing the generated code.
One reason I've championed the development of visual programming (flow-based, node diagrams, etc) is that while you don't want to compress a big complex program down into a single layer and become unreadable in the process, graphical methods are a great way for people to see what options they have available and just point at things they want to try out.
Instead of struggling with syntax at the same time as trying to find out what they can do with a new API, they can engage in trial-and-error to find out the capabilities and what makes it worth using, then build up their competency once they are clear about their objectives.
I'm looking forward to trying this now that it's available for my favorite IDE, but I'll probably want to set up a hotkey to switch it on and off as I need it. Once I get fully comfortable with something I often find code completion tools get in the way of my flow.
The old "just copy-paste from Stack Overflow" approach to development is satirised and ridiculed these days (despite being still in common practice I'm certain), because as we all know so well by now, an accepted answer on SO does not always equate to a correct answer. Yes, the SO guys & community do do their best to improve answer quality iteratively (wiki answers, etc.), but there's still a lot of bad answers, and even many of the "good" ones become outdated or don't keep up with modern best-practice (especially when it comes to security).
Omitting urlencoding isn't the biggest crime, but it is a pretty standard URL-building step, and the fact that a tool released this year is spitting out code that omits something so simple is fairly damning. It's also a micro-example of much larger errors Copilot will surely be responsible for. Missing url encoding can be an injection vector in many applications, even if it's not the most common risk, but miss encoding in other string-building ops and you've made your way into the OWASP Top 10.
The big difference between copilot and SO is there's no community engaging in an open & transparent iterative process to improve the quality of answers.
… as a top level comment said, this is optimizing for the wrong problem.
I didn't allow it since I think it implied uploading my code to their servers.
- less than perfect import/types/var suggestions that LSP in typed languages would've made perfect suggestions for (e.g named import in go would use the package name instead).
- latency feels a bit high and my thoughts would get interrupted waiting for a suggestion to come.
For the former, I wonder hard feasible it would be to give structured suggestions to the LSPs that it would swap for correct var names and imports and such. Or test each suggestion with the LSP for error counts and offer the least erroring suggestion.
How high? That's interesting.
For those who don't know, he's essentially the godfather of vim plugins - I even have an entire 'tpope section' in my init.vim
I added an issue. https://github.com/github/feedback/discussions/6847
Anyone else install in neovim?
I filed a PR because it was a bit frustrating to go through the entire setup and then find out I needed to be granted access.
https://github.com/github/copilot.vim/pull/2