[hwchase17]

sorry to hear that, totally understand feeling burnt

ooc - do you think theres anything we could do to change that? that is one of the biggest things we are wrestling with. (aside from completely distancing from langchain project)

[chatmasta]

My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part. That’s the real reason people use something other than the native SDK of an LLM provider - they want to be able to swap out LLMs. That’s a well-defined problem that you can solve with a straight forward library. There’s still a lot of hidden work because you need to nail the “least common denominator” of the interfaces while retaining specialized behavior of each provider. But it’s not a leaky abstraction.

The “chaining” part is a huge problem space where the proper solution looks different in every context. It’s all the problems of templating engines, ETL scripts and workflow orchestration. (Actually I’ve had a pet idea for a while, of implementing a custom react renderer for “JSX for LLMs”). Stay away from that.

My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).

[hwchase17]

> My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part

a lot of our effort recently has been going into standardizing model wrappers, including for tool calling, images etc. this will continue to be a huge focus

> My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).

I would actually argue we have done this (to some extent). we've invested a lot in LangSmith (about half our team), making it usable with or without langchain. Likewise, we're investing more and more in langgraph, also usable with or without langchain (that is in the orchestration space, which youre separately not bullish on, but for us that was a separate bet than LangChain orchestration)

[causal]

I'm not sure. My suspicion is that the fundamental issue with frameworks like LangChain is that the problem domain they are attempting to solve is a proper subset of the problems that LLMs also solve.

Good code abstractions make code more tractable, tending towards natural language as they get better. But LLMs are already at the natural language level. How can you usefully abstract that further?

I think there are plenty of LLM utilities to be made- libraries for calling models, setting parameters, templating prompts, etc. But I think anything that ultimately hides prompts behind code will create more friction than not.

[causal]

Glad to hear that- sounds like I should give LangGraph a try after all

[hwchase17]

totally agree on not hiding prompts, and have tried to stop doing that as much as possible in LangChain and are not doing that at all in LangGraph

thanks for the thoughts, appreciate it