While AI can quickly generate functional React components, fine-tuning layout details and validating dynamic business data directly in raw code creates friction during product iteration. Pairing generated code with an interactive canvas allows teams to inspect and refine interfaces in context. In this post, we share our architectural lessons on bridging the two: using provenance tracking to trace rendered UI back to originating source expressions, instance scoping to apply visual adjustments without corrupting shared component definitions, and version reconciliation to preserve layout changes across iterative updates and concurrent edits.
When engineering teams integrate coding agents into business applications, they often hit a hard architectural wall: bridging the gap between AI-generated code and human-driven visual editing.
Business users expect to generate personalized brand storefronts using AI, but they also demand the ability to visually tweak text, adjust spacing, or swap images directly on a canvas—without writing code or continuing to prompt the model. Furthermore, the generated interfaces cannot be static artifacts. A product catalog must maintain live references to inventory and pricing services so that when a backend price changes, the UI reflects it without requiring a code recompilation or redeployment.
This creates a tension. Traditional visual builders rely on fixed schemas and constrained component libraries, which provide a reliable editing interface but artificially limit the coding agent’s creative range. Conversely, letting a model write unrestricted React/TypeScript gives it the necessary expressive freedom, but natively lacks the strict mappings required for a WYSIWYG editor.
This article examines the engineering mechanisms required to let models write standard React, while deriving the necessary indexes to support visual editing, dynamic data binding, and safe concurrency between agents and human operators.
Initially, teams often attempt to bridge this gap by forcing the LLM to output a strict UI schema (like a JSON configuration) or by requiring the model to annotate its React output with specific editing markers and fixed directories.
These approaches rapidly degrade. Brand layouts and interactions constantly push the boundaries of predetermined component schemas, leading to a sprawling, unmaintainable configuration protocol. When forcing models to inject proprietary tracking tokens or write restricted subsets of React, the model spends excessive compute adhering to (or failing at) the editing protocol rather than solving the UI problem. Validators, prompts, and write-back logic all require synchronized maintenance.
The breakthrough comes from shifting the burden. Instead of forcing the model to write "editable code," the model writes standard React/TypeScript. The platform then relies on compiler instrumentation and runtime derivation to build an Edit Index. The source code, page references, and instance overrides constitute the versioned project state; there is no secondary "page tree" to keep in sync.
For a deeper look into the systemic pressures driving this choice, see Connecting Coding Agents to Business Software: Architectural Lessons.
To make plain code editable on a canvas, the system must map a clicked DOM element back to the exact source location that owns its value. We achieve this through Abstract Syntax Tree (AST) parsing combined with TypeScript symbol resolution.
Consider a simple shared component and two independent call sites:
// Component definition
function Note({ title }: { title: string }) {
return <h2>{title}</h2>;
}
// Page layout
export default function Page() {
return (
<div>
<Note title="Standard Delivery"/>
<Note title="Designed for small spaces"/>
</div>
);
}If a user clicks "Designed for small spaces" on the canvas and changes it to "Compact Design," the editor cannot simply execute a global string replacement—that would be brittle and error-prone. It also cannot modify the Note component's internal structure, as that would affect all instances.
Instead, the system utilizes Value Provenance. By statically tracing the lexical symbols and parameter passing relationships, the compiler identifies the title prop and all candidate call sites. However, static analysis alone cannot know which rendered instance was clicked. It is the runtime instance information, combined with the static provenance index, that maps the click back to the second <Note> invocation. The edit command then directly patches that specific AST node. Variables sharing a name do not imply they share a source; provenance tracks the explicit declaration references.
Static inference alone cannot resolve all value sources, particularly when branching logic or external business data is involved.
const displayTitle = product.title ?? fallbackTitle;
return <h1>{displayTitle}</h1>;In this scenario, static analysis can identify product.title and fallbackTitle as candidate sources. However, to know which source is actively rendered on the canvas, the system relies on Compiler Instrumentation.
During the compilation of the preview environment, the build tool injects DOM selections, call paths, and collection memberships. It acts as a runtime observer. It does not re-evaluate the expression (which could trigger side effects like network requests or state mutations). Instead, it observes the executed path and checks the object identity and property descriptors against the static candidate list. The client selection must always be verified against the current server-side Edit Index to ensure a valid write target.
Mapping independent call sites is straightforward, but dynamically mapped collections introduce a distinct challenge:
{items.map(product => (
<Card item={product} key={product.id} />
))}Here, the component definition, the items.map call site, the collection member, and the resulting DOM instances all possess different identities. A React key helps coordinate DOM updates, but it does not provide a durable address for a visual edit. Furthermore, the product.id alone is insufficient if the same product appears in multiple sections of the page (e.g., "Cart" vs. "Recommended").
If a user visually changes the background color of the third card to purple, modifying the <Card> component directly would make all cards purple. Patching the shared items.map call site is syntactically valid, but an unconditional shared-prop change affects every member and does not express a single-member edit. To retain a specific instance difference, one supported method is an Instance Override. The system records a targeted override (e.g., backgroundColor: 'purple') tied to the validated component call path and member identity. This override is saved as part of the versioned project state—acting as a patch applied during rendering. It persists a resolvable instance target, field, and scope (such as mobile vs. desktop device scopes), allowing the preview compiler and the final published build to apply the same override semantics without duplicating code.
A critical requirement of these systems is distinguishing between UI changes (Project State) and business data changes (Business State).
If a user interacts with a product price on the visual canvas:
Because the React code retains dynamic bindings (e.g., fetching by product ID rather than statically embedding the price string), a background process modifying the price in the database will organically update the published site based on its caching and revalidation strategies. No code generation or project deployment is required for data updates. Furthermore, undoing a layout edit in the project repository will safely revert the CSS, but it will not roll back the subsequent backend price change.
For more on cleanly separating these domains, refer to Why We Model Business Agents Like Coding Agents.
Visual editors and autonomous coding agents operate concurrently. A human might be tweaking a layout on the canvas while an agent refactors the component structure in the background.
Consider a canvas command generated from user interaction containing the payload: { expectedRevision, selectionId, field, operation, scope, value }. If the canvas is operating on Revision 1 (r1), but an agent has already committed Revision 2 (r2), a command from r1 cannot blindly resolve against the r2 index. The system first performs early validation of the project revision, selection identity, and index state to verify permissions and source values. Then, it utilizes an atomic CAS (Compare-And-Swap) operation. Before committing the generated patch, it checks that the project's HEAD is still at r1, detecting any concurrent commits that occurred during patch preparation. If the check passes, the patch commits atomically. It is important to note this governs versioned project state, distinct from any business-record versions or transactions.
When the agent successfully commits r2 (perhaps wrapping the product list in a new <div>), what happens to the Instance Overrides defined in r1?
The system uses Identity Reconciliation to map instances across versions. Reconciliations only carry over if the structural identity logically persists.
In cases where structural identity is lost, or if the underlying base value source changes dramatically, the override stops applying and the system leaves a diagnostic trace for the developer. A valid React tree does not guarantee every visual element remains safely backwards-editable. When code becomes too complex for reliable bidirectional resolution, the platform gracefully degrades by providing explicit configuration fallbacks and raw code access.
Making AI-generated code visually editable requires moving away from strict, brittle UI schemas and embracing standard React architectures. By combining static AST inference with runtime observation, engineers can track Value Provenance to precise write targets. Managing dynamic lists via Instance Overrides, enforcing strict boundaries between project code and business data, and implementing CAS with Identity Reconciliation allows human operators and autonomous agents to safely co-create production software.
To discuss architectural patterns, contribute to open discussions, or view referenced conceptual demos, visit Agent Editable UI—which provides MIT design documents and a static TSX/synthetic-data walkthrough, not a runnable editor, compiler or preview runtime—or reach out to our engineering team via Issues, Discussions, or contact@novariseintl.com.
Exploring how coding agents operate within business software. While agents reason about workflows and use code to compose tasks, the host platform manages data permissions, durable project state, gated writes, and continuous human editing.
For bounded actions, standard tool calling works well. But for multi-step e-commerce workflows, code execution provides a cleaner path for composition. We share our architecture evolution across sandboxing, authorized views, immutable snapshots, watermarks, and approval gates.
An engineering look at how platform architecture, domain contracts, and context lifecycle management enable AI agents to build complete, cross-domain business workflows.