Generate an Architecture Diagram from a GitHub Repo: GitDiagram, Eraser and repowise Compared

To generate an architecture diagram from a GitHub repo, paste the repo URL into a generator. GitDiagram and Eraser use a model to read the file tree, README and sampled source, then draw the system. repowise parses every import instead. The drawing is easier to read; the parsed graph is complete and you can check every edge.

I build repowise, so read the rest knowing that. I tried to be fair, and the test below includes a place where our own output is wrong.

Two different ways to draw a repo

There are two families of tools behind the "repo to diagram" search, and they answer different questions.

The first family asks a model to describe the system. You give it the repository, it reads what fits in its context window, and it returns boxes and arrows that tell a story: the request comes in here, goes through this, ends up there. GitDiagram and Eraser are in this family, as is any coding agent you ask to "draw the architecture as Mermaid".

The second family parses the code. A parser turns every file into a syntax tree, finds each import, and resolves it to the file it points at. The result is a dependency graph that holds every file and every import edge, with no judgement about which ones matter. Madge, dependency-cruiser and pydeps are single-language versions of this. repowise does it across languages and then groups the graph into something you can read.

The first family is better at telling the story of the code and the second at being complete, so most arguments about "which diagram tool is accurate" compare one family's strength with the other family's weakness.

The test: Flask, one drawing, one parse

I picked pallets/flask because it is small enough to check by hand (24 Python modules under src/flask) and popular enough that GitDiagram already had a diagram for it, so I did not need to spend anyone's quota generating one.

What I did, on 6 October 2026:

1. Opened gitdiagram.com/pallets/flask and pulled the Mermaid source out of the page.
2. Cloned Flask at commit 2a8a38b, the commit repowise has indexed for its Flask page, and wrote a 40-line script with Python's ast module that lists every import between Flask's own modules. Imports inside if TYPE_CHECKING: blocks are kept separate, because they never run.
3. Compared the two, edge by edge.

I did not run Eraser on Flask. Its codebase diagrams start from a prompt you write and need an Eraser account, and I wanted to compare outputs nobody had steered. I describe Eraser from its documentation below.

What the GitDiagram drawing gets right

The diagram is a good one. It shows 15 Flask modules plus six external pieces (HTTP client, WSGI server, your application, Werkzeug, Jinja2, itsdangerous), each module linked to its file on GitHub. The flow it tells is correct: the WSGI server calls the Flask app, the app dispatches to your view function, templates render through Jinja2, sessions sign cookies with itsdangerous.

The written overview that comes with it is careful: for cli.py and wrappers.py it says the file's body "was not sampled", which is an honest thing for a model to admit.

The drawing also caught a dependency that an import graph cannot see. The diagram has an edge from the JSON provider to the Flask app labelled "creates response". src/flask/json/provider.py does not import the app at runtime. It holds a weak reference to the app and calls self._app.response_class(...) on line 105. That dependency only shows up if you read the code, and the model read it.

What it leaves out

The parsed graph has 24 modules and 78 runtime import edges between them. Measured against that:

• The two most-imported modules are missing. globals.py is imported by 12 other Flask modules and helpers.py by 9. Neither appears in the diagram. If you are about to change helpers.py, the drawing gives you no hint that nine files depend on it.
• Nine modules are missing in total: globals.py, helpers.py, config.py, debughelpers.py, logging.py, testing.py, typing.py, views.py and the top-level blueprints.py. The diagram's "Blueprint Registration" box links to sansio/blueprints.py, but the Blueprint class you import from flask lives in src/flask/blueprints.py, which subclasses the sans-IO one.
• Some real edges are absent. app.py imports sessions.py at runtime, but in the drawing nothing points at the session box except your own application. wrappers.py sits in the diagram with no edges at all, while in the code app.py imports it and it imports json, helpers and debughelpers.

The drawing is a curated summary, and a summary has to drop things. The problem is that you cannot tell from the picture what was dropped. A box with no arrows can mean "nothing depends on this" or "the model did not sample it", and those two readings lead to very different decisions.

