I don't really understand why an engineer would use langraph. If a graph based interface for coding was useful, wouldn't they already be used for regular programming? Regular software functions can be viewed as graphs already, what's new about LLMs that make a graph based UI desired? Maybe for really basic no-code programs for non-programmers?
Langgraph is not a no-code tool for visual programming, it's an implementation of the Pregel algorithm for execution of cyclical computation graphs (ie not DAGs)
Honestly I'm happy to be proven wrong about the usefulness of it.
I've used langsmith and found it quite useful. I think I was just so jaded by my bad experience with Langchain, that I'm immediately skeptical of other "lang" products.
I almost didn't try langgraph because I had similar experiences with langchain. IMO it is a lot better than langchain; its abstractions are lower level and more appropriate at least for the projects I've taken on. I think it's probably the best toolkit with which to prototype an agent-based workflow right now.
That being said, it's not doing that much. And you still end up having to use some of langchain's abstractions. If this current "make a cyclical graph of LLM agents that send messages to each other" thing has any staying power than I imagine we'll see a more robust option soon. Personally I'd love a way to build agent graphs in a strongly typed language with first class concurrency.
Really? Can you point to code for that? To me it's just a way to describe a graph and execute it, exactly like https://github.com/dagworks-inc/burr (I'm an author).
One of the issues with LLMs is that each function needs to be tested and observed more thoroughly than regular functions, which leads to these UIs to figure out what the heck is actually going on.
For our DSL (BAML https://github.com/BoundaryML/baml ) we found that adding a VSCode playground to visualize LLM function inputs and outputs was a massive win in terms of debuggability and testability, so I can see why langraph is going this way.
