Hacker News new | ask | show | jobs
by tevon 1309 days ago
Seems this article completely misses the benefits of copilot. Its a massive step forward in productivity. For me, its about suggesting proper syntax across the various libraries we use. It really does cut time by 10s of percent.

I don't buy the argument that the risk of a yet-to-be-litigated case against a different company, who will certainly fight this hard; is greater than the productivity gain of using copilot.

Additionally, the security argument feels ridiculous to me. We lift code examples from gists and stackoverflow ALL THE TIME! But any good dev doesn't just paste it in and go, instead we review the code snippet to ensure its secure. Same thing with copilot, of course its going to write buggy/insecure code, but instead of going to stackoverflow for a snippet its suggested in my IDE and with my current context.

13 comments

Using it in practice, the sheer quantity of suggestions (often one for every line) is fatiguing especially when 99% of the time they seem fine.

I posit it becomes increasingly likely over large periods of time over many engineers that severe bug or security issue will be introduced via an AI provided suggestion.

This risk to me is inherently different than the risk accepted that engineers will use bad code from Stack Overflow. Even Stack Overflow has social signals (upvotes, comments) that allow even an inexperienced engineer to quickly estimate quality. The amount of code used by engineers from Stack Overflow or blogs etc, is much smaller.

Github Copilot is constantly recommending things and does not gives you any social signals lower experienced engineers can use to discern quality or correctness. Even worse, these are suggestions that are written by an AI that does not have any self-preserving motivations.

Copilot's default behavior is stupid. You can turn off auto-suggest so that it only recommends something when you prompt it to, and that should really be the default behavior. This would encourage more thoughtful use of the tool, and solve the fatigue problem completely.

In IntelliJ, disabling auto complete just requires clicking on the Copilot icon in the bottom and disabling it. Alt+\ will then trigger a prompt. I know there's a way to do this in VSCode as well, but I don't know how.

> I know there's a way to do this in VSCode as well, but I don't know how.

I dug into this a bit, since I want the same functionality, I found I needed an extension called settings-cycler (https://marketplace.visualstudio.com/items?itemName=hoovercj...) which lets one flip the 'github.copilot.inlineSuggest.enable' setting on and off with a keybind.

Not sure who's in charge of the Copilot extension for VS Code, but if you're out there reading this, the people definitely want this :) Otherwise of course, your tool rocks!

I switched it off and never remember to bother using it. It's obvious why it's enabled by default.
"...does not gives you any social signals lower experienced engineers can use to discern quality or correctness" is very astute.

I experienced this in practice. I was pairing with an inexperienced engineer who was using Copilot. He was blindly accepting every Copilot suggestion that came up.

When I expressed doubt in the generated code (incorrect logic + unnecessarily complex syntax), he didn't believe me and instead trusted that the AI was right.

I would argue that this kind of problem is going to become less of an issue overtime, since they're going to have to also solve the issue of suggesting code samples from deprecated API versions - it's likely that eventually they'll figure out a similar way to promote more secure types of code in the suggestions based on Stack overflow or other types of ranking systems.
Yes, the will surely improve a lot and also train users to write better prompts and comments. With millions of users accepting suggestions, then fixing them, they get tons of free labeling. If they monitor the execution errors they got another useful signal. If they use an execution environment they could use reinforcement learning, like AlphaGo, to generate more training data.
As programmers we take pride in being DRY. Copilot is helping us not reinvent the same concept 1000 times. It also makes developers happier, reduces the need to context switch, increases speed and reduces frustration.

> Github Copilot is constantly recommending things

It's only a momentary problem, will be fixed or worked around. And is this a bad thing to get as many suggestions as you could? I think it's ok as long as you can control its verbiage.

> does not gives you any social signals

I don't see any reason it could not report on the number of stars and votes the code has received. It's a problem of similarity search between the generated code and the training set, thus finding attribution and having the ability to check votes and even the license. All doable.

> an AI that does not have any self-preserving motivations

Why touch on that, people have bodies and AIs like Copilot have only training sets. We can explore and do new things, AIs have to watch and learn but never make a move of their own.

>> As programmers we take pride in being DRY. Copilot is helping us not reinvent the same concept 1000 times.

That's what libraries are for.

Copilot is just copy / paste of the code it was trained on.

When the code it was trained on is later discovered to have CVEs, will it automatically patch the pasted code?

With a library, you can update to the patched version. Copilot has no such feature.

