AST Engine Architecture & Specs
A monumental code generation engine featuring strict `LanguageGenerator` interfaces, `@xyflow/react` graph traversal, and zero-runtime interpretation.
Compilation & Performance Metrics
Interpretation Overhead
0ms (Compiles to Native Targets)
Graph Traversal Time
<2ms for 500+ node graphs
Supported Targets
31 Supported Languages & Formats
AST Node Definitions
150+ Semantic Primitives
1. The Core Compilation Loop
The magic of the Aeion OS AST architecture is its perfect separation of visual interface from execution logic.
- The Graph Traverser: The base ASTCompiler class handles the complex topological sorting of the visual graph. It maps inputs to outputs securely, memoizes every node's compiled output, and constructs an Abstract Syntax Tree.
- The `LanguageGenerator` Interface: Instead of hardcoding execution logic, the ASTCompiler accepts an injected LanguageGenerator instance. When compiling, it hands each node to the generator's generateNode(node, resolveInput) method, allowing the generator to output the exact semantic syntax required for its target environment (e.g., C, Python, TSX, GLSL).
2. Unprecedented Extensibility (The Meta-Compiler)
Aeion OS is designed to expand its own capabilities over time.
- Deterministic by Design: Because every generator (from the G-Code generator producing CNC instructions to the Infrastructure-as-Code generator producing Terraform) implements the same strict LanguageGenerator contract, output is always a fixed, traceable translation of the visual graph — never free-form or improvised — which is what makes it safe to hand these targets to non-specialist authors in the first place.
- The Meta-Compiler: The AST engine includes a generator that produces new generators. A developer describes a target language's grammar visually, and the meta-compiler emits a ready-to-register generator implementation — letting teams extend the platform to entirely new output languages without waiting on a platform release.
3. Why Compile Instead of Interpret
Most "no-code" tools interpret a visual graph at runtime through a heavy VM. The AST engine rejects interpretation and emits native source in the target language instead, and that single design choice has consequences worth stating precisely:
- Performance: A compiled artifact runs at the target language's natural speed — a generated React component renders as fast as hand-written TSX, a generated WGSL shader runs directly on the GPU. There is no interpreter layer to pay for on every render or every tick.
- Debuggability: The output is readable source, not opaque bytecode. A senior engineer can open the generated TypeScript, GLSL, C, or G-Code and review it exactly like hand-written code — when something misbehaves, you debug the logic, not a black-box runtime.
- Portability & no lock-in: Compiled output runs anywhere the target language runs. The G-Code streams to any RS-274-compatible CNC, the OpenQASM runs on any standards-compliant quantum backend, and a team that later migrates keeps the compiled source — the IP is the code, not a proprietary runtime.
- Versionability: Because every generator emits plain text, output is diffable and reviewable. A workflow change can flow through the same git review as any other code, and the visual AST itself is tracked with diff and rollback.
The pitch is compile-once, target-anywhere — the visual canvas is the authoring surface, but what ships is ordinary, portable code.
Frequently Asked Questions
Each generator implements the `LanguageGenerator` contract. The `ASTCompiler` topologically sorts the graph, memoizes each node's output, and hands every node to the generator's `generateNode(node, resolveInput)` method; `resolveInput` returns the already-compiled outputs of upstream nodes. The generator emits the exact target-language syntax for that node, and `finalize(chunks)` assembles the final executable payload.
Implement the `LanguageGenerator` interface for your target, then register it — the visual canvas immediately surfaces it alongside the built-in generators. You do not fork the engine; the base `ASTCompiler` handles graph traversal and memoization, so a new target is one contract implementation, not a new compiler.
Instead of prompting a model to emit raw React or Python — which invites syntax errors and hallucinated APIs — Aeion prompts the LLM to output a strict JSON array of AST nodes and edges. The deterministic compiler then translates that graph into executable code, so the model contributes structure while the compiler guarantees the syntax.
Yes. Because every generator implements the same strict contract, the output is a fixed, traceable translation of the visual graph — never free-form or improvised. The same graph compiles to the same code every time, which is what makes it safe to hand these targets to non-specialist authors.
Yes — a compiler block registers natively inside the rich-text TipTap editor. Typing `/shader` or `/xdp` in a document mounts a visual node canvas inline; the resulting compiled code embeds directly in the paragraph, turning static documentation into executable, interactive components.