The best part about this is that you know the type of people/companies using langchain are likely the type that are not going to patch this in a timely manner.
Langchain is `left-pad` -- a big waste of your time, and Mastra is Next.js -- mostly saving you infrastructure boilerplate if you use it right.
But I think the primary difference is that Python is a very bad language for agent/LLM stuff (e.g. static typesystem, streaming, isomorphic code, strong package management ecosystem is what you want, all of which Python is bad with). And if for some ungodly reason you had to do it in Python, you'd avoid LangChain anyway so you could bolt on strong shim layers to fix Python's shortcomings in a way that won't break when you upgrade packages.
Yes, I know there's LangChain.js. But at that point you might as well use something that isn't a port from Python.
> what would you say indicates a high quality candidate when they are discussing agent harnessing and orchestration?
Anything that shows they understand exactly how data flows through the system (because at some point you're gonna be debugging it). You can even do that with LangChain, but then all you'd be doing is complaining about LangChain.
I literally invoke sglang and vllm in Python. You are supposed to (if not using them over-the-network) use the two fastest inference engines there is via Python.
If we’re going to throw experience around, after 30+ years of coding experience, I really don’t care too much anymore as long as it gets the job done and it doesn’t get in the way.
LangChain is ok, LangGraph et al I try to avoid like the plague as it’s too “framework”-ish and doesn’t compose well with other things.
I guess the difference where I draw the line is that LLMs are inherently random I/O so you have to treat them like UI, or the network, where you really have no idea what garbage is gonna come in and you have to be defensive if you're going to build something complex -- otherwise, you as a programmer will not be able to understand or trust it and you will get hit by Murphy's law when you take off your blinders. (if it's simple or a prototype nobody is counting on, obviously none of this matters)
To me insisting that stochastic inputs be handled in a framework that provides strong typing guarantees is not too different from insisting your untrusted sandbox be written in a memory safe language.
I just don’t follow your logic of “LLMs are inherently random IO” (ok, I can somehow get behind that, but structured output is a thing) -> “you have to treat them like UI / network” (ok, yes, it’s untrusted) -> static typing solves everything (how exactly?)
This just seems like another “static typing is better than dynamic typing” debate which really doesn’t have a lot to do with LLMs.
A lot of these frameworks are lauded, but if they were as good as they claim you would run into them in all sorts of apps. The only agents that i ever end up using are coding agents, i think they're obviously the most popular implementations of agents. Do they use langchain? No, i don't think so. They probably use in house logic cus it's just as easy and gives them more flexibility and less dependencies
LangSmith’s prompt engineering workflow is okay-ish but a lot of work and gets quite expensive quite fast, and only works for a specific set of prompts (ie one-turn prompts, multi-turn never works).
PydanticAI seems more lightweight and gets out of the way.
I found the general premise of the tools (in particular LangGraph) to be solid. I was never in the position to use it (not my current area of work), but had I been I may have suggested building some prototypes with it.
Langchain claimed to be an abstraction on top of LLMs, but in fact, added additional unecessary complexity.
Prompt management was such a buzzword when langchain came out, but 99% of LLM use cases don't need prompt management - GitHub and strings works just fine.
As for "import openai", that's actually somewhat orthogonal, but if what you want is a common API for different providers then there are many options around that do just that. But then again at that point you probably also want something like OpenRouter, which has its own generic API.
class AI(Protocol):
def call_llm(prompt: str) -> str: …
It was so early in the game none of those frame works are ready. What they do under the hood when I looked wasn't a lot. I just wanted some sort of abstraction over the model apis and the ability to use the native api if the abstraction wasn't good enough. I ended up using Spring AI. Its working well for me at the moment. I dipped into the native APIS when I needed a new feature (web search).
Out of all the others Crew AI was my second choice. All of those frameworks seem parasitic. One your on the platform you are locked in. Some were open source but if you wanted to do anything useful you needed an API key and you could see that features were going to be locked behind some sort of payment.
Honestly I think you could get a lot done with one of the CLI's like Claude Code running in a VM.
Overall I felt like it solves a problem doesn't exist, and I've been happily sending direct API calls for years to LLMs without issues.
I think structured output with schema validation mostly replaces the need for complex prompt frameworks. I do look at the LC source from time to time because they do have good prompts backed into the framework.
Even on smallish ~50k datasets error was still very high and interpretation of schema was not particularly good.
The bigger problem is that LangChain/Python is the least set up to take advantage of strong schemas even when you do have it.
Agree about pillaging for prompts though.
OpenAI and Gemini models can handle ridiculously complicated and convoluted schemas, if I needed complicated JSON output I wouldn’t use anything that didn’t guarantee it.
I have pushed Gemini 2.5 Pro further than I thought possible when it comes to ridiculously over complicated (by necessity) structured output.
That was more fun than actually using it.
I've talked to many people who regret building on top of it but they're in too deep.
I think you may come to the same conclusions over time.
> Today, langchain and langgraph have a combined 90M monthly downloads, and 35 percent of the Fortune 500 use our services
What? This seems crazy. Maybe I'm blind, but I don't see the long term billion dollar business op here.
Leftpad also had those stats, iirc.
I built an internal CI chat bot with it like 6 months ago when I was learning. It’s deployed and doing what everyone needs it to do.
Claude Code can do most of what it does without needing anything special. I think that’s the future but I hate the vendor lock in Anthropic is pushing with CC.
All my python tools could be skills, and some folks are doing that now but I don’t need to chase after every shiny thing — otherwise I’d never stop rewriting the damn thing.
Especially since there’s no standardizing yet on plugins/skills/commands/hooks yet.
Accepting any kind of vendor lock in within this space at the moment is an incredibly bad idea. Who knows what will get released next week, let alone the next year. Anthropic might be dead in the water in six months. It's unlikely but not impossible. Expand that to a couple of years and it's not even that unlikely.