No jobs get easier with automation - they always move a step up in abstraction level.
An accountant who was super proficient in adding numbers no longer can rely on those skills once calculator was invented.
No jobs get easier with automation - they always move a step up in abstraction level.
An accountant who was super proficient in adding numbers no longer can rely on those skills once calculator was invented.
This is the key. I haven't found that things have become harder. The hard parts are still hard, and those have been the most important and prominent parts of my job once I reached a certain level.
However, I do wonder how we will train juniors to become seniors. Perhaps the answer is that the curriculum changes from coding and data structures to architecture and design which was typically a last minute addition in college.
That said, there are plenty of amateurs who find coding to be approachable and system design to me daunting. For them, eliminating coding and moving the focus to system design would be a nightmare.
I've never heard of Godbolt before but I have written assembly for x86, AVR and PIC. I've optimized PTX based on analyzing the SASS assembly instructions for building GPU-accelerated linear system solvers.
System architecture is part of engineering. It's literally part of the design documents we had to produce in my engineering capstone project. Engineering is about choosing among a bunch of alternatives to meet the intended goal. That requires understanding the problem that's to be solved, details of all the alternatives and their trade-offs, and how those alternatives would be implemented into a solution. You apply the same engineering principals at the system architecture level, module level, function level, and even each line of code.
I work with some very capable developers. I can discuss with them and come up with a plan at a system or module level and trust them to make their own design decisions. We can discuss them ahead of time if I think it might be too much for them. I can review their work and iterate with them if I have concerns. These are all things I can do with modern AI tools.
If that's self-serving, so be it, but me and fellow engineers of all different levels of experience are seeing benefits from using AI at times where it makes sense for us. This hasn't cost us our jobs - we are hiring madly - but it has helped us to learn things and build things faster.
It's another tool in the toolbox. Use it when it suits you.
I dunno about that. Look at blogging as an example - AI took away the "easy"[1] part of blogging, and now we are left with 90% crap AI-generated "articles" like the one you just read.
I feel it's the other way around - AI took away the hard parts, of both blogging and programming, and now what have to look forward to every single damn day is a deluge of AI slop of absolutely poor quality.
Continuing with the literature analogy (because this article was written by an AI), adding AI as a tool for authors isn't producing the next Terry Pratchett quicker, it's delaying the production of the next Terry Pratchett because the next Terry Pratchett will be drowned out by an unstoppable volume of AI slop.
After all, if you can't recognise obvious AI blog posts, what makes you think you can recognise poor code?
---------------------
[1] I am using the term as you are using it. I don't really believe that it took away the easy part.