zlacker

>>orph+(OP)
I have a few questions about copilot. I haven’t gotten a chance to use it yet.

Is it irrational that this makes me a little anxious about job security over the longterm? Idk why but this was my initial reaction when learning about this.

Given the scenario where copilot and its likes becomes used in a widespread manner. Can it be argued that this might improve productivity but stifle innovation?

Im pretty early in my career but the rate things are capable of changing soon doesn’t sit too well with me.

>>wara23+UC
> Is it irrational that this makes me a little anxious about job security over the longterm?

In the 50s, we programmed computers with punch cards. Who does now? How many web developers today could tell the difference between `malloc` and `calloc`? Probably not that many.

For a lot of developers, programming today bears very little relation to programming decades ago. Copilot is like any other innovation - it obsoletes some skills, and it introduces new ones.

I doubt copilot will reduce the need for engineers: but it may change the work they do. But that's no different to any other industry.

>>objclx+DF
I don’t like this narrative. Going from punch cards, to Assembly, to C and to dynamic languages all empowered the programmer with more expressive languages. I don’t believe going from Python to programming via code comments is the same deal.

It would be more like we still write asm but we have editors that let you write a little C code and then it spits out a paragraph of ‘reasonable’ asm that still has to be maintained.

>>eloisi+1S
That's roughly how I've seen experienced people work on high-performance code. I mean, they rarely maintain the generated assembly directly, but they do write code with the assembly it would generate in mind, and keeping the code generating comparable assembly over time is part of maintaining the performance-critical parts of the codebase.