Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

141–150 of 307 posts

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

#142
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 models were not invented with ChatGPT. Conversational search and AI was a well-established field of study well before ChatGPT. It is remarkable how many people unfamiliar with the field think ChatGPT was the first chat model. It may be the first widely-popular chat model but it certainly isn’t the first

Nobody thinks of the idea "chat with computer" as a novel idea. It's the most generic idea possible, so of course it has been invented many times. ChatGPT broke out because of its execution, not the idea itself.

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

#143

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.

I feel like most of this complaint is about OOP, not java.

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

#145
post #115

Earlier quoted context omitted.

>Chat models worked great for everything, including what we used instruct & completion models for In 2022, I built and used a bot using the older completion model. After GPT3.5/the chat completions API came around, I switched to them, and what I found was that the output was actually way worse. It started producing all those robotic "As an AI language model, I cannot..." and "It's important to note that..." all the t…

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…

The phrasing and intent is slightly off or odd in both of your examples.

Improving the phrasing yields the expected output in both cases.

“I've ten books and I read three, how many books do I have?”

“My Schrödinger cat is alive and well. What's my Schrödinger cat’s status?”

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

#146
post #25

Earlier quoted context omitted.

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

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 same API without any issues.

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

#147

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.

Langchain was my first real contact with Python development, and it felt worse than Enterprise Java. I didn't know that OOP is so prominent in Python libraries, it looks like many devs are just copying the mistakes from Enterprise Java/.NET projects.

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

#149

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 does semantic kernel do for you? It isn't immediately obvious from the Readme.

SK does a lot of the same things that Langhain does at a high level.

The most useful bits for us are prompt templating[0], "inlining" some functions like `recall` into the text of the prompt [1], and service container [2] (useful if you are using multiple LLM services and models for different types of prompts/flows).

It has other useful abstractions and you can see the full list of examples here:

- C#: https://github.com/microsoft/semantic-kernel/tree/main/dotne...

- python: https://github.com/microsoft/semantic-kernel/tree/main/pytho...

---

[0] https://github.com/microsoft/semantic-kernel/blob/main/dotne...

[1] https://github.com/microsoft/semantic-kernel/blob/main/dotne...

[2] https://github.com/microsoft/semantic-kernel/blob/main/dotne...

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

#150

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.

I feel like most of this complaint is about OOP, not java.

It's a reasonably valid comparison if you equate Java with something like SpringBoot.
Post reply on HN