Convert

Convert code into an architecture diagram.

The general case: point it at code and get a diagram of what is there rather than what you remember building.

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
Multi-tenant SaaS architecture. 12 components across 5 tiers.
Multi-tenant SaaS architecture. Produced by the app's layout engine from a semantic graph, not placed by hand.

What conversion means here

There is no mechanical mapping from code to architecture, because architecture is a set of judgements about which distinctions matter. What happens instead is a survey: manifests and deployment files establish what the project claims to be, entry points and the import graph establish what it actually connects to, and the result is a proposed set of components and edges. That is a reading rather than a translation, which is why the output is a first draft you correct rather than a build artifact.

Why the layout is not part of the guesswork

The model decides what the components are; it never decides where they go. The graph it emits has no coordinates, and ELK computes positions and orthogonal routing from it. That split is what makes the output usable: the part a language model is bad at, spatial arrangement, is handled by a solver that cannot produce overlaps.

Correcting it is editing the graph

The first draft will include something incidental or miss a relationship that lives in configuration rather than code. Removing a node or adding an edge re-solves the whole layout, so corrections cost nothing in alignment. That is the practical difference from a tool where your manual edits and the generator's next output fight each other.

What survives the conversion

Comes throughDoes not
ComponentsServices, modules, packages with an entry pointRuntime-assembled components
EdgesImports, client instantiation, configured addressesCalls resolved dynamically
Data storesDrivers and connection configurationStores reached through an abstraction only
External servicesSDK imports and configured endpointsAnything called by URL built at runtime
ResponsibilitiesInferred from names and structureIntent that is not written down
InfrastructureWhat is in compose or manifestsAnything created in a console

The command

shell
$ cd your-repo
$ lucid
# then: Diagram the architecture of this repository
FAQ

Questions

How accurate is code-to-diagram conversion?

Good on structure that is expressed in the code, weak on anything assembled at runtime or configured elsewhere. Treat the first draft as roughly the quality of what a strong engineer would produce after an hour of reading, which is genuinely useful and not authoritative.

Does it upload my code?

Not with a local model. Running against Ollama it is entirely on your machine. With a hosted model, file contents go to that provider under your own key.

Which languages work?

It reads and reasons about files rather than using per-language parsers, so it works across languages and on polyglot repositories, with the caveat that it has no compiler-level certainty about the import graph.

Related