[HN Gopher] We chose LangGraph to build our coding agent
___________________________________________________________________
We chose LangGraph to build our coding agent
Author : jimminyx
Score : 72 points
Date : 2025-03-25 05:50 UTC (17 hours ago)
(HTM) web link (www.qodo.ai)
(TXT) w3m dump (www.qodo.ai)
| AIrtemis wrote:
| I read the article but have yet to understand why someone would
| want to use a framework that introduces meaningless abstractions
| that are not properly documented or well maintained -aka, they
| often introduce breaking changes.
|
| I'm interested in a useful agentic framework but LangGraph
| doesn't seem to cut it.
| four_fifths wrote:
| fully agree that LangChain is a meaningless abstraction but
| I've found that the graph abstraction that LangGraph uses is a
| very useful mental model for thinking about an agentic flow
| MauiWarrior wrote:
| Would you use different framework?
| leopoldj wrote:
| For what LangChain does, most of the time I see no need for
| any framework. I would rather directly work with a vendor's
| official package. LangGraph is different. It is a legitimate
| piece of workflow software and not a wrapper framework. Now,
| when it comes to workflow there are many other well
| established engines out there that I will consider first.
| raverbashing wrote:
| Pretty much this
|
| Not to mention most of those frameworks were almost vibecoded.
|
| They offer very little on top of what you could do it yourself
|
| But of course some people think "if it exists we need to use
| it"
| jeffspinny wrote:
| I think the main thing LangGraph adds is a state machine
| framework for human in the loop with time travel.
|
| So if you have an authoring workflow where a doc goes through a
| bunch of steps, and at some steps the analyst might want to fix
| some LLM output manually, and try a couple of things and then
| go back to the way it was before and try again, it will do that
| and you won't have to make your own state machine.
| datadrivenangel wrote:
| Now is it actually a state machine or is it just well logged?
| nfcampos wrote:
| LangGraph implements a variant of the Pregel/BSP algorithm
| for orchestrating workflows with cycles (ie. not DAGs) and
| parallelism without data races. You can design your graph
| as a state machine if you so desire
| scosman wrote:
| Agreed if you are building a typical service. The abstractions
| will slow you down and don't and anything.
|
| The use case where they are helpful is "bring your own keys"
| apps. I maintain https://github.com/kiln-ai/kiln which allows
| you to bring keys for 13 different providers. The abstraction
| is very much worth it for me.
|
| That said:
|
| - I migrated from LangChain to LiteLLM and never looked back
|
| - I have over 1000 automated integration tests that check the
| grid of LLM features (tools, json), model, and provider.
| Without them it would still be a mess.
| teoruiz wrote:
| I found that the PydanticAI [0] framework strikes a perfect
| balance between control and abstraction.
|
| I'm building a non trivial AI app and the validation and
| dependency injection is such a great addition compared to using
| the LLM libraries directly.
|
| [0] https://ai.pydantic.dev/
| esafak wrote:
| They recently added MCP support: https://ai.pydantic.dev/mcp/
|
| Have you tried it?
| teoruiz wrote:
| Not yet! Really looking forward to it. Their development pace
| is hard to keep up with.
| chandureddyvari wrote:
| Thanks just discovered https://ai.pydantic.dev/graph/
|
| from the above link, which seems to use FSMs instead of DAGs.
| andy_xor_andrew wrote:
| Thanks, this looks great. I've been playing with Huggingface's
| Smolagents, which is fun to tinker with and relatively easy to
| read through. But it is so tightly coupled to its two agent
| implementations - ToolAgent and CodeAgent - that it's not
| trivial at all to add your own state transformations.
|
| This framework looks really well designed, I'm going to take it
| for a spin.
| diego898 wrote:
| The one thing I wish was better developed is persistence and
| streaming - they give sample code to stream, but it's
| essentially a complete implementation of streaming that every
| client needs to implement.
| TimPC wrote:
| One thing that's nice in LangGraph is the flexibility in what a
| node is. A node doesn't have to be an agent it can be any State
| manipulation function. So you can create nodes that exclusively
| do preprocessing or postprocessing and get your run loop as close
| as possible to just ainvoke on your graph repeatedly.
|
| You can have a subclass of your Node class be an AgentNode class
| and then subclass that for each type of Agent and then when you
| declare your Graph object you pass in the data to instantiate the
| AgentNode with the type of data it needs. It is a bit weird that
| LangGraph doesn't have a default Node class but it sort of makes
| sense that they want you to write it in a way that makes sense
| for how you use it.
|
| I do highly recommend abstracting your graph into Node and Edge
| classes (with appropriate subclasses) and being able to declare
| your graph in a constant that you can pass to a build_graph
| method. Getting as much code reuse as possible dramatically
| simplifies debugging graph issuses.
| mendeza wrote:
| How can one deploy LangGraph as an API (with production like
| features)? I have worked with langgraph serve to deploy locally,
| but are there other frameworks to deploy langgraph?
| mns06 wrote:
| You can check out https://github.com/JoshuaC215/agent-service-
| toolkit for a pretty comprehensive template for deploying a
| langgraph service, with a streamlit UI as an example client
| astralagent wrote:
| What are the benefits of these frameworks(Langgraph, Llamaindex)
| over a dedicated orchestration platform like Temporal (or DBOS as
| a lightweight alternative)?
___________________________________________________________________
(page generated 2025-03-25 23:03 UTC)