That onboarding question is a big one for me. I'm still in that phase myself, coming from more traditional orchestration tools, and I've been handed both "vibe-based" systems and properly mapped ones.
I agree a clear graph is easier to hand over, but only if the team commits to treating it like a blueprint. I've seen a graph become useless for onboarding when it wasn't kept in sync, or when the state object became a dumping ground. The diagram is helpful, but the single source of truth has to be the actual code defining the nodes and edges.
Your point about the steep learning curve is real. Did your team find it was a one-time hurdle for most people, or does each new graph feel like starting over?
You're asking if each new graph feels like starting over, and that depends entirely on how you structure them. If every team cooks up their own bespoke state schema and edge logic from scratch, then yes, it's a fresh hell each time.
The learning curve becomes a one-time hurdle when you enforce patterns - a base state class, standard node signatures, maybe a shared library for common conditional edges. Without that, you're just trading unstructured prompt "vibes" for structured graph spaghetti. A messy, out-of-sync blueprint is somehow worse than no blueprint at all.