> Copilot is just copy / paste of the code it was trained on.

Every time I hear someone say this, I hear "I've never really tried Copilot, but I have an opinion because I saw something on Twitter."

Given the function name for a test and 1-2 examples of tests you've written, Copilot will write the complete test for you, including building complex data structures for the expected value. It correctly uses complex internal APIs that aren't even hosted on GitHub, much less publicly.

Given nothing but an `@Test` annotation, it will actually generate complete tests that cover cases you haven't yet covered.

There are all kinds of possible attacks on Copilot. If you had said it can copy/paste its training data I wouldn't have argued, but "it just copy/pastes the code it was trained on" is demonstrably false, and anyone who's really tried it will tell you the same thing.

EDIT: There's also this fun Copilot use I stumbled across, which I dare you to find in the training data:

    /**
    Given this text:
 
    Call me Ishmael. Some years ago - never mind how long precisely - having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world.

    Fill in a JSON structure with my name, how much money I had, and where I'm going:
    */

    {
        "name": "Ishmael",
        "money": 0,
        "destination": "the watery part of the world"
    }
It can even read an invoice, you can ask it "what is the due date?" It's a system that solves due date and Ishmael questions out of the box. And everything in-between.
>> It can even read an invoice, you can ask it "what is the due date?" It's a system that solves due date and Ishmael questions out of the box. And everything in-between.

That's cool.

But emitting copyrighted code without attribution and in violation of the code's license is still copyright infringement.

If I created a robot assistant that cleans your house, does the shopping, and occasionally stole things from the store, it would still be breaking the law.

>> If you had said it can copy/paste its training data I wouldn't have argued, but "it just copy/pastes the code it was trained on" is demonstrably false, and anyone who's really tried it will tell you the same thing.

So if "it could commit copyright infringement, but does not always do so" is good enough for your company's legal review team, then go for it.

Has anyone tried to see how similar is their manually written code to other codes out there? I bet small snippets 1-2 lines long are easy to find. It would be funny to realise that we're more "regurgitative" than Copilot by mere happenstance.
> I posit it becomes increasingly likely over large periods of time over many engineers that severe bug or security issue will be introduced via an AI provided suggestion.

AI can also do code review and documentation helping us reduce the number of bugs. Overall it might actually help.

This is a very solid argument. How do we fix that?

THIS is the article I want to read!

"I posit it becomes increasingly likely over large periods of time over many engineers that severe bug or security issue will be introduced via an AI provided suggestion."

I'll go one further with the "Co-pilot is stupid."

It's supposed to be artificial intelligence. Why in the eff is it suggesting code with a bug or security issue? Isn't the whole point that it can use that fancy AI to analyze the code and check for those kind of things on top of suggesting code?

Half-baked.

Ah yes, humans are perfect, never make any mistakes. That's why only AI write bugs.
This. If copilot suggests anything more than basic syntax or boilerplate I don’t use it. If it writes code I don’t understand or wouldn’t be able to write myself I won’t use it. Why? Because at the end of the day it’s my code. In what world is a good engineer submitting a PR for coworkers to look over that isn’t their code?

If this is a real issue the solution is not banning yet another tool. It’s education. Teaching engineers how to properly understand code attribution and licenses.

Yes! Exactly.

The article suggests that he wants to know "who wrote the code" if a senior dev he trusts submits a PR. He doesn't want to be surprised that "the AI" wrote some of this code.

But its ALL written by the senior dev. If he trusts that dev, that means that dev has thoroughly read and tested his code! That's the important bit. Remembering proper syntax/imports/nesting levels is the tiniest piece of writing good code. And copilot can take that off our hands.

That's like saying that code copy/pasted from OSS projects on github was "written by the developer". Which is not true.

The speed of your developer and the correctness and test coverage of your code doesn't matter when it comes to license compliance.

And license compliance could cost your company 100x (if not more) the value of your best software developer - especially for the non-OSS licenses.

> That's like saying that code copy/pasted from OSS projects on github was "written by the developer".

I don't think that's what OP is saying. What I think OP is saying (and I agree) is that submitted code is trusted if you trust the source. If you take the person putting code in front of you and ask "Would this person copy someone else's code and submit it as their own" and the answer is "No they would not copy code" then every step that trusted-person took to get to that code is immaterial. Whether they used StackOverflow or Copilot or whatever AI assisted code generating tools do or don't get developed in the future. At the end of the day a good, trustworthy engineer isn't going to use licensed software by "accident"[1].

