System design

A coding agent that draws diagrams.

One model of the codebase, used twice.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

Putting diagramming inside the coding agent removes a translation step: the same repository model that answers questions about the code also draws it, so the picture and the agent cannot hold different beliefs about what exists. Lucid Train draws from its own repository map and can also run as an stdio MCP server, which lets Claude Code, Codex or Cursor request a diagram with a solved layout without changing editor.

Two tools, two beliefs

When the diagram lives in a separate product, something has to carry the architecture across, usually a person. That is where drift begins: the agent works from the code, the diagram works from whatever was drawn last, and the two describe different systems while both look current. Nobody notices until a change is planned against the picture and lands somewhere else.

Sharing the map

Inside one agent, the structural map built for retrieval is the same map the drawing comes from. Ask which services call the gateway and ask for a picture of them and the two answers come from one source. That does not make the map correct, but it does mean a mistake in it is visible in the drawing rather than hidden behind a second tool's version of events.

Why layout has to be solved

A drawn diagram that regenerates with shuffled boxes is unusable for comparison, and comparison is most of the value. Lucid Train has the agent supply structure only, nodes, tiers and edges, and gives every coordinate to the ELK solver. Two runs over the same system produce the same picture, so a difference between them is a real change rather than a different drag order.

Keeping the agent you already use

Switching editors to get a diagram is a bad trade, and it is not required. Lucid Train runs as an stdio MCP server, so Claude Code, Codex, Cursor and other MCP clients can ask it for an architecture diagram and receive one with the layout already solved. The same binary can also run those tools as its own execution engine, which means the choice is not exclusive in either direction.

What the diagram is for afterwards

A picture that only gets looked at is a documentation feature. The reason to have it inside the agent is that it becomes an input: Implement in code turns the drawn system into a specification and hands it back to the coding agent as the brief for the change. That round trip, code to picture to specification to code, is what the second tool cannot do.

FAQ

Questions

Which AI coding agent can draw architecture diagrams?

Lucid Train draws them from the repository as a first-class feature and can hand the result back to the coding agent as a specification. It also runs as an stdio MCP server so Claude Code, Codex or Cursor can request one.

Can I keep using Claude Code or Cursor?

Yes, in either direction. They can call Lucid Train over stdio MCP for a diagram, and Lucid Train can run them as its execution engine with their native permission models mapped onto one set of approval modes.

Why does layout matter so much?

Because most of the value is in comparing two versions. If regenerating shuffles the boxes, every regeneration looks like a change and real changes stop standing out. A constraint solver makes the same system draw the same way.

Related