> Your job was never to write code, it is to solve problems for your users. They are why we have a job. You need to talk with the users, empathize with them, understand their problems and feel their pains. This is much too important to be left exclusively in the hands of product managers and designers. You are the problem solver, so you need to fully understand the problem.
Adding to this point, LLMs won't fully understand the problem, so they're simply incapable of developing complete solutions. I've had a lot of success with these tools in developing functions, but at that point I've already architected and designed the solution. Even so, it saves time. These should be regarded as developer productivity tools, not developer replacement tools.
Developer productivity tools are developer replacement tools. If the current paradigm is: principal/senior devs design system, implemented by more junior devs, and LLM tools enable the seniors to produce lots of code, then the juniors are the ones getting replaced. The next step up the stack is enabling the PMs and business people to design (and implement) the system. There is no reason to think LLM based tools are in principle incapable of that.
"Software development" will still exist, but if productivity tools become so capable that your PM can crank out a dozen variations and iterate on them solo, that will lead to developer replacement.
IDK, I've been developing software for 40 years now and have been through several of these "developer replacement" hype cycles. Every single time what ended up happening was even more developers were required. I see this as being the same, at least for the next few years. I do believe that the ultimate end point is quite different - developers will be replaced - but that's several years away and will require major changes to the approach currently being used for software development.
Yes this is honestly the silliest part of the whole conversation.
I am currently employing 6 software engineers in my company. If from tomorrow they were 10x more productive then I would employ 6 software engineers because that is the budget I have.
Their increased productivity would lead to a faster growth and I would then have budget for more.
If you increase the productivity of software engineers then people will hire more software engineers not fewer.
I've been through this cycle as well, but I don't think this works the same way. I mean the only way it would work the same is if AI never reaches its promises, and I don't mean AGI, but never reaches the level of the thinking of a software developer. Then yes, no replacement. But do you really think AI will never get smart enough? Because the second it gets, whoever works on that level flies out the window. A therapeut needs his hands to work, so a very complex hardware interface with a long way ahead to reproduce, but a developer's work happens directly in the computer, zero hardware replacement costs.
Ten years? Maybe. But our workflow will have changed to accommodate AI being the primary code generator.
Twenty years? The new workflow from ten years will be standard and AI will be able to competently do all code generation.
Will AI replace software developers? Yes, and many of those developers will have transitioned to new work driving the new workflow.
By the time AI is ready to replace the developers driving the new workflow, then there's very little at that point that humans can do, and AI can't, without assistance from humans. In other words, replacing software developers isn't our biggest problem because by the time AI can do that, nearly all humans are replaceable.
What do you mean by the AI "reaching a developers level of thinking" and if "it will get smart enough"? Because it doesn't do any thinking it predicts the statistically most likely token depending on the input.
I've honestly never had that success. LLMs for me more often get in the way than actually help anything. It may be that it's because I deal mostly in very large code bases with their own nuances.
Works much better on greenfield projects. Brownfield requires the LLM to have ingested your codebase and all the libraries you're using. That's why tools such as DeepSeek are exciting because that potentially opens up the door to much better brownfield development - which is where the real value lies!
Counter point though- what if it was trained on your specific code base? Wouldn't it be able to then help with those given nuances?
The code base I have I would love to be able to just give some AI free reign and learn the structure since a lot of it is fairly repetitive; I know it would be so easy to say "hey add X just like Y" and it would be able to do it easily.
The rare times where I have no good idea what to do, it is faster to code with an LLM. The rest of the time, when I know just what I want, it takes longer for me to formulate it, query the LLM and discuss and validate its output.
My more experienced/senior colleagues all say roughly the same. It’s great help for our juniors though. They learn a lot and are more capable on their own with the AI assistance.
It’s improving all the time though, so I’m not writing it off at all. I am developing an evaluation suite so I can keep watching the progress in a systematic way..
Open benchmarks are vulnerable to saturation. I think benchmarks should have an embargo periodic, until which only 3% of the question-answer pairs is released, with an explicit warning not to use it 3 months after being released.
I think there are types of problems that AI will be great at solving. If you can pass in a whole codebase then we might have LLMs that can suggest refactoring etc to improve code quality.
Code mods like upgrading from python 2 -> 3 could also become possible.
Adding to this point, LLMs won't fully understand the problem, so they're simply incapable of developing complete solutions. I've had a lot of success with these tools in developing functions, but at that point I've already architected and designed the solution. Even so, it saves time. These should be regarded as developer productivity tools, not developer replacement tools.