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.
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.
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.
You could state they are not the first to write this which would be more correct.
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.
That "significant enough [...] to taint the entire codebase" remains to be decided in court.
I am not a lawyer, but that's been enough to get people in legal trouble in the US.
I doubt any employer would appreciate being this particular guinea pig because one of their employees wanted to avoid writing some boilerplate.
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."
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
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.
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.)
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'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.
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
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...
There won't be apps, actually, they'll do everything programmatically.
And all humans would have been killed by then in an AI doom.