1. I put "accident" in quotes because it seems so crazy to me that someone would start writing a method "doThing" and then CoPilot spits out a licensed implementation of "doThing" and the engineer would look at it and go "This seems fine."

> every step that trusted-person took to get to that code is immaterial.

Which is, unfortunately, completely useless when it comes to copyright infringement. Trust in the individual will not change the output of an audit for copyrighted code, or the results from said audit.

The only thing that a "trusted" individual can contribute in a copyright infringement investigation is attesting that they did not know that the code they put in the codebase was copyrighted. And all that does is save the company from getting the higher "willful infringement" fines, if it should get that far.

Wilful Infringement Damages: https://www.ce9.uscourts.gov/jury-instructions/node/708

It was written by the developer. If I write down lyrics I remember I still wrote it. Whether I have the copyright to make money off of it or whether it is trademarked are different things.

You could state they are not the first to write this which would be more correct.

GitHub Copilot has been concretely demonstrated to emit significant chunks of OSS licensed code.

Significant enough that if the license is GPL (which some has been) it will "taint" the entire codebase and license it under GPL. Significant enough to be found by automated OSS audit tools, which would trigger a re-write and education for the developer who committed it.

EDIT:

> If I write down lyrics I remember I still wrote it.

Not from a copyright point of view. The rights to those lyrics belong to the songwriter. It's kinda like photographs. You don't automatically have the right to distribute a photograph of yourself that was taken by someone else.

> Significant enough that if the license is GPL (which some has been) it will "taint" the entire codebase and license it under GPL. Significant enough to be found by automated OSS audit tools, which would trigger a re-write and education for the developer who committed it.

That "significant enough [...] to taint the entire codebase" remains to be decided in court.

> If it writes code I don’t understand or wouldn’t be able to write myself

For me the bar is higher - it's not that I wouldn't understand it, it's that its easier to miss mistakes when reviewing than when writing from scratch. In the same way you may have ignored the typo in this comment and understood what I meant regardless of the mistake. But that doesn't work for programming - a mistake is a mistake and likely matters in edge cases even if it's not immediately obvious.

Do you think we'll be writing software 200 years from now?

50? 25?

I'll bet the people spinning cotton thought that would endure forever.

(Sorry if my tone comes across as fervent. I'm excited to be displaced by this, because what follows is the stuff of dreams.)

The invention of the cotton gin simply moved people from spinning cotton to picking cotton. And increased demand for slaves.

I'm not excited to be displaced personally, but I'm also not really worried about being displaced. If displacement is inevitable, I don't see how the average programmer is going to leverage this for the "stuff of dreams". Usually, tech advancements result in a greater consolidation of wealth into the hands of those that already own capital. Recent tech is no exception. Yes, there has been a lot of wealth created for regular people, but we're still working 40+ hour weeks, and earnings have not matched the increase in productivity.

What I am concerned about is that our field is becoming increasingly arcane magic for the younger generations, especially the masses that are being completely and utterly failed by the education system.

I apologize ahead of time for rambling, but I'm with you on this!

In my coworkers and many of the applicants we see, there's a trend of over optimization. The common meme is the 'leet code' interview process.

I suppose the best way I can convey this is... I think there's hyper focus on the mechanics of doing things. Making people not afraid of the code, unaware of the world around it

Abandoning a lot of thought for process. Or even the physical systems it runs on. I recently learned about the term 'mechanical sympathy'

Sometimes it's important to ask if you need the code or system at all!

I know it's not fair to people but I groan any time I see a CS degree

Between 2016 and 2021, I've been of the opinion that I cannot make any reasonable forecast of even vague large-scale social/technological/economic development past 2030, because the trends in technology go all funky around then.

Thanks to recent developments in AI (textual and visual), I no longer feel confident predicting any of those things past about the beginning of 2028.

It's not a singularity, it's an event horizon: https://kitsunesoftware.wordpress.com/2022/09/20/not-a-singu...

I don't see a world where programming isn't the last thing to go. We pretty much have a general intelligence when a "programmer" is no longer needed. That doesn't mean programming will look anything like it does today in 200 years but will the profession, doing kinda the sameish thing, still exist? Absolutely!
It's interesting to think about. If programming can be automated away, then you can use that automation to automate away any job in the world that can be automated.
Whenever I watch Geordi and Data doing something in engineering, they’re often talking to the computer about constructing models and sims and such.

To me this is the most ultimate form of declarative programming. Not that we will all be talking it out, but that we will explain in natural language what we’re after.

It maximizes how much time we spend in the “problem understanding/solving” phase and minimizes the tedium of actually setting up the apparatus.

I mean, yes? People will be doing math as long as there are people around to do it. It'll look different, sure. But there will always be problems, and math/programming is problem solving par excellence.
These assisted coding systems are tremendously exciting but they are only the analogue of moving from a shovel to a powered excavator; it still needs a trained individual who knows what the final result needs to look like to a fairly high technical level to be effective. So, yes, 25-50 years from now humans will still be be the principal element in writing software.
Yeah, in the future there will be only AIs developing apps and AIs using apps.

There won't be apps, actually, they'll do everything programmatically.

And all humans would have been killed by then in an AI doom.

I don't understand how it improves productivity _that_ much. Most of my time isn't actually spent on syntax but rather reading Hacker news and making irrelevant comments.
> I don't buy the argument that the risk... is greater than the productivity gain of using copilot.

How does your company's general counsel feel?

This article is written at CTOs, not engineers.

I suspect prohibiting Copilot will just become another checkbox on compliance security questionnaires. The fact that Kolide can detect it and that Kolide can feed compliance suites like Vanta or SecureFrame means the infrastructure is already there. It's not only your lawyers that want these guarantees, it's often your customers.
We don't have GC (too small), so caveat my take with the fact that I'm writing from a smaller companies perspective.

May be different for a larger, value-preserving company who would face more scrutiny.

That being said, I still find it extremely unlikely that there would be legal ramifications from using a product being pushed by one of the largest software companies in the world. Why go for a user and not Microsoft themselves?

> That being said, I still find it extremely unlikely that there would be legal ramifications from using a product being pushed by one of the largest software companies in the world.

Microsoft is explicitly saying it's your responsibility to check if the Copilot's output that you add to your codebase is not infringing on anyone's license.

Also, it's actually a complex legal question if Copilot itself is infringing anyone's copyright. But, there is no doubt whatsoever that you don't have the right to distribute someone else's copyrighted code (without a license) just because it was produced by Copilot and not manually copied by you. And it is also very clear that Copilot can occasionally generate larger pieces of someone else's code.

Edit: fixed typos

> Microsoft is explicitly saying it's your responsibility to check if the Copilot's output that you ads to your codebase is infringing on anyone's license.

(Never used copilot)

Wow, this is kinda shocking IMO. It kind of negates the entire value proposition of the tool.

How am I supposed to find out whether a snippet is infringing? Should I paste it into google or something? Shouldn’t Copilot be the one to tell me if a snippet too-closely matches some existing code it learned from?

If MS is indeed saying this, I feel like it’s something they put in the agreement to cover their own asses. There’s no way they’d really expect everyone to do this sort of thing. Moreover I don’t feel that’s a very strong defense MS could use in court if somebody decides to go after MS for making the tool that makes infringement so easy. It sounds like one of those “wink wink” types of clauses that they know full well nobody will follow.

From the official FAQ [0]:

> Other than the filter, what other measures can I take to assess code suggested by GitHub Copilot?

> You should take the same precautions as you would with any code you write that uses material you did not independently originate. These include rigorous testing, IP scanning [emphasis mine], and checking for security vulnerabilities. You should make sure your IDE or editor does not automatically compile or run generated code before you review it.

I think lots of companies do run tools such as BlackDuck and others to scan their entire code base and ensure (or at least have some ass-covering) that there is no accidental copyright infringement.

[0] https://github.com/features/copilot#other-than-the-filter-wh...

How much of what you save by using Copilot will then be spent on BlackDuck licenses?
> Why go for a user and not Microsoft themselves?

1) the user likely doesn’t have the legal resources of Microsoft.

2) the user is the one committing the infringement.

If Microsoft stood behind this they could offer to indemnify users against lawsuits relating to CoPilot usage, but they don’t.

In Intellij or Visual Studio, syntax suggestion/tab completion are already great. Those technologies - which involve none of the legal risks of Copilot- are a massive step forward in productivity. Copilot does help extend these benefits to other languages that I occasionally dabble in, like Lua and embedded C, though it's clearly better in languages which are better represented in its dataset.

I don't find the natural language comment to buggy algorithm part of Copilot to be particularly useful. I know some people asked to be able to write a "DoWhatIMean(), method, but programmers really only wanted that to auto-expand to "protected virtual void DoWhatIMean() {}" without having to wait 30 seconds to check for a compile error and see if it was protected void virtual or protected virtual void...

> In Intellij or Visual Studio, syntax suggestion/tab completion are already great. Those technologies - which involve none of the legal risks of Copilot- are a massive step forward in productivity. Copilot does help extend these benefits to other languages that I occasionally dabble in, like Lua and embedded C, though it's clearly better in languages which are better represented in its dataset.

Copilot is so much beyond regular autocomplete that it's playing a completely different game.

I've been using it today while writing a recursive descent parser for a new toy language. I built out the AST in a separate module, and implemented a few productions and tests.

For all subsequent tests, I'm able to name the test and ask Copilot to write it. It will write out a snippet in my custom language, the code to parse that snippet, and construct the AST that my parser should be producing, then assert that my output actually does match. It does this with about 80% accuracy. The result is that writing the tests to verify my parser takes easily 25% of the time that it has when I've done this by hand.

In general, this is where I have found Copilot really shines: tests are important but boring and repetitive and so often don't get written. Copilot has a good enough understanding of your code to accurately produce tests based on the method name. So rather than slogging through copy paste for all the edge cases, you can just give it one example and let it extrapolate from there.

It can even fill in gaps in your test coverage: give it a @Test/#[test] as input and it will frequently invent a test case that covers something that no test above it does.

Thing is, for something like an AST parser you want a property test, not a bunch of autogenerated boilerplate.

Generally, if something is boring and repetitive it's probably shouldn't be written, better code generation is rarely a good answer.

Property tests are nice for lots of things, but for an AST parser? You'd basically have to re-implement the parser in order to test the parser, wouldn't you?

I suppose you could test "if I convert the AST back to a string do I get the same result", but that's not actually your goal with an Abstract Syntax Tree. If nothing else the white space should be allowed to change.

What sort of property tests did you have in mind?

You are right that simplified reimplementations make good property tests, but in this case I'd go the other way around: generate an AST, render it a in test case-dependent way (adding whitespace as you said, but also parens etc), inject known faults for a fraction of test cases, and check that the parsed AST is equivalent to the original one or errored out if a fault was injected. Rendering a given AST is usually simpler than parsing it.
Does Microsoft let their developers use it? Say, when working on Windows? If not, I'd say the very vendor of the software considers it radioactive, so I'll keep treating it that way, too.
Is 'what would a microsft dev do' really the bar we want to live by, though?
In this case, yes, of course—I don't really get your objection. If their own legal counsel is advising them not to let their developers use their own product over legal concerns (and what else could be the reason?) that would be a pretty good argument against anyone else using it.

Nb. I don't know whether they do or do not, in fact, let their developers use it.

Say what you want about microsoft - they've got some of the best lawyers in the world on this kind of stuff. If they're not doing it they either don't trust the tech or don't trust the law.
No but it's not a bad litmus test in this situation.
> It really does cut time by 10s of percent.

I used it for about a month. It gave me a few false positive that really burned me - it's not worth the risk. Maybe future versions would be better.

I've gotten plenty of false positives, but the mistakes turn up in testing and are pretty easy to spot when reviewing the code. Anything more subtle is likely to have been missed when written by hand anyway.

What happened to burn you so badly?

What're the examples of false positives?

Agreed it gets things wrong very frequently. But I've found it much easier to use its suggestion as another "input" to writing code.

Indeed. I had to write a graph traversal iterator in Rust and Copilot wrote the entire thing for me. I could have written it myself, it would have looked similar, but it just... did it. It was trivially to test and verify correctness.

That's minutes of work, maybe even 10 minutes, turned into seconds. That is huge.

The risk here is extremely low. Who is going to sue consumers of Copilot? It makes no sense. They'll sue Microsoft and, in a decade, we'll see if the win or lose (IMO Microsoft will win, but it's not important).

Did it "write it for you"? Or did it "illegally copy it for you"? That's a very big difference.

I'm not claiming that you can't get big productivity boosts by ripping off code like a crazy person. I bet you can! But should you?

Nothing has been decided in a court of law so saying that it's "illegal" is disingenuous.

Even if it's remarkably similar to another function from a completely different code base but some of the symbols or variable names or function name has been changed, I would argue that it still falls under fair use, and is sufficiently transformative.

> Nothing has been decided in a court of law so saying that it's "illegal" is disingenuous.

There are plenty of examples by now of big chunks of code lifted verbatim but without attribution. Pretty clear cut stuff.

> Even if it's remarkably similar to another function from a completely different code base but some of the symbols or variable names or function name has been changed, I would argue that it still falls under fair use, and is sufficiently transformative.

That's BS on many levels. Changing variable names doesn't make copyright go away. It's just trying to hide your violation of it.

I am pretty vocally against copyright, but let's not kid ourselves about the morality of this. No attribution is immoral.

Microsoft's own FAQ suggests it's on users of Copilot to avoid infringing, and that without a clue of where and how the suggestions came to be.
Yes, software copyright and patents are a mistake.
>> Yes, software copyright and patents are a mistake.

Richard Stallman would agree, but there are many of us who make a living writing software.

Is software valuable enough that people will pay money for it?

If you write original software that solves a problem, shouldn't you be able to license it how you want and profit from it?

You are welcome to license the software you create how you want. Let me license the software I create how I want.

If I dual license my software as GPL and commercial and GitHub Copilot reproduces my GPLed code without attribution and without the license, how it that not copyright violation?

Do you find meaningful distinction between an individual reading your code and copying patterns vs an AI model doing the same?
No, provided that both give proper attribution and follow the license the code is released under.
Stallman is pretty hard FOR copyright. The strong guarantees of "free software" is 100% based on strong copyright law.
That's not what i get from reading him https://www.globalnerdy.com/2007/07/06/richard-m-stallman-co...

My favorite part:

>Copyright Now

>Now with digital data and computer networks, it much easier for us to copy and manipulate information

> Digital technology has changed the effect of copyright law

> Copyright used to be a power that was:

> wielded by authors

> over publishers

> to yield benefits to the public

> Now it’s a power that is:

> wielded by publishers

> to punish the public

> in the name of the authors

> Now the public wants to copy and share — what would a democratic government do?

I don't really care, it's a trivial algorithm that I would have written virtually identically.
I always get the impression that CoPilot critics have never actually used it to get any work done and are basing their criticism solely on a tweet they saw about the Quake square root copy pasta function
The article itself lists three other recent examples, two of which are clearly copyright infringement https://twitter.com/DocSparse/status/1581461734665367554

It is not a theoretical concern

Oof. LGPL. That "time saver" will infect your entire codebase and open your company to sizable liability.

Even if they're never sued, companies will do internal OSS scans to limit their risks which would catch this. The result would be (at minimum) a talking to for the dev who committed it, and developer time spent doing a clean room re-write.

>will infect your entire codebase

No, it won't. It will only infect the resulting binary.

And then I will download a trial of the resulting binary, and send a GPL compliance letter to the company. Unless they took care to use dynamic linking in the LGPL case, they are legally obliged to send me the source code under the license, so I can release it all as FOSS under that license.
Yes, they are legally obliged, but they can just tell you to pound sand and you can't do anything because you aren't the copyright holder.
Ok, 3 tweets where someone has coaxed copilot into reproducing some copypasta for clout.

That's just not likely in any real use of copilot since it is typically completing single lines, using the variables and patterns which occur in the file that is being edited.

Anybody who had actually used it for work would know that these contrived examples are irrelevant.

I was a naysayer but find copilot makes me more productive. Especially at writing tests. It's very good at recognizing patterns in your own work, and completing an entire test based on the function name.
I tried to do this and I couldn't figure it out. I never got the sense that it knew anything about the code I had written, just that it was dreaming stuff up from its training set.
> instead we review the code snippet to ensure its secure

Doesn't matter. A developer's speed and test completeness and code quality matter not one whit when it comes to licensing. That 10x developer could mire the company in fines and code re-writes if they include copyrighted code, especially if it's not OSS.

> Same thing with copilot, of course its going to write buggy/insecure code, but instead of going to stackoverflow for a snippet its suggested in my IDE and with my current context.

copilot actually can have the benefit here of being able to retroactively mark some snippet as insecure, if it gets flagged as such by the moderators. Any user who used it could get automatic notification.

Physically coding is not at all where I spend the majority of my time at work or on personal projects. I exclusively use Haskell though, so maybe that has more to do with it.

But why optimize a non-critical path?