I’ve been trying to work with LangChain and LangGraph recently and I’m wondering if anyone else finds these frameworks overly complicated?
Does anyone else feel like these tools are unnecessarily complex? I keep running into issues where writing simple hardcoded solutions seems faster than dealing with all the framework overhead. I know hardcoded stuff isn’t great for maintenance, but with all the breaking changes between LangChain versions (0.1 to 0.2 to 0.3), maintaining code feels difficult either way.
What happened to me:
I wanted to create an automated workflow system. Everyone talks about how agents and LLMs are the future, so I started looking at different options. I checked out various tools like Dify, LangFlow, Flowise, and others, but settled on LangGraph because it’s more code-focused and doesn’t need complex database setups for simple projects.
Since I prefer self-hosted solutions over external API providers (I want to keep my data local), I decided to use llama.cpp which I’ve used before. That’s when my problems started:
The OpenAI-compatible API in llama.cpp has issues with function calling
Jinja template processing has bugs
Tool calls don’t return proper IDs
All I want is to build a workflow system that can do function calling with my local llama.cpp setup, using custom functions that work with my existing projects. Why does this have to be so difficult?
Has anyone found better alternatives or workarounds for these issues?
You’re not imagining it - these frameworks really do overcomplicate simple stuff. I wasted months fighting LangChain’s abstraction layers before I realized I was creating problems that didn’t need to exist. For local function calling, skip the OpenAI compatibility layer completely. Going straight to your model’s native API usually works way better than forcing compatibility through middleware. Those template processing headaches you mentioned? That’s what happens when there are too many translation layers between your code and the model. What worked for me was building a simple wrapper around just the stuff I actually needed instead of importing massive frameworks. I started with basic HTTP requests to my local model, added my own function call parsing, then slowly built up only the features I used. It took roughly the same time as debugging framework issues, but I actually understood what I built. The breaking changes thing is legit too - maintaining my own lightweight code has been way more stable than constantly chasing framework updates.
Honestly, langchain tries to do everything instead of nailing one thing. I’ve had way better luck with simple custom scripts that hit model endpoints directly - less debugging and no nasty surprises when dependencies update.
The real issue isn’t LangChain being complex - it’s using the wrong tool.
I’ve built tons of workflow systems with local LLMs. Everyone keeps trying to force AI frameworks to handle workflow orchestration. That’s backwards.
You need a workflow automation platform that talks to your local models. Skip LangChain’s abstraction layers and llama.cpp headaches.
Set up your local model however you want (Ollama, llama.cpp, whatever). Build your workflow in a proper automation tool that handles orchestration, function calling, errors, and data flow.
Did exactly this for a client last year. Local models for processing, custom Python for business logic, database ops, API calls. Zero framework drama. The workflow engine handles complex stuff while your models just do their job.
You get visual workflow building, proper debugging, reliable execution, and no version nightmares. Plus your data stays local since you control everything.
Been there with the LangChain pain. The framework complexity is real.
Here’s what worked for me after similar headaches: ditch LangChain’s breaking changes and llama.cpp compatibility mess. Build workflows with automation tools that actually work.
For local LLMs, skip the framework overhead entirely. Set up your models (Ollama’s solid), then use a proper automation platform to orchestrate everything. You get visual builders, reliable function calling, proper error handling, and no version nightmares.
Built a similar system last month. Handles document processing, calls multiple local models, runs custom Python functions, integrates with existing APIs. Zero LangChain headaches. Took a weekend instead of weeks debugging framework issues.
Use the right automation tool instead of forcing AI frameworks to manage workflows.
Yeah, llama.cpp’s function calling is completely broken. I switched to vllm - handles tool calls way better than their OpenAI compatibility crap. Still can’t stand how LangChain breaks everything with constant changes. They redesign the whole thing every 6 months.
totally feel you! langchain is a bit of a headache sometimes. i found that sticking to the openai sdk is way easier for quick tasks. also, got better results with ollama for local setups instead of llama.cpp! way less frustration.
Same exact frustrations here with LangGraph and local models. These frameworks expect you’re using cloud APIs where everything magically works. Go local and suddenly all those abstraction layers hurt more than they help. Had the same llama.cpp headaches and completely changed my approach. Don’t bother making LangGraph play nice with those sketchy OpenAI compatibility layers - build direct integration with your local models using their native interfaces instead. Those function calling issues vanish when you’re not translating through three different API layers. For workflow stuff, I treat it as totally separate. Let your local LLM do the AI work, then use proper workflow tools for orchestration. You dodge all the framework complexity but keep everything local like you wanted. Way less maintenance when you’re not constantly fighting framework assumptions that don’t fit your setup.