How Lega's Editor is Built: Architecture Overview

Most design tools were built for a world where a human clicks every element into place. Lega was built for a world where an AI generates the first draft and a human refines it — and that difference shows up all the way down in how the editor itself is architected. This page is a conceptual, non-proprietary tour of the ideas behind it, for anyone curious how a canvas editor holds together when generation, not just manual editing, is a first-class operation.

Why architecture matters here

Bolting AI generation onto a traditional design tool usually means treating the AI's output as a special case — a flattened image, a locked group, something the "real" editor doesn't fully understand. That approach caps what AI-first design can do: the generated result is a guess you either accept wholesale or throw away.

Lega takes a different starting point. Every layer the AI produces — text, shapes, images, decorative elements — is exactly the same kind of object the editor would create if you drew it by hand. There's no separate "AI layer" type with reduced capabilities. That single decision is what makes the rest of the editor's design fall into place.

The command pattern

At the core of Lega's editor is a command-based state model: every change to a document, whether it comes from a mouse drag, a keyboard shortcut, or an AI generation call, is expressed as a discrete command applied to editor state. Commands are the only way state changes — there's no back-channel mutation.

This has a few practical consequences:

• Undo/redo is universal. Because AI generation produces commands like everything else, generating a layout, then undoing it, then redoing it, behaves identically to any manual edit. Users never end up in a state the history stack doesn't understand.
• State stays consistent. A command either fully applies or it doesn't; there's no partial-apply state where half a generated layout is on the canvas and half failed validation.
• Testability. Because commands are data, not imperative code paths, editor behavior can be tested by asserting on the sequence of commands a given interaction produces, rather than by simulating pixels on a canvas.

The command pattern is also what makes AI regeneration of a single element possible without disturbing the rest of a composition — a regeneration is just a command scoped to one layer, not a full re-render of the document.

Plugin composition

The editor itself doesn't hard-code features like keyboard shortcuts, alignment guides, or history tracking into a monolithic core. Instead, capabilities are composed as plugins that register behavior against the same command bus. This is a pattern with roots in extensible editor frameworks built around a small core and a wide plugin surface, rather than a single do-everything class.

Practically, this means:

• The canvas core stays small and easy to reason about — it doesn't need to know about smart guides, multi-select, or export logic.
• Features can be added, removed, or swapped without touching unrelated code — the AI-authored layers don't need special-cased handling in the selection plugin, the alignment plugin, or the export plugin, because they're indistinguishable from any other layer once committed.
• New surface area — a new layer type, a new panel, a new interaction mode — has a defined seam to plug into rather than requiring changes scattered across the codebase.

For a closer, more technical look at how this plugin system is structured, see How Legon's Plugin Architecture Works.

The dual renderer

Lega's canvas compiles every document into one internal scene representation, which can then be drawn by either of two rendering backends: a Canvas2D-based renderer for the live editing view, or an SVG-based renderer used as a fallback path. Both backends draw from the same compiled scene — there's a single source of truth for what a document looks like, and the renderer is just how that truth gets painted to pixels.

This matters for a few reasons that go beyond internal engineering tidiness:

• What you see is what you export. Because export and thumbnail generation render through the same compiled-scene pipeline as the live view, there's no drift between what's on screen and what comes out the other end.
• Resilience. If one rendering path has an issue in a particular environment, the other is available as a fallback without the document format itself needing to change.
• A stable target for AI generation. Because the AI only ever needs to produce layers in the scene format — not pixels, not backend-specific drawing instructions — adding or changing a rendering backend doesn't touch the AI generation pipeline at all.

Why this adds up to "AI-native"

None of these three ideas — commands, plugins, dual rendering — are unique to AI-first tools on their own. What makes them add up to something AI-native is that together they mean AI generation is not a special mode. Generated content flows through the same command bus, gets rendered by the same compiled scene, and is manipulable by the same plugins as anything drawn by hand. The AI isn't a feature bolted onto an editor designed for manual work; it's a peer producer of ordinary editor state.

That's also why regeneration, partial refinement, and manual editing can be freely mixed in one session without the document ever entering an inconsistent state — they're all just commands against the same document, saved in the same design document format.

If you want the deeper technical rationale behind the plugin system specifically, or how Lega's AI adapters plug into this architecture, see How Legon's Plugin Architecture Works and How Lega's AI Adapter System Works. For the editor's day-to-day feature surface rather than its internals, start with the Legon Editor Overview.