Why we no longer use LangChain for building our AI agents
1–10 of 307 posts
Re: Why we no longer use LangChain for building our AI agents
#2Bigger problem might be using agents in the first place.
We did some testing with agents for content generation (e.g. "authoring" agent, "researcher" agent, "editor" agent) and found that it was easier to just write it as 3 sequential prompts with an explicit control loop.
It's easier to debug, monitor, and control the output flow this way.
But we still use Semantic Kernel[0] because the lowest level abstractions that it provides are still very useful in reducing the code that we have to roll ourselves and also makes some parts of the API very flexible. These are things we'd end up writing ourselves anyways so why not just use the framework primitives instead?
Re: Why we no longer use LangChain for building our AI agents
#3I recently unwrapped linktransformer to get access to some intermediate calculations and realized it was a pretty thin wrapper around SentenceTransformer and DBScan. It would have taken me so much longer to get similar results without copying their defaults and IO flow. It’s easy to take for granted code you didn’t have to develop from scratch. It would be interesting if there was a tool that inlined dependency calls and shook out unvisited branches automatically.
Re: Why we no longer use LangChain for building our AI agents
#4Yup. The problem with frameworks is they assume (historically mostly but not always correctly) that layers of abstraction mean one can forget about the layers below. This just doesn't work with LLMs. The systems are closer to biology or something.
Re: Why we no longer use LangChain for building our AI agents
#5I recently unwrapped linktransformer to get access to some intermediate calculations and realized it was a pretty thin wrapper around SentenceTransformer and DBScan. It would have taken me so much longer to get similar results without copying their defaults and IO flow. It’s easy to take for granted code you didn’t have to develop from scratch. It would be interesting if there was a tool that inlined dependency calls…
From memory, I recall Vulture might do something like that!
Re: Why we no longer use LangChain for building our AI agents
#6IMO LangChain provides very high level abstractions that are very useful for prototyping. It allows you to abstract away components while you dig deeper on some parts that will deliver actual value.
But aside from that, I don't think I would run it in production. If something breaks, I feel like we would be in a world of pain to get things back up and running. I am glad they shared their experience on that, this is an interesting data point.
Re: Why we no longer use LangChain for building our AI agents
#7In some sense, this could be retitled "We no longer use training wheels on our bikes"
Re: Why we no longer use LangChain for building our AI agents
#8Bigger problem might be using agents in the first place. We did some testing with agents for content generation (e.g. "authoring" agent, "researcher" agent, "editor" agent) and found that it was easier to just write it as 3 sequential prompts with an explicit control loop. It's easier to debug, monitor, and control the output flow this way. But we still use Semantic Kernel[0] because the lowest level abstractions tha…
What's the difference? I thought "agents" was just a fancier word for sequential prompts.
Re: Why we no longer use LangChain for building our AI agents
#9I just pulled out LangChain from our AI agents; we now have much smaller docker images and the code is a lot easier to understand.
Re: Why we no longer use LangChain for building our AI agents
#10My reading of the article is that because LangChain is abstracted poorly, frameworks should not be used, but that seems a bit far.
my experience is that Python has a frustrating developer experience for production services. So I would prefer a framework with better abstractions and a solid production language (performance and safety), over no framework and Python (if those were options)