Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

Post reply on HN
Print view View original

221–230 of 307 posts

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

#221

Post by bestcoder69 »

paraph1n wrote: post #199
sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Could someone point me towards a good resource for learning how to build a RAG app without llangchain or llamaindex? It's hard to find good information.

openai cookbook! Instructor is a decent library that can help with the annoying parts without abstracting the whole api call - see it’s docs for RAG examples.

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

#222

Post by danenania »

w4 wrote: post #200
sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

I had a similar experience when LangChain first came out. I spent a good amount of time trying to use it - including making some contributions to add functionality I needed - but ultimately dropped it. It made my head hurt. Most LLM applications require nothing more than string handling, API calls, loops, and maybe a vector DB if you're doing RAG. You don't need several layers of abstraction and a bucketload of depen…

I haven't used LangChain, but my sense is that much of what it's really helping people with is stream handling and async control flow. While there are libraries that make it easier, I think doing this stuff right in Python can feel like swimming against the current given its history as a primarily synchronous, single-threaded runtime.

I built an agent-based AI coding tool in Go (https://github.com/plandex-ai/plandex) and I've been very happy with that choice. While there's much less of an ecosystem of LLM-related libraries and frameworks, Go's concurrency primitives make it straightforward to implement whatever I need, and I never have to worry about leaky or awkward abstractions.

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

#223

Post by hwchase17 »

causal wrote: post #211
hwchase17 wrote: post #205

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…

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)

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

#224

Post by hwchase17 »

fswd wrote: post #217
hwchase17 wrote: post #205

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…

using LangGraph for a month, every single "graph" was the same single solution. The idea is cool, but it isn't solving the right problem.... (and the problem statement shouldn't be generating buzz on twitter. sorry to be harsh). You could borrow some ideas from DSPy (which borrows from pytorch) their Module: def forward: and chain LM objects this way. LangGraph sounds cool, but is a very fancy and limited version of…

ooc, what was the "same single solution"

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

#225

Post by bestcoder69 »

iknownthing wrote: post #207
captaincaveman wrote: post #158

I think LangChain basically tried to do a land grab, insert itself between developers and LLM's. But it didn't add significant value and seemed to dress it up by adding abstractions that didn't really make sense. It was that abstraction gobbledygook smell that made me cautious.

Looks like they've parlayed it into some kind of business https://www.langchain.com/

They’ve been growth hacking the whole time pretty much, optimizing for virality. Eg integrating with every ai thing under the sun, so they could publish a seo-friendly “use gpt3 with someVecDb and lang chain” page, but for every permutation you can think. Easy for them to write since langchains abstractions are just unnecessary wrappers. They’ve also had meetups since very early on. The design seems to make langchain hard to remove since you’re no longer doing functional composition like you’d do in normal python - you’re combining Chains. You can’t insert your own log statements in between their calls so you have to onboard to langsmith for observability (their saas play). Now they have a DSL with their own binary operators :[

VC-backed, if you couldn’t guess already

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

#226

Post by wnmurphy »

fforflo wrote: post #133

LLM frameworks like LangChain are causing a java-fication or Python . Do you want a banana? You should first create the universe and the jungle and use dependency injection to provide every tree one at a time, then create the monkey that will grab and eat the banana.

I feel this too, I think it's because Java is an artifact of layers of innovation that have accumulated over time, which weren't present at its inception. Langchain is similar, but has been developing even more rapidly than Java did.

I still find LC really useful if you stick to the core abstractions. That tends to minimize the dependency issues.

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

#227

Post by causal »

ctxc wrote: post #220
causal wrote: 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…

They were early to the scene, made the decisions that made sense at each point in time. Initially I (like many other engineers with no AI exposure) didn't know enough to want to play around with the knobs too much. Now I do. So the playing field has and is changing, langChain are adapting. Isn't that a bit too extreme? Goodwill burnt up? When the field changes, there will be new abstractions - of course I'll have to…

You seem to be implying all abstractions are equal, its just use-case dependent. I disagree- some really are worse than others. In your webdev example, it would not be hard to contrive a framework designed to frustrate. This can also happen by accident. Sometimes bad products really do waste time.

In the case of LangChain, I think it was an earnest attempt, but a misguided one. So I'm grateful for LangChain's attempt, and attempts to correct- especially since itis free to use. But there are alternatives that I would rather give a shot first.

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

#228

Post by bastawhiz »

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 out. Some of the things that I tried applying it for:

- Doing a kind of function calling (or at least, implementing the schema validation) for non-gpt models

- parsing out code snippets from responses (and ignoring the rest of the output)

- Having the output of a prompt return as a simple enum without hallucinations

- process a piece of information in multiple steps, like a decision tree, to create structured output about some text (is this a directory listing or a document with content? What category is it? Is it NSFW? What is the reason for it being NSFW?)

Any resources are appreciated

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

#229

Post by bestcoder69 »

elbear wrote: post #84

It would have been great if the article provided a more realistic example. The example they use is indeed more complex than the openai equivalent, but LangChain allows you to use several models from several providers. Also, it's true that the override of the pipe character is unexpected. But it should make sense, if you're familiar with Linux/Unix. And I find it shows more clearly that you are constructing a pipeline…

I can already use multiple backends by writing different code. The value-add langchain would need to prove is whether i can get better results using their abstractions compared to me doing it manually. Every time I’ve looked at how langchain’s prompts are constructed, they went wayyy against LLM vendor guidance so I have doubts.

Also the downside of not being able to easily tweak prompts based on experiments (crucial!)

And not to mention the library doesn’t actually live up to this use case, and you immediately (IME) run into “you actually can’t use a _Chain with provider _ if you want to use their _ API”, so I ultimately did have to care about whats supposed to be abstracted over

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

#230

Post by causal »

hwchase17 wrote: post #223
causal wrote: 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)

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.

Post reply on HN