Show HN: Arcaide – Explore code with multi-level call graphs(arcaide.foo)
arcaide.foo
Show HN: Arcaide – Explore code with multi-level call graphs
https://arcaide.foo
15 comments
Consider to let the user export the graph itself and convert/use it elsewhere.
I love this! It's relatively simplistic and would be a really fun tool to use during lectures.
It's a bit like a (simplified) version of Ilograph[0]. Are these editable, or strictly LLM-generated?
[0] https://www.ilograph.com
[0] https://www.ilograph.com
They're generated from source code using a combination of static analysis + llm analysis. They're not editable per se, but you can update them when you edit your code.
I think you found a very good prompt/technique to extract mostly the high level stuff without making the diagrams too complicated. And then elk.js seems to do the layout.
Deepwiki.com also has some usable autogenerated architecture diagrams worth a look.
Deepwiki.com also has some usable autogenerated architecture diagrams worth a look.
I wish something like this could trace also data flow in a program.
Something I do have in mind. Do you have an idea of the kind of UX you'd like to see?
I would be interested in this too if you ever build it.
Only naïve ones I'm afraid, such as a heap view.
How does it decide which call graphs to include? In a typical project there can be many and these graphs seem to be a small subset.
It identifies telemetry, accessors, and other trivial code and strips them out of the graph. The idea is to retain architecturally relevant parts of the code.
How u make this??
The approach I'm exploring is to construct "multi-level" call graphs. These are call graphs represented in the form of program structure showing control flow not just at the function level, but rolled up to higher level units such as classes and packages. This gives you the ability to zoom in and out and see your code at different levels of abstraction, à la C4 diagrams, allowing you to navigate large graphs by expanding the areas you care about and collapsing the rest.
The graph is then fed to an LLM for semantic analysis. This does two things, detects telemetry, trivial utilities to strip them out of the graph further condensing it, and identifies external interfaces and dependencies to enrich the graph. The result is a single graph which incorporates both structural and behavioral aspects. You can see package level dependencies, class composition and relationships, as well as external services, databases and user interactions. Think of it as a package diagram + class diagram + use case diagram combined into a single composite diagram.
Of course, ultimately source is king. There is no substitute for reading code to understand the details of what it is doing. But a map doesn't replace the terrain, it tells you where to walk. As we shift from hand coding each line to orchestrating agents that are generating all the code, maintaining the "big picture" becomes ever more important. We need better maps to help us navigate the terrain.
I would love to hear what you think though. Do check out some of the example diagrams in the link [1] and share your feedback. Also interested in your general thoughts on program comprehension!
[1] Link: https://arcaide.foo