WillMcCall

Glad you liked it!

Makes total sense, and sorry to hear about the incident. At the moment, closed source models are the only viable way to generate high quality diagrams. Once that changes, we'd prefer to switch to open source too for many of the reasons you mentioned.

Thanks for the feedback! A fully local stack would give control back to developers, which we would love to do once open source model performance improves. Hoping we can change your mind on the value of navigating and editing code with visual diagrams, it's quite a bit easier!

The call graph doesn't highlight dead code specifically, but unused blocks are manually identifiable through isolated/broken chains. Is this something you'd like to see?

Glad you see the potential! We do have an existing function "call graph" view that uses traditional static analysis methods with LSP calls. Augmenting this view with LLMs seems very promising, and we are very much headed in that direction! Are there use cases you can see this being helpful for?

That makes sense, we'll make this change!

Curious to learn more about the project, what were you working on? We're not hiring at the moment, but let's stay in touch!

Definitely an interesting thought, although we wouldn't be able to support any UI/UX. We could host a separate utility and expose endpoints for UML or markdown though.

This sounds like an ambitious project with a number of interesting technical challenges. It may be some time before the tooling will exist to support your use case, but then again, you can always build custom tooling of your own! It's very interesting to see how with minimal intervention, many of these operations seem very close to being automated. Thanks for sharing!

Thanks for the feedback and resources!

In designing CodeViz we were inspired by the Maya hypershade, which closely resembles the diagram-based blender tool that you shared.

https://help.autodesk.com/view/MAYAUL/2024/ENU/?guid=GUID-22...

These examples show how taking a diagram-based approach to software development can abstract away complexity with minimal loss of control over the end result. I love your image of "atomic code legos," and these legos can still always be edited the level of code when needed.

And yes, if CodeViz can generate architecture diagrams from code, the inverse can and will be possible: generating code from architecture diagrams.

Re: Edit

The top level categorizations are indeed fixed, however the nodes themselves can be arbitrary. We've found this helps with grouping and organization while still allowing for the flexibility required to accommodate different systems. I'm curious, are there any categories missing here that could be added?

Currently, we categorize by: Frontend (UI/UX elements), Backend (API/Business/Data Access), DB(persisting storage), External Services (Backends maintained outside codebase), Shared Components (internally maintained libraries and helpers)

Yes of course, Let's set up some time to chat! Looks like a great tool!

Sounds good, thanks for the feedback! Would open-sourcing CodeViz change your willingness to give it a try?

Definitely agree that rigor is a tricky term here, do you think the open-ended nature of C4 diagrams is a feature, not a bug? We've found in practice that top level diagram generation is both an art and a science, maybe it ought to stay that way.

In any case, shooting you a PM to set up some time to chat, and thanks again for the input!

Great points/questions. I suspect that information relevant to codebase architectures follows the 80/20 principle. For example, a router and index file in a React App will usually give you around 80% of what's needed to infer high level container info.

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!

The lines represent a connection or interaction between different parts of the codebase. Most often these are dependencies like you mentioned, but a "dependency" could be a parent-child relationship, API call, imported function, and there are certain exceptions such as user interactions. Right now immediate edge labels are displayed on node hover, but I agree that the criteria for inclusion/exclusion of lines should be precisely defined. Any thoughts on what you'd like to see?