System design

What is a systems-design-first coding agent?

The architecture is the input, not the write-up.

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

A systems-design-first coding agent treats system architecture as an input to implementation rather than documentation produced afterwards. The order is inverted: the architecture is drawn and agreed first, then handed to the agent as the specification it builds against, and revised when the running system disagrees with it. Lucid Train implements this literally, with an Implement in code action that turns the drawn system into a written spec for the coding agent.

The ordering that defines it

Most AI coding tools are code-first: you describe a change, the agent edits files, and a diagram, if one appears at all, is generated afterwards to describe what was already built. A design-first agent inverts that. The system is drawn and argued over while it is still cheap to change, and only then does implementation begin against it. The practical test of whether a tool belongs in this category is simple: can the diagram cause code, or can code only cause the diagram? If the arrow runs one way, the tool is a documentation generator with an agent attached.

Why a picture is a better argument than a paragraph

A written plan hides its own gaps. A drawn system does not: a missing queue between two services is visible, an unbounded fan-out is visible, and a datastore with four writers and no owner is visible at a glance. That is why architecture review happens on whiteboards rather than in prose. Moving the same artefact in front of the agent means the disagreement happens before the code exists, which is the only point at which changing the design is nearly free.

What has to be true for the handoff to work

Two things, and they are both mechanical. The diagram has to be a model rather than a drawing, so the components, the edges between them and the file each one maps to are structured data the agent can read, not shapes on a canvas. And the layout has to be solved rather than authored, so a regenerated diagram is comparable to the previous one. Lucid Train's agent emits a semantic graph of nodes, tiers and edges, and the ELK constraint solver decides every coordinate, which is what makes two runs of the same system produce the same picture.

The loop after the first build

Design-first is not a one-way waterfall, and a tool that treats it as one is worse than useless on a codebase older than a week. The useful version is a loop: the design produces code, the code runs, the runtime disagrees with the design somewhere, and the design is updated to match reality. Lucid Train keeps the return path open by drawing architecture from an existing repository, so the current picture is derived from what is on disk rather than from what someone drew last quarter.

Where Lucid Train sits

The Diagram tab draws a repository's architecture with the agent supplying structure and the solver supplying position. Implement in code turns that drawn system into a specification and hands it to the coding agent, which can be Lucid Train's own or Claude Code, Codex, Cursor or OpenCode running as the execution engine. Project knowledge persists in .lucid/knowledge.md and .lucid/CHANGELOG.md so the next session starts informed. Sub-agents execute in isolated git worktrees with the diff applied back, so a large design change can be built in parallel without four agents writing over each other.

Where the architecture sits in each approach

Code-first agentDiagram toolDesign-first agent
Architecture isA by-productThe deliverableAn input
Diagram producedAfter the code, if at allBy handBefore and after the code
Layout decided byNot applicableThe person dragging shapesA constraint solver
Can the diagram cause codeNoNoYes
Survives a refactorRegenerated or staleStaleRedrawn from the repository
FAQ

Questions

What is a systems-design-first coding agent?

A coding agent that takes the system architecture as its input specification rather than emitting a diagram after the code is written. The defining test is whether the diagram can cause code, not just describe it.

How is that different from asking an AI to draw an architecture diagram?

A diagram generator produces a picture. A design-first agent produces a picture that is also a structured model, then builds against it. The picture is a checkpoint in the workflow rather than the output of it.

Does it replace writing code by hand?

No. It changes what the agent is briefed with. The code still gets reviewed, tested and corrected in the usual way, and the design step mainly moves arguments earlier, to the point where they are cheap.

Does the diagram go stale?

It does if it is drawn once and stored. Lucid Train draws the architecture from the repository on request, so the current picture comes from the code that exists rather than from a file somebody last edited months ago.

Related