Diagrams as code is one of the better ideas engineering picked up in the last decade. A diagram that lives in a text file is a diagram you can review, diff, and roll back. It travels with the code it describes, and it never gets lost in someone's downloads folder.
There is one catch, and everyone who has kept a diagram as code knows exactly what it is. Text is a wonderful way to store a diagram and a miserable way to arrange one. The moment you want to nudge a single box two centimetres to the left, you are back in the syntax, guessing at ranks and directions and invisible layout rules, re-rendering until the engine finally puts the thing where your eye wanted it all along.
The whiteboard is the missing half
The reason people reach for a whiteboard is that it answers a different question. Code answers "what is the source of truth." A whiteboard answers "does this look right." You point at a box and drag it. You circle the risky path in red. You do not think about how the layout is encoded, because there is no encoding; there is just the picture and your hand.
LetDraw's take is that you should not have to choose. Paste your diagram code and it becomes real, editable shapes on a canvas. Not a flat image you can only look at, but actual boxes and arrows you can grab. Here is the kind of source most teams already keep in a repo:
graph TD A[Client] --> B[API Gateway] B --> C[Auth Service] B --> D[Orders Service] D --> E[(Database)]
Import that Mermaid, and LetDraw does not hand you a picture of it. It hands you the graph as shapes you can move:
Now the tedious part is over. You did not tune a single layout directive. You got a first pass for free, and everything on the canvas is yours to adjust.
Move one box, fix the note, highlight the path
Because the import produces genuine shapes, the whiteboard half just works. You do the things that are painful in text and trivial by hand:
- Move a box where your eye wants it, without re-rendering to check
- Restyle a node so the one that matters stands out from the rest
- Add a note next to the part reviewers always ask about
- Highlight a path to show the request flow you care about today
The arrows help instead of fighting you. Native start and end arrowheads are built in, along with UML hollow heads for inheritance and ER crow's-foot cardinality for schema work. You never hand-draw a marker or fake a notation with a rotated triangle. And when you drag a box across another one, smart connectors reroute the arrow around your shapes automatically, so the line stays clean instead of cutting through a node.
Text is where a diagram should live. A canvas is where it should be arranged. You should not have to pick one.
The round-trip is the whole point
Here is the part that keeps this honest. When you are done nudging, you export the drawing back to Mermaid or D2. The diagram returns to your repo as code, reviewable in a pull request like anything else. The loop looks like this:
- Code in your repo is the source of truth, diffed and reviewed
- Canvas is where a human arranges it and makes it readable
- Code again on the way out, so the improved layout ships as text
That last step is what separates "I imported a diagram once" from "diagrams as code that a human can actually stand to maintain." The syntax stops being a wall. You keep the reviewability of code and the ergonomics of a whiteboard, and neither one has to lose.
How to try it
Open a canvas, reach for Generate from Code, and paste a Mermaid or D2 snippet you already have. Drag the boxes until it reads the way you would draw it on a wall. Then export it back to code and drop it in your repo. The whole trip, code to canvas to code, takes about as long as it took to read this.