Same argument can be said for not using any tooling really. "Tech is the easy part". No difference typing code on notepad and having zero process/engineering infrastructure I guess. Because stakeholder management is the main engineering skill apparently.

Btw, AI doesn't just code, there are AIs for debugging, monitoring etc too.

There are two levels to this.

1. Tooling obviously does improve performance, but not so huge a margin. Yes, if AI could automate more elements of tooling, that would very much help. If I could tell an AI "bisect this bug, across all projects in our system, starting with this known-bad point", that would be very helpful -- sometimes. And I'm sure we'll get there soon enough. But there is fractal complexity here: what if isolating the bug requires stepping into LLDB, or dumping some object code, or running with certain stressors on certain hardware? So it's not clear that "LLM can produce code from specs, given tight oversight" will map (soon) to "LLM can independently assemble tools together and agentically do what I need done".

2. Even if all tooling were automated, there's still going to be stuff left over. Can the LLM draft architectural specs, reach out to other teams (or their LLMs), sit in meetings and piece together the big picture, sus out what the execs really want us to be working on, etc.? I do spend a significant (double-digit) percentage of my time working on that, so if you eliminate everything else -- then you could get 10x improvement, but going beyond that would start to run up against Amdahl's Law.

If you were to really measure speed improvement of notepad vs a tricked out IDE, it's probably not much. The problem would be the annoyance caused to an engineer who has to manually type out everything.

No, coding speed is really not the bottleneck to software engineer productivity.