Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

71–80 of 307 posts

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

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

It was the first pass at solving the common problems when building with LLMs. People jumped on it because it was trendy and popular. But it quickly became obvious that LangChain would be better named LangSpaghetti. That’s nothing against the authors. What are the chances the first attempt at solving a problem is successful? They should be commended for shipping quickly and raising money on top of it to keep iterating…

Doesn't langchain provide useful functionality when it comes to RAG? Here it seems it does considerably more but being a mere shim abstraction?

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

#72

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

Very much depends on the framework. I'm currently building a GitHub App with the Probot framework, which mostly just handles authentication boilerplate and some testing niceties, then just gives you an authenticated GitHub API client (no facade/abstraction). Then of course there's the many web application frameworks, because nobody in their right mind would want to implement http request parsing themselves (outside o…

Reread the thread and the comment. It's about the LLM frameworks and acknowledges that most non LLM frameworks historically are helpful and correct in abstracting away details.

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

#73
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 tha…

> to fetishize certain design patterns

Yes; exactly. There's value in a Schelling Point[0], and in a pattern language[1].

> requires literally none

True, yes. There isn't infinite value in these things, and "duplication is far cheaper than the wrong abstraction"[2], but they can't be avoided; they occupy local maxima.

0. https://en.wikipedia.org/wiki/Focal_point_(game_theory)

1. https://en.wikipedia.org/wiki/Pattern_language

2. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

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

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

It was the first pass at solving the common problems when building with LLMs. People jumped on it because it was trendy and popular. But it quickly became obvious that LangChain would be better named LangSpaghetti. That’s nothing against the authors. What are the chances the first attempt at solving a problem is successful? They should be commended for shipping quickly and raising money on top of it to keep iterating…

Good thing they didn't raise money to develop this piece of crap.

https://blog.langchain.dev/announcing-our-10m-seed-round-led...

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

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

I think it was great at first when llms were new and prompting required more strategy. Now the amount of of abstractions/ bloat they have for essentially string wrappers makes no sense

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

#77
post #67

Earlier quoted context omitted.

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%…

> Google's was 100% designed by a committee of people who had never seen anyone else's API Google made their API before the others had one, since they were the first with making these kind of language models. Its just that it has been an internal API before.

No.

That'd be a good explanation, but it's theoretical.

In practice:

A) there was no meaningful internal LLM API pre-ChatGPT. All this AI stuff was under lock and key until Nov 2022, then it was an emergency.

B) the bits we're discussing are OpenAI-specific concepts that could only have occurred after OpenAI's.

The API includes chat messages organized with roles, an OpenAI concept, and "tools", an OpenAI concept, both of which came well after the GPT API.

Initial API announcement here: https://developers.googleblog.com/en/palm-api-makersuite-an-...

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

#78
post #54

Earlier quoted context omitted.

Can you elaborate?

What GP means is it is a Programmable Interface, any interface you can interact against is an API. That means any programing complete language is an API, so are sign languages or human languages. While nobody does it , SQL implementations have network API, authentication, authorization, ACL/RBAC, serialization, Business logic all the things you use in RESTful apis can all be done with just db servers. You can expose…

SQL (as an API) and databases are orthogonal, though. In fact, I work on an application that uses SQL for its API even though it doesn't even have a database directly attached. All of its data comes from third-parties that only make the data available using REST services.

In theory, the app servers that sit in front of those databases could just as easily use SQL instead of GraphQL. Even practically: The libraries around working with SQL in this way have become quite good. But they solve different problems. If you have a problem GraphQL is well suited to solve, SQL will not be a suitable replacement – and vice versa.

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

#80

Earlier quoted context omitted.

It was the first pass at solving the common problems when building with LLMs. People jumped on it because it was trendy and popular. But it quickly became obvious that LangChain would be better named LangSpaghetti. That’s nothing against the authors. What are the chances the first attempt at solving a problem is successful? They should be commended for shipping quickly and raising money on top of it to keep iterating…

Doesn't langchain provide useful functionality when it comes to RAG? Here it seems it does considerably more but being a mere shim abstraction?

Not really. It's pretty much the same for RAG as it is for everything else - just a thin additional abstraction on top of apis that are easy to call on their own.
Post reply on HN