AI system design tools.
Three different products share one search term.
AI system design tools fall into three groups that are easy to confuse. Diagram generators turn a prompt or a repository into a picture. AI whiteboards add generation to a collaborative canvas. Design-first coding agents, which is where Lucid Train sits, treat the architecture as a specification the agent then implements against. Which one is right depends entirely on whether the output you need is a picture or a change to the codebase.
Group one: diagram generators
These take a prompt, a repository or an infrastructure file and return a diagram. Mermaid and PlantUML are the text notations underneath much of this category, and they are excellent when the diagram belongs in a pull request next to the code. Their weakness is layout: text notation delegates position to whichever renderer is installed, so the same source drifts between environments and large graphs become unreadable without hand-tuning.
Group two: AI on a whiteboard
Lucidchart, Miro and Excalidraw are canvases first, with generation added. Their strength is the meeting: several people editing one surface, comments, and freeform shapes that do not have to mean anything to a machine. Their weakness is that the artefact is a drawing rather than a model, so nothing downstream can consume it. If the goal is agreement between people, this group is the right answer and a coding agent is overkill.
Group three: agents that build against the design
The distinguishing property is direction. Here the architecture is structured data the agent reads before it writes code, and the diagram can cause an implementation rather than merely describing one. This group is small because it requires the architecture to be a model with components, edges and real file paths, and it requires solved layout so a regenerated picture is comparable to the last one.
Choosing between them honestly
Pick a diagram generator if the deliverable is a picture for a document or a pull request. Pick a whiteboard if the deliverable is a shared understanding between people in a room. Pick a design-first agent if the deliverable is a change to a real codebase and you want the architecture agreed before the change is written. Most teams need more than one of these, and the mistake is expecting any of them to be all three.
What Lucid Train does in group three
The agent surveys the repository and emits a semantic graph; ELK solves the layout, so position is computed rather than dragged. Implement in code turns the drawn system into a specification for the coding agent, which may be Lucid Train's own engine or Claude Code, Codex, Cursor or OpenCode. It runs as an stdio MCP server, so an agent you already use can call it for a diagram with a solved layout. Models are yours: local through Ollama, your own API keys, or any OpenAI-compatible endpoint.
What each group is actually for
| Group | Deliverable | Layout | Feeds an agent |
|---|---|---|---|
| Text notation (Mermaid, PlantUML) | A diagram in version control | Renderer dependent | No |
| AI whiteboard (Lucidchart, Miro, Excalidraw) | Shared understanding | Manual | No |
| Repository visualiser | A map of what exists | Usually automatic | No |
| Design-first agent (Lucid Train) | A code change built to an agreed design | Constraint solver | Yes |
Questions
Related
- What Is a Systems-Design-First Coding Agent?The architecture is the input, not the write-up.
- From System Design to CodeWhat has to be true for a drawing to become a build.
- Architecture-Aware Coding AgentsUnderstanding a system is not the same as reading a file.
- AI Software Architecture ToolsThree jobs, three very different reliabilities.