A project called Archify just shipped its 3.0 release with a pitch that's easy to remember: give an AI agent one sentence and it turns your project into a diagram you can click, read, and trace. Architecture maps, flow charts, sequence diagrams, data-flow views. The numbers around it are loud too — 74k stars, over 5,000 forks. The author also reports token consumption dropping more than 50% and speed improving more than 50% versus the previous version, though they're upfront that this is their own testing and results vary by project and model. Treat both of those percentages as unverified; they're one person's measurement, not a benchmark.
What caught my attention isn't the AI drawing. Diagram generators are everywhere. The interesting engineering move — the one worth copying — is hiding underneath the demo: if you parse the repository once into a stored structure and render from that, the diagram becomes deterministic and cheap to redraw. You stop paying an AI to re-read the whole codebase every time someone wants to look at the map.
The signal underneath the star count
Stack the evidence and a theme shows up. One developer is watching their Codex billing anxiously, trying to figure out whether they're on a five-hour or weekly limit and how fast the quota drains. Another wrote a whole cost breakdown on image generation, sweating over per-image token pricing before running a batch. The Archify author frames their own win as "stars go up, tokens go down." Different corners of the same room: people who build with LLMs are increasingly cost-aware, and anything that burns tokens on repeated, predictable work feels wasteful.
A code visualizer that re-invokes an agent on every view is exactly that kind of waste. The structure of a repo doesn't change between two page loads. So the smart architecture separates the expensive, occasional step (understand the code) from the cheap, frequent step (draw it). Parse into a snapshot, version the snapshot, render the snapshot. The AI only runs when the code actually changes.
Rebuilding the pattern on VicroCode
Here's how I'd lay it out using what the platform actually supports. Three pieces: a parser, a store, and a viewer.
The parser is a Python job. You can run Python online to walk a project's source files and pull out the structure you care about — modules, classes, functions, imports, call relationships. For Python source this is mostly the standard `ast` module plus some bookkeeping; you're building a graph of nodes and edges, not asking a model to guess. One honest boundary here: VicroCode gives you online Python execution and file management, not a git integration. So you bring the code in through file management rather than assuming the platform clones a live repo for you. That's a real constraint to design around, not a detail to hand-wave.
The output of that parse is a plain data structure — a list of nodes with IDs, types, and file locations, plus a list of edges. That's what you persist.
For the store, a SQLite table per snapshot works well. Give each parse run a snapshot ID, a timestamp, and a project key, then keep the nodes and edges as rows tied to that ID. Now every parse is a version, and you can diff or roll back. When you need to poke at what got captured, the built-in SQLite editor lets you inspect rows directly instead of writing a throwaway query script. Versioning is the part people skip and regret — it's what lets you answer "what did this module look like three commits ago" without re-running anything.
The viewer is a hosted HTML page. You run HTML online to serve a single page that reads a snapshot and draws the clickable map — nodes you can expand, edges you can follow, a panel that shows the file behind whatever you clicked. The rendering is pure front-end work over data you already stored, so it's fast and repeatable by construction. To feed it, expose the snapshot through an API endpoint hosted in-platform: the page requests a snapshot ID, gets back the nodes and edges as JSON, and renders. No model call in that loop.
Where the AI actually earns its keep
The parse-once design doesn't mean no AI. It means the AI runs where it adds value, not on every page view. Two spots make sense.
First, labeling and summaries. Raw `ast` output gives you names and relationships but not intent. A model call — through the platform's Model Center for a model that's already available there — can generate a short human description of what a module does, and you store that description alongside the node. It runs once per snapshot, gets cached in SQLite, and every future render reads the cached text for free. That's the mechanism that would make a token bill go down over time, though again, I'd measure it on your own project before quoting any percentage.
Second, the "one sentence" entry point, if you want it. You could let someone type a request and have an agent decide which view to assemble from the stored structure. But notice the AI is now composing a diagram from a snapshot you already parsed, not re-reading the source. Cheaper input, more predictable output.
The trade-offs I'd flag up front
Staleness is the obvious one. A stored snapshot is only as fresh as your last parse, so you need a clear trigger for re-parsing — a manual button is fine to start, and honest about what it is. Don't pretend the map is live when it's a cached version.
Language coverage is another. `ast` handles Python cleanly. Other languages need their own parsers, and I wouldn't claim the platform does that for you — that's parser code you'd write and run in Python, within whatever the online execution environment supports. Someone in the same community noted that bundling Python into a desktop app the Electron way gets heavy; here you sidestep that entirely by keeping the parse server-side and shipping only an HTML viewer, which is a genuinely nicer distribution story.
And the big one: resist the urge to make the AI redraw everything on demand. The whole point is that the structure is data, the diagram is a view of that data, and the model is an occasional enrichment step. Get that separation right and you've rebuilt the useful half of Archify — the deterministic, cheap-to-render half — as something you can host, share, and even monetize as a project on the platform.
The pitch that spreads is "one sentence, instant diagram." The engineering that lasts is "parse once, store the snapshot, render for free." Build the second one.