Post #3345209

I have only one data point: I am an embedded developer. Recently, I had to attach and debug a stepper motor with a serial interface to an embedded control system. A bog standard task. Luckily for science, I had to do practically the same seven years ago with a lab system at a research institute. And in the current job, the senior engineer responsible for the motor interface is a heavy proponent of AI tools and uses these whenever he can. Oh, and there are a few more pesky little differences: In the first job, I had to write the driver myself, as I had no working code, but some examples in Python and Java. I had only a partial protocol from the vendor and had to reverse-engineer inportant parts myself, as the vendor preferred to supply a closed-source windows driver. in the second job, we already had working though a bit old C++98 code written by somebody who had left the company, for an earlier iteration of that embedded system, which wad in production for about 8 years. the responsible engineer relied heavily on AI he told me that in multi-threaded C++ code, you don’t need locks, because the AI didn’t tell him. I had to educate him a bit about undefined behaviour in C++. In both cases, the result had to be reliable, ad it was part of exoensive snd heavy machinery with high cost of failures. The outcome? The task took four weeks in the first job, and over six months in the second job. In the first case, the result was very reliable. In the second, it is still not fully reliable. You can point out that the second was a legacy system, which is more difficult to evolve. But that’s the point - AI does not “understand” legacy systems at all, and worse its use brings down and inhibits communication and knowledge transfer. At best, you csn conclude that AI is no substitute at all for a lack of knowledge and working institutional processes.