Which way in matters most to you?
by•
OpenFlowKit 2 has five ways to make a diagram: draw it, write it as code (or paste Mermaid, D2, Structurizr), ask any AI model or a local one, let Claude Code edit it over MCP, or map a GitHub repo with every arrow cited to a file and line.
If you could only keep one, which would it be, and what's missing from it? This decides what I build next.
59 views
Replies
I think the Claude Code integration through MCP is the technical advantage. Using Mermaid syntax to generate diagrams is common, for many people but directly controlling the state with an external client cuts out the slow step of parsing. The only thing missing now is more detailed permission scoping.
@sundas_tariq Thanks! Agreed on scoping. What would you want first: read-only agents, limiting edits to certain parts of the diagram, or approving changes before they land?
The GitHub repo mapping is pretty interesting. Having each arrow point back to the actual code would save a lot of digging around.
@xiang_pan12 That’s the goal: check the diagram instead of trusting it. Would love to hear how it does on a repo you know well.
I usually end up moving things around after generating a diagram anyway, so being able to fix the layout quickly would be useful.
@haozhe_li Same here, honestly. What usually bugs you most: overlapping nodes, messy arrows, or grouping things the way you think about them?
The local model option would be useful for private projects. I wouldn't always want to send internal architecture details to an external model.
@qinuo_yang Exactly why it’s there. Diagrams stay local-first in your browser, and with a local model your architecture never leaves your machine. What do you run locally, Ollama or LM Studio? I’d love to know how it holds up on a real internal project.
Nice take! I've been through this when a diagram looked right but it was already describing an older version of the system, which is worse than not having one because everyone trusts it. What I ended up doing was keeping architecture changes small and forcing a second pass that points each important decision back to the code or a test. It makes the flow a bit slower, and I’m actually divided on how much layout should be automated, but the review becomes much less guesswork. How do you decide when a proposed change is trustworthy enough to land?