I think, we need to step back a little in these discussions. We need to ask, what productivity gains are we hoping to find? In any knowledge or specialised wor

I think, we need to step back a little in these discussions. We need to ask, what productivity gains are we hoping to find? In any knowledge or specialised work, operating a tool faster does not give great results, rather raises the risk of error and quality decline. Did duolingo once face existential threat because they failed to produce specific feature sometime? Did one of their feature suffer and cause user loss because it took more time for an engineer to write the actual code? Additionally, beyond formatting and obvious logical errors, every new code should in theory need some human review, which means more automated code means longer review. Assuming code is now produce at 2x, it also balances out that review will now take 2x. Additionally review is much more mentally taxing than putting out one’s thought into code, so risk of bugs and security holes also increases in the long term. While Software devs cost money, the job involves thinking, and that means it can’t be compared to factory work where someone is standing at next step to simply drill a screw in spotX and the next person will simply put on a cover. Despite years of effort, the attempt to make the process mirror factory floor(did anyone notice the open floor parallel to factory floors?) it failed. While many hate to see it this way, just like a surgeon will take his time to perform a brain/heart/tumor surgery, a SWE will do thinking, planning, coding and reviews. Giving a surgeon an autonomous bot that can spread the incision area faster or perform the incision faster does not mean productivity gain, it just means the doctor still needs to plan where to make the incision, how much to spread, what to chop off, what to avoid.