"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?

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.

>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."

for obscure API or SDK, upload docs and/or examples to Claude projects.

That sounds like you might potentially break some copyright of your tools. Not all our tools are FOSS (and even some FOSS licenses may not allow that).

You either feed your code into API or you don't.

If you can't share your code with Anthropic then there is nothing to talk about. Expecting it to know non-public SDK's and docs isn't reasonable. But if you want it to help you with FOSS libs/docs, this is the way.