Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

31–40 of 307 posts

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

#31

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.

SQL has sophisticated WHERE clause support, GraphQL doesn't. It should be called GraphPickL.

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

#32

I've seen a lot of stuff recently about how LangChain and other frameworks for AI/LLM are terrible and we shouldn't use them and I can't help but think that people are missing the point. If you need strong customization or flexibility frameworks of any kind are almost always the wrong choice, whether you're building a website or an AI agent. That's kind of the whole point of a framework. Opinionated workflows that en…

I think that yes, there is a better way. You have a function that calls the API, then take the output and call another function that calls the API, inserting the first output into the second one's prompt using an f-string or whatever. You can have a helper function that has defaults for model params or something.

You don't need an abstraction at all really. Inserting the previous output into the new prompt is one line of code, and calling the API is another line of code.

If you really feel like you need to abstract that then you can make an additional helper function. But often you want to do different things at each stage so that doesn't really help.

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

#33
LangChain itself blows my mind as one of the most useless libraries to exist. I hope this does not come off the wrong way but so many people told me they were using it so it was easy to move been models. I just did not understand it, these are simple API calls that felt like Web Dev 101 when starting a new product. Maybe its that so many new people were coming into the field using LLM but it surprised me as even what I thought were experienced people were struggling. Its like LLMs brought out the confusion in people.

It was interesting as a library at the very beginning to see how people were thinking about patterns but pretty useless in production.

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

#34
post #33

LangChain itself blows my mind as one of the most useless libraries to exist. I hope this does not come off the wrong way but so many people told me they were using it so it was easy to move been models. I just did not understand it, these are simple API calls that felt like Web Dev 101 when starting a new product. Maybe its that so many new people were coming into the field using LLM but it surprised me as even what…

Ah, the halcyon days of March 2023, we were a while loop away from AGI. I remember there was something that was It for like a month, to the point that whoever built the framework was treating a cocktail napkin on which they scribbled, whatever, "act, evaluate, decide next action, repeat", as if it was a historical talisman. And I wasn't sure! Maybe it was!

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

#35

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.

> if SQL were directly an API

Isn't that what SQL/CLI is for? https://publications.opengroup.org/c451

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

#36
post #8

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

It's also used to mean "characters interacting with each other" and sort of message passing between them. Not sure but I get the sense thats what the author is using it as

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

#37
post #25

Has anyone else found a good way to swap out models between companies, Langchain has made it very easy for us to swap between openai/anthropic etc

The point is that you don’t need a framework for that; the APIs are already similar enough that it should be obvious how to abstract over them using whatever approach is natural in your programming language of choice.

I have a consumer app that swaps between the 5 bigs and wholeheartedly agree, except, God help you if you're doing Gemini. I somewhat regret hacking it into the same concepts as everyone else.

I should have built stronger separation boundaries with more general abstractions. It works fine, I haven't had any critical bugs / mistakes, but it's really nasty once you get to the actual JSON you'll send.

Google's was 100% designed by a committee of people who had never seen anyone else's API, and if they had, they would have dismissed it via NIH. (disclaimer: ex-Googler, no direct knowledge)

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

#38
post #33

LangChain itself blows my mind as one of the most useless libraries to exist. I hope this does not come off the wrong way but so many people told me they were using it so it was easy to move been models. I just did not understand it, these are simple API calls that felt like Web Dev 101 when starting a new product. Maybe its that so many new people were coming into the field using LLM but it surprised me as even what…

Every time I approached LangChain, contrary to the attitude of my colleagues, I could never figure out what the point of it was other than to fetishize certain design patterns. Interacting with an LLM in a useful way requires literally none of what LangChain has to offer, yet for a time it was on its way to being the de facto way to do anything with LLMs. It reminds me a lot of the false promise of ORMs, which is that if you trust the patterns then you can swap out the underlying engine and everything will still just work, and is more or less a fantasy.

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

#39
I really like the idea of "good" and "bad" abstractions. I have absolutely built both.

This sentiment is echoed in this comment in reddit comment as well: https://www.reddit.com/r/LocalLLaMA/comments/1d4p1t6/comment....

Similarly to this post, I think that the "good" abstractions handle application logic (telemetry, state management, common complexity), and the "bad" abstractions make things abstract away tasks that you really need insight into.

This has been a big part of our philosophy on Burr (https://github.com/dagworks-inc/burr), and basically everything we build -- we never want to tell how people should interact with LLMs, rather solve the common problems. Still learning about what makes a good/bad abstraction in this space -- people really quickly reach for something like langchain then get sick of abstractions right after that and build their own stuff.

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

#40

Idk, dude spends the post whining about writing multi agent architecture and doesn’t mention langgraph once. Reads like a lead who failed to read the docs.

LangGraph is the primary reason I use LangChain - being able to express my flow as a state machine has been a boon to both the design of my platform as well as my own productivity.
Post reply on HN