Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

251–260 of 307 posts

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

#251
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…

impressive to decide against something as shiny as langchain as intern

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

#252
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.

This is fun and interesting:

https://developers.cloudflare.com/workers-ai/tutorials/build...

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

#253
post #100

I built my first commercial LLM agent back in October/November last year. As a newcomer to the LLM space, every tutorial and youtube video was about using LangChain. But something about the project had that "bad code" smell about it. I was fortunate in that the person I was building the project for was able to introduce me to a few other people more experienced with the entire nascent LLM agent field and both of them…

I tried to use Langchain a couple times, but every time I did, I kept feeling like there was an incredible amount of abstraction and paradigms that were completely unnecessary for what I was doing.

I ended up calling the model myself and extracting things using a flexible json parser, I ended up doing what I needed with about 80 lines of code.

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

#254

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…

LangChain had a time and place. That was Spring of 2023, when everyone was figuring out how to string together llm calls with function calls.

We've figured that out, and the answer (like usual) is just K.I.S.S., not LangChain.

It seems even the LangChain folks are abandoning it. Good on you, you will most likely succeed if you do.

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

#255

I don't like langchain that much either. It's not as bad as LLAmaIndex and Haystack in regards to extreme overengineering and overabstracting but it still is bad. The reason I still use Langchain is that often times I need to be able to swap out LLM service providers, embedding models and so on for clients. Thats really the only part about langchain that really works well. Btw. you don't have to actually chain langch…

(jerry here from llamaindex)

wait do you have specific examples of "overengineering and overabstracting" from llamaindex? very open to feedback and suggestions on improvement - we've spent a lot of work making sure everything is customizable

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

#256
post #100

I built my first commercial LLM agent back in October/November last year. As a newcomer to the LLM space, every tutorial and youtube video was about using LangChain. But something about the project had that "bad code" smell about it. I was fortunate in that the person I was building the project for was able to introduce me to a few other people more experienced with the entire nascent LLM agent field and both of them…

This is their game. Infiltrate HN, X, YouTube, Google with “tutorials” and “case studies”. Basically re-target engineers until they’ve seen your name again and again. Then, they sell.

Langchain, Pinecone, it’s all the same playbook.

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

#257

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.

Is that really it?

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

#258
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've had the same experience. I thought I was the weird one, but, my god, LangChain isn't usable beyond demos. It feels like even proper logging is pushing it beyond it's capabilities.

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

#259
post #146

Earlier quoted context omitted.

Would recommend just picking up a gateway that you can deploy and act as an OpenAI compatible endpoint. We built something like this for ourselves here -> https://www.npmjs.com/package/@kluai/gateway?activeTab=readm... . Documentation is a bit sparse but TL;DR - deploy it in a cloudflare worker and now you can access about 15 providers (the one that matter - OpenAI, Cohere, Azure, Bedrock, Gemini, etc) all with the s…

Wow; this is really nice work, I wish you deep success.

Coming back to write something more full-throated: Klu.ai is a rare thing in the LLM space, well-thought out, has the ancillary tools you need, is beautiful, and isn't a giveaway from a BigCo that is a privacy nightmare: ex. Cloudflare has some sort of halfway similar nonsense that, in all seriousness, logs all inputs/outputs.

I haven't tried it out in code, it's too late for me and I'm doing native apps, but I can tell you this is a significant step up in the space.

Even if you don't use multiple LLMs yet, and your integration is working swell right now, you will someday. These will be commodities, valuable commodities, but commodities. It's better to get ahead of it now.

Ex. If you were using GPT-4 2 months ago, you'd be disappointed by GPT-4o, and it'd be an obvious financial and quality decision to at least _try_ Claude 3.5 Sonnet.

It's a weird one. Benchmarks great. Not bad. Pretty damn good. But ex. It's now the only provider I have to worry about for RAG. Prompt says "don't add footnotes, pause at the end silently, and I will provide citations", and GPT-4o does nonsense like saying "I am now pausing silently for citations: markdown formatted divider"

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

#260
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…

On top of that, if you use the TypeScript version, the abstractions are often... weird. They feel like verbatim ports of the Python implementations. Many things are abstracted in ways that are not very type-safe and you'd design differently with type safety in mind. Some classes feel like they only exist to provide some structure in a language without type safety (Python) and wouldn't really need to exist with structural type checking.
Post reply on HN