It is a common pattern across organizations: a file named something like process-final-v7-REALLY-final.pdf, sitting in a folder next to a dozen earlier versions. Process diagrams, flowcharts and workflows tend to be scattered across OneDrive, Google Drive, Visio, Confluence and SharePoint, with no versioning, no history, and no easy way to tell why a process changed or who changed it.
Software developers solved this exact problem years ago. Their code lives in Git: every change is recorded, every version can be restored, and the history explains the why, not only the what.
Diagram-as-code tools like Mermaid have existed for years, so treating a diagram as code is nothing new. What doesn't exist as often is the bridge: turning an existing diagram, in whatever format it happens to be in, into that same versioned discipline, without redrawing it by hand. That's the part this experiment focused on: connecting two worlds that rarely talk to each other, code and diagrams.
Plain English request in, restructured diagram out. GitHub keeps the history, Slack tells the team, and a human reviews everything in between.
A quick note
As a product professional, I use this AI Lab on my callgenix.com site to think up "what ifs" that could solve real enterprise constraints and productivity hoggers, while upskilling myself with hands-on, practical AI experience.
So, as a weekend pet project, I started building this web app two months ago. It essentially converts diagrams and flowcharts, in most formats, into code, Mermaid code.
This is a video presentation (demo) of this web app. For the curious, you can find the "tech stack" and integrations down at the bottom of this page.
For now, this remains a project I am keeping close rather than releasing openly, so it isn't something set up for others to install just yet, though who knows what the future holds.
Before building anything, I ran one test. I gave Claude the same business process in five different formats: BPMN, draw.io, SVG, PDF and a plain sequence diagram. It understood all five. Reliably, every time.
That was the moment it clicked, not that a diagram can be represented as code, Mermaid and similar tools have done that for years, but that an AI could reliably cross the format gap. If it can read and rewrite any of those formats, then a diagram sitting in a PDF or an old Visio export doesn't need to be redrawn by hand to get the same versioning and change history developers already take for granted.
Any diagram in, Mermaid code out
A process diagram in JPEG/PNG, BPMN, draw.io, SVG, PDF or XML format can be converted into Mermaid, a diagram-as-code language.
Change requests in plain English
A change request phrased the way it might be explained to a colleague, for example "add an expedited path for low-risk customers", is enough for Claude to interpret the business logic, rebuild the diagram and explain exactly what changed.
Human in the loop, always
A before/after toggle allows the change to be reviewed, line by line and visually, before anything is saved. Nothing gets committed without a human review first.
Version history with the why attached
Saving a version to GitHub also writes the business objective into the commit history: not "updated diagram v7", but the actual reason behind the change.
The team stays in the loop
A Slack notification, carrying the objective, the change summary and a review link, closes the communication loop.
The part I like most
The next person who asks "why does this process work this way?" does not need to call a meeting. They can read the change history, in plain English, with the business reason attached to every version.
LLMs and structured diagram languages
Claude handles diagram formats far better than I expected. The five-format test was the foundation of the whole project, and I ran it before writing a single line of code.
API authentication fails in creative ways
GitHub classic tokens expect the word "token", not "Bearer", and a config file that returns an array instead of setting a variable can burn through an entire evening of debugging. A lesson learned the hard way.
Human in the loop is not a buzzword
The before/after review step is what makes an AI modification trustworthy enough to save. Without it, this would be a toy.
The interesting problems are around the AI, not in it
Review, versioning, notification. The workflow around the model is where the real design decisions live.
What amazed me about this AI Lab experience was the vibe coding, so to speak, with Claude.
First round, the compliance lane split into two columns running the whole page, checkpoints looked exactly like the decision gateways next to them, five documents sat right inside the flow and blocked it, RACI got squeezed into one diamond until nobody could read it. I pointed out what BPMN actually expects, and the next round held: one contained lane, checkpoints as hexagons, documents moved onto dashed lines, RACI sitting quietly beside the gateway instead of crammed inside it. Then I ran it again with different wording, just to rule out luck. It held a second time. That's when it stopped being just another nice drawing and became something I could actually trust, with a human in the loop checking every round before it counted as done.
None of those fixes were cosmetic. A lane that's actually contained, not two floating columns, is what tells a reader the Compliance Officer owns specific checkpoints and nothing else. Hexagons instead of diamonds keep a compliance gate from being mistaken for an ordinary yes/no decision. Documents on dashed lines instead of inline nodes mean the process doesn't grind to a halt waiting on paperwork that's really just a record. And RACI sitting beside a gateway, instead of stuffed inside it, keeps the decision label readable. Small details, but they're the gap between a diagram that looks right and one that could actually be relied on for a compliance answer.
Vibe coding usually means trusting the first thing that comes back. Here it meant the opposite: iterate, correct, re-run with different wording to rule out luck, and only trust the result once it held up twice. That loop, more than the diagram itself, is what this part of the experiment was really about.
AI layer
Diagram interpretation and modification run on Claude, model Opus 4.6, through Anthropic's Messages API. A structured system prompt asks for the modified Mermaid code, the business objective and the explanation as three separate, clearly delimited blocks, so the frontend can parse and display each one on its own instead of scraping free-form text.
Cost per call
Every response from Claude also carries its own token usage. The app reads that and shows the real cost of that specific call, live, right next to how long it took. The full breakdown of how that number gets calculated is on the API cost page.
Diagram engine
Mermaid is the diagram-as-code target language, rendered client-side with Mermaid.js. It is also the syntax Claude reads and writes back, which is what makes the round trip between diagram and code possible.
Version control
Version history runs on the GitHub REST API. Each save is a commit, with the business objective written into the commit message and a sequence number pulled from a version log file that the proxy reads and updates automatically.
Team notifications
Slack Incoming Webhooks post the objective, the change summary and a review link, so a change never sits invisible between two people.
Hosting and security
Everything runs on shared cPanel hosting with PHP 7.4. Every external call, to Claude, GitHub and Slack, goes through a PHP proxy first, so none of the API keys are ever exposed to the browser.
Frontend
One HTML file, vanilla JavaScript, no framework and no build step. Fonts and icons load from a CDN, Inter, JetBrains Mono and Tabler Icons, and that is the entire dependency list.
Next up: stress-testing the tool with bigger and messier real-world diagrams, and seeing how far the plain English editing can go before it breaks.