"LLMs are great when you are doing the same things as everyone else. Step outside of that and it's far more trouble than it's worth."
If you're doing something in a way it's not in the training data set, maybe your way of approaching the problem is wrong?
>If you're doing something in a way it's not in the training data set
in my industry, the "training data set" won't get much farther from public code than the barebones, generated doxygen comments we call "documentation".
But in a way you're also right. The industry's approach is fundamentally wrong, making 20 solutions to a problem with plenty of room to standardize a proper approach (plenty of room where you need proprietary techniques, but that's getting less true by the month). But an LLM isn't going to fix that cultural issue and will suffer from it.
> The industry's approach is fundamentally wrong, making 20 solutions to a problem with plenty of room to standardize a proper approach [...]. But an LLM isn't going to fix that cultural issue and will suffer from it.
LLM-powered development may push the industry towards standardization. "Oh, CoPilot cannot generate proper code for your SDK/API/service? Sorry, all my developers use CoPilot, so we will not integrate with your SDK/API/service until you provide better, CoPilot-friendly docs and examples."
Sorry but some of us aren't building the ten millionth CRUD app.
SuccessFactors is a popular HR platform and I was asking it any question and getting the wrong answer every time.