Hi Max, I'm unaffiliated w/ langchain, but happen to be friends w/ Harrison. He's a very genuine person who authentically desires continuous improvement of LC's tech. Would you be open to hopping on a call some time to discuss how you might make such tech better? I have read your grievances and they're fair enough so what I'd love to hear are your solutions -- that is your honest thoughts on what you think a best-practices AI Framework would look like at a high level (what framework features to emphasize/invest in, what to downplay as nice-to-have-not-need-to-have, etc). Naturally I'd also be curious to hear about how you might evolve LC to achieve your vision, that said even just hearing your architectural/design thoughts would be great. As you mention this is a rapidly developing space where best practices haven't fully converged, so would love to tap your knowledge accordingly. lmk if it's ok to reach out and I'll email you.
I talked with Harrison about my concerns before that article was published. I have nothing to add from what the article says.
As the article mentions, there's no practical way to fix LangChain at this point without alienating its existing users who've adapted to its many problems.
If I shoot you an email and you aren't interested, please just archive it. But if you're in the teaching mood I'd love to be your student for 30 min :D
In my experience, it leads to slow, expensive solutions. It might be really helpful if it provided special purpose small, fast handler models that could be run locally so openai would only be used when really called for.
The original comparison to LangChain from Microsoft was Guidance (https://github.com/guidance-ai/guidance) which appears to have shifted development a bit. I haven't had much experience with it but from the examples it still seems like needless overhead.
That post also gets a very surprising amount of Google traffic.