Starting this year, I’ve decided to stay away from LangChain completely. This isn’t just following the trend of criticism, but based on real problems my team faced.
We built a proof of concept that worked great. Management loved it and wanted it in production. That’s when the nightmare began.
The main issue is complexity. Simple tasks require digging deep into the source code. You have to understand the internal workings just to create basic custom classes. This defeats the purpose of using a helper library.
Debugging became a huge pain. It’s hard to figure out which parts are causing issues. The documentation doesn’t help much when things break.
Version updates are another headache. Even minor updates break existing functionality. We had to create separate services for different LangChain versions. Now we manage multiple services instead of one clean solution.
I know this might upset some people, but I’m sharing our actual experience.
For anyone looking for better options, we now use several focused libraries. The openai package handles most operations well. For structured responses, outlines-dev and instructor work great. guidance-ai is perfect for quick LLM integrations. For vector databases, we use the native database libraries directly since switching between databases is rare.
Langchain’s been overengineered since day one. We dropped it early - plain API calls beat all those abstraction layers. You’re right about teams getting stuck maintaining the framework instead of shipping features. Instructor’s way cleaner than Langchain’s structured output nightmare.
Been there with LangChain’s frustrations, but I took a different route. We still use it, just very selectively - only the parts that actually save us time. Those breaking changes are brutal. We learned to pin exact versions and test everything before updates. Game changer was wrapping LangChain components in our own abstraction layer. When stuff breaks (and it will), we just fix the wrapper instead of refactoring everything. Your focused libraries approach is smart for new projects. We’re slowly moving that direction too, but legacy code makes switching everything a nightmare. Going direct with the openai package definitely gives you way more control when debugging. One more thing - the complexity gets worse as your needs get more specific. LangChain tries to do everything, so you end up with tons of unused abstractions bloating your dependencies.
The complexity issue you mentioned hits home. I’ve watched teams burn months trying to get LangChain working in production.
Skip the heavyweight frameworks. Go with automation platforms instead. When we needed LLM workflows, I built everything using visual automation tools.
That debugging nightmare? Gone when you can see your entire flow visually. Each step’s clear. No digging through source code to find what’s broken.
Version management becomes simple. No package dependencies or breaking changes - just stable platform updates that don’t wreck your existing workflows.
I built our entire LLM pipeline this way. OpenAI integration, data processing, response handling - everything connected visually. Takes 30 minutes to set up what’d take days with traditional coding.
Best part? Anyone on the team can understand and modify the flows. No getting stuck when whoever wrote the LangChain code isn’t around.
For your use case, replace all those separate libraries with one unified automation approach. Connect OpenAI directly, handle structured responses with simple data transformations, integrate vector databases without wrestling multiple SDKs.
Check out Latenode for this setup: https://latenode.com
Surprised more people aren’t talking about this. We did the exact same thing last month after wasting six weeks on a deployment that should’ve taken days. Testing was what killed it for us. You can’t unit test when everything’s buried in nested abstractions. Mock objects break constantly because LangChain keeps changing internal interfaces. Our integration tests took forever and failed randomly. Memory usage is another issue nobody talks about. LangChain loads way more dependencies than you need. Our Docker images were huge compared to targeted libraries. We’re getting much better results with openai package plus focused tools. Development speed improved dramatically once we stopped fighting the framework. New team members understand our codebase in hours instead of weeks. One addition to your library list - tiktoken for token counting if you need precise API cost control. Way more reliable than LangChain’s token estimation.