System design

AI software architecture tools.

Three jobs, three very different reliabilities.

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

AI is useful on software architecture in three distinct jobs: drawing the system that already exists, proposing a system that does not yet exist, and reviewing a design against known failure modes. The first is the most reliable because it can be checked against the repository. The third is genuinely useful and the least trusted. Lucid Train covers drawing and review, and treats a proposed architecture as a draft to argue with.

Drawing what exists

This is the job with a right answer. The architecture of a repository is determined by the code, so the output can be verified: every component cites a file, and a component citing a path that is not there is wrong in a way anyone can see. It is also the job teams need most often, because the system nobody can draw is usually the one nobody wants to change.

Proposing what does not exist

Here there is no right answer, only tradeoffs against constraints the model cannot see. A proposal that adds a queue may be exactly correct or may add a component nobody will operate. The output is worth having as a starting point and dangerous as a decision, and the useful framing is a first draft from a well-read colleague who has never met your on-call rotation.

Reviewing a design

Between the two sits review: given this architecture, what fails first? Models are reasonably good at naming the classic failure modes, a single point of failure, an unbounded queue, a retry storm, a hot path with no tests, because those patterns are extensively documented. Treat the output as a checklist to work through rather than a verdict, and expect roughly the hit rate of a thorough but unfamiliar reviewer.

Keeping the picture honest

Whatever the job, an architecture diagram earns trust by being checkable and loses it by being decorative. Two properties do most of that work. Every component maps to a real path, so a claim can be verified. And layout is computed by a solver rather than dragged, so the same system drawn twice looks the same and a genuine change stands out instead of being lost in shuffled boxes.

What Lucid Train covers

The Diagram tab draws a repository's real architecture with each node citing a path. The Audit tab reviews code against a rule set. Dashboards connects to Grafana so a design can be compared against what production is actually doing, which is the only feedback that settles an argument about a bottleneck. Connectors accepts stdio MCP servers, so an agent can reach the systems you already run.

FAQ

Questions

Can AI create a software architecture diagram?

Yes, and it is most reliable when drawing a system that already exists, because the result can be checked against the code. A proposed architecture for a system that does not exist yet is a draft rather than an answer.

Is an AI-generated architecture trustworthy?

Trust the parts that cite something. A component naming a real file is checkable in seconds. A recommendation about scaling rests on constraints the model cannot see, so it needs your judgement.

Can it review an architecture for problems?

It names the well-documented failure modes reliably enough to be a useful checklist: single points of failure, unbounded queues, retry storms, hot paths without tests. It is a prompt for a review, not a substitute for one.

Related