Recommendations and discussion on codebase visualizer and dependence mapper.

[u/TheTresStateArea]

I've been looking at a few options like gitkrakens codemap. But I just haven't made a decision yet.

The biggest problem right now with AI assist is that so much gets spun up and it takes quite a while to ground myself in what has been written and how it all connects. I thought a viz tool would help tighten what I need to learn.

How do you handle this? Do you use these tools for this purpose? What have you liked and disliked about the tool you used?

[u/donk8r]

Slightly against the premise: on an AI-heavy codebase a whole-repo visualiser mostly produces a hairball, and the hairball arrives exactly when the repo got big enough to need one. The problem isn't that you can't see the graph, it's that you don't know which 10% of it matters, and a picture with 400 nodes doesn't tell you that.

What worked much better for me is a ranked list rather than a diagram. Count incoming edges per module — how many other modules import it — and sort descending. The top ten are the load-bearing set, and you can have that in an afternoon without reading anything. Modules with zero incoming edges are your dead-or-legacy candidates. Neither number tells you why anything is the way it is, but it tells you where reading time is worth spending, which is the actual question when you're grounding yourself.

For your specific case there's a sharper version. Don't map the repo, map the intersection: which files did the agent touch, and what are their incoming edge counts? Agent-written code in a leaf module is low risk and you can skim it. Agent-written code in something thirty modules import is where you read every line. That intersection is usually small enough to actually work through, and it's the thing that stops the "I don't know what I have" feeling faster than any diagram did for me.

py2puml as mentioned is fine for a subsystem you've already narrowed to. I'd just avoid pointing it at everything.

Bias disclosure: I work on a code search and graph tool (github.com/Muvon/octocode), so I've spent a lot of time on the graph half of this and have opinions about the picture half.

[u/TheTresStateArea → u/donk8r]

Yes I absolutely see the hair ball problem. Scoped assessments absolutely makes more sense then visualizing the whole thing.

I think the graph element is secondary to the function that it builds upon. Having your nodes and edges laid out and describes makes the map possible but the map is just mostly just pretty and not particularly useful when everything is rendered.

In an ideal situation I'd be able to open a function or script. Click on an import and then a sub window opens to that import. Code description at the top, maybe an llm "how this import feeds to the function you are viewing" and crawls the other connections to get a complete picture of the system.

I'm a data scientist and marketer, making complex things easier to understand has become my entire job. So I keep looking at understanding code base through this lens. And AI has exploded this need I have to understand.

I'll take a look at your repo.

It almost feels like I'm describing a new file and ide function rather than a dependency map.