But the code is the easy part. Solving the right problem is the hard part.
If anything matches the definition of banality in this discussion, it's the puerile assertion that writing code is software development.
It isn't.
Even at FANGs the first thing they say to newjoiners and hiring prospects for entry level positions is that the workload involving writing code amounts to nearly 50% of your total workload.
And now all of a sudden are we expected to believe that optimizing the 50% solves the 100%?
I think you lost track of the discussion. I pointed out that in the absolute best case scenario LLMs only focus on tasks that represent a fraction of a software engineer's work.
Then, once you realize that, you will understand that the total gains of optimizing away the time taken on a fraction of a task only buys you a modest improvement on total performance. It can speed up a task, but it does not and cannot possibly eliminate the whole job.
To see what I mean, see Amdahl's law.
https://en.wikipedia.org/wiki/Amdahl%27s_law
Again, only a fraction of the tasks of a regular software engineering role involves writing code. Some high-profile roles claim their entry level positions at best spend 50% of their time writing code. If LLMs can magically get rid of said 50%,the total speedup is at best 2x speedup in delivery.
You can look at that and think to yourself "hey that's a lot". That is not what's being discussed here. I mean, read the blog post you are commenting on. What's being discussed is that LLMs reduce time spent on a fraction of the software development tasks, but work on other software engineering activities increases as it's no longer blocked by this bottleneck.
As others have wrote, the so-called AI doesn't reduce work: it intensifies it.
https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies...
Also, why do you think the phenomenon of AI-induced burnout, dubbed AI fatigue, is emerging? Processes are shifting, but the work is still there.
Which is just huge if we can get 2x speedup.