[khalilravanna]

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.

[tevon]

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.

[falcolas]

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.

[khalilravanna]

> 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."

[falcolas]

> 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

[iceburgcrm]

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.

[falcolas]

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.

[warkdarrior]

> 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.

[falcolas]

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

I doubt any employer would appreciate being this particular guinea pig because one of their employees wanted to avoid writing some boilerplate.

[ekidd]

Several of the byte-for-byte copies pointed out by open source authors were longer than 20 lines, and contained verbatim comments.

I am not a lawyer, but that's been enough to get people in legal trouble in the US.

[viraptor]

> 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.

[echelon]

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.)

[yonaguska]

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.

[bravetraveler]

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

[ben_w]

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...

[tick_tock_tick]

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!

[bcrosby95]

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.

[Waterluvian]

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.

[tines]

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.

[ThrowawayR2]

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.

[rmbyrro]

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.