You cannot tell me that letting anyone do something for you does not affect the skills that you outsourced, unless you are some sort of a superhuman.
As an example, I have been drawing portraits for quite a few years now, and whenever I go on a hiatus and come back after a few months, I can notice my skill not being anywhere close to where it was before I stopped using it.
Sure, after 2 or 3 portraits they mostly come back because of the previous experience, but skill rust is a real thing, and if you think your coding skills are the same because you used to code 20 years but haven't coded for some time, you are probably just lying to yourself.
Been reading and drinking that kool-aid for some time until I realized it's just an internet bubble mumbo jumbo. Majority of systems are still written in C and C++, and will be for unforeseeable future.
Yes but currently I don't know of a single company in my area that doesn't make you use AI daily because of the supposedly increased productivity. That means that juniors also absolutely have to use AI, probably sabotaging their learning process in the long run.
What stops a small, or even a large group of people to intentionally "poison" the LLMs for everyone? Seems to me that they are very fragile, and that an attack like that could cost AI companies a lot. How are they defending themselves from such attacks?
The instances should be based on the context. For example we had a few different API providers for the same thing, and someone refactored the separate classes into a single one that treats all of the APIs the same.
Well, turns out that 3 of the APIs changed the way they return the data, so instead of separating the logic, someone kept adding a bunch of if statements into a single function in order to avoid repeating the code in multiple places. It was a nightmare to maintain and I ended up completely refactoring it, and even tho some of the code was repeated, it was much easier to maintain and accommodate to the API changes.
I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days.
The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.
You are comparing compilers to a completely non deterministic code generation tool that often does not take observable behavior into account at all and will happily screw a part of your system without you noticing, because you misworded a single prompt.
No amount of unit/integration tests cover every single use case in sufficiently complex software, so you cannot rely on that alone.
You don't. I can guarantee that 90% of the generated code will never receive a detailed review, simply because there's too much of a cognitive overhead, and too little time, everything moves too fast.
I remember having to do such a code review before an AI in a highly complex component, and it would take a full day of work to do it. In this day and age, most of the people i know take like half an hour and are mostly scanning for obvious mistakes, where the bigger problem are those sneaky non obvious ones.
As an example, I have been drawing portraits for quite a few years now, and whenever I go on a hiatus and come back after a few months, I can notice my skill not being anywhere close to where it was before I stopped using it.
Sure, after 2 or 3 portraits they mostly come back because of the previous experience, but skill rust is a real thing, and if you think your coding skills are the same because you used to code 20 years but haven't coded for some time, you are probably just lying to yourself.