Like AI could write code perfectly as soon as I thought of it, and that would not improve my productivity 10x. Coding was never the slow part. Everything that goes around coding (like determining that the extra load here is not going to overload things, getting PMs to actually make their mind up what the feature is going to do, etc.), means that there's simply not that much time to be saved on coding activities.
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.
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.
> coding speed
> the annoyance caused to an engineer
No one said productivity is this one thing and not that one thing, only you say that because it's convenient for your argument. Productivity is a combination of many things, and again it's not just typing out code that's the only area AI can help.
The context here is AI assisted engineering and you raised the point that non-engineering productivity is more important for engineers, which I think is absurd.
You can have 10x engineering productivity boost and still complete work in the same amount of time, because of communication and human factors. Maybe it's a problem, may be it's not. It's still a productivity gain that will make you work better nonetheless.
I did not raise it, but what was raised was "coding speed": as in, the speed to type code into an editor.
That's not "engineering", but "coding".
Engineering already assumes a lot more than just coding: most importantly, thinking through a problem, learning about it and considering a design that would solve it.
Nobody raised communication or the human factors.
Current LLMs can indisputably help with the learning part, with the same caveats (they will sometimes make shit up). Here we are looking at how much they help with the coding part.
