DevSwat AST- visualizer with analyzer - Turn codebases into interactive maps, graphs, and governance
by•
DevSwat Code Analysis is a code intelligence platform that turns large codebases into interactive maps, dependency graphs, and governance reports. Unlike traditional static analyzers, it combines scan, compare, trace, and agent workflows so teams can understand architecture, review changes, and act on issues in one place. It also supports GitHub scans, uploads, saved analyses, and AI-assisted governance, making it useful for both local exploration and team-scale code review.
Replies
one thing that would be super helpful is a built-in dashboard for tracking model drift and confidence scores over time, so teams can see at a glance when something is going sideways in production without digging through logs
BetterClaw
Love the idea of making complex codebases easier to understand visually. Interactive maps and governance can save teams a lot of time when onboarding or maintaining large systems, especially as AI-generated code becomes more common.
Curious...does DevSwat integrate with GitHub and support tracking architectural changes over time?
@worksforme Thanks — yes, DevSwat integrates with GitHub, and we do track architectural changes over time. The goal is exactly to make it easier to see how the codebase evolves, spot drift, and understand the impact of changes visually.
Have you considered adding a built-in cost-tracking dashboard that breaks down token spend and latency per request? Would make it way easier to justify the bill to stakeholders and spot which workflows are quietly eating budget.
@farukkorkuygpl Thanks — we hadn’t considered a built-in cost dashboard yet, but that’s a really strong point. Token spend and latency per request would definitely help teams understand costs and catch expensive workflows sooner.
Have you considered adding a visual debugging dashboard that shows model decision paths in real time? It would be super useful for spotting exactly where the AI drifts or fails in production without digging through logs.
@dilarakurtt8sl that’s a really strong idea. We already have tracing and governance in place internally, so a real-time visual debugging dashboard for decision paths is definitely something we’d consider surfacing. It would make drift and failure points much easier to spot without digging through logs.
Finally got around to poking at DevSwat, and the observability hooks feel genuinely useful for catching flaky model behavior. Nice to see someone focused on making AI dependable instead of just flashy.
@sebahatkocgmy0 Thanks a lot — that means a lot to hear. We’ve been putting a lot of work into observability and governance because we think dependable AI matters more than flashy demos. Glad it’s coming through.
The scan/compare/trace-in-one-place framing beats yet another static analyzer that dumps a graph and leaves you to interpret it. Since it does GitHub scans plus direct uploads and AI-assisted governance, does my source get sent to a hosted model or your servers to build the maps, or can the analysis run locally so a private codebase never leaves my machine? And is the dependency graph built from real static analysis, or inferred by the LLM in a way that can hallucinate an edge that is not actually in the code?
Thanks for the thoughtful question—this gets right to the core of how we built it.
On data handling: today, our main interactive visualization and mapping run on our servers in a sandboxed execution environment. That’s what powers the full UI experience.
However, we also offer a local option through our IDE app (a fork of VS Code), where static analysis runs entirely on your machine. In that setup, your private codebase does not leave your environment. The only cloud-connected part is the orchestration layer for coding agents, which operates separately and does not expose your source code.
If you need stricter guarantees, we can provide a fully self-hosted deployment on request. We’re also considering adding a localhost UI so you can get the full visualization experience without relying on our hosted environment.
On the dependency graph: it is built from real static code analysis, not inferred by an LLM. We do not rely on a model to “guess” edges, so you won’t get hallucinated dependencies.
The LLM comes into play after the analysis, where our “Graph Junior” agent uses the static analysis results—along with historical context—to improve insights, suggest fixes, and surface patterns over time.
In practice, this means the graph itself is deterministic and grounded in code, while the AI layer helps you interpret and act on it more effectively. You’ll get the best results by scanning the same codebase periodically, since the “Graph Junior” agent learns and provides increasingly useful recommendations over time.
The IDE-fork path answers the privacy half nicely — local static analysis with only the agent orchestration reaching out is a boundary I can actually reason about. The part I'm still unsure on: is the dependency graph itself produced by real static analysis (parser/AST, resolved imports and call sites), or is any of it LLM-inferred? That distinction decides whether a missing edge is a bug I can file or just a model that guessed wrong, and it's the whole reason to trust it over a coding agent's own guesswork.
@hi_i_am_mimo real static analysis are not depend on LLM . LLM use only Junior agent for code fix suggestion base on static analysis.
That's the clean separation I was hoping for — deterministic map as ground truth, LLM only as a junior agent suggesting fixes on top of it. Last one: are those fix suggestions always gated behind my review before anything touches the code, or can the junior agent apply a change and re-run analysis on its own? Keeping the human in the loop on writes is what makes me trust a read-only map underneath.