Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

231–240 of 307 posts

Re: Why we no longer use LangChain for building our AI agents

#231

Genuine question: can someone point me to a use case where langchain makes the problem easier to solve than using the openai/anthropic/ollama SDKs directly? I've gotten a lot of advice to use langchain, but the docs haven't really shown me how it simplifies the task, or at least not more than using an SDK directly. I really want to at least understand when to use this as a tool but so far I've been failing to figure…

It makes it simple (and uniform) to switch providers.

Re: Why we no longer use LangChain for building our AI agents

#232

Hi HN, Harrison (CEO/co-founder of LangChain) here, wanted to chime in briefly I appreciate Fabian and the Octomind team sharing their experience in a level-headed and precise way. I don't think this is trying to be click-baity at all which I appreciate. I want to share a bit about how we are thinking about things because I think it aligns with some of the points here (although this may be worth a longer post) > But…

Thanks Harrison. LangGraph (eg graph theory + Networkx) is the correct implementation of multi-agent frameworks, though it is looking further into, and anticipating a future, then where most GPT/agent deployments are at.

And while structured output and tool calling are good, from client feedback, I'm seeing more of a need for different types of composable agents other then the default ReAct, which has distinct limitations and performs poorly in many scenarios. Reflection/Reflextion are really good, REWOO or Plan/Execute as well.

Different agents for different situations...

Re: Why we no longer use LangChain for building our AI agents

#233
post #230

Earlier quoted context omitted.

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)

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 ple…

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

Re: Why we no longer use LangChain for building our AI agents

#234

Hi HN, Harrison (CEO/co-founder of LangChain) here, wanted to chime in briefly I appreciate Fabian and the Octomind team sharing their experience in a level-headed and precise way. I don't think this is trying to be click-baity at all which I appreciate. I want to share a bit about how we are thinking about things because I think it aligns with some of the points here (although this may be worth a longer post) > But…

[deleted]

Re: Why we no longer use LangChain for building our AI agents

#235
post #230

Earlier quoted context omitted.

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)

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 ple…

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

Re: Why we no longer use LangChain for building our AI agents

#236

Hi HN, Harrison (CEO/co-founder of LangChain) here, wanted to chime in briefly I appreciate Fabian and the Octomind team sharing their experience in a level-headed and precise way. I don't think this is trying to be click-baity at all which I appreciate. I want to share a bit about how we are thinking about things because I think it aligns with some of the points here (although this may be worth a longer post) > But…

[deleted]

I also have my criticisms of LangChain, but this feels mean-spirited towards devs that I think are honestly trying and didn't charge anything to use.

Re: Why we no longer use LangChain for building our AI agents

#237

Hi HN, Harrison (CEO/co-founder of LangChain) here, wanted to chime in briefly I appreciate Fabian and the Octomind team sharing their experience in a level-headed and precise way. I don't think this is trying to be click-baity at all which I appreciate. I want to share a bit about how we are thinking about things because I think it aligns with some of the points here (although this may be worth a longer post) > But…

Thanks Harrison. LangGraph (eg graph theory + Networkx) is the correct implementation of multi-agent frameworks, though it is looking further into, and anticipating a future, then where most GPT/agent deployments are at. And while structured output and tool calling are good, from client feedback, I'm seeing more of a need for different types of composable agents other then the default ReAct, which has distinct limita…

> Different agents for different situations...

totally agree. we've opted for keeping langgraph very low level and not adding these higher level abstractions. we do have examples for them in the notebooks, but havent moved them into the core library. maybe at some point (if things stabilize) we will. I would argue the react architecture is the only stable one at the moment. planning and reflection are GREAT techniques to bring into your custom agent, but i dont think theres a great generic implementation of them yet

Re: Why we no longer use LangChain for building our AI agents

#238
post #235
post #230

Earlier quoted context omitted.

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 ple…

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

would love any feedback if you do!

Re: Why we no longer use LangChain for building our AI agents

#239
post #211

Earlier quoted context omitted.

I appreciate that you're taking feedback seriously, and it sounds like you're making some good changes. But frankly, all my goodwill was burnt up in the days I spent trying to make LangChain work, and the number of posts I've seen like this one make it clear I'm not the only one. The changes you've made might be awesome, but it also means NEW abstractions to learn, and "fool me once..." comes to mind. But if you're s…

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)

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

Re: Why we no longer use LangChain for building our AI agents

#240
post #236

Earlier quoted context omitted.

[deleted]

I also have my criticisms of LangChain, but this feels mean-spirited towards devs that I think are honestly trying and didn't charge anything to use.

the road to hell is paved with engineers honestly trying
Post reply on HN