The Mermaid below is the part of the parsed graph that the drawing does not show. You can paste it into any Markdown viewer that renders Mermaid.

The parsed side, including where it is weak

repowise's Flask architecture page groups the repo into four layers: Application (29 files, including all of src/flask), Config (10), Docs and Tooling (28) and Test (61). For a library this size, that top level is coarse, because all of Flask's source sits in one box. You have to open the map and zoom in to the file graph to see that globals.py and helpers.py sit at the centre, and the map does not tell you the request-flow story the GitDiagram drawing tells in one glance.

I also downloaded the Structurizr DSL export from the Knowledge Graph page (Structurizr DSL is a text format for C4 architecture diagrams). It describes Flask as one Python container with components for flask (25 files, 496 symbols), tests (52 files) and the three example apps. One relationship in it is wrong: an import edge from the flask source component to tests. My script finds no import from src/flask into tests/, so that edge should not be there. It is the kind of mistake a parser makes when it resolves a name to the wrong file, and it is checkable in a way a model's omission is not: you can point at the edge, look for the import it came from, find there isn't one, and report it as a bug.

Both approaches make mistakes, but of different kinds. A model leaves things out, and you cannot see the gaps. A parser includes everything and occasionally resolves an import to the wrong file, and you can trace each edge back to a line of code.

Eraser, from its docs

Eraser's codebase diagrams start from a prompt. Its docs give examples like asking for a cloud architecture diagram of the services under a folder, and recommend naming specific paths to improve accuracy. That makes it good for a particular slice you already know about (the Terraform under infra/, the Prisma schema, one service's request flow), and less suited to "show me this repo I have never seen".

Eraser has strengths the other two tools lack. Its diagrams are editable in a proper diagramming app, by hand or as diagram-as-code. And Eraserbot can watch files: when a pull request touches them, it comments an updated diagram on the PR within a minute or two. Eraserbot needs a connected repo and usage-based pricing turned on. The free plan includes 3 AI diagrams; Starter is $15 per member per month billed yearly ($20 monthly) with 40, and Business is $45 billed yearly ($60 monthly) with 250.

Choosing a tool

Use GitDiagram when you want to understand an unfamiliar public repo in the next five minutes. It is free and fast, its boxes link to real files, and the newer pipeline reads sampled source files as well as the README. Treat it as an introduction written by a smart colleague who skimmed the code. It now also has its own MCP server at gitdiagram.com/mcp, so a coding agent can fetch a public repo's diagram directly.

Use Eraser when the diagram is a deliverable: a design review, a doc page, a slide. You decide what it should show, then edit it until it is right, and Eraserbot keeps that specific diagram from drifting.

Use a parsed graph when the diagram feeds a decision. Before you change helpers.py, you want all nine dependents, not the five that made it into a summary. Single-language tools like Madge or pydeps give you that for free. repowise gives it across languages, with layers, ownership and change history on the same page, and re-indexes on every push on Pro so the graph does not go stale.

In practice I use both: the drawing to learn what the authors meant, and the graph to check what the code actually does.

How we measured

• GitDiagram: the cached diagram at gitdiagram.com/pallets/flask, Mermaid source read from the page on 6 October 2026. I do not know which Flask commit it was generated from; its file links point at main. Between repowise's indexed commit (2a8a38b, 11 August 2026) and Flask's main on 8 September, only two lines changed in app.py and helpers.py, with no new or removed modules.
• Parsed graph: Python's ast over the 24 .py files in src/flask at 2a8a38b. Relative and absolute imports of Flask's own modules were resolved to files; imports inside TYPE_CHECKING blocks were excluded from the 78 runtime edges. This counts imports only, so calls through object references (like the JSON provider's) are not in it.
• repowise: the public Flask page and the Structurizr DSL export from api.repowise.dev, snapshot of commit 2a8a38b.
• This test covers one repo, and Flask is small and tidy. On a large repo a model sees a smaller share of the code, so I would expect omissions to grow, but I have not measured that here.