Do I need my ML dependencies installed to analyze the codebase?

No. Analysis is pure AST parsing — nothing is imported or executed, so you don't need torch, sklearn, CUDA, or your data to map the code. That also means it's safe on any machine, including CI.

Can it find abandoned experiment code in an ML repo?

Yes. 'check --dead-code' lists functions with no in-project callers that aren't entry points — typically old trainers and abandoned experiments — each with a file:line. It's deliberately conservative: a review list, not a delete list.

Does it work on notebooks?

It analyzes .py files. The common workflow is to map the pipeline package that notebooks call into; anything that has been promoted from notebook to module is covered.

Visualize an ML Pipeline Codebase — Find the Dead Experiments

Commands below run against an ML-shaped fixture in the repo (examples/scenarios/ml_pipeline — a live run → ingest → features → train → evaluate pipeline plus deliberately orphaned experiment code). Output is verbatim.

See the pipeline that actually runs

$ py-code-visualizer visualize examples/scenarios/ml_pipeline -o pipeline.html

Built graph with 16 functions and 13 calls Interactive HTML visualization saved to pipeline.html

Canonical stats: 16 functions, 13 calls, 0 cycles, 0 ambiguous edges — in one self-contained offline file. The map shows one clean spine from pipeline.run through each stage — and an island of experiment functions connected to nothing. That island is your cleanup backlog, made visible.

List the graveyard, with proof

$ py-code-visualizer check examples/scenarios/ml_pipeline --dead-code

✅ Architecture check passed: no rule or cycle violations. 🟡 2 function(s) with no in-project callers (review — may be public API): experiments.grid_search_abandoned experiments.train_model_v1_legacy

Deliberately conservative: _fit_legacy is not listed even though it's effectively dead, because the (dead) legacy trainer still calls it — the tool reports what it can prove, and once you delete the trainer, the next run flags its helper too. A review list you can trust, not a chainsaw.

Refactor the training loop with an agent — safely

"Refactor train_model to support checkpointing" is a classic agent task. Give the agent verified facts about who calls it and what it calls, instead of letting it guess from a repo dump:

$ py-code-visualizer context examples/scenarios/ml_pipeline --focus train_model

# Context Pack — ml_pipeline - Focus: `train.train_model` - Included functions: 13 ## Verified calls (caller → callee · confidence · provenance) - `pipeline.run` → `train.train_model` · resolved · …/pipeline.py:12 - `train.train_model` → `train._fit` · resolved · …/train.py:6 - `train.train_model` → `train._hyperparams` · resolved · …/train.py:5 …

The agent knows — with provenance — that only pipeline.run depends on the signature it's about to change. See the full agent-context walkthrough.

What you got. The live pipeline mapped and separated from the experiment graveyard (2 orphaned functions found here, each with a file:line), zero dependencies installed, and verified context for AI-assisted refactoring of the training loop. The mess every ML repo carries, finally measurable.

Fixture: examples/scenarios/ml_pipeline. Output shown verbatim except lists trimmed with … and repeated path prefixes shortened to …/ for width. Scales: a measured 98,669-line project maps in ~4.9 s.

← All use cases