Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

211–220 of 307 posts

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

#211

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 sure it's in a much better place now, then for marketing purposes you might be better off relaunching as LangChain2, intentionally distancing the project from earlier versions.

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

#212
Here's a real world example of a custom RAG pipeline built with Langchain

https://zackproser.com/chat

I did a full tutorial with source code that's linked at the top of that page ^

Fwiw I think it's a good idea to build with and without Langchain for deeper understanding.

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

#214
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 wish I was this pragmatic as an intern.

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

#215
post #135

Earlier quoted context omitted.

People call the first actually useful thing the first thing, that's not surprising or wrong.

That statement is patently incorrect. While the 'usefulness' of something can be subjective, the date of creation is an absolute, immutable fact.

It's like arguing over who invented the light bulb or the personal computer. Answers other than "Edison" and "Wozniak", while very possibly more correct than either, will lead to an hours-long argument that changes exactly 0 minds.

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

#216

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…

Have you considered LiteLLM?

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

#217

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 basic conditional statements like switch/if, already built into languages.

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

#218
post #68

Langchain was released in October 2022. ChatGPT was released in November 2022. Langchain was before chat models were invented. It let us turn these one-shot APIs into Markov chains. ChatGPT came in and made us realize we didn't want Markov chains; a conversational structure worked just as well. After ChatGPT and GPT 3.5, there were no more non-chat models in the LLM world. Chat models worked great for everything, inc…

Chat GPT is just GPT version 3.5. OpenAI released many other versions of GPT before that. In fact, Open AI became really popular around the time of the GPT 2 which was a fairly good chat model. Also, the Transformer architecture was not created by OpenAI so LLMs were a thing way before OpenAI existed :)

The point isn't the models but the structure. Let's say you wanted AI to compare Phone 1 and Phone 2.

GPT-3 was originally a completion model. Meaning you'd say something like

    Here are the specifications of 3 different phones: (dump specs here)

    Here is a summary.

    Phone 0
    pros: cheap, tough, long battery life.
    cons: ugly, low resolution.

    Phone 1
    pros:
And then GPT would fill it out. Phone 0 didn't matter, it was just there to get GPT in the mood.

Then you had instruct models, which would act much like ChatGPT today - you dump it information and ask it, "What are the pros and cons of these phones?" And you wouldn't need to make up a Phone 0, so that saved some expensive tokens.

But the problem with these is you did a thing and it was done. Let's say you wanted to do something else with this information.

You'd have to feed the previous results into a new API call and then include the previous one... but you might only want the better phone's result and exclude the other. Langchain was great at this. It kept everything neatly together so you could see what you were doing.

But today, with chat models, you wouldn't need it. You'd just follow up the first question with another question. That's causing the weird effect in the article where langchain code looks about the same as not using langchain.

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

#219

Langchain reminds me of GraphQL. A technology that a lot of ppl seem to hype about, sounds like something you should use because all the cool kids use it, but at the end of the day just makes things unncessarily complicated.

GraphQL actually holds value in my view as it gives custom SQL-like functionality instead of basic JSON APIs. With it, you can do fewer calls and retrieve only the attributes you need. Granted, if SQL were directly an API, then GraphQL wouldn't hold too much value. Langchain has no such benefit.

[deleted]

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

#220
post #211

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…

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 understand them to decide for myself if they're optimal or not.

React has an abstraction. Svelte has something different. AlpineJS, another. Vanilla JS has none. Does that mean only one is right and the remaining are wrong?

I'd just understand them and pick what seems right for my usecase.

Post reply on HN