Should I vibe code
Diagram-as-code, whiteboards, and documentation for engineering teams
Diagram-as-code is a solved problem. Keeping the canvas and the code from drifting apart is not.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Half of Eraser is already free. Mermaid and D2 turn text into a rendered diagram, models write both fluently without any prompt engineering worth the name, and an agent will stand up "paste a description, get a system diagram" before lunch. That demo is genuinely good, and if it is all you need, stop reading and build it. What Eraser sells is the other half, which is where the weeks go: a canvas and a code block that stay in agreement when you drag a node, version history you did not think about until you needed it, real-time cursors, and Eraserbot regenerating architecture diagrams as the repository changes. That last one is also the part with a real edge — the codebase scanner is a pipe from your private source into a model endpoint, and the DIY version of it has whatever retention policy you did not read. Nothing here ends in a regulator's inbox. It ends in a folder of diagrams your team stopped trusting, which is a slower and more ordinary kind of loss.
What actually breaks
not "if". the specific failures.
- Two-way sync between the canvas and the code. Generating a diagram from text is easy; regenerating the text after someone dragged a node is the feature, and it is where every clone stalls
- Layout stability — re-render after a one-line edit and the whole graph reshuffles, so a diagram in a pull request shows forty changed nodes instead of one
- Version history, which nobody builds until the afternoon somebody wipes a canvas everyone was looking at
- The model's output, silently. A provider ships a new version, the syntax it emits drifts, and diagrams that used to render come back as parse errors on a Monday
- Share links. A guessable link to a system diagram is a free map of your internal architecture, service names and all
- Concurrent editing, which is a CRDT problem the moment two people have the same file open and not before
- Codebase scanning, if you build it: private source code leaving your network for a model endpoint whose retention terms nobody on the team has read
- Export fidelity into Confluence and Notion, which is the reason anyone uses the integrations, and which is fiddly forever
Is that you?
the verdict is a default, not a law
- The diagrams live in the repository as Mermaid or D2 and render in the pull request, and there is no canvas at all
- It is one person or one team, and the source of truth is text you already back up with git
- Nothing scans a private repository and sends it anywhere you have not approved
- Losing every diagram would cost an afternoon of redrawing, not a week of archaeology
- The canvas is the source of truth and the only copy lives in your database
- Architecture diagrams get shared by link with people outside the team
- You are wiring a code scanner to an LLM without a written answer on where the code goes
- Several people will edit the same diagram at once and you have not chosen a conflict model
If you build it anyway
the checklist, then the prompt that enforces it
- Make text the source of truth and the canvas a view of it. Every other ordering forces you to write a canvas-to-code serialiser, which is the hardest part of the product.
- Store diagrams as files in a git repository the team already has. You inherit history, review, blame and backup for nothing.
- Pin the layout: seed the engine deterministically and hold node positions in the source, so a one-word edit does not produce a diff across the whole graph.
- Render with Mermaid or D2 rather than writing a layout engine. Graph layout is a research field, not a sprint.
- Validate model output before it reaches the renderer — parse it, and on failure retry with the parser error rather than showing a blank canvas.
- Make share links unguessable and expiring by default, and put an explicit "this diagram is public" marker on anything visible without login.
- If you scan a repository, list exactly what leaves the machine — paths, file contents, environment variables — and get that list agreed before it runs once.
- Export to SVG and Markdown on a schedule so the diagrams survive the tool.
I am building a diagram-as-code tool with an AI generator and a canvas. Treat
the diagrams as documentation that has to outlive this codebase, and order the
work accordingly. Push back if I ask for the canvas before the file format.
1. Text is the source of truth. Diagrams are Mermaid or D2 files on disk, in a
git repository. The canvas renders those files and edits write back to
them. If I propose a database-first design, tell me what I lose.
2. Do not write a layout engine. Use Mermaid or D2 and say which. If a layout
looks wrong, the fix is the source syntax, not a custom router.
3. Make rendering deterministic before anything is pretty: same input, same
output, positions pinned in the source. Show me that a one-line edit
produces a one-line diff and not a reshuffled graph.
4. Then the AI step, treating model output as untrusted input. Parse it,
reject it on failure, retry once with the parser error attached, and never
put unparsed model text on the canvas.
5. Before any repository scanning exists, write in the README exactly what
leaves my machine — which paths, whole files or excerpts, which provider,
what their retention policy says. Then make it opt-in per directory and
refuse to scan a whole repo by default.
6. Never send .env, credentials files or anything matched by .gitignore to a
model. Enforce that in code, not in a prompt.
7. Sharing ships with the diagram: unguessable link IDs, expiry by default,
and a visible marker on anything readable without login. An architecture
diagram is an internal map.
8. Export before collaboration: SVG and Markdown for every diagram, on a
schedule, into the same repository.
9. If I ask for real-time multiplayer editing, tell me that is a CRDT project
with its own maintenance story, and offer file locking first.
10. Out of scope and stated in the README: Confluence and Notion integrations,
version history beyond git, and self-updating codebase diagrams. If I want
those, say that $20 per seat is the cheaper answer.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
When more than a handful of people edit the same diagrams and someone starts asking what changed. Twenty dollars per member per month buys version history, real-time editing, and integrations into the wiki your team already reads — and unlimited free guests, which quietly removes the hardest part of a homemade version, which is letting people look at a diagram without giving them an account.
$20/mo is cheaper than your weekend.
Keep the diagram source in your own git repository from day one and this entry has no exit problem at all — Mermaid and D2 both render anywhere, and the files are readable by a human without any of your code. The piece worth exporting on a schedule is the rendered SVG, because a diagram that only exists as source is a diagram that stops existing the day the renderer version you pinned no longer installs.
Text-to-diagram renderer with broad syntax support, already embedded in GitHub, GitLab and most wikis.
Declarative diagram language with several layout engines and a watch-mode compiler, aimed squarely at architecture diagrams.
Questions
If Mermaid is free, what am I paying Eraser for?
The canvas, the collaboration and the integrations. Mermaid renders text; it does not let a product manager drag a box, does not keep history, does not put cursors on the screen, and does not push the result into Confluence. Whether that bundle is worth $20 a seat depends entirely on whether anyone other than engineers touches your diagrams.
The AI diagram generation looks like the hard part. Is it?
It is the easiest part now. Models write Mermaid and D2 well, and the whole feature is a prompt, a parser and a retry. The difficulty has moved to what happens after generation — a human edits the picture, and something has to reconcile that edit with the text that produced it.
What about Eraserbot generating diagrams from our codebase?
That is the one piece with a real edge, and it is worth treating separately. Scanning a private repository means source code leaves your machine for a model endpoint, so decide explicitly what goes and what never does — .env files, credential stores, anything in .gitignore — and enforce it in code rather than in a system prompt.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Mermaid is MIT and already renders in your README. The subscription is a login screen around a Markdown feature.
“Read-only” is not “harmless”. ReadOnlyAccess includes s3:GetObject, and your weekend diagram tool now holds it.
The canvas is MIT — take it. What Plus sells is the server that still has your boards on Monday.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice