Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

261–270 of 307 posts

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

#261
post #209

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.

It's funny because I was using Langchain recently and found the most confusing part to be the inheritance model and what type was meant to fill which function in the chain. Using Java would make it impossible to mistype an object even while coding. I constantly wonder why the hell the industry decided Python was suitable for this kind of work.

Reasons for using Python: it is easier to find code on github for reuse and tweaking, most novel research publishes in PyTorch, there is a significant network effect if you follow cutting edge.

Second reason - to fail fast. No sense in sculpting novel ideas in C++ while you can muddle with Python 3x faster, that's code intended to be used just a few times, on a single computer or cluster. That was an era dominated by research, not deployments.

Llama.cpp was only possible after the neural architecture stabilized and they could focus on a narrow subset of basic functions needed by LLMs for inference.

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

#262
FWIW I think LangChain has evolved a lot and is a nice time saver once you figure out the patterns it uses. The LangSmith observability is frankly fantastic to quickly get a sense of how your expected LLM flow engineering ends up working out in practice. So much FUD here, unwarranted IMO. Don’t forget, reading code is harder than writing it, doesn’t warrant throwing out the baby with the bath water. Don’t fall for NIH :) Haven’t had issues running in prod recently either since they’ve matured their packaging with core/community/partner etc. For agentic use cases look at LangGraph for a cleaner set of primitives that give you the amount of control needed there.

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

#263
post #220
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…

I don't think the choices made sense even back when they were made. LangChain always looked like an answer in search of a question, a collection of abstractions that don't do much except making a simple thing more complex.

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

#264

Earlier quoted context omitted.

OOP is Java, and Java is OOP, right? My point is to follow a dogmatic OOP approach (think all the nouns like Agent, Prompt, etc.) to model something rather sequential.

Maybe. Developers love to invent new definitions for existing terms all the time, so Java is OOP under one or more of those definitions, but Java is not OOP in the original sense. So, it depends on the definition of OOP arbitrarily chosen today.

The "original sense" argument is frankly nonsense. Simula 67 was the original OOP language, predating Smalltalk, and it already had "classes" and "objects". It also looked a great deal like Java and the OOP parts of C++.

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

#265
post #138

Earlier quoted context omitted.

Sounds like your LLM guy just isn’t very good. Langchain is, when you boil it down, an abstraction over text concatenation, staged calls to open ai, and calls to vector search libraries. Even without standard tooling, an experienced programmer should be able to write an understandable system that does those things.

> Sounds like your LLM guy just isn’t very good. That's the central idea here. Most guys available to hire aren't. Hence why they get constrained into a framework that limits the damage they can cause. In other areas of software development the frameworks are quite mature at this point so it works well enough. This AI/LLM/whatever you want to call it area of development, however, hadn't garnered much interest until r…

LLMs are, at least at present, exactly the kind of thing where trying to use an abstraction without understanding what it actually does is exactly what's going to create a mess in the long run.

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

#266

Earlier quoted context omitted.

OpenAI had a real issue with making (for their time) great models but streching their rollout over months. They gave access to press and some twitter users, everyone else had to apply for their use case only to be put on the waitlist. That completely killed any momentum. The first version of ChatGPT wasn't a huge leap from simulating chat with instruction-tuned GPT 3.5, the real innovation was scaling it to the point…

The main reason ChatGPT took off was: 1) Response time of the API of that quality was 10x quicker than the Davinci-instruct-3 model that was released in summer 2022, making interaction more feasible with lower wait times and with concurrency 2) OpenAI strictly banned chat applications on the GPT API; even summarising with more than 150 tokens required your to submit a use case for review; I built an app around this i…

"Instruct tuning was far more impactful than conversational model tuning because instruct enabled so many synthesizing use cases beyond the training data."

I saw many model providers nowadays provide instruct model in name as chat model. What difference between instruct tuning and conversational model tuning specifically?

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

#267

Earlier quoted context omitted.

I was curious whether you were using "API" as shorthand for something like "HTTP API" or something like that. It seeemed odd for you to say "Granted, if SQL were directly an API, then GraphQL wouldn't hold too much value" when you actually can use SQL directly in this sense. The reasons that people generally don't are interesting in their own right. (If I recall - one of the criticisms of GraphQL is that it's a bit t…

You can implement a GraphQL service in anyway you desire. There is no inherent relation to the storage solution you use. GraphQL isn't anywhere close to being similar to SQL, so I find the desire for an analogy very confusing. To me, these are grammars for interacting with an API, not an API. To me, it is like calling a set of search parameters in a URL an API or describing some random function call as an API. The in…

What is your definition of API?

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

#268
post #23
post #10

My reading of the article is that because LangChain is abstracted poorly, frameworks should not be used, but that seems a bit far. my experience is that Python has a frustrating developer experience for production services. So I would prefer a framework with better abstractions and a solid production language (performance and safety), over no framework and Python (if those were options)

prompt engineering requires the ability to see what is happening at various steps and langchain makes that harder if not impossible. honestly I don't need that much abstraction.

I think this is another crucial part. Right now, writing prompts is kinda like writing hand-crafted assembly back in the day where that was routine because there was simply no other way to get good results out of hardware in many cases - but also because the tasks that are actually doable do not require much code, so it's perfectly feasible to write it in assembly by hand.

LangChain is kinda like taking that state of hardware and bolting on a modern C++ compiler with templates and STL on it.

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

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

Data centric on YouTube has some great videos . https://youtube.com/@data-centric?si=EOdFjXQ4uv02J774

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

#270

Earlier quoted context omitted.

yeah gpt 3.5 just worked. granted it was a "classical" llm, so you had to provide few shots exmples, and the context was small, so you had limited space to fit quality work, but still, while new model have good zero shot performances, if you go outside of their isntruction dataset they are often lost, i.e. gpt4: "I've ten book and I read three, how many book I have?" "You have 7 books left to read. " and gpt4o: "shro…

I disagree about those questions being good examples of GPT4 pitfalls. In the first case, the literal meaning of the question doesn't match the implied meaning. "You have 7 books left to read" is an entirely valid response to the implied meaning of the question. I could imagine a human giving the same response. The response to the Schroedinger's cat question is not as good, but the phrasing of the question is exceedi…

Agree
Post reply on HN