The interesting part of generating a diagram is not drawing the boxes. It is deciding what to trust before those boxes become application state.
I built architecture generation in Codelit so an engineer can move from a rough description to something they can inspect, edit, and question. Architecture is an app inside the Thread workspace, alongside product planning and agent work.
From a request to an editable graph
The pipeline has four responsibilities: interpret the request, produce a candidate graph, arrange it, and render it.
| Stage | What it contributes | What still needs checking |
|---|---|---|
| Prompt and context | Requirements, existing diagram, constraints | Missing or contradictory requirements |
| Structured output | Nodes, edges, labels, groups | Schema, references, unsupported fields |
| Layout | Positions and spacing | Overlap, hierarchy, readability |
| Canvas | Inspection and manual editing | Architectural correctness |
JSON mode is not a correctness guarantee. A response can be truncated, refused, malformed, or valid JSON that violates the application's schema. The application needs to handle each outcome without destroying the previous diagram.
The generation article follows that boundary in more detail.
Preserve the engineer's control
The first diagram is a starting point. A follow-up can ask for a cache, a different data store, or an asynchronous path. The useful interaction is the ability to inspect that change and adjust it, rather than accepting another opaque image.
Specific requirements help:
- Name the workflow, not just the product category.
- State the expected load as an assumption.
- Include recovery, data, and operational constraints.
- Identify the parts of an existing design that must stay unchanged.
“Add monitoring” can produce monitoring components. It cannot make the system production-ready.
Keep the renderer independent
React Flow provides the editable surface; layout and provider handling have their own responsibilities. This separation makes it possible to improve the canvas or change provider routing without treating either as the architecture's source of truth.
A provider response is a candidate. The diagram the user has accepted and edited is product state.
What the result proves
A generated architecture proves that a model and renderer produced an inspectable proposal. It does not prove capacity, security, cost, or deployed behavior.
Those questions need evidence beyond the diagram: load tests, configuration review, actual prices, and runtime checks. The architecture review can help form a checklist, but it cannot supply measurements that were never taken.
That is the product decision behind the feature: make the design easier to inspect before making it easier to deploy.