Should I vibe code
Text-to-diagram editor for software architecture and process models
Layout is the hard part, and Graphviz solved it in the nineties. You are paying €7 a month for a textarea.
?
Their verdict, the Premium Monthly 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
Text in, diagram out, and the genuinely hard part — layout — was solved by other people decades ago and given away. Mermaid, D2 and Graphviz between them render every diagram type Gleek sells, and wiring one into a textarea with a live preview and an SVG export is an evening. There is even a reason to prefer your own beyond the money: an architecture diagram is a map of your infrastructure, and the one you paste into a hosted editor is a copy of that map on somebody else's servers. Keep the source in git, render it in CI, and you end up with a better setup than the subscription.
What actually breaks
not "if". the specific failures.
- Layout quality, which is the actual product — badly routed edges make a diagram nobody trusts
- Your own syntax, if you invent one, because then no other tool on earth can read your diagrams
- Diagrams stored as blobs in a database instead of as text next to the code they describe
- Fonts in exported SVG, which look right on your machine and wrong in every reviewer's browser
- A hosted renderer fed untrusted input, where remote image fetches and embedded HTML become SSRF and XSS
Is that you?
the verdict is a default, not a law
- You render with an existing engine rather than writing a layout algorithm
- The diagram source lives in the repo as text, in version control, next to what it documents
- Export produces SVG and PDF as well as PNG
- It runs locally or on your own box, so your topology never leaves the network
- You are about to design a diagram language, which is a hobby and not a Tuesday
- You need real-time multiplayer editing on a shared canvas — that is a different product with a different verdict
- You will host it publicly and accept arbitrary diagram source from strangers without sandboxing the renderer
If you build it anyway
the checklist, then the prompt that enforces it
- Use Mermaid, D2 or Graphviz. The parser is the easy half; edge routing, crossing minimisation and label placement are decades of other people's research.
- Keep the diagram source as text in version control. The rendered image is a build artefact, not the document.
- Render in CI and commit or attach the SVG, so a diagram that stops parsing is a failed build rather than a surprise in a README six months later.
- Subset or embed fonts on export. A diagram that renders differently on the reviewer's machine is worse than no diagram.
- If you host it for the team, disable remote image fetching and strip embedded HTML from labels. Diagram renderers that take untrusted text have a long CVE history in exactly those two places.
- Do not invent syntax. Adopting Mermaid means GitHub, GitLab and every editor plugin can already read your files.
I am building a text-to-diagram editor. Keep it small and keep it honest. 1. Do not write a layout engine. Use Mermaid, D2 or Graphviz and treat it as the dependency the whole tool is built around. If I ask you to hand-roll node placement, refuse and explain what you would be reimplementing. 2. Do not invent a new syntax. Use the engine's language as-is, so my diagrams stay readable by GitHub, editors and anyone I hand a file to. 3. The source of truth is a text file on disk in my repo. The renderer reads it and writes SVG; the app never becomes the only place a diagram exists. 4. Build export before the editor UI: SVG first, then PDF, then PNG. Subset or embed fonts so exports render identically off my machine. 5. Add a CI-friendly command that renders every diagram in the repo and exits non-zero on a parse error, so a broken diagram fails a build. 6. Run rendering locally by default. If I later ask for a hosted version, stop and cover these first: no remote image or font fetching from diagram source, HTML in labels escaped rather than rendered, a render timeout, and a size cap on input — a diagram renderer accepting untrusted text is an SSRF and XSS surface, and that is the only way this tool can hurt anyone. 7. Keep a deterministic render: same input, same bytes out, so diffs are useful. 8. Out of scope unless I ask: real-time collaboration, comments, accounts, sharing links, and an AI prompt-to-diagram box. Each is a separate product, and the first three are what turn a local tool into one I have to operate.
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
Gleek's paid tier (€6.95 a month, or €58.40 a year) sells AI prompt-to-diagram, git integration and SVG export. If the AI box is genuinely what you want, that is cheap and you should just buy it. But note what you would be paying to unlock: SVG export of your own text. Insist on owning the export in any tool you choose, and the migration back out is a directory copy.
There is nothing to exit. The diagrams are .mmd or .d2 files in your repository; they render on GitHub, in editors and in a dozen other tools, with or without whatever UI you wrapped around them. That is the entire argument for text-based diagramming and it is why this one is easy.
Text-to-diagram renderer with broad syntax coverage and native rendering inside GitHub.
Modern diagram scripting language with a genuinely good automatic layout engine and a CLI.
Long-running text-to-UML toolchain covering sequence, class, state and activity diagrams.
Questions
If Mermaid is free, what is Gleek selling?
Keystrokes, mostly — a terser syntax aimed at people who resent reaching for the mouse — plus git sync, an AI prompt box and SVG export behind the paid tier. That is a real product for someone. It is not a product you cannot replace with a textarea, a preview pane and a dependency.
Is there any risk here at all?
Two small ones, and both are avoidable. The first is that a system diagram describes your infrastructure, so pasting it into a hosted editor moves that description somewhere you do not control. The second only appears if you host a renderer for other people: diagram engines that fetch remote images or render HTML in labels have shipped SSRF and XSS bugs, so a public instance needs both switched off.
Why not just use draw.io or a whiteboard tool?
Different job. A canvas tool is for thinking with other people in real time; a text-to-diagram tool is for documentation that lives in the repo and updates in a pull request. If you want the canvas, look at the collaborative tools — they carry a heavier verdict because the shared state is the product.
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.
A deck is a performance, not a document. Yours has to run once, offline, on a screen you have never seen.
The zooming canvas is a weekend. The conference-room projector at 1024x768 is the product.
“Read-only” is not “harmless”. ReadOnlyAccess includes s3:GetObject, and your weekend diagram tool now holds it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice