Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

301–307 of 307 posts

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

#301
post #127

Earlier quoted context omitted.

My understanding is that the original Gmail team actually invented modern LLMs in passing back in 2004, and it’s taken outsiders two decades to catch up because doing so requires setting up the Closure Compiler correctly.

Lol, sounds like you have more experience with other ex/Googlers doing this than I do. I'm honestly surprised, I didn't know there was a whole shell game to be played with "what's an LLM anyway" to justify "whats NIH? our API was designed by experienced experts"

[dead]

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

#302
post #84

It would have been great if the article provided a more realistic example. The example they use is indeed more complex than the openai equivalent, but LangChain allows you to use several models from several providers. Also, it's true that the override of the pipe character is unexpected. But it should make sense, if you're familiar with Linux/Unix. And I find it shows more clearly that you are constructing a pipeline…

I can already use multiple backends by writing different code. The value-add langchain would need to prove is whether i can get better results using their abstractions compared to me doing it manually. Every time I’ve looked at how langchain’s prompts are constructed, they went wayyy against LLM vendor guidance so I have doubts. Also the downside of not being able to easily tweak prompts based on experiments (crucial…

Your comment gives better reasons than the article for not using LangChain.

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

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

> Most guys available to hire aren't

Sounds like your hiring team just isn’t very good.

There are plenty of skilled people working in LLM land

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

#304

Earlier quoted context omitted.

>All this AI stuff was under lock and key until Nov 2022, then it was an emergency. This is absolutely false, as the other person said. As one example: We had already built and were using AI based code completion in production by then. Here's a public blog post from July, 2022: https://research.google/blog/ml-enhanced-code-completion-imp... This is just one easy publicly verifiable example, there are others. (We actu…

Pretending that was an LLM as it is understood today, and that whatever internal API was available for internal use cases is actually the same as the public API for Gemini today, and that it was the same as an API for adding a "chat completion" to a "conversation" with messages, roles, and JSON schemas is silly.

I'm glad you know exactly what happened, what it was capable of, etc, despite not working on it, and not asking a single question of those who did!

This follows right in line with the rest of your approach.

If you want to know things, it works better to ask questions than make assertions about what other people did or didn't do.

Nobody really cares about the opinions of those who can't be bothered to learn.

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

#305
post #303

Earlier quoted context omitted.

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

> Most guys available to hire aren't Sounds like your hiring team just isn’t very good. There are plenty of skilled people working in LLM land

Some hiring teams just don’t operate in unlimited venture capital land and have tight boundaries in terms of compensation. There’s someone good in anything if you can throw enough money at the problem.

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

#306

Earlier quoted context omitted.

> My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part a lot of our effort recently has been going into standardizing model wrappers, including for tool calling, images etc. this will continue to be a huge focus > My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go…

Separating into smaller libraries is a smart move. And yeah, like you said, I might be bearish on the orchestration space, but at least you can insulate it from the rest of your projects. Best of luck to you. I don’t agree with the disparaging tone of the comments here. You executed quickly and that’s the hardest part. I wouldn’t bet against you, as long as you can keep iterating at the same pace that got you over th…

I agree. Adopting a more modular approach is a great idea. Coming from the Java ecosystem, I still miss having something like the Spring framework in Python. I believe Spring remains an example of excellent framework design. Let me explain what I mean.

Using Spring requires adopting Spring IoC, but beyond that, everything is modular. You can choose to use only the abstractions you need, such as ORM, messaging, caching, and so on. At its core, Spring IoC is used to loosely integrate these components. Later on, they introduced Spring Boot and Spring Cloud, which are distributions of various Spring modules, offering an opinionated application programming model that simplifies getting started.

This strategy allows users the flexibility to selectively use the components they need while also providing an opinionated programming model that saves time and effort when starting a new project.

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

#307
I had the same impression after working through the LangChain tutorials. The one thing I'd like to ask about is Observability. LangChain has some tools around observability that seem genuinely useful to me, and specific to working with LLMs. Are there ways to use only these tools, or alternative observability tools you recommend for working with LLMs?
Post reply on HN