|
|
|
|
|
by alixanderwang
654 days ago
|
|
Hi and congrats on the launch! I run a company that also does software diagrams and we've often been posed the question of generating automated diagrams. We've never done so, primarily because I've never found auto-generated diagrams helpful yet. Code dependency graphs have existed for a generation now and I've just never seen one referenced by anyone. I wonder if things have changed now with LLMs. The examples in your youtube video look good. I'm curious how they're generated. "We were surprised to find that a small fraction of code can generate a very accurate representation of the system." is a surprising statement to me. It's not been my experience that the code can reveal an accurate representation of human-understandable architecture beyond the call graph. The backend system generated from OpenHands (in your video) also looks pretty different from their own architecture diagram in their README: https://github.com/All-Hands-AI/OpenHands/tree/main/openhand... . How do you reconcile what an LLM says an architecture looks like with what maintainers prescribe? Is there a way to give feedback to it? (similar to pthangeda's comment on customization) I wish there was a way to point this at a repo to test its efficacy. Though I understand that that'd be prohibitively expensive to do for free on the landing page. I'm also curious how you guys distinguish yourself from https://docs.codesee.io/docs/review-maps-for-visual-studio-c... . They tried this for a few years but shut down recently (https://www.linkedin.com/posts/shaneak_update-codesee-has-be...) |
|
In terms of generating architecture diagrams, we follow the c4 model, with top level nodes defined as separately deployable units of software, and lower level component nodes being a set of functions wrapped behind a common interface. As the product develops, we'd like to include a way for feedback/fine tuning, but ideally the definition of an architecture diagram would be rigorous enough that there is no ambiguity, this is what we're aiming for. If you'd like to try it out on a specific repo, you can always use our extension for further analysis.
You're right to notice the similarity with CodeSee. Ultimately we're looking to focus on improving the developer experience without needing to leave the IDE. The idea is that CodeViz can replace or augment search and directory tree by providing a more intuitive interface for navigation!